What Is a Requirement?

We define a requirement as a condition or capability to which a system must conform.

In his efforts to establish quality criteria as a basis for measurement for evaluating software systems, Robert Grady, during his tenure at Hewlett-Packard, categorized the necessary quality attributes of a software system as functionality, usability, reliability, performance, and supportability, referred to as "FURPS." ^[1] We have found this acronym to be a useful reminder of the types of requirements we need to consider to fully define a quality system.

^[1] Robert Grady, Practical Software Metrics for Project Management and Process Improvement . Englewood Cliffs, NJ: Prentice-Hall, 1992, p. 32.

Functional Requirements

When we think about the requirements of a system, we naturally tend to think first about those things that the system does on behalf of the user . After all, we developers like to think that we have a "bias for action," and we expect no less of the systems we build. We express these actions as functional, or behavioral, requirements, which specify the actions that a system must be able to perform.

Functional requirements are used to express the behavior of a system by specifying both the input and output conditions that are expected to result.

Nonfunctional Requirements

In order to deliver the desired quality to the end user, a system must also exhibit a wide variety of attributes that are not described specifically by the system's functional requirements. For the system to exhibit these quality attributes, an additional set of requirements must be imposed. We refer to this set of requirements as nonfunctional requirements. Ultimately, they are every bit as important to the end-user community as are the functional requirements.

Using the FURPS categories, the following list summarizes considerations for defining the nonfunctional quality attributes of a system:

• Usability

  Usability requirements address human factors ”aesthetics, ease of learning, and ease of use ”and consistency in the user interface, user documentation, and training materials.

• Reliability

  Reliability requirements address frequency and severity of failure, recoverability, predictability, and accuracy.

• Performance

  Performance requirements impose conditions on functional requirements ”for example, a requirement that specifies the transaction rate, speed, availability, accuracy, response time, recovery time, or memory usage with which a given action must be performed.

• Supportability

  Supportability requirements address testability, maintainability, and the other qualities required to keep the system up-to-date after its release. Supportability requirements are unique in that they are not necessarily imposed on the system itself but instead often refer to the process used to create the system or various artifacts of the system development process. An example is the use of a specific C++ coding standard.

Frankly, it's not particularly important to divide requirements into these categories, and there is little value in a debate about whether a specific requirement is a usability or a supportability requirement. The value in these definitions is that they provide a template, or checklist, for requirements elicitation and for assessing the completeness of your understanding. In other words, if you ask about and come to understand requirements of all these categories, you will have a high degree of certainty that you have truly understood the critical requirements before you begin substantial investment in development. Often you will find, for example, that certain reliability requirements are implied by given functional requirements, and it is equally important to explore these reliability requirements. A system that fails to meet an implied reliability or performance requirement fails just as badly as a system that fails to meet an explicit functional need.