• Process Engineer

• Launch Development Process

Sample Change Request Form

1. Identification

2. Current Problem

3. Proposed Change (Originator)

4. Proposed Change (Change Review Team)

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

• Other:

5. Resolution

6. Assessment

7. Change Review Team Disposition

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.

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.

• Change Request Management