| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\openup_basic\guidances\guidelines\effective_req_reviews.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: effective_req_reviews.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_E-dPIL-GEdqb7N6KIeDL8Q CRC: 1184040965 -->Effective Requirement Reviews<!-- END:presentationName,_E-dPIL-GEdqb7N6KIeDL8Q --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_E-dPIL-GEdqb7N6KIeDL8Q CRC: 1060930239 -->This guideline discusses how to conduct reviews with relevant stakeholders to ensure agreement, assess quality, and identify changes required.<!-- END:briefDescription,_E-dPIL-GEdqb7N6KIeDL8Q --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-pNA0DbSdSoUqnjQIiOeHcQ CRC: 1359170333 --><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> 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 of 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 <a class="elementLinkWithType" href="./../../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a> and the associated <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">Guideline: Change Requests</a> 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. 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 <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO03]</a>. The first tier is informal and performed by a smaller team, possibly |
| many times. The second 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 review the |
| requirements during the first-tier reviews to ensure that they are unambiguous, complete and |
| consistent. It is important to include testers and developers to ensure that the requirements are verifiable and |
| feasible. These reviews determine whether the requirements are ready for the larger community to |
| review. 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. |
| 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> 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 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 /> |
| |
| </li> |
| </ol><!-- END:mainDescription,-pNA0DbSdSoUqnjQIiOeHcQ --> |
| </body> |
| </html> |
