Guideline: Effective Requirement Reviews |
This guideline discusses how to conduct reviews with relevant stakeholders to ensure agreement, assess quality, and/or identify changes required.
Relationships
Related Elements | Define Vision Detail Requirements Find and Outline Requirements
Main Description
### Effective Requirements Reviews The cost of correcting errors increases exponentially throughout the development lifecycle [BOE88]. Therefore, it is important to discover problems early enough to solve them quickly and inexpensively. Requirements reviews are meant to discover problems with the Requirements before significant effort is spent implementing the wrong thing. This is not to say that we must have a complete set of requirements prior to implementation, but those that are selected for implementation in the early interations, and those that will have a broad impact on the system (often called "architecturally significant") should be reviewed internally and with the stakeholders to ensure concurrence before investing significant effort in implementation. #### Informal Reviews Requirements reviews can be informal - showing draft requirements to your colleagues or demonstrating a prototype. These informal reviews are excellent for getting the structure of the requirements right 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. #### Formal Reviews Requirement reviews can be formal - starting with careful preparation, so comments are received and organized prior to the meeting. The meeting itself produces decisions on all review items. After the meeting, the review actions must be pursued to completion. If these actions involve a non-trivial amount of work, or require a change to an artifact that is under configuration control, consider raising Change Requests in order to prioritize and track work. See Task: Request Change and associated Guideline: Change Requests for more information on change requests. Formal reviews are more wide-ranging and expensive. They provide for more balanced review from multiple perspectives. However, formal reviews involve more people, which makes them more difficult to coordinate (and thus the need for formality) and expensive in terms of sheer man-hours. #### Two Tier Reviews One technique to get the best of both worlds is to use staged or "Two-Tier" reviews [ADO03]. The lower tier is informal, performed by a smaller team possibly many times. The second tier is more formal, performed by the complete group, perhaps only once. The requirements authors and their peers review the requirements during the lower-tier reviews to ensure they are correct both syntactically and functionally, as well as determining whether they are ready for the community at-large to review. These reviews may be informal desk-reviews, formal meetings or a combination of the two. In any event, the Checklist: Qualities of Good Requirements and the Checklist: Use Case can be used to help in the review. Involve the larger group during the higher tier review to get more eyes on the problem and to achieve concurrence that the requirements are suitable for implementation and validation. The same checklists should be used. It is recommended to have one formal requirement review at the LCO milestone and optionally one at the LCA milestone if significant changes have occurred that introduce un-acceptable risk. The benefits of tiered reviews include: Eliminating the noise caused by minor edits during the first tier reviews, allowing subsequent reviews to focus on functionality; Providing a professional look to the requirements, presenting both the requirements and their authors in the best possible light; Safeguarding the time of stakeholders reviewing the requirements and to prevent "review burnout"; and Providing the best opportunity for full, effective reviews. #### Golden Rules of Reviewing Some Golden Rules for reviewing are [TEL06]: Encourage Criticism: remember that people are improving the requirements, not criticizing you. Even the harshest criticism often contains a grain of truth. Take the attitude that every suggestion is a gift. A few specific people make the best reviewers, time and again. Cultivate them and make sure they have time allocated for the work. It's not over until the corrections have been made and agreed upon. Allocate the time accordingly.
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright