 |
This artifact is used to document and track a requested change to one or more work products. It provides a record of decisions and, with an appropriate assessment process, ensures that the change impact of the request is considered. |
Domains: Configuration and Change Management |
|
Purpose
This artifact is the primary interface artifact between the change management process (on the project level) and
the overall development process. |
Relationships
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Process Usage |
|
Description
Main Description |
A change request (CR) is typically a proposed variance from the system's current (or currently planned)
behavior. It can also be used for a generic piece of work that is required to support the project. Change requests
may include
-
A report of an error (defect)
-
An enhancement request
Change requests provide a record of decisions and, with an appropriate assessment process, ensures that their change
impacts are considered.
Some important types of change requests include:
Enhancement Requests
Used by various stakeholders to request future features that 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
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 reasonably be 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.
|
Brief Outline |
Below list of suggested fields and data that one might collect in a Change Request Form .
-
Identification
-
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
-
Proposed Change (Originator)
-
Description of the proposed change
-
Estimated cost to implement the proposed change
-
Proposed Change (Change Review Team)
-
Action (Approved, Disapproved, Deferred)
-
Description of the proposed change
-
Target release
-
Affected Configuration Items
-
Category
-
Error Fix
-
Enhancement
-
New Feature
-
Other
-
Resolution
-
Estimated cost to implement the proposed change
-
Implementer
-
Actual time to implement change
(Include time for all effort including Analysis, Implementation, Test, Documentation)
-
Affected Number of Lines of Code
-
Resolution outcome (Fixed, No plan to fix, Duplicate, Works as designed)
-
Assessment
-
Verification Methods
-
Inspection
-
Analysis
-
Demonstration
-
Test
-
Test Platforms
-
Test Cases
-
Change request current state
-
Submitted, Assessed, Approved, Assigned, Resolved, Verified, Closed
|
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.
|
© Copyright IBM Corp. 1987, 2008. All Rights Reserved.
|
|