Recipe

Plan a small embedded project from a request

Use when: someone describes a device in everyday words and you have to build it and prove it works

Goal: a written plan whose every requirement has a test, and a build order that always leaves a working device

Taught in Engineering a project

1. 1

   List what the device must do. Give each an id, a number, a method and a pass line, and sort them into MVP, intermediate and advanced.

   Example

   D2 (MVP): buzzer starts 60 s ± 2 s after the door opens; stopwatch from door-open to sound; 5 of 5 trials.

   Why: a requirement without a pass line can't fail, so it can't tell you when you're done.

2. 2

   Boxes for inputs, firmware parts and outputs. Mark the hardware-free parts.

   Example

   reed switch → debounce → door timer (hardware-free) → buzzer, LED.

   Why: the hardware-free boxes are the ones host tests can prove before any wiring exists.

3. 3

   Parts with dated cost bands; a wiring table with one column per board. Check every row against the pin rules.

   Example

   Buzzer at 35 mA on an Uno R4 pin: over 8 mA, so it goes through an NPN transistor.

   Why: a pin-current or voltage mistake caught on paper costs nothing; on the bench it can cost a pin.

4. 4

   Order the milestones so each ends in a demo. Pair every requirement with a host test or a bench check in a traceability table.

   • a requirement has no test — write one, or admit it is a wish.
   • a test matches no requirement — drop it, or add the requirement it was protecting.

   Why: the table is how you know "done" without arguing.

5. 5

   Write steps a stranger could follow, including one failure. Afterwards compare estimates with results and score the rubric.

   Example

   Step 4: hold the door open; at 60 s the buzzer sounds. Step 5: unplug the reed switch; the LED shows a fault.

   Why: the review turns this project's surprises into the next project's requirements.