Artifacts > Configuration & Change Management Artifact Set > Change Request

SWEN 5135 Configuration Management

 


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:

Input to Activities: Output from Activities:

Purpose To top of page

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 To top of page

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:
  1. 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:
  1. Proposed Change (Originator)

  • Description of the proposed change:
  • Estimated cost to implement the proposed change:
  1. Proposed Change (Change Review Team)

  • Action:
  • Approved:
  • Disapproved:
  • Deferred:
  • Description of the proposed change:
  • Affected Configuration Items:
  • Category:
  • Error Fix:
  • Enhancement:
  • New Feature:
  • Other:
  1. Resolution

  • Estimated cost to implement the proposed change:
  • Implementer:
  • Actual time to implement change:
  • Analysis:
  • Implementation:
  • Test:
  • Documentation:
  • Affected Number of Lines of Code:
  1. Assessment

  • Test Methods:
  • Inspection
  • Analysis
  • Demonstration
  • Test:
  • Test Platforms:
  • Test Cases:
  1. Change Review Team Disposition

  • Changes Approved and Accepted:

Timing To top of page

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 To top of page

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 To top of page

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


Display Rational Unified Process using frames

Rational Unified Process