• Skip to main content
  • Skip to primary sidebar
  • Skip to secondary sidebar
  • Skip to footer

Computer Notes

Library
    • Computer Fundamental
    • Computer Memory
    • DBMS Tutorial
    • Operating System
    • Computer Networking
    • C Programming
    • C++ Programming
    • Java Programming
    • C# Programming
    • SQL Tutorial
    • Management Tutorial
    • Computer Graphics
    • Compiler Design
    • Style Sheet
    • JavaScript Tutorial
    • Html Tutorial
    • Wordpress Tutorial
    • Python Tutorial
    • PHP Tutorial
    • JSP Tutorial
    • AngularJS Tutorial
    • Data Structures
    • E Commerce Tutorial
    • Visual Basic
    • Structs2 Tutorial
    • Digital Electronics
    • Internet Terms
    • Servlet Tutorial
    • Software Engineering
    • Interviews Questions
    • Basic Terms
    • Troubleshooting
Menu

Header Right

Home » Software Engineering » Software Design Reviews in Software Engineering
Next →
← Prev

Software Design Reviews in Software Engineering

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.

We’ll be covering the following topics in this tutorial:

  • Types of Software Design Reviews
  • Software Design Review Process
  • Evaluating Software Design Reviews

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.

You’ll also like:

  1. Principles of Software Design & Concepts in Software Engineering
  2. Data Design in Software Engineering
  3. Architectural Design in Software Engineering
  4. Component-Level Design in software engineering
  5. Software Engineering – What is Software Engineering? Write Basic Objective and Need for Software Engineering
Next →
← Prev
Like/Subscribe us for latest updates     

About Dinesh Thakur
Dinesh ThakurDinesh Thakur holds an B.C.A, MCDBA, MCSD certifications. Dinesh authors the hugely popular Computer Notes blog. Where he writes how-to guides around Computer fundamental , computer software, Computer programming, and web apps.

Dinesh Thakur is a Freelance Writer who helps different clients from all over the globe. Dinesh has written over 500+ blogs, 30+ eBooks, and 10000+ Posts for all types of clients.


For any type of query or something that you think is missing, please feel free to Contact us.


Primary Sidebar

Software Engineering

Software Engineering

  • SE - Home
  • SE - Feasibility Study
  • SE - Software
  • SE - Software Maintenance Types
  • SE - Software Design Principles
  • SE - Prototyping Model
  • SE - SRS Characteristics
  • SE - Project Planning
  • SE - SRS Structure
  • SE - Software Myths
  • SE - Software Requirement
  • SE - Architectural Design
  • SE - Software Metrics
  • SE - Object-Oriented Testing
  • SE - Software Crisis
  • SE - SRS Components
  • SE - Layers
  • SE - Problems
  • SE - Requirements Analysis
  • SE - Software Process
  • SE - Software Metrics
  • SE - Debugging
  • SE - Formal Methods Model
  • SE - Management Process
  • SE - Data Design
  • SE - Testing Strategies
  • SE - Coupling and Cohesion
  • SE - hoc Model
  • SE - Challenges
  • SE - Process Vs Project
  • SE - Requirements Validation
  • SE - Component-Level Design
  • SE - Spiral Model
  • SE - RAD Model
  • SE - Coding Guidelines
  • SE - Techniques
  • SE - Software Testing
  • SE - Incremental Model
  • SE - Programming Practices
  • SE - Software Measurement
  • SE - Software Process Models
  • SE - Software Design Documentation
  • SE - Software Process Assessment
  • SE - Process Model
  • SE - Requirements Management Process
  • SE - Time Boxing Model
  • SE - Measuring Software Quality
  • SE - Top Down Vs Bottom UP Approaches
  • SE - Components Applications
  • SE - Error Vs Fault
  • SE - Monitoring a Project
  • SE - Software Quality Factors
  • SE - Phases
  • SE - Structural Testing
  • SE - COCOMO Model
  • SE - Code Verification Techniques
  • SE - Classical Life Cycle Model
  • SE - Design Techniques
  • SE - Software Maintenance Life Cycle
  • SE - Function Points
  • SE - Design Phase Objectives
  • SE - Software Maintenance
  • SE - V-Model
  • SE - Software Maintenance Models
  • SE - Object Oriented Metrics
  • SE - Software Design Reviews
  • SE - Structured Analysis
  • SE - Top-Down & Bottom up Techniques
  • SE - Software Development Phases
  • SE - Coding Methodology
  • SE - Emergence
  • SE - Test Case Design
  • SE - Coding Documentation
  • SE - Test Oracles
  • SE - Testing Levels
  • SE - Test Plan
  • SE - Staffing
  • SE - Functional Testing
  • SE - Bottom-Up Design
  • SE - Software Maintenance
  • SE - Software Design Phases
  • SE - Risk Management
  • SE - SRS Validation
  • SE - Test Case Specifications
  • SE - Software Testing Levels
  • SE - Maintenance Techniques
  • SE - Software Testing Tools
  • SE - Requirement Reviews
  • SE - Test Criteria
  • SE - Major Problems
  • SE - Quality Assurance Plans
  • SE - Different Verification Methods
  • SE - Exhaustive Testing
  • SE - Project Management Process
  • SE - Designing Software Metrics
  • SE - Static Analysis
  • SE - Software Project Manager
  • SE - Black Box Testing
  • SE - Errors Types
  • SE - Object Oriented Analysis

Other Links

  • Software Engineering - PDF Version

Footer

Basic Course

  • Computer Fundamental
  • Computer Networking
  • Operating System
  • Database System
  • Computer Graphics
  • Management System
  • Software Engineering
  • Digital Electronics
  • Electronic Commerce
  • Compiler Design
  • Troubleshooting

Programming

  • Java Programming
  • Structured Query (SQL)
  • C Programming
  • C++ Programming
  • Visual Basic
  • Data Structures
  • Struts 2
  • Java Servlet
  • C# Programming
  • Basic Terms
  • Interviews

World Wide Web

  • Internet
  • Java Script
  • HTML Language
  • Cascading Style Sheet
  • Java Server Pages
  • Wordpress
  • PHP
  • Python Tutorial
  • AngularJS
  • Troubleshooting

 About Us |  Contact Us |  FAQ

Dinesh Thakur is a Technology Columinist and founder of Computer Notes.

Copyright © 2025. All Rights Reserved.

APPLY FOR ONLINE JOB IN BIGGEST CRYPTO COMPANIES
APPLY NOW