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.
Functional RequirementsWhen 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 RequirementsIn 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:
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. |