A Resource-Constraint is a Resource-Requirement, which specifically restricts, or serves as a warning about, the Level that can be used of a Resource.
A Resource-Constraint is specified as a Scalar Resource Attribute Level. It signals the Level at which some degree of System failure will
be experienced or, the Level at which the entire System becomes threatened.
Two main Parameters can be used to specify these Constraint Levels: Tolerable (Tolerable and worse might be recoverable) and Survival
(worse is unrecoverable).
Scale: Gigabytes of defined [Memory Component].
=== Targets ========
Wish [Memory Component = Online Backup]: 1,000 GB <- Design Team.
Rationale: Improves Recovery Speed.
Stretch [Memory Component = Online Storage, US Market]: 500 GB? <- Marketing.
Budget [Memory Component = Primary]: 100 GB <- Initial Software Size Estimates.
=== Constraints ===========
Tolerable [Memory Component = Online Storage, US Market]: 250 GB Or Less? <- Marketing.
Rationale: Large Scale Users must have this Level <- US Sales.
Survival [Memory Component = Online Storage, US Market]: 100 GB? <- Marketing.
Rationale: Nobody would even consider our System with less <- US Sales
1. Resource-Constraints are imposed or suggested by defined Stakeholders. These Stakeholders and their reasons should be explicitly Documented with the Constraint Level, for example, by using Authority, Source, Rationale, or Stakeholder Parameters.
2. Resource-Constraint Levels (Fail, Survival) tend to be much worse than the Stakeholder-valued Resource-Targets (Budget, Stretch, Wish).
3. The Tolerable and Survival Concepts are adequate for most Scalar-Constraint purposes. However, Tolerable is also available for use. It is a matter of taste.
-- --[ -- -- --]----->O “Upper and lower survival Constraint limits.”
-- -- -! --->O
Constraint *218 Performance-Constraint *438 Resource-Target *436 Fail *098 Survival *440 Tolerable *602 Range *552 Failure-Range Intolerable-Range
This Concept entered by Lisa.