01
A good requirement is necessary.
Delete it. If nobody is worse off, it was never a requirement — only cost.
01 / ATTRIBUTEA good requirement is
necessary.
necessary.
/
Let’s talkTopic 01 / Systems Engineering
Fixed in requirements, it costs a sentence.
Fixed later, it costs the product.
That gap is what systems engineering exists to close. Not paperwork about the product — the discipline that keeps a whole team's idea of the product identical, from the first conversation to the last test report.
Explore the ten attributes ↓REQUIREMENT × EVIDENCE
One product. It changed hands, and changed.
01The customer described it.
02Sales retold it.
03The lead understood it.
04The document recorded it.
05Systems designed it.
06Software built it.
07Test ran it.
08Then the quote explained it.
Everyone was certain they agreed.
02
A good requirement is correct.
15–27 °C because that is the room — not 5–60 °C to be safe.
02 / ATTRIBUTEA good requirement is
correct.
correct.
03
A good requirement is complete.
A minimum with no maximum is half a requirement.
03 / ATTRIBUTEA good requirement is
complete.
complete.
04
A good requirement is concise.
One requirement, one issue. The rationale lives somewhere else.
04 / ATTRIBUTEA good requirement is
concise.
concise.
05
A good requirement is unambiguous.
Fast, easy, robust, as appropriate — every one is a future argument.
05 / ATTRIBUTEA good requirement is
unambiguous.
unambiguous.
06
A good requirement is verifiable.
Name the method now: inspection, analysis, demonstration or test.
06 / ATTRIBUTEA good requirement is
verifiable.
verifiable.
07
A good requirement is feasible.
Achievable with this technology, this budget, this schedule — or it is a wish.
07 / ATTRIBUTEA good requirement is
feasible.
feasible.
08
A good requirement is implementation-free.
Write “the user can view and change the calibration settings”, not “calibration is stored in MySQL”. The second is a design decision. If you really must fix the method, write it as a constraint and label it one.
08 / ATTRIBUTEA good requirement is
implementation-free.
implementation-free.
09
A good requirement is consistent.
Said once, in one vocabulary, contradicting nothing above or below it.
09 / ATTRIBUTEA good requirement is
consistent.
consistent.
10
A good requirement is traceable.
An ID, a parent, and a test that will one day cite it.
10 / ATTRIBUTEA good requirement is
traceable.
traceable.
02 / One requirement, two ways to write it“It shall fit in any lab.”
“It shall fit in any lab.”
Which lab?
Nobody can carry an instrument into “any lab” and try it, so this sentence can never be shown to be met — it never gets to be finished, and it never gets to be signed off. Three bounded dimensions can: height ≤ 1500 mm, width ≤ 1500 mm, depth ≤ 700 mm. Now it can be measured, and accepted. A few more minutes to write; weeks of argument saved.
A vague word today is an argument later.
Tap the underlined phrases. Each is a defect category from the ambiguity checklist, and each is somewhere a supplier can quote to their reading rather than yours.
The system processing of samples and provide results , blood and tissue.
Select a phrase to see what it costs.
03 / Anatomy of a requirementA requirement is not a sentence.
A requirement is not a sentence.
It is five decisions in a row.
When a cartridge is inserted, while the instrument is initialised, the instrument shall scan the cartridge.
- 01Trigger
When a cartridge is inserted — The moment the requirement applies. Written with When.
- 02Precondition
while the instrument is initialised — The state it depends on. Written with While.
- 03System
the instrument — Who performs it. A named thing — not “the system”.
- 04Response
shall scan — What it does. One observable action, not a capability.
- 05Object
the cartridge — What it acts on. Leave this out and the sentence is unfinished.
Field note / Extreme-environment wildfire recorder
Three failures, and the phase that should have caught each one.
The University of Melbourne's wildfire research laboratory, with forestry agencies in California and Victoria, commissioned a joint development: one field instrument carrying twelve sensor types. In the laboratory it performed beautifully.
Then it went to a fire ground.
None of the three failures below was an engineering mistake.
The enclosure was never a constraint.
The boards were finished before the customer specified a military blast-proof case with internal insulation. The usable volume turned out to be far smaller than assumed, and the design went back.
Where it should have been caughtDesign planning — the mounting environment was never locked. Design input — it was never written as a constraint.
The sensor was chosen, not specified.
A high-resolution differential pressure sensor, recommended and accepted, carried roughly a 0.75% zero offset. Nobody had written a test condition for drift, so it surfaced in the field — as about three metres per second of wind that was not there.
Where it should have been caughtDesign input — no performance condition. Design verification — no drift scenario in the protocol.
The real environment was never written down.
Fire-ground temperatures held above a thousand degrees for more than ten minutes. Heat travelled in through conduits and cabling and the interior reached 75 °C. Standard cells lost most of their life, commercial-grade parts drifted, and soft PVC air tubing deformed above 65 °C.
Where it should have been caughtDesign input — no operating temperature profile. Design output — no high-temperature material call-out. Verification and validation — no component behaviour at temperature.
All three were a requirement that was never written.
Specify the distribution.
An LLM agent has no pass/fail line. What you can give it is a unit, a method of measurement and a target distribution — plus a route to a human for the tail you did not specify.
An unverifiable requirement is a wish.
Every requirement is born with its verification method attached. If you cannot say how you would test it, you have not finished writing it.
The V does not close by itself.
Define ↓ each level narrows the lasteach level answers one ↑ Prove
05Design output
Select a level to see what it produces and what proves it.
One vocabulary
A glossary costs an afternoon. An argument about what “done” means costs a sprint, and it will happen more than once.
One requirement, one method
Inspection, analysis, demonstration or test — decided while writing, recorded in the trace matrix, never invented at verification time.
Gates, not filing dates
Design input and design output are decisions about whether to carry on. If nothing can fail them, they are not gates.
Verification and validation are not the same test.
Two steps, two different questions, two different kinds of evidence. Confusing them is how a programme passes every test and still ships the wrong product.
Asks — did we build the right product?Checked against what the user actually has to do.
Evidence is real people, in their environment, finishing the real task. Which is why verification can pass in full and validation still fail — the product is exactly what was specified, and the specification was wrong.
Before you sign off design input
Ask five uncomfortable questions.
- Can every requirement here be tested, and does each one say how?
- Is there anything in here we committed to that the customer never asked for?
- What is the real operating environment, and where is that written down?
- Which term in this document means two different things to two people?
- If this requirement is wrong, when do we find out — and what does it cost by then?
Good design makes meaning visible