Requirements and Constraints

A constraint is a statement of restriction that modifies a requirement or set of requirements by limiting the range of acceptable solutions. While this may initially be perceived as a drawback to the development of a project, constraints in many ways have a powerful way of helping projects work smoothly or reduce the risks of catastrophic failure. Constraints appear across all levels of the requirements hierarchy (business, functional, system, user).

Consider a system that is meant to be used internally by a company that gets built with functionality for users to access from external sources. A constraint - "System shall be used by employees of Company X" - elicited, documented and communicated could potentially save not just development time but also reduce risks. Developers, having been informed of such a constraint, will develop features that keep the scope of development to just the employees of Company X.

It is with such an example, that PMs and BAs must do well to capture early so as to prevent catastrophe and move forward successfully in projects.

Constraints are usually driven by at least three factors: business environment and rules, cost/time/quality balance, and environment such as OS platform, computer languages, product choice, deployment, etc. Constraints need to account for these factors, but BAs need to be careful of being too prescriptive of the solution, thus limiting options too early for the technical team. You should never assume what choices the technical team will make. Getting the balance right between enough information to estimate from while not being too prescriptive is one of the more difficult challenges of setting down requirements.

The rationale for a constraint is also important. While constraints are important to have in any project, one must keep in mind that too many constraints captured without proper rationale can ultimately stifle a project. This can limit meaningful solutions that can arise because of such restrictions on requirements.

Karl Wiegers points out that PMs and BAs must ask why each constraint exists, question its validity, and record the rationale for including such a constraint in a requirement. Test plans must also provide cases for ensuring systems comply with the constraints placed on their requirements. It is also recommended that User Interface options not be constrained at an early stage in the requirements analysis process. Functional Requirements however should be captured as early as possible to risk any re-development of a feature to accommodate the constraint

Got something to say?

Name (required)

Email Address (required)

Website

Speak your mind

[?]