Artifact: Change Request

	Change Request are used to document and track requests for a change to the product. This provides a record of decisions and, with an appropriate assessment process, ensures that the change impact of the request is considered.
Role:	Change Control Manager
Optionality/Occurrence:	Mandatory. Occurs as many times as required.
Templates and Reports:
Examples:
UML Representation:	Not applicable.
More Information:	Concept: Change Request Management

Purpose Brief Outline Properties Timing Responsibility Tailoring

Input to Activities:  Agree on the Mission Assess and Improve Test Effort Confirm Duplicate or Rejected CR Define Test Details Elicit Stakeholder Requests Identify Test Motivators Manage Dependencies Review Change Request Review Requirements Schedule and Assign Work Update Change Request Verify Changes in Build

Output from Activities:  Analyze Test Failure Confirm Duplicate or Rejected CR Launch Development Process Manage Acceptance Test Manage Beta Test Review Change Request Submit Change Request Update Change Request Verify Changes in Build

Purpose

The necessity for change is inherent in developing a software system as it evolves during its initial creation and as it is subsequently used and maintained in day-to-day operation in an live environment. Change Request are also known by various names such as CR's, defects, bugs, incidents, enhancement requests. Capturing and managing these requests appropriately ensures that changes to a system are made in a controlled way so that their effect on the system can be predicted. Some import types of Change Request include:

Enhancement Requests are used by various stakeholders to request future features they desire to have included in the product. These are a type of Stakeholder Request that capture and articulate an understanding of the stakeholders needs.

Defects are reports of anomalies or failures in a delivered work product. Defects include such things as omissions and imperfections found during early lifecycle phases, or symptoms of faults (failures) that need to be isolated and corrected within the software. Defects may also include deviations from what can be reasonably expected of the software behavior (such as usability issues).

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 CR's:

• Analysts uses CR's define significant changes to high-level requirements and to determine requirements from, especially from those CR's identified as Enhancement Requests.
• Managers use CR's to manage and control work assignment.
• Testers use CR's to describe failures (defects), omissions and quality issues found during software testing.
• The Implementer uses defect CR's to analyze failures and find the underlying faults or causes of the failure so as to resolve the CR.
• The Test Analyst uses CR's to plan the tests required to verify resolved CR's and to evaluate the test effort by analyzing sets of defects to measure trends in the quality of the software and the software engineering process.

Brief Outline

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:

Properties

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

Size of the change

• 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 tests that will need to be conducted to verify the change has been successful?

Timing

Change Management practices are often institutionalized or established early on in the project lifecycle. As such, CR's, 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 Change Request. However, these need to be reviewed and approved for the associated resolution work in a manner appropriate for the context of the software project. In larger teams or more formal cultures, approval is generally made by the supervisor of the person raising the Change Request. In many cases the final arbitration of a Change Request is by a Review Team such as a Change Control Board (CCB).

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

• All information identifying and describing the change, including assumption or background about how the need for change was discovered, has been provided sufficiently and is accurate.
• The request is unique in that it is not another occurrence of a previously identified change.

While the Change Control Manager role is generally responsible for managing these requests, in the case of Enhancement Requests the Change Control Manager typically collaborates with the System Analyst and Architect roles to assess the change.

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.

It is generally more efficient to store change requests in a database or change request management system, so that change requests can be more easily managed (for example, sorting by priority, tracking assignment and completion status, and so on). On a small project, a spreadsheet may be sufficient.

On a small project, you can manage the defects as a simple list, (for example, using your favorite spreadsheet) with a separate column for each attribute you need to track the change request. This is only manageable for small systems-when the number of people involved and the amount of defects grow, you'll need to start using a more flexible defect-tracking system.

Rational Unified Process