I admit it: I’m a process kind of guy. My opinion is that any time we have a relatively complex activity that needs to be performed numerous times and involves multiple people, it’s a good idea to write down the steps in that activity. It’s also a good idea to train people so they know how to perform the activity effectively. Even a simple documented process description (and simple is nearly always better than complex) helps ensure that we succeed in our mission each time we perform the activity.

Managing changes is one of those activities that every software organization must perform in largely the same fashion. This article, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003), describes a typical change control process that can be used, with minor adaptation, by just about any development organization. You can download a sample change control process description from http://www.processimpact.com/goodies.shtml.

Figure 1 illustrates a proposed template for a change control process description to handle requirements modifications and other project changes. The discussion in this article pertains primarily to how the process would handle changes proposed in requirements. I find it helpful to include the following four components in all procedures and process descriptions:

• Entry criteria—the conditions that must be satisfied before executing the process or procedure.
• The various tasks involved in the process or procedure, the project role responsible for each task, and other participants in the task.
• Steps to verify that the tasks were completed correctly.
• Exit criteria—the conditions that indicate when the process or procedure is successfully completed.

You’ll find these elements in steps 4, 5, 6, and 7 of Figure 1. Now let’s look at what you might put into each section of this template.

 

1. Introduction

The introduction describes the purpose of this process and identifies the organizational scope to which it applies. If this process covers changes only in certain work products, identify them here. Also indicate whether any specific kinds of changes are exempted, such as changes in interim or temporary work products created during the course of a project. Define any terms that are necessary for understanding the rest of the document in section 1.3.

2. Roles and Responsibilities

List the project team members—by role, not by name—who participate in the change-control activities and describe their responsibilities. Table 1 suggests some pertinent roles; adapt these to each project situation. Different individuals need not fill each role. For example, the CCB Chair might also receive submitted change requests. Several—perhaps all—roles can be filled by the same person on a small project.

 

3. Change-Request Status

A change request passes through a defined life cycle, having a different status at each stage in its life. You can represent these status changes by using a state-transition diagram, as illustrated in Figure 2. Update a request’s status only when the specified criteria are met.

4. Entry Criteria

The basic entry criterion for your change control process is that a valid change request has been received through an approved channel. All potential originators should know how to submit a change request, whether it’s by completing a paper or Web-based form, sending an email message, or entering the information into a change-control tool. Assign a unique identification tag to every change request, and route them all to a single point of contact, the Request Receiver.

5. Tasks

The next step is to evaluate the request for technical feasibility, cost, and alignment with the project’s business requirements and resource constraints. The change control board (CCB) Chair might assign an evaluator to perform an impact analysis, risk analysis, hazard analysis, or other assessments. This analysis ensures that the potential consequences of accepting the change are well understood. The evaluator and the CCB should also consider the business and technical implications of rejecting the change.

The appropriate decision makers, chartered as the CCB, then elect whether to approve or reject the requested change. The CCB gives each approved change a priority level or target implementation date, or it allocates the change to a specific build or release number. The CCB communicates the decision by updating the request’s status and notifying all team members who might have to modify work products. Affected work products could include the requirements documentation, design descriptions and models, user interface components, code, test documentation, help screens, and user manuals. The modifier(s) update the affected work products as necessary.

6. Verification

Requirements changes are typically verified through a peer review to ensure that modified specifications, use cases, and models correctly reflect all aspects of the change. Use traceability information to find all the parts of the system that the change touched and that therefore must be verified. Multiple team members might verify the changes made in downstream work products through testing or review. Following verification, the modifier installs the updated work products to make them available to the rest of the team and redefines the base¬line to reflect the changes.

7. Exit Criteria

All of the following exit criteria must be satisfied to properly complete an execution of your change control process:

 The status of the request is Rejected, Closed, or Canceled.

 All modified work products are installed into the correct locations.

 The originator, CCB Chair, project manager, and other relevant project participants have been notified of the change details and the current status of the change request.

 If you have requirements traceability matrix for your project, it has been updated.

8. Change-Control Status Reporting

Identify the charts and reports you’ll use to summarize the contents of the change control database. These charts typically show the number of change requests in each status category as a function of time. Describe the procedures for producing the charts and reports. The project manager uses these reports when tracking the project’s status.

Appendix: Data Items Stored for Each Request

Table 2 lists some data items to consider storing for each change request. When you define your own list, indicate which items are required and which are optional. Also, indicate whether the value for each item is set automatically by your change-control tool or manually by one of the participants in the change-management process.

The next article in this series describes the composition and responsibilities of the CCB, the change control board.

 

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.