Requirements Configuration Management

Some elements of the preceding change review and approval process are referred to as change control , version control , or configuration management 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 28-5).

Figure 28-5. Requirements configuration management overview

The benefits of a requirements management process based on configuration management 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

Tool-Based Support for Change Management

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 tooling helps you understand and manage the following 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 other elements of the system 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.

Elements Impacted by Change

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 28-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.

Figure 28-6. Abbreviated traceability matrix after FEA5 was altered

As the project evolves, changes inevitably will be proposed for various aspects of the project, from the top-level Vision document through to 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.

1. If the change to the feature does not impact a requirement, you need only clear the suspect link. Note that subsequent changes to the feature may again set the suspect link.

2. 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 you'll need to examine those interactions 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 one or more use cases, which may in turn impact several use-case realizations (in the implementation model), as well as those test cases that were derived from the changed use case. If you have established a traceability strategy and you have proper tool support, these "suspect elements" (which are those elements that were "traced from" the changed element) should be brought to your attention automatically.

Audit Trail of Change History

You may also find it beneficial to maintain an audit trail of changes, especially changes made to individual use cases. With tool support, you should be able to manage each use case separately, regardless of the document or model it's in. Thus, changes you make to each use case will be captured automatically by your tool and can be recalled for later inspection and review.

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 name of the change's author as well as the date and time of the change. Then, at any future time, the chronology of the change and information on who created the change 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, to refer 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.

Configuration Management and Change Management

A change history should exist at three levels within your project.

1. At the finest level of detail, the change history records all changes to each individual use case or requirement within the project.

2. 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.

3. 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.