<?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.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-pNA0DbSdSoUqnjQIiOeHcQ"
    name="achieving_concurrence,_E-dPIL-GEdqb7N6KIeDL8Q" guid="-pNA0DbSdSoUqnjQIiOeHcQ"
    changeDate="2006-09-22T06:09:40.793-0700" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    The cost of correcting errors increases exponentially throughout the development lifecycle &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#BOE88&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[BOE88]&lt;/a>. Therefore, it is important to discover problems early enough to solve them&#xD;
    quickly and inexpensively.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Requirements reviews are intended to discover problems with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/concepts/requirements_8006414F.html&quot; guid=&quot;_0Wh-sMlgEdmt3adZL5Dmdw&quot;>Requirements&lt;/a>&amp;nbsp;before you spend significant time and work in implementing the&#xD;
    wrong thing. This is not to say that you must have a complete set of requirements before implementation, but be sure to&#xD;
    review, internally and with stakeholders, those that are selected for implementation in the early iterations and those&#xD;
    that will have a broad impact on the system (often called &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/concepts/architecturally_significant_requirements_1EE5D757.html&quot; guid=&quot;_HrZGIA4MEduibvKwrGxWxA&quot;>Architecturally Significant Requirements&lt;/a>) to ensure everyone's concurrence before&#xD;
    investing significant effort in implementation.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Informal reviews&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a&#xD;
    prototype.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    These informal reviews are excellent for getting the structure of the requirements correct and removing obvious&#xD;
    mistakes. By keeping the review team small, it is easier to make rapid progress. However, informal reviews can miss&#xD;
    important perspectives&amp;nbsp;of&amp;nbsp;critical stakeholders.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Formal reviews&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Requirement reviews can be formal meetings. Start with careful preparation, so that you receive and organize comments&#xD;
    before the meeting. The meeting itself should produce decisions on all review items. After the meeting, you must pursue&#xD;
    the review actions to completion. If these actions involve a substantial amount of work or require a change to an&#xD;
    artifact that is under configuration control, consider submitting &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/concepts/change_requests_AD4868FE.html&quot; guid=&quot;_6jdvECb3Edqh1LYUOGRh2A&quot;>Change Requests&lt;/a> to prioritize and track the work. See&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/tasks/request_change_A048C387.html&quot; guid=&quot;_0mwzEclgEdmt3adZL5Dmdw&quot;>Task: Request Change&lt;/a>&amp;nbsp;and the associated&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/submitting_change_requests_7A1FE1A6.html&quot; guid=&quot;_fnZj0NVXEdqy9sbRhejO5Q&quot;>Guideline: Submitting Change Requests&lt;/a>&amp;nbsp;for more information on change requests.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Formal reviews are more wide-ranging and expensive. They provide for more balanced reviews from multiple&#xD;
    perspectives.&amp;nbsp; However, formal reviews involve more people, which makes them more difficult to coordinate (thus&#xD;
    the need for formality) and expensive in terms of work hours.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Two-tier reviews&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    One technique to get the best of both worlds is to use staged, or &quot;two-tier&quot;, reviews&amp;nbsp;&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#ADO03&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[ADO03]&lt;/a>. The&amp;nbsp;first tier is informal and performed by a smaller team, possibly&#xD;
    many times. The second&amp;nbsp;tier is more formal and performed by the complete group, perhaps only once.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>First-tier review:&lt;/strong> The authors of the requirements and the development team&amp;nbsp;review the&#xD;
    requirements during the first-tier reviews to ensure that they are&amp;nbsp;unambiguous, complete&amp;nbsp;and&#xD;
    consistent.&amp;nbsp; It is important to include testers and developers to ensure that the requirements are verifiable and&#xD;
    feasible.&amp;nbsp;These reviews&amp;nbsp;determine whether the requirements are ready for the larger community to&#xD;
    review.&amp;nbsp; First-tier reviews may be informal, formal, or a combination of the two.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Second-tier review:&lt;/strong> Involve the larger group during the higher-tier review to get more minds working&#xD;
    on the problem and to achieve concurrence that the requirements are suitable for implementation and validation.&amp;nbsp;&#xD;
    It is best to have one formal requirement review at the Lifecycle Objective (LCO) milestone and, optionally, one at the&#xD;
    Lifecycle Architecture (LCA) milestone if significant changes have occurred that introduce unacceptable risk.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At both stages, these two resources will be helpful: &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/checklists/good_requirements_594ACCBD.html&quot; guid=&quot;_jxn9EO0HEdqHTdbLTmC5IQ&quot;>Checklist: Qualities of Good Requirements&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/checklists/use_case_C5362874.html&quot; guid=&quot;_0kNwINk1Edq2Q8qZoWbvGA&quot;>Checklist: Use Case&lt;/a>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Tiered reviews offer several benefits:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on&#xD;
        functionality&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Provide a professional look to the requirements, presenting both the requirements and their authors in the best&#xD;
        possible light&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Safeguard the time of stakeholders who are reviewing the requirements, thus preventing &quot;review burnout&quot;, or&#xD;
        diminished effectiveness from overload and stress&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Provide the best opportunity for full, effective reviews.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;h4>&#xD;
    Golden rules of reviewing&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Follow these golden&amp;nbsp;rules of reviewing &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#TEL06&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[TEL06]&lt;/a>:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        &lt;strong>Encourage criticism:&lt;/strong> Remember that people are improving the requirements, not criticizing you.&#xD;
        Even the harshest criticism often contains a grain of truth. Adopt the attitude that every suggestion is a gift.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Choose your best reviewers:&lt;/strong> A few specific people make the best reviewers, time and again.&#xD;
        Cultivate them.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Allow adequate time:&lt;/strong> It's not over until you have agreed upon and made the corrections.&lt;br />&#xD;
        &amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ol></mainDescription>
</org.eclipse.epf.uma:ContentDescription>