Software Design Reviews and its importance in agile development

Much like code review in software development, design review evaluates your system architecture to uncover potential issues before the design is complete.

What is Software Design Review?

Software design reviews are an essential practice in agile development, where teams deliver working software in short iterations. They help ensure that the software meets the requirements, follows the design principles, and adheres to the coding standards.

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

In this article, you will learn what software design reviews are, why they are important, how to conduct them effectively, and what are some common challenges and benefits.

Why are software design reviews important?

Software design reviews are important for several reasons. First, they help improve the quality of the software by detecting and preventing design flaws, errors, or inconsistencies early in the development cycle. Second, they help align the software with the business goals and the user needs by ensuring that the design meets the requirements and expectations. Third, they help foster a culture of collaboration and learning by sharing knowledge, skills, and perspectives among the team members and other stakeholders. Fourth, they help reduce the cost and time of development by avoiding rework, duplication, or over-engineering.

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.

Preliminary Design Review

During preliminary design review, the high-level 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:

• To ensure that the software requirements are reflected in the software design

• To specify whether effective modularity is achieved

• To define interfaces for modules and external system elements

• To ensure that the data structure is consistent with the information domain

• To ensure that maintainability has been considered

• 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 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:

• Customers: Responsible for defining the software’s requirements.

• 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.

• Secretary: A silent observer who does not take part in the review process but records the main points of the review.

• System designers: Includes people involved in designing not only the software but also the entire system.

• 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:

• To assure that there are no defects in the technical and conceptual designs

• To verify that the design being reviewed satisfies the design requirements established in the design specifications

• To assess the functionality and maturity of the design critically

• 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:

• System tester: Understands the technical issues of design and compare them with the design created for similar projects.

• Analyst: Responsible for writing system documentation.

• 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: Customers are options in Critical Design Review team.

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:

• To assure the feasibility of the detailed design

• To assure that the interface is consistent with the design

• To specify whether the design is compatible to implementation language

• To ensure that structured programming constructs are used throughout

• 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

To conduct software design reviews effectively, you need to follow some best practices. Start by planning and preparing the review by defining the scope, objectives, and criteria. Invite the participants in advance and prepare the design artifacts and materials to be presented. Set the agenda and duration of the review, then move on to conducting the review. Present your design clearly and concisely while explaining the rationale behind your decisions. Listen to feedback and questions from reviewers while encouraging constructive discussion. Record action items and follow-up tasks, then close the review by summarizing main points and outcomes. Thank participants for their time and input, communicate next steps and expectations, then follow up on action items and tasks. 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.

  • Select the members for the software design review team, assign them their roles, and prepare schedules for the review.

  • Distribute the software design review package to all the reviewing participants.

  • 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 defects. If defects are found, they discuss those defects with one another. The recorder documents the defects along with the suggested action items and recommendations.

  • The design team rectifies the defects (if any) in design and makes the required changes in the appropriate design review material.

  • 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:

• Is the solution achieved with the developed design?

• Is the design reusable?

• Is the design well structured and easy to understand?

• Is the design compatible with other platforms?

• Is it easy to modify or enlarge the design?

• Is the design well documented?

• Does the design use suitable techniques in order to handle faults and prevent failures?

• Does the design reuse components from other projects, wherever necessary?

Common Challenges of Software Design Review

Software design reviews can pose some challenges for agile teams. Challenges include:

• Finding the right balance between speed and quality

• Dealing with ambiguity and change

• Managing the human factor

Benefits of Software Design Review

A traditional agile delivery stream without a design review process might look like this:

This figure shows an agile delivery stream with a design review process:

Following are some benefits of using a design review process to evaluate your designs:

• Quality: As with code review, having an (experienced) peer look and provide feedback will cover more angles and avoid common mistakes.

• Communication: The thoughts and ideas exchanged during the review process create alignment and fuel innovation.

• Documentation: Keeping a consistent, documented history of solution designs is challenging, mainly if many small changes contribute to the current state. Design review will produce documentation that everyone can easily understand and connect to the broader picture. This documentation will also last the test of time after its writers leave the company.

• Standardization: Having a common language and set of tools increases productivity and saves money and time.

• Raising the bar: Digital transformation and agile are hungry for results, with many obstacles in their way. Utilize the reviewer's experience and feedback to push for better solutions.

• Tracking technical debt: Sometimes a workaround is required to achieve time to market. The design review process acts as a tracker for technical debt and ensures any debt pays off.

• Reusability: Different teams and departments can share solutions and apply common guidelines and best practices. The design review process is a common denominator for this sharing.

Wrap Up

Design review has clear value that far outweighs the overhead it introduces, much like code review does in software releases. Organizations should consider it part of their governance model in conjunction with other tools and practices.

The result should be a digital transformation that encompasses freedom, autonomy, reusability, cost-saving, and strong alignment. Design review is essential for the agile squads' motivation and speed of innovation.