Testable requirements checklist

Turn "the product should be good" into requirements a team can build to and a test can pass or fail.

Check every requirement against this

• It says what, not how. It does not prescribe the solution.
• It has a number and a unit (hours, °C, mm, g, %, €).
• It names the conditions it applies in (temperature, load, user, environment).
• It names a test method and who runs it.
• It names when it will be verified (EVT, DVT or PVT).
• It traces back to a customer need. If you cannot say which, question it.
• It does not conflict with another requirement (size vs battery vs cost).
• Someone other than the author can say whether the product passes.

Weak to testable (example numbers: set your own)

Weak	Testable
Battery should last a long time.	At least 8 h of the standard use profile at 25 °C, measured from 100% to shutdown.
Must be rugged.	Survives 10 drops from 1.2 m onto concrete with no loss of function.
Easy to assemble.	Assembled in under 90 s by a trained operator with no tools beyond the fixture.
Runs cool.	Case surface stays below 45 °C after 2 h at full load in a 30 °C room.

The four-week set-up

Week	Output	Done?
1 · PRD	What the product must do and for whom, every line testable. Review with someone who will build it.
2 · TRD	Technical limits and interfaces, each with an owner. Interface specs signed by both sides.
3 · Critical path	Task list with dependencies. The longest chain marked. Lab and tooling lead times included.
4 · Kickoff	Plan with contingency written in. Risks listed. Gate criteria agreed in advance.

Why: a requirement nobody can test is a debate waiting to happen at the gate. Contingency is not padding; it is the honest admission that something unplanned will happen.

From The Hardest Hardware Lessons · thehardesthardwarelessons.com · Free to use and share with attribution.