Constraint
- Constraint
- any architectural, design, or implementation decision that legitimate stakeholders have determined is mandatory
and therefore has been selected to be treated as if it were a normal requirement
As illustrated in the preceding figure, Constraint is part of the following inheritance hierarchy:
The typical responsibilities of a constraint are to:
- Constrain the architecture, design, or implementation.
- Specify the constraint as a requirement.
The following guidelines have been found to be useful when producing constraints:
- Constraints have traditionally been referred to as design
constraints, but this term is too specific because many
constraints actually constrain the architecture or the implementation.
- Constraints should only be specified if really necessary.
Ordinarily, requirements engineers should avoid specifying
architecture, design, and implementation constraints.
- Constraints should include a rationale because they
restrict the choice of architects, designers, and programmers.
- There are numerous valid reasons for specifying constraints:
- A customer organization may want to standardize on a
given architecture across multiple applications in order to
minimize maintenance costs and errors, retraining costs, and operator error.
- The customer organization may already use certain
hardware components, programming languages, databases, etc.
