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.
- Quantitative: Each requirement should define a range of values that a parameter must fall within and the conditions under which it must do so (e.g., The power supply must provide a voltage in the range of 4.5-5.5V for a current load up to 100mA). Every quantifiable measurement must have a tolerance associated with it. Remember if you say "must be 5V", you can never measure exactly 5V and your verification will fail no matter what (think ECE 313). Exceptions would be binary measurements (LED is on, software flag is set, etc). Even for software components, you need some kind of quantifiable test (error rate, run time, etc).
- Thorough: A good set of requirements should cover all functionality of the project. You should be able to hand your requirements to an engineer who knows nothing about your project and they would have enough information to design a system that performs just like your design (the designs may not necessarily match but they should perform the same functions).
- Defined by Project Goals: Your requirements must be driven by what your system is being designed to do. It is tempting to find a component, take specifications from the datasheet and use those for your requirements but this misses the point entirely. You should be choosing your requirements based on your project goals and then finding components that meet your requirements.
As an example, consider the case in which a module contains only a single part. Suppose that in working out your design, you determine a temperature sensing module must provide a reading accurate to within 5° C. For your design, you choose a sensor which is accurate to within 1° C, which is much better than the requirement. In your RV table, the requirement should still state "accurate to within 5° C" even though the actual sensor will perform better. Why is this important? Perhaps in future implementations, cost becomes an issue. The 1° C sensor is 10x more expensive than a similar sensor that provides 4° C accuracy. If you had changed your requirement to match the capability of the original sensor, you would not meet requirements by switching to the less expensive (and less accurate) sensor. Remember, requirements are based upon what you the module must be able to do and are decided upon before you make actual implementation decisions. - Commonly Overlooked Requirements: Below is a list, by no means exhaustive, of considerations frequently overlooked in generating requirements. Consider if any apply to your project.
- Circuit protection: How will your circuit handle a sudden short/open?
- Input/Output protection: What would happen if a user inserted a plug or battery in backwards?
- Environment: Will your project function in hot or cold conditions? In the rain?
- Latency: What amount of time can be tolerated between user/data input and a response from your project?
- Software: What functions does your software need accomplish?
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.
- Define Equipment: Explicitly state what type of test equipment you will use to take a measurement (e.g., oscilloscope, DMM, yardstick, etc). You should also clearly define any additional equipment needed to perform a given test such as a variable load, or other sensor equipment needed to provide a "truth" signal for reference.
- Define Test Procedures: Give a step by step procedure for each test. An engineer who knows little to nothing about your project should be able to follow your procedures and make the correct measurements. Reference specific pin connections on electrical diagrams to tell the test engineer where to connect equipment.
- Define Presentation of Results: The verification procedure will state how the results will be recorded in your notebook and presented in your final report (table of data, graph, single numerical value, labelled diagram, etc).
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).