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