Why Do Requirements Change?

If it were possible to create a definitive set of requirements for a system once and only once, life would be much simpler, and there would be no need for this chapter. We could simply create a perfect Vision document, use-case model, and supplementary specification; freeze them for the duration of the development effort; and then declare everything past that point to be the responsibility of the maintenance team. Alas, things don't work that way. They never did in the past, and even with a more systematic approach to requirements management in the context of an iterative process, they will not work that way in the future.

A requirements management process can be useful only if it recognizes and addresses the issue of change.

There are several reasons for the inevitability of changes to the requirements. Some of these reasons are internal factors and may be under our control, but many of them are external factors and are outside the control of the developers and the users. Let's talk about external factors first.

External Factors

External change agents are factors over which the team has little or no control.

External factors are those change agents over which the project team has little or no control. No matter how we manage them, we must prepare ourselves technically, emotionally, and managerially to be able to address these changes as part of the normal course of software development activity. Changes occur for the following reasons.

• There was a change to the problem that we were attempting to solve with the new system. Perhaps a change occurred in the economy, in government regulations, or in the marketplace and consumer preferences. Because of the fast pace of technology change, it is more and more likely that such changes will take place before we even finish solving the original problem the user described.

• The users changed their minds or their perceptions about what they wanted the system to do. This, too, can occur for a number of reasons: not only because users are fickle, particularly when specifying the details of the human interface for their system, but also because their perceptions are based on the marketplace, the economy, the state of government regulations, and so on. Moreover, the identity of the users themselves sometimes changes. For example, if the user who described the requirements for the system leaves the customer's team, the replacement is likely to be someone with an entirely different set of opinions and perceptions.

• The external environment has changed, which creates new constraints and/or new opportunities. One of the most obvious examples of environmental change is the ongoing improvements in computer hardware and software systems: If tomorrow's computers are 50 percent faster, cheaper, and smaller and run more advanced applications than do today's computers, they will likely trigger a change in the requirements for a system. Before 1995, hardly anyone anticipated the Internet and the World Wide Web. The requirements for a wide range of information systems ”from word processors to customer information systems to banking systems ”are clearly quite different today from what they were in the pre-Internet era.

• The new system comes into existence. As we discussed, one insidious external factor, and a prime one in the "Yes, But" syndrome, is that the very existence of a new system causes the requirements for the system itself to change. As the organizational behavior evolves around the new system, the old ways of doing things are no longer appropriate; the need for new types of information emerge, and new requirements for the system inevitably develop. Thus, the simple act of delivering a new system elicits additional new requirements for the new system!

As a practical matter, a process to manage requirements can be useful only if it recognizes and addresses the issue of change. We can't prevent change, but we can prepare ourselves for it and then manage it when it happens.

Internal Factors

Internal change agents will also contribute new requirements.

In addition to the external factors, a number of internal factors can contribute to the problem of change.

• We failed to ask the right people the right questions at the right time during the initial requirements gathering effort. If our process does not include all stakeholders or if we do not ask all the right questions of them, we contribute to the change problem by simply not understanding the true requirements for the system. In other words, there are far more "Undiscovered Ruins" than necessary, and we are making significant changes that could have been avoided had we developed a more comprehensive understanding up front.

• We failed to create a practical process to help manage changes to the requirements that would normally have happened on an incremental basis. We may have attempted to "freeze" the requirements; thus, the "latent," necessary changes piled up until they created such pressure that they inevitably exploded in the face of the developers and the users, causing rework and stress.

• Iterating from requirements to design begets new requirements. As we described in Chapter 20, even if we do everything right, the process of designing the system will expose new requirements and necessitate changes to requirements that have already been elaborated. To ignore this would deprive ourselves of innovative capabilities enabled by design decisions or changes in technology. Worse, we would be forced to pretend that every existing requirement was perfectly understood and elaborated earlier, that no negotiation, compromise, or alternate set of requirements discovered at this time could possibly achieve the user's need as well as (or perhaps better than) the original stated requirement. Either approach would constitute foolishness of the highest order.

Therefore, if we are to prepare ourselves to properly manage change, we'll need to take each of the above factors into account. However, there is yet another, perhaps even more pernicious source of change that we have yet to explore. Let's look at a specific project and see what other factors we can discover.