If it were possible to define a 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, software requirements specification, and use-case model; 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, they will not work that way in the future.
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.
External factors are those change agents over which the project team has 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 because:
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 now more and more likely that such changes will take place before we even finish solving the original problem that 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. Back in the 1993–1994 time frame, 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. One of the most insidious external factors, and a prime factor 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 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 manage it.
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. Or, perhaps, we created no change process at all, thereby allowing, or even encouraging, people to change whatever they wished whenever they wished. In this case, at some point, almost everything is change, and you can no longer "see the forest for the trees."
Before we address these problems, however, let's look at a specific project and see what other factors we can discover.
Weinberg (1995) notes that change can be insidious. In one project postmortem, he compared the known requirements of the system at the end of the project to those known at the beginning of the project. In so doing, he discovered a variety of sources of requirements change. Some were "official," representing customer requests made through the appropriate channels of communications, but many were surprisingly "unofficial," or what Weinberg calls "requirements leakage":
Enhancements mentioned by distributors who had been overheard by programmers at a sales convention
Direct customer requests to programmers
Mistakes that had been made and shipped and had to be supported
Hardware features that didn't get in or didn't work
Knee-jerk change-of-scope reactions to competitors
Functionality inserted by programmers with "careful consideration" of what's good for the customer
Programmers' "Easter Eggs"
Each of these sources may contribute only a small amount of change, but in accumulation, unofficial sources contributed up to half of the total scope of one project! In other words, half of the total work product of the system was invested in requirements leakage, or requirements that entered the system without visibility to the team members responsible for managing to schedule, budget, and quality criteria.
How can a project manager accommodate change of this type and still meet the schedule and quality criteria? It can't be done! In order to have a reasonable probability of success, requirements leakage must be stopped or, at least, reduced to manageable levels.
Programmers' Easter Eggs
Programmers' Easter Eggs are a particularly pathological form of requirements leakage. An Easter Egg is a hidden behavior built into the system for debug purposes, for the "fun of it," or, occasionally, for worse motives. In our experience, Easter Eggs are extremely dangerous, and programmers must know that to insert them is completely unacceptable and that doing so will subject the offenders to dire consequences. Two painfully true cases follow.
A large military simulation system took a long time to execute, so the programmers built in a background game of "Battleship" to amuse themselves during the simulation. Unfortunately, they never took it out; nor did its existence appear on any of the verification and validation activities or reports. When it was discovered, the customer, having lost confidence in the contractor, canceled the entire program: a multimillion-dollar loss to the subcontractor and a serious detriment to future business opportunities.
A junior programmer contributing to the development of a shrink-wrapped software tool amused himself by building in derogatory error messages in early stubs of error-recovery code. One such message was accidentally left in and discovered by a customer in a formal product training session. The software had to be repaired and rereleased on an unplanned basis, causing the loss of critical team-weeks to the company.
Clearly, given the fact that change is a natural part of the process and that change will come from both external and internal sources, a process for managing change is needed. 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 to be 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.
Recognize that change is inevitable, and plan for it.
Baseline the requirements.
Establish a single channel to control change.
Use a change control system to capture changes.
Manage change hierarchically.
We'll look at each of these elements in more detail.
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.
As for the legitimacy of change, all (with the single exception of the Easter Egg), can be considered legitimate in that they originate from a stakeholder who has both a real need and the potential to add real value to the application.
For example, requests for changes from the development team are legitimate, as that team knows more about the system than anyone else. Clearly, we hope and expect that the developers will have a variety of suggestions on what the system should do. Some of the "best" requirements come from the implementers who are closest to the system; only they 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.
Toward the end of the elaboration phase in the development cycle, the team should baseline all known requirements for the system. The baselining process may be as simple as putting version control on the pertinent artifacts—Vision document, software requirements, and use-case models—and 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, or those being added, deleted, or modified and that can now be distinguished 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 as to 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. And, 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 developers—life 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%–4% a month during the course of development. However, when the change rate exceeds 2 percent a month, the phenomenon of "requirements churn" becomes a very serious risk to the customer's project.
Changes to a software system can be insidious. 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 the 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. Also, there is that thorny issue of the schedule and the budget for a project, 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.
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 project champion or manager: the "owner" of the Vision document and other requirements artifacts, someone who has an overall understanding of the system requirements and design. Or, it can be someone else.
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 18.)
In any case, a change in the system should not be initiated until the change control mechanism makes the change "official."
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 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 system—due to the potential for the fix to destabilize the entire system and thereby jeopardize the release date—and which ones will be removed. Also, many bugs may affect the requirements, require interpolation between the requirements, or require disambiguation of a known requirement.
In some cases, it won't even be obvious what kind of change is being requested. This is particularly common when end users complain about 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.) But 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 can brag that its payroll system is the only one being marketed that will now be able to 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 34-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 34-1 to suggest that the process is controlled and attempts to prevent uncontrolled wildfires of change from sweeping through the system.)
The system should be used to capture all inputs and to transmit them to the authority of the change control board (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 34-2.
The fact that all of these people are interested in making changes to the requirements is not intrinsically bad; aside from the Easter Egg phenomenon, we could even imagine that all of these changes are beneficial. But 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, design, or other subsystems; further, this fact may not be obvious to the marketing representative, who casually asks the programmer to make a "quick and easy" change to the system.
But the problem is even worse, for 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. And 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 that 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 of 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 here 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.
In order to mitigate this ripple effect, changes to the requirements should be carried out in the top-down hierarchical fashion shown in Figure 34-3. As discussed earlier in this book, changes to a baseline Vision document can be documented in a separate "Delta" 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.
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 "suspect links," or 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.
For example, Figure 34-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. You need to review SR3 and SR4 for possible interactions as a result 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.
Some elements of the preceding change review and approval process are referred to as "change control," "version control," or configuration management (CM) in some organizations. Interestingly, most organizations have a reasonably rigorous process for configuration management of the source code produced during the implementation lifecycle phase of a project, but no corresponding process for the project requirements. Even if the organization does have a formal process for generating the Vision document and software requirements, it often ignores the many requirements-oriented changes that creep into the project during the coding phase.
However, in today's modern tool environments, it's a reasonably straightforward matter to have all elements of the requirements hierarchy under configuration management (see Figure 34-5).
The benefits of a CM-based requirements management process should be obvious by now, but let's review them briefly. Such a process
Prevents unauthorized and potentially destructive or frivolous changes to the requirements
Preserves the revisions to requirements documents
Facilitates the retrieval and/or reconstruction of previous versions of documents
Supports a managed, organized baseline "release strategy" for incremental improvements or updates to a system
Prevents simultaneous update of documents or conflicting and uncoordinated updates to different documents at the same time.
In this recap of previous sections, we offer a practical approach for change management, assuming that you have a set of tools to support this effort. If you choose to use your own manual techniques, portions of this section may not be applicable, but the overall ideas are worth reviewing nonetheless.
Change management practices help you to understand and manage these important project development aspects:
If a single product feature is proposed for a change, what are the work consequences of that change? In other words, change management helps you determine the amount of rework that may be required. The amount of work to effect a change may have significant impact on your project resource planning and workload planning.
If an element is proposed for a change, what are the other elements of the system that may be impacted by the change? This topic is of key concern both to your project planning and to your customer.
Active projects inevitably take wrong turns. It is certain that your project will arrive at a point at which you would like to be able to "roll back" a requirement and to examine a previous revision of the requirement. In addition, it would be helpful to remember how and why the requirement was changed. In other words, an audit trail of each requirement is valuable and may even be mandated by regulatory agencies as part of the design process.
After establishing the traceability relationships for your project, you should use the traceability linkages as a tool for change management. In the case of HOLIS, for example, suppose that we need to change the wording of FEA5 ("Vacation settings") in Figure 34-6 to reflect a revised statement of the product feature. Note the diagonal lines through the traceability arrows in the row for FEA5. These lines, the "suspect links," are intended to warn you that changing the feature may have an impact on SR1 and SR3 and that you should therefore review them.
As the project evolves, changes inevitably will be proposed for various aspects of the project: the top-level Vision document, through specification, implementation, and testing. Whenever a change occurs, you should use the suspect links to warn you of possible relationships affected by the change. Your change management activities usually will involve one of two steps.
If the change to the feature does not impact a requirement, you need only clear the suspect link. Note that subsequent later changes to the feature may again set the suspect link.
If the feature does impact a requirement, you may need to rework the affected element. For example, the proposed change to the feature may require a respecification of another requirement. After editing it, you will discover that additional suspect links now warn you of the potential interactions linked to changing it. Then, those interactions will need to be examined for changes, and so on.
Change management capability must exist throughout multiple levels of traceability relationships. That is, changing a feature entry in the Vision document may impact several software requirements in the SRS and/or selected use cases, which may, in turn, impact several implementation units, which may, in turn, impact one or more test plans. You should also track the traceability linkages bidirectionally. For example, changing a test plan specification may cause you to look back to the implementation units for potential impact. In turn, changing an implementation unit may require a reinspection of affected software requirements and may even require a reinspection of the top-level features, which are ultimately linked via the traceability relationships you established.
You will also find it beneficial to maintain an audit trail of changes, especially changes made to individual requirements. With tool support, you should be able to manage each requirement separately, regardless of the document or model it's in. Thus, changes you make to each requirement will be captured automatically by your tool and can be recalled for later inspection and review.
The change history should capture the current statement of the requirement, including the current values of all of the requirement's attributes. By capturing all such parameters, you can use the history as a concise overview of the requirement.
The change history also allows you to view a chronological history of all prior changes to the requirement, including its attributes. The tool should automatically capture all changes to the text of the requirement, as well as changes to the values for the requirement's attributes.
Whenever the tool detects a change, the background for the change should be automatically captured. In addition, the tool should include an automatic capture of the change's author and the date and time of the change. Then, at any future time, the chronology of the change and the change author can be viewed as part of the history record.
The tool should also allow you to enter a change description to document the change. Typically, you might enter a sentence or two to explain why the change was made, make references to project memos regarding the change, and so on. Documenting the change will provide a satisfactory rationale and cross reference so that later inspection of the history can adequately recall the motivation for the change. This will be a key element in any regulatory or project review of those changes that affect the claims, efficacy, and safety of the device and its software.
Figure 34-7 shows a printout of a partial SRS requirement history (SR4.4). Note that the change history is arranged in reverse chronological order and records changes to both the text (change 1.0001 versus 1.0000) and the values of selected attributes.
Text changes can be very tiny, such as a change in punctuation, or, as in the case of SR4.4, a major revision. Nevertheless, any change is a change and should be logged appropriately by the change management tool.
A change history should exist at three levels within your project.
At the finest level of detail, the change history records all changes to each individual requirement within the project. This is the level of detail exhibited in Figure 34-7.
At a middle level of detail, you should automatically maintain a similar change history for each project document. Document-level history is typically maintained by your source code control system or document control system.
At the most general level of detail, you should automatically maintain a similar change history for the entire project. Both the project and the archives can be fully integrated into a configuration management system.
In other words, you need a set of tools providing a fully automatic, comprehensive, and seamless integration to common applications that will assist you in the configuration management tasks involved in running a large software development project.
Although requirements will change during project development, change itself need not destabilize the development process. With a comprehensive change control process in place and with requirements artifacts placed under the control of the development team's configuration management system, the team will be well prepared for the key requirements challenge of managing change.
It is important to realize that managing change in a large project is usually too big to handle by manual methods. Yes, you need a process to control the manner in which change enters the project. However, we have found it to be a formidable task to attempt to understand the ramifications of the change without tools that help you find all of the affected elements of the project.
Team Skill 6 Summary
Team Skill 6, Building the Right System, completes the transition from understanding the problem to implementing the solution system.
Designing and implementing the correct system is tough. One useful technique is to use the requirements and the use cases to drive the implementation architecture and design. We also learned about verification, an analytic approach that constantly monitors the evolution of the project's features, requirements, design, and implementation. Verification is supported by the use of traceability techniques to relate parts of your project to one another.
Traceability techniques allow you to make certain that everything required for the project is present and accounted for. Also, the same techniques allow you to ferret out unnecessary or superfluous items that will only bog down your development efforts in useless side roads. Although verification is an analytical technique, it is important to remember that thinking is important. You can't simply apply the verification techniques mechanically.
Validation is the other half of the V&V approach to ensuring that the system is built correctly. Validation uses testing activities and traceability techniques to ensure that the system conforms to its requirements. Acceptance testing is then applied to ensure that the system works as intended in the customer's environment and that it really does solve the customer's problem.
You may also need to apply hazard analysis and risk analysis to help you decide which portions of your system need verification and validation and in what amounts. Your investments in these activities should be controlled by your return on investment (ROI) analysis.
Finally, a critical feature of building the right system is the matter of managing change. Change is a way of life; we can plan for change and manage it. Managing change helps us make sure that the system we built is the right system and, moreover, that it continues to be the right system over time.
With the completion of Team Skill 6, we are ready to move to the last chapter.Chapter 35 is intended to help you apply the skills you have learned and to help you get off to a good start on your next project.