The functional requirements for a new system specify what the proposed system will do. A constraint specifies how the system must operate or how it must be built.
Some fad methodologies use the clumsy and misleading term non-functional requirement instead of constraint, presumably in order to persuade the systems analyst to specify constraints along with the functional requirements. That's wrong. Most constraints should be specified well after the functional requirements have been specified, reviewed, and approved.
Constraints fall into these broad categories:
Inexperienced end users may naïvely expect perfection in the operation of their new system. Every instance of outage or incorrect result then counts as a black mark against the system, and after some number of black marks are accumulated the system is judged a failure. The users may then strongly express dissatisfaction against the developers.
This all-too-common scenario is easily avoided by making sure that the sponsoring users have realistic expectations when they approve the project. Here are some of the specifics:
|Undetected failure||Of course, all system failures are detected eventually. We need to tell the sponsoring users the frequency and probability of an error that isn't detected until after some action has been taken that's costly, embarrassing, or impossible to correct, such as mailing customer bills or administering medication. For some "critical" applications the sponsoring users will insist that such failures must never occur, and they'll be willing to pay extra for the necessary fail-safe procedures.|
Here again we need to make sure the sponsoring users have realistic expectations. We don't want to hear complaints after the system is delivered about sluggish response time or databases overflowing disk space. Here are some of the measures:
|Online transaction processing:||
Note that performance constraints can be tested, while reliability constraints1 can only be analyzed and estimated.
Here the analyst should avoid specifying constraints that unreasonably limit the developers' options. In many cases, especially in large organizations, the organization's standards will apply unless the project obtains permission to deviate.
Nevertheless, if some unusual situation requires, the analyst may specify aspects of the operational environment:
Return to Requirements Guidelines
IDI home page
Last modified 16 March 2009