In Chapter 2, quoting Dorfman and Thayer , we provided the definition for a software requirement:
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  suggests that we need five major classes of things in order to fully describe the behavior of a software system (Figure 20-1).
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 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
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.