Work Product: Change Request
These artifacts 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.
Purpose
  • To Formulate and track Changes and Defects
Relationships
Input ToMandatory:
  • None
Optional: External:
  • None
Description
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:

  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
Main Description

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 Requests provide a record of decisions and, with an appropriate assessment process, ensures that their change impacts are considered.

 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 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:

  • Role Set: 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.
  • Role Set: Managers uses CR's to manage and control work assignment.
  • Role Set: Testers use CR's to describe failures (defects), omissions and quality issues found during software testing.
  • Role Set: Developers uses defect CR's to analyze failures and find the underlying faults or causes of the failure so as to resolve the CR.
  • Role: Test Analyst uses CR's to plan the tests that will 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.
Properties
Optional
PlannedYes
Tailoring
Representation Options

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). On a small project, a spreadsheet may be sufficient.

On a small project you can manage the defects as a simple list. You can also use a spreadsheet with a separate column for each attribute of the change request. This is only manageable for small systems. When the number of people involved and the amount of defects grow beyond a certain point you will need to use a more flexible defect-tracking system.



More Information
Concepts

©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.