Looking Deeper into Software Requirements

In Chapter 2, quoting Dorfman and Thayer [1990], we provided the definition for a software requirement:

1. A software capability needed by the user to solve a problem or to achieve an objective

2. A software capability that must be met or possessed by a system or a system component to satisfy a contract, standard, specification, or other formally imposed documentation

Since that time, we've been speaking of these requirements things ”features and use cases ”at a fairly high level of abstraction. It was sufficient to understand the system at a macro-level view. However, as we get closer to implementation, additional specificity is required. To understand how and where the specificity is needed, and to make sure that we have discovered all the requirements to be imposed on the system at a given point in time, we'll need some additional guidance.

Davis [1999] suggests that we need five major classes of things in order to fully describe the behavior of a software system (Figure 20-1).

1. Inputs to the system ” not only the content of the input but also, as necessary, the details of input devices and the form, look, and feel ”protocol ”of the input. As most developers are well aware, this area can involve significant detail and may be subject to volatility, especially for GUI, multimedia, or Internet environments.

2. Outputs from the system ” a description of the output devices, such as voice-output or visual display, that must be supported, as well as the protocol and formats of the information generated by the system.

3. Functions of the system ” the mapping of inputs to outputs, and their various combinations.

4. Attributes of the system ” such typical non-behavioral requirements as reliability, maintainability, availability, and throughput, that the developers must taken into account.

5. Attributes of the system environment ” such additional non-behavioral requirements as the ability of the system to operate with other applications, loads, and operating systems.

Figure 20-1. System elements

We have worked with this categorization for a number of years and have found that it works quite well; it helps people think about the requirements problem in a complete and more organized manner. Accordingly, we can determine a complete set of software requirements by defining all of the five system elements.

In addition, we'll be able to evaluate whether a "thing" is a software requirement by testing it against these guidelines.

The Relationship between Software Requirements and Use Cases

"But," you might say, "we haven't talked about these software requirements things much at all ”we've been talking about use cases, haven't we?" Indeed we have, and that is because

Use cases are just one way to express software requirements.

Use cases are a convenient way for certain, but just one way nonetheless. In addition, we'll also discover that use cases can't conveniently express certain types of requirements ("the application must support up to 100 simultaneous users"), and there are better ways to express other types of requirements as well. We'll cover this issue in Chapter 22.

The Relationship between Features and Software Requirements

We also spent some time exploring the "features" of a system, simple descriptions of desired and useful behaviors. We can now see that there is a direct relationship between features and software requirements. Features are simple descriptions of systems services described in a shorthand manner. Software requirements, whether stated as use cases or in other forms, express those features in much more detailed terms. In other words, features help us understand and communicate at a high level of abstraction, but we probably can't fully describe the system and write code from those descriptions. They are too abstract for this purpose.

Software requirements, however, are specific. We can code from them, and they should be specific enough to be "testable"; that is, we should be able to test a system to validate that it really does implement the requirement. For example, suppose we are developing a defect-tracking system for an assembly-line manufacturing organization or for a software development organization. Table 20-1 shows the relationship between one of the features identified in the Vision document and its associated use cases. This mapping (and the ability to trace between the various features, use cases, and other requirements) will form the backbone of a requirements management concept known as "traceability," a topic we'll discuss later.