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
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  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
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
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.
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.