Specifying Constraints
©Information Disciplines, Inc., Chicago
Conrad Weisert, 13 March 2009

What are constraints and when should we specify them?

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:

  1. Constraints on the end product.
    1. Reliability and availability constraints.
    2. Performance constraints.
    3. Environment constraints.
  2. Constraints on the development.
    1. Use of application software products.
    2. Use of tools and programming languages.

Specifying reliability and availability constraints

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:

Availability
  • Normal hours of operation (for an on-line system)
    or run frequency (for a batch system)
  • Maximum acceptable frequency of unscheduled unavailability by duration.
    for example: No more than three instances per month of 5-minute outage, and no more than 2 instances per year of more than half-hour outage.
Detected failure
  • Maximum acceptable frequency of interruption requiring re-entry of data
    for example: No more than one instance per year of failure requiring re-entry of two-hours worth of data.
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.

Specifying performance constraints

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:
  • average and maximum volume per unit time
  • maximum number of simultaneous users
  • maximum tolerable response time for each type of transaction or other user action.
Batch processing
  • Average and maximum data volumes for each type of run
  • Maximum elapsed time for each type of run
Data volume
  • Maximum number of each type of record (entity) to be stored permanently or temporarily

Note that performance constraints can be tested, while reliability constraints1 can only be analyzed and estimated.

Specifying environment and development constraints

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:

or aspects of the development work:
1—But backup and recovery procedures must be thoroughly tested.

Return to Requirements Guidelines
IDI home page

Last modified 16 March 2009