An evidence-driven engineering workflow

• Create a compact requirement-to-test record and use it to choose between two build concepts without erasing unresolved risk.

• units-estimation

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.

Problem

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.

Steps

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.

Result

The matrix produces a tie; a targeted rigidity prototype is the next justified action.

Sanity check

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

Which requirement is most directly verifiable?

A. The robot shall stop 120–150 mm from a flat target in 9 of 10 trials on the named surface B. The robot shall feel safe C. The robot shall use an ultrasonic sensor D. The robot shall be innovative

Your answer: ______________________________

Reasoning:

Goal

Produce and execute one traceable requirement test for a paper desk-robot subsystem.

Equipment

• paper or cardboard
• ruler
• tape
• small inert mass
• phone camera
• notebook or versioned text file

Procedure

1. Write one measurable requirement for a camera mast, including load, height range, and a simple pass criterion.
2. Sketch fixed and adjustable concepts and record two criteria plus one unresolved assumption for each.
3. Build the smallest cardboard prototype that tests the highest-risk assumption and predict its behavior.
4. Deliberately loosen one tape joint as a fault; use the requirement test to identify which metric changes rather than merely calling it bad.
5. Record actual result, photograph the setup, and write the next design decision with its evidence and remaining uncertainty.

What to 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.

Transfer challenge

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.

Cautions

• Use only light inert loads and keep the prototype below eye level.
• A paper prototype does not validate structural, electrical, or product safety.

Learner: ____________________ Date: ____________________

Evidence artifact or file: ____________________________________________

Notes: