An evidence-driven engineering workflow
Translate a need into testable requirements, compare concepts, prototype the riskiest assumption, and leave a traceable build record.
- Create a compact requirement-to-test record and use it to choose between two build concepts without erasing unresolved risk.
Related study — optional context
Understand
The working idea
Engineering begins with a need, but a build becomes tractable through requirements: statements that are specific enough to test. “Make a good desk robot” is a wish. “Stop at least 120 mm from a matte obstacle while moving at 0.15 m/s on the test surface” links behavior, conditions, and a threshold. Constraints limit the solution—budget, size, voltage, tools—while preferences help rank acceptable options.
A practical loop is define, explore, choose, prototype, test, and revise. First map functions rather than favorite parts: sense distance, decide when to stop, remove motor power, and support the sensor. Generate multiple concepts, then compare them against weighted criteria with assumptions visible. A decision matrix does not make judgment objective; it makes reasoning inspectable. Prototype the highest-risk unknown early. If sensor performance in sunlight is uncertain, test that before designing a polished enclosure.
Traceability connects each requirement to evidence. A verification table can list requirement, method, result, date, and artifact. Versioned notes, photographs, wiring diagrams, and small commits explain what changed and why. For a camera mount, the build decision might be a 210 mm brace because calculation predicts the location and a cardboard prototype confirms clearance. Record both; neither replaces the other.
A common failure is solution fixation: writing requirements that secretly mandate the first idea. Another is moving the goalposts after a failed test or polishing low-risk details while a core assumption remains unknown. A prototype is a question made physical, not automatically a smaller final product. Treat failures as evidence, keep unresolved items explicit, and revise either the design or a requirement only with a reason. A reproducible trail lets another builder challenge the decision instead of guessing what happened.
Follow the reasoning
Worked example
Choose a sensor mount using weighted scores. Rigidity weight 3, adjustability weight 2, build time weight 1. Fixed mount scores 5,1,5; slotted mount scores 3,5,3 on a 1–5 scale.
- 1
Fixed weighted score = 3×5 + 2×1 + 1×5 = 22.
- 2
Slotted weighted score = 3×3 + 2×5 + 1×3 = 22.
- 3
The equal totals expose a tradeoff rather than select a winner.
- 4
Choose a risk test: measure whether the slotted mount's lower assumed rigidity still meets the image-stability requirement.
The matrix produces a tie; a targeted rigidity prototype is the next justified action.
Sanity checkWeights sum to 6, so any total must lie from 6 to 30. Both scores of 22 are within range and should not be reported as proof of equal real performance.
Try it yourself
Independent check
Move to the bench
Produce and execute one traceable requirement test for a paper desk-robot subsystem.
- paper or cardboard
- ruler
- tape
- small inert mass
- phone camera
- notebook or versioned text file
Experiment
- Write one measurable requirement for a camera mast, including load, height range, and a simple pass criterion.
- Sketch fixed and adjustable concepts and record two criteria plus one unresolved assumption for each.
- Build the smallest cardboard prototype that tests the highest-risk assumption and predict its behavior.
- Deliberately loosen one tape joint as a fault; use the requirement test to identify which metric changes rather than merely calling it bad.
- Record actual result, photograph the setup, and write the next design decision with its evidence and remaining uncertainty.
Observe
- Expected: a sound joint supports the stated inert test mass within the chosen deflection limit; actual deflection and setup conditions belong in the record.
- Expected fault clue: the loose joint should increase deflection or reduce repeatability, linking a physical cause to a requirement metric.
Draft a requirement-to-test row for choosing a low-voltage blower in a vacuum-cleaner analogue, including airflow proxy, runtime, and a clear non-equivalence statement.
- Use only light inert loads and keep the prototype below eye level.
- A paper prototype does not validate structural, electrical, or product safety.
Keep evidence
Bench note
Record what you expected, what you actually measured or observed, and one difference worth investigating. This is self-reported evidence, not a certification.