Constrained Resource Boundaries and System Design-Case Study

A constrained resource (such as a technician, piece of equipment, or facility) has a certain capacity per unit of time, such as an ability to handle 8 appointments per day or 5 assignments at a time. These capacity numbers convey a boundary condition "C" in your requirements that must be handled by your functional architecture. ((A lower boundary condition at 0 is often implied by these discussions.) Your functional architecture must be able to handle the range of values implied by that condition, including 0, 1, 2, C, C+1, C+n (for an arbitrarily large "n"), and your test plans must make sure that each implied variation of the functionality around that constraint is being managed effectively according to the overall requirements for your system.

Suppose the constrained resource also has an availability that must be managed with its capacity, and this will convey an additional boundary condition that must be managed. For example, if appointments for your constrained resource are scheduled, the expected duration of each appointment represents a boundary condition that must be managed in your functional architecture. Some sessions for these appointments might be completed early, and some late, causing exception pressure on your system to manage the constrained resource effectively. Sessions completed early create extra capacity that could go to waste if not handled in your functional architecture, and session that run late create conflict in downstream scheduled assignments that are impacted by the delay.

If "E" is the expected duration that convey a boundary condition, your range of functional values might include E-50%, E-25%, E, E+25%, E+50%, etc. The functional architecture must have functionality for dealing with these exceptions, so your test planning must be prepared to verify and validate all of the permutations that might arise. Special variation on this boundary condition includes being done 100% early (E-100%, analogous to the lower 0 boundary condition for capacity) because an appointment is cancelled at the last minute, or some critical other participant doesn't show up. We're not looking here at small variations that would be considered routine systemic variance, and larger variances might need to be stratified if the functionality would vary based on exactly how early or late would be considered significant.

Questions:

1. Identify and describe a constrained resource being managed by your system for both capacity "C" and availability "E". (All organismic systems will have at least one, by definition.)
2. Identify and discuss the two related boundary conditions and list the values of those conditions that are pertinent.
3. With respect to a generalized System, discuss the differences in functionality that are including in functional architecture to handle the range of expected or possible values around defined boundary conditions, and discuss when, where, and how you can include all of that functionality in a test plan.