A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements, such as limited development resources or a decision by senior management that restricts the way you develop a system. Constraints can be economic, political, technical, or environmental and pertain to your team resources, schedule, target environment, or to the system itself. Figure 1 presents several potential constraints for the university system. Constraints are documented in a similar manner to business rules and technical requirements.Figure 1. Constraints (summary form).
C24 The system will work on our existing technical infrastructure – no new technologies will be introduced.
C56 The system will only use the data contained in the existing corporate database.
C73 The system shall be available 99.99% of the time for any 24-hour period.
C76 All master’s degree programs must include the development of a thesis.
An interesting thing about Figure 1 is that it contains two constraints, C73 and C76, that could also be identified as a technical requirement and a business rule respectively. Constraints can be a little confusing because of their overlap with business rules and technical requirements. Don’t worry about it. The important thing is that you’ve identified the requirement, if you happen to mis-categorize it as a constraint instead of a business rule that’s perfectly okay, the world isn’t going to end as a result (unless of course you’re working on a nuclear missile guidance system). I wouldn’t identify the same requirement as both a business rule and a constraint, that would be busy work, but I wouldn’t waste any time arguing over whether something is a constraint or another type of requirement.
As with business rules, you identify constraints as you are developing other artifacts, such as your use case model and user interface.
