Step: Establish the Change Request Process

Complete Change Request Form

An example Change Request Form is provided in Artifact: Change Requests.

The Change Request Form is a formal document where the requester sets out the change required to the system. The form records the required change as well as recommended changes and estimated costs of making the change. The form may also include a ‘history’ of dates on when the change was requested, approved, implemented and validated.

The general procedure for handling Change Requests is in accordance with the following algorithm:

Request change by completing a Change Request Form

Analyze Change Request

IF change is valid THEN

Assess how the change might be implemented

Access cost of change

IF change is accepted THEN

REPEAT

Make changes to software

Submit changed software for quality approval

UNTIL software quality is adequate

Create new software subsystem/system

ELSE

Reject Change Request

END

ELSE

Reject Change Request

END

Information recorded on the Change Request Form provides useful primary data for reporting on project related defects, and progress based on defect resolution metrics. This aspect of Configuration Status Accounting (CSA) is described in other steps within the overall Configuration Management Process Workflow.

Analyze the Change Request

Once a Change Request is submitted, it is analyzed to ensure that it is indeed valid. Change Requests need to be reviewed at various levels within the development team. A team leader will often review and approve Change Requests submitted by any of his staff. If, however, the scope of a change is beyond the responsibilities of the team it is escalated for the next level of review. If the impact of the change spans several different development teams, it is reviewed by the Change Review Team. Some organizations refer to the Change Review Team as the Change Control Board (CCB).

Occasionally, a reported system malfunction may be due more to its usage rather than being linked to system implementation. It might also be the case that the ‘problem’ has already been reported and is being addressed.

The outcome of the analysis step is either to accept the Change Request or to reject it on the basis that it is invalid, duplicate or ‘out of scope’ given the current project vision or mandate.

Assess Cost of Change Request

For valid changes, the next step is to assess and cost the change based on the impact it has on the overall system, and how easily it can be implemented.

Input from the costing step is provided to the Change Review Team for assessment. The Change Review Team reviews the Change Request and its impact from a strategic, organizational as well as the technical point of view. The Change Review Team has to decide whether the Change Request can be economically justified.

Apply the Change Request

Once a Change Request has been approved it can be applied to the software. The revised software then undergoes quality assurance checks to make sure that changes were made in accordance with project adopted practices, and that it does not adversely affect other parts of the existing software.

Once the changes have been made the new version of the software is incorporated into the ‘product’ version of the overall software.

Maintain the Change History

As software changes are made, it is important that a record of all of the changes is maintained.

An effective way to maintain a change history is at the beginning of each software component, and within the change requests.

An example of the kind of change data to maintain in a component header could be the following:

Modification History

Version    Modifier                     Date         Change              Reason

1.1            Bruce Bogtrotter      98.05.01     Test Ranges      CR#232

1.2            Maria Mussolini       98.06.02     Requirements      CR#454