OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/submitting_change_requests.xmi

<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-w7sImtXWkf4HDXdUWjRsUg" name="new_guideline,_fnZj0NVXEdqy9sbRhejO5Q" guid="-w7sImtXWkf4HDXdUWjRsUg" authors="Chris Sibbald" changeDate="2007-02-26T13:52:05.226-0500" 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>&lt;h3&gt;
    Background
&lt;/h3&gt;
&lt;p&gt;
    Change requests typically have a lifecycle. They are raised,&amp;nbsp;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.
&lt;/p&gt;
&lt;p&gt;
    During review of a change request, the goal&amp;nbsp;is to assess the&amp;nbsp;technical, cost, and schedule impact
    of&amp;nbsp;implementing the change.&amp;nbsp; The technical impact&amp;nbsp;assessment includes&amp;nbsp;the determination of
    which&amp;nbsp;work products&amp;nbsp;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.
&lt;/p&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    The&amp;nbsp;current process uses the &lt;a class=&quot;elementLinkWithType&quot;
    href=&quot;./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html&quot;
    guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;&gt;Artifact: Work Items List&lt;/a&gt; to capture, prioritize, and track the change requests
    using the attributes defined for that artifact.
&lt;/p&gt;
&lt;h3&gt;
    Submitting Change Requests
&lt;/h3&gt;
&lt;p&gt;
    When submitting a change request provide as much information as possible to enable a speedy review and
    disposition.&amp;nbsp; As a minimum, all change requests should include the following information:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;strong&gt;ID&lt;/strong&gt; - a unique identifier for the change request to simplify tracking.&amp;nbsp; If you are using some
        form of change tracking tool the tool will assign a unique ID.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Brief Description&lt;/strong&gt;&amp;nbsp;- a name that summarizes the change request
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Detailed Description&lt;/strong&gt; - A detailed description of the change request.&amp;nbsp; For a defect, if you
        can provide information that will help reproduce the defect please do so.&amp;nbsp; For an enhancement request, provide
        a rationale for the request.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Affected Item&lt;/strong&gt;&amp;nbsp;- the affected artifact and version.
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Severity&lt;/strong&gt; - how severe is this issue (show stopper, nice to have, etc.).
    &lt;/li&gt;
    &lt;li&gt;
        &lt;strong&gt;Priority&lt;/strong&gt; - how important it is this request in your opinion.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;
    Depending upon the system you are using, the names of these data elements may differ.&amp;nbsp; However, this information
    is required, in one form or another, to permit a speedy review and disposition of the change request.
&lt;/p&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>