The Requirements Dilemma: What versus How

The Requirements Dilemma: What versus How

As we have seen, requirements tell the developers what their system must do and therefore must cover the issues of the system inputs, outputs, functions, and attributes, along with the attributes of the system environment.

Table 20-1. Use Cases Associated with Particular Vision Document Features

Vision Document Feature	Use Cases
The defect-tracking system will provide trending information to help the user assess project status.	Configure Report Utility Compile History Trend

But there's a lot of other information that the requirements should not contain. In particular, they should avoid stipulating any unnecessary design or implementation details, information associated with project management, and information about how the system will be tested . In this way, the requirements focus on the behavior of the system, and they are volatile only to the extent that the behavior is volatile or subject to change. Davis [1993] calls this the "what versus how" paradigm, where what represents the requirements, or what the system is to do, and how represents the design or other project information that is to be implemented to achieve this objective.

Excluding Project Information

Project- related information (such as schedules, configuration management plans, verification and validation plans, budgets , and staffing schedules) is sometimes bundled into the set of requirements for the convenience of the project manager. In general, this must be avoided since changes in this information (for example, schedule changes) increase volatility and the tendency for the "requirements" to be out of date. When the requirements are dated, they become less trustworthy and more likely to be ignored. In addition, the inevitable debates about such things should be well separated from the discussion of what the system is supposed to do . There are different stakeholders involved, and they serve different purposes.

The budget could be construed as a requirement too; however, this is another type of information that doesn't fit our definition and therefore doesn't belong with the overall system or software requirements. The budget may turn out to be an important piece of information when the developers try to decide which implementation strategies they'll choose; some strategies may be too expensive or may take too long to carry out. Nevertheless, they are not system requirements.

In a similar fashion, information describing how we'll know that the requirements have actually been met ”test procedures or acceptance procedures ”also don't meet the definition and therefore don't belong in the requirements.

Excluding Design Information

The requirements should also exclude information about the system design or architecture. Otherwise , you may accidentally restrict your team from pursuing whatever design options make the most sense for your application. ("Hey, we have to design it that way; it's in the requirements.")

Whereas the elimination of project management and testing details from the list of requirements is fairly straightforward, the elimination of design/implementation details is usually much more difficult and much more subtle. Suppose, for example, that the requirement in Table 20-1 had been worded like this: "Trending information will be provided in a histogram report written in Visual Basic, showing major contributing causes on the x-axis and the number of defects found on the y-axis" (Figure 20-2).

Figure 20-2. Example histogram report

Although the reference to Visual Basic appears to be a fairly blatant violation of the guidelines we've recommended (because it doesn't represent any input, output, function, or behavioral attribute), it's useful to ask, "Who decided to impose the requirement that the histogram be implemented in Visual Basic, and why was that decision made?" Possible answers to that question might include the following.

• One of the technically oriented members of the group defining the Vision document decided that Visual Basic should be specified because it is the "best" solution for the problem.

• The user may have specified it. Knowing just enough about technology to be dangerous, the user, worried that the technical people may adopt another technology that's more expensive or less readily available, knows that Visual Basic is readily available and relatively cheap, and the user wants that technology to be used.

• A process or political decision within the development organization may have mandated that all applications will be developed with Visual Basic. In an effort to ensure compliance and to prevent its policies from being ignored, management insists that references to Visual Basic be inserted whenever possible into requirements documents.

If a technical developer decides to insert a reference to Visual Basic because of an arbitrary preference for the language, it obviously has no legitimate place in the list of requirements. If the user provided the requirement, things get a little stickier. If the customer refuses to pay for a system unless it's written in Visual Basic, the best course of action is to treat it like a requirement, although we will place it in a special class, called design constraints , so that it is separated from the normal requirements, which influence only the external behavior . Nevertheless, it's an implementation constraint that has been imposed on the development team. (By the way, if you think this example is unrealistic , consider the common requirement imposed until the late 1990s by the U.S. Defense Department on its software contractors to build systems using Ada.)

Meanwhile, the discussion of Visual Basic in this example may have obscured a subtler and perhaps more important requirements analysis: Why does the trending information have to be shown in a histogram report? Why not a bar chart, a pie chart, or another representation of the information? Furthermore, does the word report imply a hard-copy printed document, or does it also imply that the information can be otherwise displayed? Is it necessary to capture the information so that it can be imported into other programs or exposed to the corporate extranet? The feature described in the Vision document can almost certainly be fulfilled in various ways, some of which have very definite implementation consequences.

In many cases, the description of a problem from which a requirement can be formulated is influenced by the user's perception of the potential solutions that are available to solve the problem. The same is true of the developers who participate with the user to formulate the features that make up the Vision document and the requirements. As the old adage reminds us, "If your only tool is a hammer , all your problems look like a nail." But we need to be vigilant about unnecessary and unconscious implementation constraints creeping into the requirements, and we need to remove such constraints whenever we can.