TYPES OF REQUIREMENTS

Traditionally, requirements are seen as detailed textual specifications that fit into one of the categories mentioned above, expressed in the form "The system shall . . ." To manage the full requirements process effectively, however, it is helpful to gain a comprehensive understanding of the actual user and other stakeholder needs that are to be fulfilled by the system being developed. This understanding arms the development team with the why ("Why does this system need to operate at 99.3% accuracy?") as well as the what. Knowing this, the team will be able to do a better job of interpreting the requirements ("Does it also need to operate at 99.3% accuracy while routine maintenance is happening?") as well as being able to make trade-offs and design decisions that optimize the development process ("If we can achieve 92% accuracy with half the effort, is that a reasonable trade-off?").

Stakeholders: Requests versus Needs

We define a stakeholder as any person or representative of an organization who has a stake ”a vested interest ”in the outcome of a project. The most obvious stakeholder, of course, is the end user, but we must remember to consider other important stakeholders: a purchaser, a contractor, a developer, a project manager, or anyone else who cares enough or whose needs must be met by the project. For example, a nonuser stakeholder might be a system administrator whose workload will depend on certain default conditions imposed by the system software on the user. Other nonuser stakeholders might represent the economic beneficiary of the system.

Using this definition, it seems obvious that the development team must understand the specific needs of the key stakeholders of the system. But how do we identify those needs? It is important that we actively gather all types of stakeholder requests (the raw input data used to figure out the needs ) throughout the development lifecycle. Early in the project, we may use interviews, questionnaires, and workshops; further on in a project we will collect change requests, defect reports , and enhancement requests. Often, these requests will be vague and ambiguous ”and often stated as a need (e.g., "I need easier ways to share my knowledge of project status" or "I need to increase my productivity" or "We need to increase the performance of the system"). The requests from the stakeholders set a very important context for understanding the real needs of the stakeholders and provide critical input to our product requirements. This input provides a crucial piece of the puzzle that allows us to determine both the whys and the whats of system behavior.

System Features

Interestingly, when you initially interview stakeholders about their needs and requirements, they typically describe neither of the entities just defined. Typically, they tell you neither their real need (e.g., "If Joe and I don't start communicating better, our jobs are at risk" or "I want to be able to slow this vehicle down as quickly as possible without skidding") nor the actual requirement for the system (e.g., "I must be able to attach an RTF file to an e-mail message" or "The vehicle shall have a computer control system dedicated to each wheel that . . ."). Instead, they often describe an abstraction of both (e.g., "I want auto-matic e-mail notification" or "I want a vehicle with ABS").

We call this type of abstraction ”these higher-level expressions of system behavior ”the features of the system. Technically, we can think of a feature as "a service to be provided by the system that directly fulfills a user need." Often these features are not well defined, and they may even be in conflict (e.g., "I want ABS" and "I want lower maintenance requirements"), but nonetheless they are a representation of real needs. What is happening in this discussion is that the stakeholder has already translated the real need ("better communication with Joe") into a behavior of the system ("automatic e-mail notification"). In so doing, there has been a subtle shift in the stakeholder's thinking from the what ("better communication") to the how ”that is, how it will be implemented ("automated e-mail notification").

Because it is easy to discuss these features in natural language and to document and communicate them, they add important context to the requirements workflow. In the Rational Unified Process, we simply treat these features as another type of requirement. In addition, by adding to these features various attributes ”such as risk, level of effort, and customer priority ”you add a richness to your understanding of the system. You can then use this enhanced understanding to manage scope before substantial investments have been made in low-priority features.

Software Requirements

Neither an understanding of stakeholder needs nor an understanding of system features is, by itself, adequate to communicate to developers exactly what the system should do ("Hey, Bill, go code an automatic e-mail notification system"). You need an additional level of specificity that translates these needs and features into specifications that you can design, implement, and test to determine system conformance. At this level of specificity, you must deal with both the functional and nonfunctional requirements of the system.

Specifying Software Requirementswith Use Cases

In Chapter 6, A Use-Case-Driven Process, we learned about use-case modeling, a powerful technique that we can use to express the detailed behavior of the system via simple threads of user-system interactions that users and developers can understand easily. A use-case model is a model of the system and its intended behavior. It consists of a set of actors to represent external entities that interact with the system along with use cases that define how the system is used by the actors. The use-case model is an effective way of expressing these more detailed software requirements.