Requirements and Verification

Description

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.

Examples

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

Smart Frisbee

Ryan Moser, Blake Yerkes, James Younce

Smart Frisbee

Featured Project

The idea of this project would be to improve upon the 395 project ‘Smart Frisbee’ done by a group that included James Younce. The improvements would be to create a wristband with low power / short range RF capabilities that would be able to transmit a user ID to the frisbee, allowing the frisbee to know what player is holding it. Furthermore, the PCB from the 395 course would be used as a point of reference, but significantly redesigned in order to introduce the transceiver, a high accuracy GPS module, and any other parts that could be modified to decrease power consumption. The frisbee’s current sensors are a GPS module, and an MPU 6050, which houses an accelerometer and gyroscope.

The software of the system on the frisbee would be redesigned and optimized to record various statistics as well as improve gameplay tracking features for teams and individual players. These statistics could be player specific events such as the number of throws, number of catches, longest throw, fastest throw, most goals, etc.

The new hardware would improve the frisbee’s ability to properly moderate gameplay and improve “housekeeping”, such as ensuring that an interception by the other team in the end zone would not be counted as a score. Further improvements would be seen on the software side, as the frisbee in it’s current iteration will score as long as the frisbee was thrown over the endzone, and the only way to eliminate false goals is to press a button within a 10 second window after the goal.