Project-related information, such as schedules, configuration management plans, verification and validation plans, budgets, and staffing schedules, are 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, such as 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; nevertheless, 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, because some strategies may be too expensive or may take too long to carry out. Nevertheless, they are not 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 specs.

We usually find it convenient to "push the envelope" a little bit here. In many cases, it is probably useful for the requirement writer to give a "hint" as to a suitable test for the requirement. After all, the requirement writer had a specific behavior in mind for the requirement, and it's only reasonable to give as much help as possible.

The requirements should also not include information about the system design or architecture. Otherwise, you may accidentally have restricted 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 first requirement in Table 23-1 had been worded like this: "SR63.1 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" (see Figure 23-2).

Figure 23-2. Pareto diagram

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 be:

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 that this example is unrealistic, consider the common requirement imposed by the U.S. Defense Department on its software contractors until the late 1990s to build systems using Ada.)

Meanwhile, the discussion of Visual Basic in this example may have obscured a more subtle and perhaps more important requirement 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 displayed on a computer screen? Is it necessary to capture the information so that it can be imported into other programs or uploaded 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.

In reality, the requirements versus design activities must be iterative. Requirements discovery, definition, and design decisions are circular. The process is a continual give and take, in that

Occasionally, discovery of a new technology may cause us to throw out a host of assumptions about what the requirements were supposed to be; we may have discovered an entirely new approach that obviates the old strategy. ("Let's throw out the entire client/data access/GUI module and substitute a browser-based interface.") This is a prime, and legitimate, source of requirements change.

This process is as it should be; to attempt to do otherwise would be folly. On the other hand, there is grave danger in all of this, for if we do not truly understand the customer's needs and the customer is not engaged actively in the requirements process—and yes, in some cases, even understanding our design-related activities— the wrong decision might be made. When properly managed, this "continual reconsideration of requirements and design" is a truly fantastic process, as technology drives our continually improving ability to meet our customer's real needs. That's the essence of what effective and iterative requirements management is all about. But when improperly managed, we continually "chase our technology tail," and disaster results. We never said it would be easy.

As you might expect, functional requirements express how the system behaves. These requirements are usually action oriented ("When the user does x, the system will do y.") Most products and applications, conceived to do useful work, are rich with software functional requirements. Software is used to implement the majority of the functionality.

When you are defining functional requirements, you should seek a good balance between being too specific in stating a requirement and being too general or too ambiguous. For example, it is not usually helpful to have a general functional requirement stated in the form "When you push this button, the system turns on and operates." On the other hand, a requirement statement that takes up several pages of text is probably too specific, but it may be the right thing to do in very special cases. We'll return to this matter in Chapter 26.

We have found that most functional requirements can be stated in simple declarative statements or in the use case form we'll describe in the next chapter. Experience has shown us that a one- or two-sentence statement of a requirement is usually the best way to match a user need with a level of specificity that a developer can deal with.

So far in this chapter, most of the examples for requirements have involved behavioral, or functional, requirements of a system, focusing on inputs, outputs, and processing details. The functional requirements tell us how the system must behave when presented with certain inputs or conditions.

But that's not enough to fully describe the requirements of a system. We must also consider things that Grady (1992) called "nonfunctional requirements:"

These requirements are used most typically to express some of the "attributes of the system" or "attributes of the system environment" elements of our elaborated definition. This convenient classification helps us to understand more about the system we are to build. Let's look at each in further detail.

Usability . It's important to describe the ease with which the system can be learned and operated by the intended users. Indeed, we may have to identify various categories of users: beginners, "normal" users, "power" users, illiterate users, users who are not fluent in the native language of the "normal" users, and so on. If you expect your customer to review and to participate in these discussion—and you'd better—you should realize that whatever requirements you write in this area will be written in a natural language; you shouldn't expect to see a finite state machine description of usability!

Since usability tends to be in the eye of the beholder, how do we specify such a fuzzy set of requirements? Some suggestions follow.

Examples of usability breakthroughs in the computer world include the difference between command line interfaces, exemplified by DOS (shudder!) and UNIX systems, versus the GUI interfaces, exemplified by Macintosh and Windows systems. It is clear that the GUI interfaces were instrumental in making computers easier to use by the great masses of nontechnical users. Another example is the Internet browser, which gave a "face" to the World Wide Web and radically accelerated the adoption of the Internet for the average user.

Several interesting attempts to strengthen the somewhat fuzzy notion of usability have been made. Perhaps the most interesting effort has resulted in the "User's Bill of Rights" (Karat 1998). A recent version of the bill contains ten key points:

Note that some of the topics covered in the Bill of Rights are essentially un-measurable and are probably not good candidates for requirements per se. On the other hand, it seems clear that the bill should be useful to you as a starting point in developing questions and defining requirements for the usability of the proposed product.

Reliability . Of course, nobody likes bugs, defects, system failures, or lost data, and in the absence of any reference to such phenomena in the requirements, the user will naturally assume that none will exist. But in today's computer-literate world, even the most optimistic user is aware that things do go wrong. Thus, the requirements should describe the degree to which the system must behave in a user-acceptable fashion. This typically includes the following issues:

