Trace Requirements to Tests in an Engineering Design Report

An engineering design report is stronger when readers can trace each important requirement to a design choice and a verification result. Attractive diagrams and calculations are useful, but the report should still answer a basic question: did the design meet the stated need under defined conditions? A small requirements table can reveal gaps before submission. Use the course brief, applicable standards and actual test evidence; never invent a pass result for a test that was not performed.

Turn needs into testable requirements

Translate broad phrases such as “lightweight,” “safe” or “easy to use” into criteria appropriate to the project. Give each requirement an identifier, rationale, measurement or observation method and acceptance condition. If a client requirement is qualitative, explain how it will be assessed. Keep assumptions separate from confirmed requirements. A number has little meaning without units, operating conditions and a method for measuring it.

Link choices to constraints

For each design alternative, show how it responds to requirements and what trade-offs it creates. A lighter material may change cost, durability or manufacturing constraints. Explain the calculation, simulation or reasoning behind selecting an option. If a standard is cited, identify the applicable version and clause that actually matters, and confirm it is appropriate to the context. Do not decorate the report with standard names you have not consulted.

Define verification before results

Decide what test, inspection or analysis can demonstrate each criterion. Record equipment, calibration assumptions, sample conditions and repetitions as required by the brief. Distinguish verification of the design against specifications from validation of whether it solves the user’s problem. When physical testing is impossible, explain the model’s assumptions and limits rather than describing a simulation as a field trial.

Report failed or incomplete checks

A failed criterion is valuable information when it identifies a design change. Record the observed result and whether it falls outside the acceptance range. If a test was not run, mark it unverified rather than passed by implication. Discuss measurement uncertainty and conditions that could affect repeatability. A report that hides failures prevents the reader from judging feasibility.

Close the loop in the conclusion

Summarise which requirements were met, which remain uncertain and what change or additional test is needed. Link each claim back to the evidence table. A recommendation to build a second prototype should identify the specific weakness it addresses. Keep calculations, drawings and test data accessible in labelled appendices while the main text explains the engineering decision.

Worked example

For a student bridge prototype, a requirement might specify a load at a given span and mass limit. A traceability row links that requirement to member sizing calculations and a measured load test, including whether the prototype met the threshold. If the team tested only one prototype, the report should state that limitation rather than claiming general reliability across all future builds.

A small traceability matrix

Create four columns: requirement ID, design element, verification method and result. For a device that must operate for a stated duration, link the requirement to power budgeting and a timed test under specified conditions. If you only calculated expected battery life, mark physical verification pending. If a measured result misses the threshold, note the discrepancy and likely design change. Add a fifth column for evidence file or figure when the report has many appendices. This matrix can reveal that a polished prototype addresses most requirements but leaves one safety or usability condition untested. Use the discovery to improve the design or make an honest recommendation for the next iteration. It also gives the reader a direct path from the original need to the final engineering judgment.

Checklist before you submit

Identify requirements with units and conditions.
Map each requirement to design rationale and verification.
Mark untested criteria as unverified.
State what the evidence supports in the final recommendation.

Questions students ask

Do calculations alone prove a prototype meets the requirement?

They support a design prediction. Whether physical verification is also required depends on the brief and the nature of the requirement.

Should failed tests be removed from the report?

No. Explain the failure, the likely cause and the design or test change it motivates.