Design Review

Video Lecture

Video, Slides

updated Fa 2020


The design review is a 30-minute meeting intended to make sure that the team has a successful project. Students will present and defend their design while instructors and TAs critique it, identifying any infeasible or unsafe aspects and steering the team toward success. Instructors and TAs will ask questions throughout and may choose the order of blocks to be discussed. Specifically, here is what the course staff are looking for:
  1. Evidence that the overall design and high-level requirements solve the problem stated.
  2. Check if the overall design has suitable difficulty for course standards and completion in one semester. Scope may need to be adjusted if otherwise.
  3. Check team members' engineering preparedness to implement each module.
  4. Check that each team member is assigned an equal portion of the project effort.
Prepare for the following sequence.
  1. Promptly project the design document on projector.
  2. Introduce team members (name, major, and the project part each is in charge of).
  3. Present problem statement and proposed solution (<1 minutes) following the template in DDC (see Description 1.a)
  4. Present design overview (<5 minutes)
    1. High-level requirements: check DDC
    2. Block diagram: check DDC
    3. Physical design
  5. For the remainder of the review, you will participate in a detailed discussion of the design. Plan to cover each block, one at a time, beginning with the most critical. The course staff will ask questions and may step in to guide the discussion. Be prepared to discuss all aspects of your design with a focus on the following.
    1. Requirements & Verification: (see DDC); We'll look at all the important block requirements. Prepare to justify the components chosen and compare with important alternatives.
    2. Evidence that the design meets requirements (use the following as applicable)
      • Simulations
      • Calculations
      • Measurements
      • Schematics
      • Flowcharts
      • Mechanical drawings
      • Tolerance analysis: check DDC
      • Schedule: Suggestions:
        1. Think about what you can do in parallel, what has to be sequential;
        2. Work on hardware before software;
        3. Perform unit testing before system testing;
        4. Unit test each module on a breadboard before starting PCB design);
        5. Leave margin for unexpected delays or accidents. You are mostly responsible for those exceptions, just as if you were the owner of this senior design business;
      • Cost:hourly rate is ~$50 not $10. In addition, apply the 2.5x overhead multiplier ($125/hr is the cost of your senior design business), which includes the cost of salaries of you, your boss, CxOs, sales, janitors, etc.


The DR Grading Rubric is available to guide your DR preparation. Two sample Design Review documents are available as examples of what we expect: a Good Sample DR, a Moderate Sample DR, and a good example R&V table as it was presented in a final report. Notes are made in red type to point out what is lacking. Note that the grading rubrics and point structure may have evolved since these reports were generated, so use them only as a guide as to what we are generally expecting.

Submission and Deadlines

Your design document should be uploaded to PACE in PDF format by Midnight the Friday before design review. If you uploaded a mock DR document to PACE, please make sure that it has been removed before uploading the final DR..

Tech must-know and FAQ for design

Here is the link of "Tech must-know and FAQ for design" which is accessible after logging into

Over semesters, ECE445 course staff have encountered repeated mistakes from students. The document above is designed to provide students with the essential knowledge needed in order to have a good design. Spending 5 min reading it might save you 15 hours later. Also, there might be some quiz questions in your DDC or Design Review. Please help us improve this document. We value your feedback!

Electronic Replacement for COVID-19 Building Monitors @ UIUC

Patrick McBrayer, Zewen Rao, Yijie Zhang

Featured Project

Team Members: Patrick McBrayer, Yijie Zhang, Zewen Rao

Problem Statement:

Students who volunteer to monitor buildings at UIUC are at increased risk of contracting COVID-19 itself, and passing it on to others before they are aware of the infection. Due to this, I propose a project that would create a technological solution to this issue using physical 2-factor authentication through the “airlock” style doorways we have at ECEB and across campus.

Solution Overview:

As we do not have access to the backend of the Safer Illinois application, or the ability to use campus buildings as a workspace for our project, we will be designing a proof of concept 2FA system for UIUC building access. Our solution would be composed of two main subsystems, one that allows initial entry into the “airlock” portion of the building using a scannable QR code, and the other that detects the number of people that entered the space, to determine whether or not the user will be granted access to the interior of the building.

Solution Components:

Subsystem #1: Initial Detection of Building Access

- QR/barcode scanner capable of reading the code presented by the user, that tells the system whether that person has been granted or denied building access. (An example of this type of sensor: (

- QR code generator using C++/Python to support the QR code scanner.

- Microcontroller to receive the information from the QR code reader and decode the information, then decide whether to unlock the door, or keep it shut. (The microcontroller would also need an internal timer, as we plan on encoding a lifespan into the QR code, therefore making them unusable after 4 days).

- LED Light to indicate to the user whether or not access was granted.

- Electronic locking mechanism to open both sets of doors.

Subsystem #2: Airlock Authentication of a Single User

- 2 aligned sensors ( one tx and other is rx) on the bottom of the door that counts the number of people crossing a certain line. (possibly considering two sets of these, so the person could not jump over, or move under the sensors. Most likely having the second set around the middle of the door frame.

- Microcontroller to decode the information provided by the door sensors, and then determine the number of people who have entered the space. Based on this information we can either grant or deny access to the interior building.

- LED Light to indicate to the user if they have been granted access.

- Possibly a speaker at this stage as well, to tell the user the reason they have not been granted access, and letting them know the

incident has been reported if they attempted to let someone into the building.

Criterion of Success:

- Our system generates valid QR codes that can be read by our scanner, and the data encoded such as lifespan of the code and building access is transmitted to the microcontroller.

- Our 2FA detection of multiple entries into the space works across a wide range of users. This includes users bound to wheelchairs, and a wide range of heights and body sizes.