A Process for Managing Change

Clearly, given the fact that change is a natural part of the process and that change will come from both external and internal sources, we need a process for managing change. Such a process puts the team in control so that it can effectively discover change, perform impact analysis, and incorporate those changes that are deemed both necessary and acceptable into the system in a systematic manner. Building on Weinberg's recommendations, a process for more effectively managing change must include the following steps.

1. Recognize that change is inevitable, and plan for it.

2. Baseline the requirements.

3. Establish a single channel to control change.

4. Use a change control system to capture changes.

5. Manage change hierarchically.

We'll look at each of these elements in more detail.

Step 1: Recognize That Change Is Inevitable, and Plan for It

The first step is a simple one. The team must recognize that changing requirements for the system is inevitable and even necessary. Some amount of change will occur, and the team should develop an awareness of this issue and a corresponding plan for managing change that should include some allowance for change in the initial baseline. (Fortunately, if you've accepted the iterative development guidelines espoused in this book, you are already well on your way to this understanding.)

As for the legitimacy of change, with the single exception of the Easter Egg, all requests for change can be considered legitimate in that they originate from a stakeholder who has both a real need and the potential to add value to the application.

For example, requests for changes from the development team are legitimate since that team knows more about the system than anyone else does. Some of the "best" requirements come from the implementers who are closest to the system; they best recognize what the system really can do. We should encourage their input to the process since the result will be a better system for our users.

Step 2: Baseline the Requirements

In each iteration, the team should baseline the requirements for the build. The baselining process may be as simple as putting version control on the pertinent artifactsthe Vision document, software requirements, and use-case modelsand publishing the baseline for the development team. The collection of itemized requirements in these documents creates a baseline of information about the requirements and anticipated use cases for the system.

This simple step gives the team the ability to distinguish between known, or "old," requirements and new requirements (those being added, deleted, or modified and thus distinguishable from the "baseline" of known requirements). Once the baseline has been established, new requirements can be more easily identified and managed. A request for a new requirement can be compared against the existing baseline to see where it will fit in and whether it will create a conflict with any other requirements; this is often something that users overlook in their haste to respond to a change in their environment. If the change is accepted, we can manage the evolution of that change from the vision to the software requirements, from the software requirements to the appropriate technical design documents and models, and then to the code and the test procedures.

If this is done in an orderly, efficient, and responsive manner, the user community is likely to be much more cooperative. In the past, users in many organizations felt that they were being "stonewalled" by the technical development community when they asked for a change. Often, it was because the team had a chaotic , inefficient process for making the changes or because it was unable to describe the nature of that process to the users.

However, the fact that we can be responsive and efficient about making requirements changes doesn't mean that we want to invite vast numbers of frivolous changes. In the best of all worlds from the perspectives of both the users and the developerslife would be a lot simpler if we could create a single set of stable, correct requirements. Even with a reasonably well-managed change control process, there's a limit to the number of such changes that the developers will be able to accommodate, especially during the design and implementation stages of the project. It's typical, for example, to see requirements change at the rate of 1 percent to 4 percent each month during the course of development. However, when the monthly change rate exceeds 2 percent, the phenomenon of "requirements churn" becomes a very serious risk to the customer's project.

The fact that we can be responsive and efficient about making changes doesn't mean that we want to invite vast numbers of frivolous changes.

Step 3: Establish a Single Channel to Control Change

Ad hoc changes to a software system can easily cause significant and unintended consequences. Although it should be obvious that the existence of a new feature can cause significant impact to software requirements, system architecture, test plans, and so on, all of us have also experienced a worst case in which a "simple change" to code causes unanticipated consequences, occasionally even catastrophic ones. In addition, one proposed new feature might obviate, or make more difficult, an important future system feature that is not even being implemented in this release.

In addition, there is that thorny issue of the schedule and the budget for a project, which is typically the responsibility of the management team. The customer's wish for a change cannot be assumed to officially change the schedule and the budget, and a negotiation or budget reconciliation process must be initiated before a change can be approved.

The customer's wish for a change cannot be assumed to officially change the schedule and the budget.

Therefore, it is crucial that every change go through a single channel to determine its impact on the system and to make the official decision as to whether the change is going to be made in the system at all. In a small project, this official channel can be the product manager or other "owner" of the Vision document and other requirements artifacts, someone who has an overall understanding of the system requirements and design.

In larger systems or ones that affect a variety of stakeholders, this official channel should consist of a few people (a change control board, or CCB) who share the responsibility and who, together, have the requisite authority and technical competence to decide when a change request is officially approved. (We briefly introduced this concept in Chapter 17.)

In any case, a change in the system should not be initiated until the change control mechanism makes the change "official."

Step 4: Use a Change Control System to Capture Changes

In a sense, it may be easiest to focus on the external, customer- requested changes because they are most readily identified and will tend to naturally find their way into the project via the project management or change control function. However, during development, there will be a tremendous number and variety of other types of potential changes to the system.

Indeed, many of the proposed changes that occur during the design, coding, and testing of a system may appear to be unrelated to requirements, involving corrections to code- or design-level bugs. However, the impact must still be assessed. And yes, as the deadline approaches, we must even make conscious decisions about which bugs will be allowed to remain in the systemdue to the potential for the fix to destabilize the entire system and thereby jeopardize the release dateand which ones will be removed. Also, many bugs may affect the requirements, require interpolation between the requirements, or require disambiguation of a known requirement.

We will have to make conscious decisions about which bugs will remain in the system.

In some cases, it won't even be obvious what kind of change is being requested. This is particularly common when end users discover problems after the system has been developed or when the members of the "help desk" team pass on their analysis of the user complaints to the technical developers. For example, suppose the end user calls the help desk and complains, "I'm trying to enter a new employee into my payroll system, but whenever I have an employee whose first name is more than 16 characters, the program crashes." The fact that the program crashes is presumably either a code-level bug or a design-level bug. (Perhaps the operating system or the DBMS package was being invoked in an illegal fashion.) Nevertheless, even if the program had produced a civilized error message for such names, there may be a bug in the requirements; they may need to be changed to allow employee names of up to 256 characters . In the extreme case, this may even involve a "feature" because the marketing department may decide that it wants to brag that its payroll system is the only one being marketed that can handle 256-character employee names .

In any event, an analysis of the situation is required, along with a decision as to where the change will be implemented in the hierarchy of documents that we've discussed. Therefore, as Figure 28-1 illustrates, the team should implement a formal method for capturing all requested changes to the system. This could be accomplished through a change request and defect tracking system that provides a centralized repository of such requests, Web-based entry of items from any physical location, automatic status tracking and trending, automatic notification of affected parties, and a mechanism for promotion of change requests into the requirements management system when appropriate. (We use the "firewall" metaphor in Figure 28-1 to suggest that the process is controlled and attempts to prevent uncontrolled wildfires of change from sweeping through the system.)

Figure 28-1. Capturing changes

The team should implement a system for capturing all change requests.

The system should be used to capture all inputs and to transmit them to the authority of the CCB for resolution. The CCB plays a key role in helping the project achieve success and should consist of no more than three to five people who represent the key stakeholders for the project: customers, marketing, and program management.

When considering whether to approve a change request, the CCB must consider the following factors:

• The impact of the change on the cost and functionality of the system

• The impact of the change on customers and other external stakeholders not well represented on the CCB: other project contractors, component suppliers, and so on

• The potential for the change to destabilize the system

When the decision is made, the CCB also has the responsibility to ensure that all those affected by the change are notified, even if the decision is made not to approve the change.

Once a change has been determined, the next step is to decide where to insert the change. (For example, we need to determine whether to change a requirement or to change a test being proposed.) Subsequent changes will ripple through in the hierarchy, as shown in Figure 28-2.

Figure 28-2. Change request flow

Step 5: Manage Change Hierarchically

The fact that all these people are interested in making changes to the system is not intrinsically bad; aside from the Easter Egg phenomenon, we could even imagine that all these changes are beneficial. However, the fact that the changes might not be documented or analyzed is a problem, and if they're not managed carefully , disaster can occur. A change to one requirement can have a ripple effect in other related requirements, the design, or other subsystems; further, this fact may not be obvious to the requester, who casually asks the programmer to make a "quick and easy" change to the system.

The problem is even worse without an explicit process. The changes typically occur in a "bottom-up" fashion. That is, if the change is envisioned while the code is being written for a new system, it's typically introduced directly into the code itself. If the developers are extremely disciplined, they might then ask themselves , "Hmmm, I wonder whether the changes we're making to the code will cause any changes in the design. Do the design-level changes have an impact on the requirements? And do the changes to the software requirements have any impact on the Vision document?" (Meanwhile, nobody remembers to tell any of this to the testing team, whose members thought they were supposed to be creating test plans for the original software requirements!)

In theory, it's possible to manage this "backward" ripple-effect phenomenon if all the respective documents are under the control of a sophisticated software tools environment. But even if all the documents are kept synchronized, the kind of bottom-up changes to the requirements that we've been discussing are still undesirable. To be blunt: a programmer doesn't have the authority to introduce new features and requirements directly into the code on the user's behalf , no matter how well intentioned . Similarly, the marketing representative who makes a casual request of the programmer for such a change, while they're both sipping a beer at the neighborhood brewpub, is not acting in an official capacity. Every new feature/requirement has an impact on the cost, schedule, reliability, and risk associated with the project.

A programmer doesn't have the authority to introduce new features and requirements directly into the code on the user's behalf.

In order to mitigate this ripple effect, changes to the requirements should be carried out in the top-down hierarchical fashion shown in Figure 28-3. As discussed earlier in this book, changes to a baseline Vision document can be documented in a separate Delta Vision document, which is normally a very small subset of the original document. However, since the Vision document changes may stipulate the deletion of features, we may need to regenerate a completely new baselined set of software requirements, and that can lead to appropriate changes in the design, the code, and the test plans.

Figure 28-3. Hierarchical ripple effect

If we have followed the processes in this book and have reasonable support from our tool environment, the downward ripple effect will be highlighted by the traceability mechanism we used in building our requirements pyramid. This allows us to work downward through the pyramid, making further changes as necessary. Each subsequent change, in turn , highlights additional places lower in the pyramid where additional analysis needs to occur.

Thus, change is a controlled "brushfire," and we can proceed logically through the hierarchy. In addition, if we've done a good job of encapsulating the systems and subsystems and have used a well-structured requirements strategy, changes should be limited to the areas directly linked to the requirements that have changed.

Returning to our case study, for example, Figure 28-4 shows a traceability report for HOLIS that resulted when a change was made. Two features, FEA3 and FEA5, indicate traceability links that the automated tool has marked as suspect. These suspected impacts resulted from proposed changes to the two features. We need to review requirements SR3 and SR4 for possible interactions because of the changes proposed by FEA3 and FEA5. In turn, possible revisions to SR3 and SR4 may ripple down into the implementation, and so on. We will explore this issue again later in this chapter.

Figure 28-4. Impact analysis by traceability link