Designs, Prototyping and Reviews

One of the critical activities in design verification is the design review, often with the aid of physical prototypes of the design. The value of reviewing a design seems obvious, but exactly how should I go about design reviews to get maximum value out of them? What constitutes a good review plan, and when should I do this planning? How should I conduct the actual reviews? What should I do before, during, and after the review? Our team seems to spend a lot of time in heated discussions during reviews -- how can I make review time more productive and less disruptive? Are there any special review techniques for software designs? For software code? It seems a lot cheaper to find design and code defects in a review than during testing -- how can I maximize the detection of defects during reviews?

• Among our Templates and Checklists, we have a set of Review Checklists for the following review types:
  • Agenda for Preliminary Design Review Meeting
  • Coding Review Guidelines
  • Critical Design Review
  • Detailed Design Review
  • Final Design Review
  • Preliminary Design Review
  • Software Bug Fix WBS
• Are you SURE your review is going to accomplish what you need it to? Will you get buy-in from everyone who needs to agree to goals of the project, or specific areas of content? Will you find errors or misunderstandings in project requirements, designs, and plans? Use our Review Meeting Planning Worksheet to plan the review methodically. You might discover new prep work that could be critical the review's success.
• Completion criteria are explicit goals that must be attained to call an element of a project, or the entire project, "complete." Completion criteria are really a communication tool and an important aspect of "quality management" on your project. They ensure the team agrees on when a particular activity or phase will be "done" and plans work, testing, and reviews accordingly.
• Our book list has useful references on planning and conducting design reviews.