| <?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="-pNA0DbSdSoUqnjQIiOeHcQ" name="achieving_concurrence,_E-dPIL-GEdqb7N6KIeDL8Q" guid="-pNA0DbSdSoUqnjQIiOeHcQ" changeDate="2006-09-22T09:09:40.793-0400" version="1.0.0"> |
| <mainDescription><p> |
| The cost of correcting errors increases exponentially throughout the development lifecycle <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" 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_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.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_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.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_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a> to prioritize and track the work. See&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a>&nbsp;and the associated&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">Guideline: 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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" 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_basic/guidances/checklists/good_requirements,_jxn9EO0HEdqHTdbLTmC5IQ.html" guid="_jxn9EO0HEdqHTdbLTmC5IQ">Checklist: Qualities of Good Requirements</a>&nbsp;and <a class="elementLinkWithType" href="./../../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" 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> |