Capstone Project Wiki

The requirements define the expected and actual performance of the product according to both the market and the development team. Expect the requirements to evolve as new information is obtained during the product development process. Each stage report submitted by the team must included updated requirements. While there are variety of ways for expressing and tracking requirements used by industry, for Capstone the requirements are captured in system and subsystem requirements matrices or the Software Requirements Specification (SRS).

See software projects for additional guidance when completing requirements for software projects.

The following elements should generally be part of the requirements artifacts section of stage reports. More information about these elements can be found in the Requirements Matrix chapter of the Product Development Reference in the textbook.

• Market Requirements: The market requirements capture the desires of the eventual customers of the product. They are more likely to be qualitative than quantitative. They will address the things customers think about when making purchasing decisions.
• Importance of Market Requirements: Not all market requirements have equal importance. Each requirement should be given an importance rating that is included as part of the requirements matrix. Be sure to indicate if a large number or small number indicates a requirement with high importance – we recommend that high importance should have large importance ratings.
• Performance Measures with Measurement Units: The performance measures represent the items the team will measure to determine how well a product meets the market wants. These are more likely to be quantitative than qualitative.
• Importance of Performance Measures: Not all performance measures have equal importance. Each measure should be given an importance rating that is included in the requirements matrix. The {Quality Function Deployment} entry in the Product Development Reference describes one way to calculate the importance of performance measures given the importance of the market requirements and the linkage between requirements and measures.
• Requirement – Measure Relationships: The relationships between the market requirements and the performance measures should be part of the requirements section. These relationships can be binary (yes/no) or can have a range of values (such as strong, medium, weak).
• Ideal Values: An important part of the requirements section is the ideal values. In most cases there are three values that are important, but sometimes there are only two. The ideal values represent the values the market would like to have if there were no tradeoffs to be made. However, there are always tradeoffs, so the actual design targets will likely differ from the ideal values.
  • Lower acceptable limit: This limit is the lower limit that is acceptable to the market. Any value lower than the lower acceptable limit will result in an unacceptable product.
  • Ideal value: This is the value that the market would desire if there were no tradeoffs to be made.
  • Upper acceptable limit: This is the upper limit that is acceptable to the market. Any value higher than the upper acceptable limit results in an unacceptable product.
• Real Values: The real values represent the values for the performance measures that are desired (given the need for tradeoffs), predicted, and measured for the product.
  • Design Targets: These are the values that the team intends to pursue, given all of the tradeoffs implicit in the selected system architecture.
  • Predicted Values: These are values of performance measures that are predicted during the product development process, generally as a result of engineering models of the product. The models used to predict performance should be defined in the tests section.
  • Measured Values: These are values of the performance measures that are measured using prototypes of the product. At the time of release to the production system, the measured values represent the actual demonstrated performance of the product. The experimental methods and procedures used to measure performance should be defined in the tests section.
• Market Response: When possible, the response of the market to the product should be tested with validation tests. This will generally be accomplished using prototypes. The degree to which the prototype meets the market requirements should be determined. The methods for validation testing should be described in the tests section.
• Performance Assessment: Having measured the performance of the product, an assessment of how well the product meets the performance measures and the market wants should be provided in the report overview. This requires the use of judgment applied to the testing results.

• Requirements Matrix: The most succinct summary of the product performance is the requirements matrix. In the opportunity development stage, there is only a single requirements matrix. In later stages, additional requirements matrices for subsystems and components can be created. The complete set of requirements matrices should be included in the requirements section. See the Requirements Matrix section of the Product Development Reference for more information on the requirements matrix. A template for the requirements matrix is also available on Learning Suite. A template file and examples are available on Box. The requirements matrices may be hard to read if printed on standard letter-size paper. It may be desirable to print the performance matrices on B-size (11 by 17 inch) paper.
• Software Requirement Specification: For software projects, or software components of mechanical projects, it may be preferable to use a software requirements specification (SRS) instead of a requirements matrix. For more information on the SRS go to Software Projects.
• Performance Graphs: In many cases, the measured or predicted performance is best represented by a graph rather than by a single number. In such cases, relevant graphs should be part of the requirements artifacts. Methods used to obtain the graphs should be part of the test artifacts, and should be cross-referenced here.