Artifact: 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.
Domains: Configuration & Change Management Work Product Kinds: Project Data
Purpose
To Formulate and track Changes and Defects
Relationships
Roles | Responsible: Change Control Manager | Modified By: Any Role Change Control Manager Deployment Manager Process Engineer Test Analyst Tester
Tasks | Input To: Confirm Duplicate or Rejected CR Review Change Requests Verify Changes in Build Agree on the Mission Assess and Improve Test Effort Define Test Details Elicit Stakeholder Requests Identify Test Motivators Manage Dependencies Review Requirements Schedule and Assign Work Update Change Request | Output From: Analyze Test Failure Confirm Duplicate or Rejected CR Launch Development Process Manage Acceptance Test Manage Beta Test Review Change Requests Submit Change Request Update Change Request Verify Changes in Build
Process Usage | Configuration & Change Management > Manage Change Requests > Change Request Deployment > Manage Acceptance Test > Change Request Deployment > Beta Test Product > Change Request Deployment > Manage Acceptance Test for Custom Install > Change Request Environment > Prepare Environment for an Iteration > Change Request Project Management > Monitor & Control Project > Change Request Requirements > Understand Stakeholder Needs > Change Request Requirements > Define the System > Change Request Requirements > Manage the Scope of the System > Change Request Requirements > Manage Changing Requirements > Change Request Test > Verify Test Approach > Change Request Test > Validate Build Stability > Change Request Test > Test and Evaluate > Change Request Test > Achieve Acceptable Mission > Change Request Test > Improve Test Assets > Change Request Test > Define Evaluation Mission > Change Request
Description
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.
Brief Outline | Sample Change Request Form Identification Project: Change Request Number: Change Request Type: (Problem or Enhancement) Title: Date Submitted: Originator: Change Request Priority: 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: Affected Configuration Items: Category: Error Fix: Enhancement: New Feature: Other: Resolution Estimated cost to implement the proposed change: Implementer: Actual time to implement change: Analysis: Implementation: Test: Documentation: Affected Number of Lines of Code: Assessment Test Methods Inspection Analysis Demonstration Test Test Platforms Test Cases Change Review Team Disposition Changes Approved and Accepted
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 | Change Request Management
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.