Requirements and Verification


Requirements: Requirements provide a technical definition of what each and every block in your system block diagram must be able to do. Each module in your system's block diagram should be associated with a set of requirements. If all requirements have been met for every module, you should have a fully functioning project. A good set of requirements should meet the following criteria.

Verification: Verifications are a set of procedures that you will use to verify that a requirement has been met. Every requirement should have a verification procedure associated with it. Good verification procedures will meet the following criteria.

Remember, a good R&V table should function like a debugging checklist.

Points Summary: At the time of demo, 50 points will be defined by the R&V table for your project. It is up to you to define how important each requirement is and how many points it will be worth. If your project is not fully functioning at the time of demo, these points will define how you will earn partial credit. If you do not provide a points summary or define one poorly (e.g., by giving too many points to a trivial requirement) the course staff reserve the right to define the points for your requirements without your input. The point summary should be organized as a table separate from the R&V table where the points are distributed across each functional block in your block diagram. Meeting the requirements for that block will then represent earning those points. If desired, you may define how many points each individual requirement is worth but this is not required.

This point allocation should initially be proposed by the students themselves with TA approval and finally instructor approval at DR. This point allocation must be printed and brought to the demo at the end of the semester. Changes must be approved by the instructor. Here is an example.


You can view example R&V tables in the sample Design Review documents: Good Sample DR and a Poor Sample DR. It is also helpful to examine the points summary example and a good example R&V table as it was presented in a final report.

A note about formatting: Requirements and Verification are best organized into a table and organized by functional block. If each module of your project has several requirements, you may want to create an R&V table for each block separately. Each row of your R&V table should have one requirement (in one column) and the corresponding verification procedure (in another column).

Submission and Deadlines

Requirements and Verification will be included in your Project Proposal, Design Review Document and you will receive feedback and suggestions for improvement. Changes to your R&V table made after design review must be approved by your TA. Changes made after Mock Demo will not be approved with the exception of extreme circumstances.

Unapproved changes to the R&V table that are presented at the Final Demo may be penalized up to 50 points (the total associated with R&V).

Interactive Proximity Donor Wall Illumination

Featured Project

Team Members:

Anita Jung (anitaj2)

Sungmin Jang (sjang27)

Zheng Liu (zliu93)

Link to the idea:


The Donor Wall on the southwest side of first floor in ECEB is to celebrate and appreciate everyone who helped and donated for ECEB.

However, because of poor lighting and color contrast between the copper and the wall behind, donor names are not noticed as much as they should, especially after sunset.

Solution Overview:

Here is the image of the Donor Wall:

We are going to design and implement a dynamic and interactive illuminating system for the Donor Wall by installing LEDs on the background. LEDs can be placed behind the names to softly illuminate each name. LEDs can also fill in the transparent gaps in the “circuit board” to allow for interaction and dynamic animation.

And our project’s system would contain 2 basic modes:

Default mode: When there is nobody near the Donor Wall, the names are softly illuminated from the back of each name block.

Moving mode: When sensors detect any stimulation such as a person walking nearby, the LEDs are controlled to animate “current” or “pulses” flowing through the “circuit board” into name boards.

Depending on the progress of our project, we have some additional modes:

Pressing mode: When someone is physically pressing on a name block, detected by pressure sensors, the LEDs are controlled to

animate scattering of outgoing light, just as if a wave or light is emitted from that name block.

Solution Components:

Sensor Subsystem:

IR sensors (PIR modules or IR LEDs with phototransistor) or ultrasonic sensors to detect presence and proximity of people in front of the Donor Wall.

Pressure sensors to detect if someone is pressing on a block.

Lighting Subsystem:

A lot of LEDs is needed to be installed on the PCBs to be our lighting subsystem. These are hidden as much as possible so that people focus on the names instead of the LEDs.

Controlling Subsystem:

The main part of the system is the controlling unit. We plan to use a microprocessor to process the signal from those sensors and send signal to LEDs. And because the system has different modes, switching between them correctly is also important for the project.

Power Subsystem:

AC (Wall outlet; 120V, 60Hz) to DC (acceptable DC voltage and current applicable for our circuit design) power adapter or possible AC-DC converter circuit

Criterion for success:

Whole system should work correctly in each mode and switch between different modes correctly. The names should be highlighted in a comfortable and aesthetically pleasing way. Our project is acceptable for senior design because it contains both hardware and software parts dealing with signal processing, power, control, and circuit design with sensors.