by Dinesh Thakur

Software design reviews are a systematic, comprehensive, and well-documented inspection of design that aims to check whether the specified design requirements are adequate and the design meets all the specified requirements. In addition, they also help in identifying the problems (if any) in the design process. IEEE defines software design review as 'a formal meeting at which a system's preliminary or detailed design is presented to the user, customer, or other interested parties for comment and approval.' These reviews are held at the end of the design phase to resolve issues (if any) related to software design decisions, that is, architectural design and detailed design (component-level and interface design) of the entire software or a part of it (such as a database).

The elements that should be examined while reviewing the software design include requirements and design specifications, verification and validation results produced from each phase of SOLe, testing and development plans, and all other project related documents and activities. Note that design reviews are considered as the best mechanism to ensure product quality and to reduce the potential risk of avoiding the problems of not meeting the schedules and requirements.

Types of Software Design Reviews

Generally, the review process is carried out in three steps, which corresponds to the steps involved in the software design process. First, a preliminary design review is conducted with the customers and users to ensure that the conceptual design (which gives an idea to the user of what the system will look like) satisfies their requirements. Next, a critical design review is conducted with analysts and other developers to check the technical design (which is used by the developers to specify how the system will work) in order to critically evaluate technical merits of the design. Next, a program design review is conducted with the programmers in order to get feedback before the design is implemented.

                                                       Types of Design Reviews

Preliminary Design Review

During preliminary design review, the high-level architectural design is reviewed to determine whether the design meets all the stated requirements as well as the non-functional requirements. This review is conducted to serve the following purposes.

  1. To ensure that the software requirements are reflected in the software architecture
  2. To specify whether effective modularity is achieved
  3. To define interfaces for modules and external system elements
  4. To ensure that the data structure is consistent with the information domain
  5. To ensure that maintainability has been considered
  6. To assess the quality factors.

In this review, it is verified that the proposed design includes the required hardware and interfaces with the other parts of the computer-based system. To conduct a preliminary design review, a review team is formed where each member acts as an independent person authorized to make necessary comments and decisions. This review team comprises the following individuals.

  1. Customers: Responsible for defining the software's requirements.
  2. Moderator: Presides over the review. The moderator encourages discussions, maintains the main objective throughout the review, settles disputes and gives unbiased observations. In short, he is responsible for the smooth functioning of the review.
  3. Secretary: A silent observer who does not take part in the review process but records the main points of the review.
  4. System designers: Includes people involved in designing not only the software but also the entire computer-based system.
  5. Other stakeholders (developers) not involved in the project: Provide an outsider's idea on the proposed design. This is beneficial as they can infuse 'fresh ideas', address issues of correctness, consistency, and good design practice.

If errors are noted in the review process then the faults are assessed on the basis of their severity. That is, if there is a minor fault it is resolved by the review team. However, if there is a major fault, the review team may agree to revise the proposed conceptual design. Note that preliminary design review is again conducted to assess the effectiveness of the revised (new) design.

Critical Design Review

Once the preliminary design review is successfully completed and the customer(s) is satisfied with the proposed design, a critical design review is conducted. This review is conducted to serve the following purposes.

  1. To assure that there are no defects in the technical and conceptual designs
  2. To verify that the design being reviewed satisfies the design requirements established in the architectural design specifications
  3. To assess the functionality and maturity of the design critically
  4. To justify the design to the outsiders so that the technical design is more clear, effective and easy to understand

In this review, diagrams and data (sometimes both) are used to evaluate alternative design strategies and how and why the major design decisions have been taken. Just like for the preliminary design review, a review team is formed to carry out a critical design review. In addition to the team members involved in the preliminary design review, this team comprises the following individuals.

  1. System tester: Understands the technical issues of design and compare them with the design created for similar projects.
  2. Analyst: Responsible for writing system documentation.
  3. Program designer for this project: Understands the design in order to derive detailed program designs.

Similar to a preliminary design review, if discrepancies are noted in the critical design review process the faults are assessed on the basis of their severity. A minor fault is resolved by the review team. If there is a major fault, the review team may agree to revise the proposed technical design. Note that a critical design review is conducted again to assess the effectiveness of the revised (new) design.

Note: Critical design review team does not involve customers.

Program Design Review

Once the critical design review is successfully completed, a program design review is conducted to obtain feedback before the implementation (coding) of the design. This review is conducted to serve the following purposes.

  1. To assure the feasibility of the detailed design
  2. To assure that the interface is consistent with the architectural design
  3. To specify whether the design is compatible to implementation language
  4. To ensure that structured programming constructs are used throughout
  5. To ensure that the implementation team is able to understand the proposed design.

A review team comprising system designers, a system tester, moderator, secretary and analyst is formed to conduct the program design review. The review team also includes program designers and developers. The program designers, after completing the program designs, present their plans to a team of other designers, analysts and programmers for comments and suggestions. Note that a successful program design review presents considerations relating to coding plans before coding begins.

Software Design Review Process

Design reviews are considered important as in these reviews the product is logically viewed as the collection of various entities/components and use-cases. These reviews are conducted at all software design levels and cover all parts of the software units. Generally, the review process comprises three criteria, as listed below.

  • Entry criteria: Software design is ready for review.
  • Activities: This criterion involves the following steps.
    1. Select the members for the software design review team, assign them their roles, and prepare schedules for the review.
    2. Distribute the software design review package to all the reviewing participants.
    3. Participants check the completeness and conformance of the design to the requirements in addition to the efficiency of the design. They also check the software for defectsal1,d if defects are found, they discuss those defects with one another. The recorder documents the defects along with the suggested action items and recommendations.
    4. The design team rectifies the defects (if any) in design and makes the required changes in the appropriate design review material.
    5. The software development manager obtains the approval of the software design from the software project manager.
  • Exit criteria: The software design is approved.

Evaluating Software Design Reviews

The software design review process is beneficial for everyone as the faults can be detected at an early stage, thereby reducing the cost of detecting errors and reducing the likelihood of missing a critical issue. Every review team member examines the integrity of the design and not the persons involved in it (that is, designers), which in turn emphasizes that the common 'objective of developing a highly rated design is achieved. To check the effectiveness of the design, the review team members should address the following questions.

  1. Is the solution achieved with the developed design?
  2. Is the design reusable?
  3. Is the design well structured and easy to understand?
  4. Is the design compatible with other platforms?
  5. Is it easy to modify or enlarge the design?
  6. Is the design well documented?
  7. Does the design use suitable techniques in order to handle faults and prevent failures?
  8. Does the design reuse components from other projects, wherever necessary?

In addition to these questions, if the proposed system is developed using a phased development (like waterfall and incremental model), then the phases should be interfaced sufficiently so that an easy transition can take place from one phase to the other.