What is a design review?

A design review is a technical meeting that is held at an early stage in the software development process. A design review generally involves a presentation of a planned software design, at a time early enough in the process to allow for changes is necessary, to an audience of stakeholders. Design reviews can fill a number of purposes, such as:

• Ensuring that the proposed design will meet the requirements
• Ensuring that the design can be implemented in the required time
• Ensuring that the design will have the needed interfaces with other systems
• Ensuring the design will be consistent with technical goals of the organization
• Ensuring the design will follow established software design principles
  Design reviews can be at various levels, corresponding to the level of detail of the design being evaluated. At the highest level, the overall architecture is reviewed; lower level design reviews focus on specific features or specific technical aspects of a system design. Design reviews can also differ with respect to the audience and timing. Very early in the design process it is often useful to present a design to intended users or customers to determine if the requirements will be met. Later in the design process the audience is usually limited to the team that will be doing the implementation.

  Why use design reviews?

  Design reviews are useful in making sure that all participants in the software development process are on the same page , that they understand how the software will be structured and how the various components will interact. Design reviews are useful in identifying design deficiencies and improvements or alternative approaches to the design.

  Who should attend a design review?

  The attendance at a design review depends on the level of the review. A high-level design review can include developers, the technical management of the project, users or customers, and participants from related development teams that will make use of the final product. Lower level design reviews should include the team that will be implementing the design plus others affected by aspects of the design, such as users of a networking interface or a database design.

  When should design reviews be held?

  Generally it is important to hold design reviews in the early stages of new software, laying out the framework in which subsequent software development will proceed. Design reviews should occur after the requirements are (fairly well) understood but before the code is written. Any project with more than one developer should hold design reviews in the early development stages of the software. If changes are being made to an existing software base, any substantial changes to the design should be reviewed by the relevant stakeholders. Even on established software projects, if several members of the development team are new to the project, a design review should be held to ensure that the team is in agreement as to the technical direction of the project.

  How to conduct a design review

• Agenda: A design review should be tightly structured to ensure that it results in useful feedback. An agenda should be distributed prior to the meeting. This agenda should identify the topics that will be presented and the specific issues that require discussion and feedback.
• Presenter: Ordinarily the design is presented by the author of the design or the person most technically aware of all aspects of the design. More than one person may present a shared design.
• Presentation: The objective of the presentation is to discuss the design in sufficient detail to enable the audience to understand how the design is intended to work, at a much higher level than a code review. Usually UML diagrams are provided and discussed, with sufficient detail to show the critical components of the design. However, these diagrams should omit extensive details that could distract the audience. Highly detailed UML diagrams can be kept on hand in case they are needed to answer questions raised in the discussion.
• Invitees. The audience for a design review should consist of stakeholders (i.e. people whose work is affected by the design being reviewed) and all attendees should have a technical awareness of the issues being discussed. The audience should be kept small enough to ensure that all participants can express technical concerns with the design.
• Requirements. It is important that design reviews take place at a time when the software requirements have been formulated, although these requirements may not be finalized; and, in fact, one consequence of a design review may be to change the requirements if it is found that the existing requirements cannot be met. A written copy of the requirements (in their current state) should be available for discussion during the design review.
• Background information. Prior to the meeting, attendees should be given a written statement of the proposed design, including UML and other diagrams and any relevant requirements. In addition, it is often useful to provide preliminary design information, such as the results of a prototyping effort, relevant performance measurements, and even customer feedback, at a design review. Visual aids can help clarify complicated aspects of the design.
• Outcome. An attendee involved in the design should write minutes, and/or make notes of any issues that arise during the meeting. Action items should identify persons responsible for resolving issues identified in the meeting. A summary of the meeting results and follow-up issues should be distributed to attendees, and others affected by the results, after the meeting.

  Where to get more more information on design reviews

  A good source for design review information is S. Pfleeger, Software Engineering, 3rd Edition. There are various standards and procedures, and examples of design reviews on the Web. Note that there is not much consensus on terminology and standards for design reviews. Software organizations tend to develop their own unique style of design reviews.