Dealing with Change

When we launch a product into the world and people start to use it for their work, experience tells us that the requirements will inevitably change (Figure 15.4). Users will probably think of something that they would like to change about the product that might make it easier for them to do their work. These changes will likely continue throughout the life of the product.

The world changes: New technologies appear, new business opportunities emerge, new ways to do things are found. In fact, it is usually some change that kicks off a product development effort. Something has changed so much that the old product, whatever it was, cannot cope, and so a new product is built. Thereafter, the new product is changed and changed until it, too, becomes old. At that point, some large change causes the old product to bereplaced by a yet newer one.

The product changes because the demands placed on it change. Consider the house in Figure 15.4, and consider your own house. Is your house exactly how it was when you first moved into it? Houses change over time, because your needs change. You start a family, granny moves in with you, you want a new carpet or a new kitchen, and so on. All of these desires represent changes to requirements, and all cause (as soon as you can afford it) changes to the product. The house, like any other product, evolves over time.

Figure 15.4.

When a product is used, it is likely to generate changes. Throughout the lifetime of the product the world will change, which will in turn cause other changes to the product.

There are both good and bad changes. Good changes come when the product has been in use for a long time, and the user wants to extend its capabilities to accommodate some new requirements. Keep in mind that these requirements have emerged from the user's experience with using the product; they could not possibly have been foreseen by the original requirements analysts. This is good because the life of the product is being extended, and the product itself is proving to be fundamentally sound.

Bad changes come when the user asks for changes that should have been foreseen or that result because the original scope of the requirements gathering was not large enough.

If you start with a large enough scopeand we repeat our warnings about the scope being much more than the anticipated automated productthen the product is far more likely to be suitable over the long term. It is more likely to be a closer match to the user's work, and it is more likely to fit seamlessly into the work environment.

Changes in the World

There are many other changes we cannot anticipatenew happenings in the world, things that did not exist when we specified the requirements for our product. For example, democratic governments change from time to time (no doubt we are all thankful for these periodic overhauls), and each incoming administration is inevitably accompanied by new policies and new regulations. Some of these changes affect our products and the way that we do work.

The world contains myriad sources of requirements: people, technology, processes, politics, and so on. A requirements specification is based on a snapshot of part of that world at a particular time. Of course, the world is in a constant state of flux. Interactions between the various requirements sources in the world are dynamic, continuous, and unpredictable; as the world changes, so do the requirements.

The best products are able to keep evolving as the world around them changes and as users become more sophisticated. As examples, consider successful software products like Microsoft Word and Excel, Adobe Photoshop, and Linux. These products have increased their functionality and refined their nonfunctional qualities many times over since their beginnings. If we are to accommodate change, we need some kind of feedback loop in our requirements process to enable us to recognize useful changes. We also need some way of controlling how, when, and whether we implement these changes.

The subject of how to recognize, model, and examine feedback in systems is discussed in Senge, Peter. The Fifth Discipline. Doubleday, 1990.

Requirements Feedback

Look at your requirements process and make sure that you are recognizing change by building in feedback loopsmechanisms for users to pass on their new thoughts about the product regardless of the stage you have reached in the development process. We have seen some organizations in which people are made to feel guilty if they change their minds about anything, especially if their earlier decisions have been written down. We do not advocate random and uncontrolled change; instead, we encourage people to tell the truth so that you can make rational decisions about how to react to that change. If you do not allow for feedback, then your systems become obsoletefast. Encourage feedback by asking people to review requirements: "What could possibly happen to change this requirement, and is there anything I can do to make that change less painful?"

Factors that contribute to successful requirements specification:

• Formal requirementsgathering process

• Use of requirements change control

• Augmentation of written requirements with prototypes

• Use of requirements quality control

• Use of function points based on requirements

• Use of reusable requirements

Source: Jones, Capers. Survey on Requirements. Software Productivity Research, 1997.

Your mechanisms for encouraging requirements feedback must continue throughout the life of the product. The requirements change over time; we know this for certain. So why not treat requirements as if they were any other kind of product and maintain them? You probably have a maintenance agreement for your personal computer or your dishwasher. Why not draw up the same kind of maintenance agreement with the product users (Figure 15.5)? Visit the users to perform regular maintenance checks. Use trawling techniques such as observation, interviewing, and apprenticing with the user on a regular, ongoing basis. The same methods that uncovered the requirements in the first place can help you unearth new requirements and keep the product healthy.

Figure 15.5.

A requirements maintenance agreement involves regular maintenance checks with the product's users. Use trawling techniques to discover new and changing requirements as early as possible.

Good feedback mechanisms help you recognize change. Having recognized new circumstances, you have to decide what to do about them. Thus you need a change control procedure to define each change and monitor its status. In his survey on factors that contribute to successful requirements specification, Capers Jones reports on the use of requirements change control. As we mentioned in our discussion of traceability, without change control the real product becomes something different from the product you are managing, so that the project is out ofcontrol.