In some cases, the requirements may specify some "predictor" metrics for reliability. A typical example of this is the use of a "complexity metric," such as the cyclomatic complexity metric, which can be used to assess the complexity—and therefore the potential "bugginess"—of a software program.

Performance . Performance requirements usually cover such categories as

If the new system has to share hardware resources with other systems or applications, it may also be necessary to stipulate the degree to which the implementation will make "civilized" use of such scarce resources as the CPU, memory, channels, disk storage, and network bandwidth.

Supportability . Supportability is the ability of the software to be easily modified to accommodate enhancements and repairs. For some application domains, the likely nature of future enhancements can be anticipated in advance, and a requirement could stipulate the "response time" of the maintenance group for simple enhancements, moderate enhancements, and complex enhancements.

For example, suppose that we are building a new payroll system; one of the many requirements of such a system is that it must compute the government withholding taxes for each employee. The user knows, of course, that the government changes the algorithm for this calculation each year. This change involves two numbers: instead of withholding X percent of an employee's gross salary up to a maximum of $P, the new law requires the payroll system to withhold Y percent up to a maximum of $Q. As a result, a requirement might say, "Modifications to the system for a new set of withholding tax rates shall be accomplished by the team within 1 day of notification by the tax regulatory authority."

But suppose that the tax authority also periodically introduced "exceptions" to this algorithm: "For left-handed people with blue eyes, the withholding tax rate shall be Z percent, up to a maximum of $R." Modifications of this kind would be more difficult for the software people to anticipate; although they might try to build their system in as flexible a manner as possible, they would still argue that the modification for left-handed employees falls into the category of "medium-level" changes, for which the requirement might stipulate a response time of 1 week.

But suppose that at the outset of the project, the manager of the payroll department also said, "By the way, it's possible that we'll expand our operation overseas, in which case, the withholding tax algorithm would have to be adjusted to reflect the current laws in France and Germany and maybe Hong Kong, too." Assuming that such a "requirement" made any sense at all, it could probably be stated only in terms of goals and intentions; it would be difficult to measure and verify such a requirement.

What the requirement statement can do, in order to increase the chances that the system will be supportable in the manner just described, is stipulate the use of certain programming languages, database management system (DBMS) environments, programming tools, maintenance routines, programming styles and standards, and so on. (In this case, these really become design constraints, as we'll see.) Whether this does produce a system that can be maintained more easily is a topic for debate and discussion, but at least we can get closer to the goal.

The third class of requirements, design constraints, typically impose limitations on the design of the system or the processes we use to build a system. For example,

As illustrated with the preceding Visual Basic example, there may be many such sources and rationales, and the designers may have to accept them whether they like them or not. But it's important to distinguish them from more conventional requirements, for many of the constraints may be arbitrary, political, or subject to rapid technological change and might thus be subject to renegotiation at a later point.

We'll define design constraints as

Design constraints can also be found in the developmental infrastructure immediately surrounding the system to be developed. These usually include

Another important source of design constraints is the body of regulations and standards under which the project is being developed. For example, the development of a medical product in the United States is subject to a significant number of Food and Drug Administration (FDA) standards and regulations, imposed on not only the product but also the process by which the product is developed and documented. Typical regulatory design constraints might include regulations and standards from the following:

Typically, the body of regulation imposed by these types of design constraints is far too lengthy to incorporate directly into your requirements. In most cases, it is sufficient to include the design constraints by reference into your package. Thus, your requirements might appear in the form: "The software shall fail safely per the provisions of TüV Software Standard, Sections 3.1-3.4."

Incorporation by reference has its hazards, however. Where necessary, you should be careful to incorporate specific and relevant references instead of more general references. For example, a single reference of the form "The product must conform to ISO 601" effectively binds your product to all of the standards in the entire document. As usual, you should strive for the "sweet spot" between too much specificity and not enough.

Almost all projects will have some design constraints. Generally, the best way to handle them is to follow these guidelines.

You could argue that design constraints are not true software requirements because they do not represent one of the five system elements in our elaborated definition. But when a design constraint is elevated to the level of legitimate business, political, or technical concern, it does meet our definition of a requirement as something necessary to "satisfy a contract, standard, specification, or other formally imposed documentation."

In those cases, it's easiest to treat the design constraint just like any other requirement and to make certain that the system is designed and developed in compliance with that design constraint. However, we should always strive to have as few design constraints as possible, since their existence may often restrict our options for implementing the other requirements, those that directly fulfill a user need.

On balance, we have found that the best plan is to consider the child requirements to be no different from the parent requirements, and you should plan on including them in the main requirements package.

Requirements readers can most easily relate the requirements back to the parent requirement if the identification of child requirements follows a logical pattern of identification based on the parent requirement's identification. For example, suppose that software requirement SR63.1 from Table 23-1 has one or more child requirements. A natural identification scheme for the child requirements would be to identify them as SR63.1.1, SR63.1.2, SR63.1.3, and so on. A hierarchical view of Table 23-1 might then appear as follows:

When managing a mixed software requirement/child requirement environment, a helpful feature is the ability to expand/collapse the total set of requirements so that you can view either the parents alone or the parents with the children.