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 CRs is that they provide a record of decisions and, due to their assessment process, ensure that change impacts are understood across the project.
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: Elicit Stakeholder Requests Manage Dependencies Review Requirements Define Test Details Schedule and Assign Work Agree Mission Identify Test Motivators Fix a Defect Determine Test Results Verify Changes in Build Review Change Request Confirm Duplicate or Rejected CR Assess and Advocate Quality Assess and Improve Test Effort Update Change Request

Output from Activities: Implement Test Implement Test Suite Analyze Test Failure Launch Development Case Assess Iteration Handle Exceptions and Problems Manage Acceptance Test Manage Beta Test Obtain Testability Commitment Database Design Review the Architecture Review the Design Define Test Approach Define Test Environment Configurations Identify Testability Mechanisms Define Testability Elements Submit Change Request Verify Tool Configuration and Installation Determine Test Results Verify Changes in Build Review Change Request Confirm Duplicate or Rejected CR Assess and Advocate Quality Assess and Improve Test Effort Update Change Request

Purpose

The necessity for change seems to be inherent in evolving and existing software systems. The Change Control Manager is responsible for defining Change Request Management procedures and maintaining CRs, ensuring that changes to a system are made in a controlled way so that their effect on the system can be predicted. CRs 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 to determine 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 and operation. Defects may also include deviations from expectation or any kind of issue that needs 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 CRs:

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

Brief Outline

The following attributes are useful in coming to a decision about any submitted CR:

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 are the possible ramifications of making this change?

Severity

• What is the impact of not implementing this request?
  • Is there any 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 change?
• What are the consequences of not making the change?

Cost

• What is the cost of saving from making this 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?

Sample 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 or Savings 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

Change Management practices are often institutionalized or established early on in the project lifecycle. As such, CRs, 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 identifying missing or incomplete use cases, test cases, or documentation.

Responsibility

Anyone on the project staff should be able to raise a CR. However, CRs 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 information identifying the defect, and 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