| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-w7sImtXWkf4HDXdUWjRsUg" name="new_guideline,_fnZj0NVXEdqy9sbRhejO5Q" guid="-w7sImtXWkf4HDXdUWjRsUg" authors="Chris Sibbald" changeDate="2007-02-26T10:52:05.000-0800" changeDescription="Moved content from previous concept:change request to this guideline and updated in accordance with discussion from April 18, 2006 telecon." version="0.2"> |
| <mainDescription><h3>
 |
| Background
 |
| </h3>
 |
| <p>
 |
| Change requests typically have a lifecycle. They are raised, reviewed, accepted or rejected, implemented, verified, and
 |
| closed. These states define the status of the change request at a particular point in time, and represent critical
 |
| information for tracking progress. Other sets of states are possible.
 |
| </p>
 |
| <p>
 |
| During review of a change request, the goal is to assess the technical, cost, and schedule impact of implementing the
 |
| change. The technical impact assessment includes the determination of which work products are affected and an estimate
 |
| of the level of effort required to change and verify all affected artifacts. This information becomes the basis of the
 |
| cost and schedule impact assessments and, ultimately, whether the change request will be accepted or rejected.
 |
| </p>
 |
| <p>
 |
| If accepted, the implementation and verification of the change request will be assigned to an iteration in the same
 |
| manner as any other work item.
 |
| </p>
 |
| <p>
 |
| The current process uses the <a class="elementLinkWithType"
 |
| href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
 |
| guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture, prioritize, and track the change requests
 |
| using the attributes defined for that artifact.
 |
| </p>
 |
| <h3>
 |
| Submitting change requests
 |
| </h3>
 |
| <p>
 |
| When submitting a change request, provide as much information as possible to enable a speedy review and disposition. At
 |
| a minimum, all change requests should include the following information:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>ID:</strong> A unique identifier for the change request to simplify tracking. If you are using some form of
 |
| change tracking tool the tool will assign a unique ID.
 |
| </li>
 |
| <li>
 |
| <strong>Brief Description:</strong> A name that summarizes the change request.
 |
| </li>
 |
| <li>
 |
| <strong>Detailed Description:</strong> A detailed description of the change request. For a defect, if you can
 |
| provide information that will help reproduce the defect please do so. For an enhancement request, provide a
 |
| rationale for the request.
 |
| </li>
 |
| <li>
 |
| <strong>Affected Item:</strong> The affected artifact and version.
 |
| </li>
 |
| <li>
 |
| <strong>Severity:</strong> How severe is this issue (show stopper, nice to have, and so on)?
 |
| </li>
 |
| <li>
 |
| <strong>Priority:</strong> How important this request is, in your opinion.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Depending upon the system you are using, the names of these data elements may differ. However, this information is
 |
| required, in one form or another, to permit speedy review and disposition of the change request.
 |
| </p><br />
 |
| <br />
 |
| <br /></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
