Artifact:  Change Request

Change Request	Changes to development artifacts are proposed through Change Requests (CRs). Change Requests are used to document and track defects, enhancement requests and any other type of request for a change to the product. The benefit of Change Requests is that they provide a record of decisions, and, due to their assessment process, ensure that change impacts are understood project wide.
Role:	Change Control Manager is responsible for Change Requests
More information:	Concepts: Change Request Management Workflow Detail: Manage Change Requests
Purpose Brief Outline Timing Responsibility Tailoring

Input to Activities: Fix a Defect Review Requirements Elicit Stakeholder Requests Manage Dependencies Schedule and Assign Work Verify Changes in Build Update Change Request Review Change Request Confirm Duplicate or Rejected CR

Output from Activities: Review the Architecture Database Design Review the Design Submit Change Request Verify Tool Configuration and Installation Evaluate Test Manage Acceptance Test Manage Beta Test Launch Development Case Assess Iteration Handle Exceptions and Problems Verify Changes in Build Update Change Request Review Change Request Confirm Duplicate or Rejected CR

Purpose

The necessity for change seems to be inherent in evolving or existing software systems. The Change Control Manager is responsible for defining Change Request Management procedures and maintaining Change Requests, ensure that changes to a system are made in a controlled way so that their effect on the system can be predicted. Change Requests may be used to document and track all types of requests for changes to the system, including enhancement requests and defects.

Enhancement requests are used by the System Analyst in determining future features to include in the product. These will be used as input when collecting Stakeholder Requests in order to Understand Stakeholder Needs.

A defect is an anomaly, or flaw, in a delivered work product. Defects include such things as omissions and imperfections found during early lifecycle phases, and or symptoms (flaws) of faults contained in software that is sufficiently mature for test or operation. Defects may also include deviations from expectation or any kind of issue that is to be tracked and resolved.

The purpose of a defect is to communicate the details of the issue, enabling corrective action, resolution, and tracking to occur. The following people use the change requests:

• The System Analyst uses Change Requests identified as Enhancement Requests for determining new features of the product,
• The Project Manager to assign work,
• The Testers, to identify and describe defects found in testing,
• The Implementer, to analyze the defect and find the faults or causes of the Change Request,
• The Test Designer, to plan test for verifying resolved Change Requests and analyze a collection of defects to measure the quality of the software and process.

Brief Outline

The following attributes are useful in coming to decision about any submitted Change Request:

Size

• How much existing work will have to change?
• How much new work will need to be added?

Alternatives

• Are there any?

Complexity

• Is the proposed change easy to make?

• What is the possible ripple effect of the change?

Severity

• What is the impact of not implementing this request?

• Is there loss of work or data involved?
• Is this an enhancement request?
• Is it a minor annoyance?

Schedule

• When is the change required?
• Is that feasible?

Impact

• What are the consequences of making the changes?
• What are the consequences of not making the change?

Cost

• What is the cost or saving from making the change?

Relationship to Other Changes

• Will other changes supersede or invalidate this one, or does it depend on other changes?

Test

• Are there any special test requirements?

EXAMPLE CHANGE REQUEST FORM

1. Identification

• Project:

• Change Request Number:

• Change Request Type: (Problem or Enhancement)

• Title:

• Date Submitted:

• Originator:

• Change Request Priority:

2. Current Problem

• Description of the current problem:

• Critical Failure:

• Nuisance:

• Enhancement:

• New Requirement:

• Conditions under which the problem was observed:

• Current Environment: Hardware

• Operating System

• Compiler

• Source of the current problem:

• Cost Impact of the current problem:

3. Proposed Change (Originator)

• Description of the proposed change:

• Estimated cost to implement the proposed change:

4. Proposed Change (Change Review Team)

• Action:

• Approved:

• Disapproved:

• Deferred:

• Description of the proposed change:

• Affected Configuration Items:

• Category:

• Error Fix:

• Enhancement:

• New Feature:

• Other:

5. Resolution

• Estimated cost to implement the proposed change:

• Implementer:

• Actual time to implement change:

• Analysis:

• Implementation:

• Test:

• Documentation:

• Affected Number of Lines of Code:

6. Assessment

• Test Methods:

• Inspection

• Analysis

• Demonstration

• Test:

• Test Platforms:

• Test Cases:

7. Change Review Team Disposition

• Changes Approved and Accepted:

Timing

CM practices are often institutionalized, or established early on in the project lifecycle. As such, Change Requests, which are integral to the change process, can be raised at any time during the course of the project.

The main source of defects is the results of executing the tests (integration, system, and performance). However, defects can appear at any point during the software development lifecycle and include the identification of missing or incomplete use cases, test cases, or documentation.

Responsibility

Anyone on the project staff should be able to raise a Change Request. However, Change Requests need to be reviewed and approved to be valid by the supervisor of the person raising the Change Request. The final arbitration on a Change Request is done by a Review Team or a Change Control Board (CCB).

The Change Control Manager is responsible for the integrity of the defect, ensuring that:

• All the information identifying the defect, describing it, and how it was discovered is accurate.
• The defect is unique or is not another occurrence of an already identified defect.

Tailoring

The actual fields and data necessary to accurately identify, describe, and track defects vary and are dependent upon the standards, guidelines, and change control system implemented.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process