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.
Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a
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.
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.
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:
Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on
Provide a professional look to the requirements, presenting both the requirements and their authors in the best
Safeguard the time of stakeholders who are reviewing the requirements, thus preventing "review burnout", or
diminished effectiveness from overload and stress
Provide the best opportunity for full, effective reviews.
Golden rules of reviewing
Follow these golden rules of reviewing [TEL06]:
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.
Choose your best reviewers: A few specific people make the best reviewers, time and again.
Allow adequate time: It's not over until you have agreed upon and made the corrections.