A Further Characterization of Requirements

The preceding discussions on requirements suggested that various "kinds" of requirements exist. Specifically, we have found it useful to think about three types of requirements, as shown in Figure 20-3:

• Functional software requirements

• Nonfunctional software requirements

• Design constraints

Figure 20-3. Types of requirements

Functional Software Requirements

As you might expect, functional requirements express how the system behaves ”its inputs, its outputs, and the functions it provides to its users. These requirements are usually system action-oriented . These are the types of requirements we have been capturing in the use cases for HOLIS.

Nonfunctional Software Requirements

However, functional requirements alone are insufficient to describe the requirements of a system completely. We must also consider other types of requirements. Grady [1992] called these types of requirements nonfunctional requirements and suggested that they arise because it is necessary to specify other aspects of the system, such as:

• Usability

• Reliability

• Performance

• Supportability

These requirements are used to express some of the "attributes of the system" or "attributes of the system environment" elements of our elaborated guidelines [Davis 1999].

Design Constraints

This last class of requirements may be the trickiest of all. Design constraints typically impose limits on the design of the systems.

We'll define constraints as

restrictions on the design of a system, or the process by which a system is developed by which a system is developed, that do not affect the external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations.

This convenient three-type classification helps us understand more about the system we are to build. We'll revisit each of these three types of requirements in Chapter 22, Developing the Supplementary Specification.