Constraint

Definition

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:

Type: Abstract
Superclass: Requirement
Subclasses:
- Architecture Constraint
- Design Constraint
- Implementation Constraint
- Physical Constraints
- Business Constraints:
  - Cost
  - Schedule
  - Staffing
- Business Rules:
  - Calculations
  - Logical Constraints
  - Logical Inferences
  - Physical Facts
  - Triggering Events
- System Component Specific Constraints:
- Industry Standards
- Legal and Regulatory Constraints
- Production Environment Constraints

The typical responsibilities of a constraint are to:

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.