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 intended to discover problems with the Requirements 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 Architecturally Significant Requirements) to ensure everyone's concurrence before investing significant effort in implementation.

Informal reviews

Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a prototype.

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.

Formal reviews

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 change requests to prioritize and track the work.

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.

Two-tier reviews

One technique to get the best of both worlds is to use staged, or "two-tier", reviews [ADO03]. 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.

First-tier review: The authors of the requirements and the development team review the requirements during the first-tier reviews to ensure that they are unambiguous, complete, correct 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.

Second-tier review: 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.

At both stages, these two resources will be helpful: Checklist: General Requirements and Checklist: Use Case

Tiered reviews offer several benefits:

1. Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on functionality
2. Provide a professional look to the requirements, presenting both the requirements and their authors in the best possible light
3. Safeguard the time of stakeholders who are reviewing the requirements, thus preventing "review burnout", or diminished effectiveness from overload and stress
4. Provide the best opportunity for full, effective reviews.

Golden rules of reviewing

Follow these golden rules of reviewing [TEL06]:

1. Encourage criticism: 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.
2. Choose your best reviewers: A few specific people make the best reviewers, time and again. Cultivate them.
3. Allow adequate time: It's not over until you have agreed upon and made the corrections.