Artifact: Change Request |
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: Change Control Manager | Modified By: Any Role Change Control Manager Change Request Implementer Change Request Verifier Project Manager
Tasks | Input To: Assign Change Request Close Change Request Resolve Change Request Review Change Request Verify Change Request | Output From: Assign Change Request Close Change Request Resolve Change Request Review Change Request Submit Change Request Verify Change Request
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 Project Name Change Request Number Change Request Type (Problem or Enhancement) Change Request Title Date Submitted Originator Change Request Priority (High, Medium, Low) 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, 2009. All Rights Reserved.