Designing design reviews

Design reviews are an important part of the software development process. The major goal of a design review is to uncover errors in the design and to improve it before commencing implementation. I just read “Active Design Reviews: Principles and Practice” by Parnas and Weiss that contains a wealth of insights on how to effectively design design reviews and to ensure that the stated goals of the review process are met.

The purpose of all design reviews is to find errors in the design and its representation. The review should be designed to make it easy for the reviewers to find errors. If errors are present, but escape the reviewers’ attention, the review has failed… Errors [may] include unstated requirements, unnecessary requirements, obsolete requirements, and design and implementation decisions stated as requirements.

Here are some of the ways to ensure that the design review meets its stated objectives:

(Click below to continue reading)

• Ensure the design is covered completely and in detail by the review
• The design document should be designed to be reviewable: it should list the functional requirements clearly, make assumptions explicit (to avoid subtle design errors escaping unnoticed), should include redundant information (to perform error checking and uncover inconsistencies), etc.
• The reviewers (and designers) should focus, during the review, on trying to uncover errors in the design.
• Reviewers may include the following categories:

o Specialists, such as a person with detailed knowledge about a particular subsystem
o Potential users of the system
o Those who are familiar with the design methodology used, even if they are not familiar with the actual application
o Those who are skilled at and enjoy uncovering logical inconsistencies and who may be used for performing systematic consistency checks, despite not being specialists in a particular area

• When a set of reviewers that can provide complete design coverage is assembled, it is important to ensure that each reviewer focus on those areas relevant to him and that he can identify the decisions made in arriving at the design. It is also important to make the reviewer think hard about what he is reading, rather than skim it for obvious errors.
• Reviewers should be familiar with the goals of the design and the constraints placed on it.
• Reviewers should be aware of and watchful for the following classes of errors (not a MECE list):

o Inconsistencies, i.e., places where the design won’t work.
o Inefficiencies, i.e., places where the design imposes a barrier to efficient programming or use.
o Ambiguities, i.e., places where the design specification may be interpreted in several different ways, or is not clear enough.
o Inflexibilities, i.e., places where the design does not accommodate change well.

The purpose of this categorization is not to ensure that each error found falls into one and only one
category, but rather to guide us in designing reviews that will find as many errors as possible.
• Performing a good job as a reviewer is difficult work. It is important that the review be designed to give the reviewers a sense of participation and accomplishment.