Requirements — SMART (Specific, Measurable, Achievable, Relevant, Testable): Visual walkthrough

This is the visual companion to the SMART topic note. Read that first for the rules; read this to feel the derivation.

Step 1 — Start with the raw wish (the fuzzy cloud)

WHAT: We begin with the most honest starting point: a sentence a human being would actually say out loud. "The satellite shall be lightweight."

WHY: Before we can appreciate why SMART helps, we must see the disease it cures. A wish like this has no edges. If I gave it to five engineers, I would get five different satellites. We need a way to picture that ambiguity so we know exactly what each SMART filter is removing.

PICTURE: The figure shows the wish as a soft cloud. Inside the cloud are many little dots — every dot is a different satellite that someone could honestly claim satisfies the words "lightweight." A 40 kg cubesat is in there. So is a 900 kg bus that its team feels is light "for its class." Nothing in the words excludes either.

Figure — Requirements — SMART (Specific, Measurable, Achievable, Relevant, Testable)

Step 2 — Filter Specific: name the thing (cut the cloud in half)

WHAT: We force the sentence to say exactly which part is constrained. Not "the satellite" — the bus structure. Not the payload, not the fuel, not the solar panels.

WHY: The word "satellite" pointed at everything at once, so every subsystem thought the requirement was about them (or about someone else). Naming the scope removes every dot in the cloud that belongs to a different component. This is the first real narrowing.

PICTURE: The cloud from Step 1 is sliced by a vertical line. Everything on the "wrong component" side (payload masses, fuel masses) is greyed out and dropped. What survives is the strip of dots that are genuinely about the bus structure.

Step 3 — Filter Measurable: attach a number, a unit, an operator, a tolerance (collapse to a boundary)

WHAT: We replace the fuzzy word "lightweight" with the things any physical constraint needs: a value, a unit, a comparison operator, a tolerance / measurement uncertainty, and the conditions under which it holds.

WHY this and not something softer? Because physics only speaks in dimensioned quantities. A mass is a number times a unit — 150 alone means nothing; 150 kg means something. And to make the sentence a gate (pass/fail) we need a comparison operator that draws a line: everything on one side passes, everything on the other fails. That is what makes it falsifiable.

Why tolerance is not optional: every real measurement has uncertainty. If a scale reads $150.0 kg \pm 0.3 kg$ , a part that weighs exactly $150 kg$ might read anywhere from $149.7$ to $150.3$ . Without a stated tolerance, a part sitting right on the line is undecidable — and an undecidable case is not falsifiable. So a truly measurable requirement pins down both the target value and the measurement uncertainty band around the check.

PICTURE: The strip of dots gets a hard vertical wall dropped onto it at $150 kg$ . Around the wall is a thin fuzzy band — the measurement uncertainty — showing that parts landing inside the band are the ones your instrument cannot cleanly call. Dots clearly to the left (lighter) turn green — they PASS. Dots clearly to the right turn coral — they FAIL. The requirement is now a boundary, not a mood.

Formula The anatomy of the measurable sentence

$the parameter m_{bus} operator: draws the pass/fail line \leq the value 150 the unit, gives the number meaning [kg] measurement tolerance (\pm 0.3 kg) the condition, when it applies at launch config$

$m_{bus}$ — the measurable quantity. You can put a scale under it.
$\leq$ — without this you have a fact, not a requirement. It is the gate.
$150$ — the number the value must not cross.
$[kg]$ — strip this and $150$ could mean grams, pounds, or newtons. Units are not decoration.
$(\pm 0.3 kg)$ — the uncertainty of the measurement/verification. It tells you how close to the line is "too close to call," so a part near the boundary still has a defined verdict.
"at launch config" — a mass can change (fuel burns off), so we pin down when we weigh it.

Step 4 — Filter Achievable: check the boundary sits inside reality

WHAT: A sentence can be perfectly measurable and still be impossible. Achievable asks: does the line we drew fall inside the region physics, technology, and budget actually allow?

WHY: You can write " $Δ v = 50 km/s$ on chemical propulsion" — it's specific and measurable — but no amount of engineering effort reaches it. Drawing a boundary in an impossible place doesn't shrink the design cloud; it empties it, and you discover this only after wasting a year. So we overlay a feasibility region and require the boundary to overlap it.

PICTURE: Two vertical bands. The green feasible band is where real bus structures can live (given materials and cost). The coral infeasible band is beyond physics/budget. Our $150 kg$ wall must land inside the green band. The figure shows a good requirement (line in green) and a doomed one (line in coral) side by side.

Formula Why the doomed propulsion example is impossible — worked in the open

The Tsiolkovsky rocket equation (Tsiolkovsky Rocket Equation) relates the speed change $Δ v$ to how much mass you throw away: $Δ v = v_{e}, exhaust speed I_{s p} g_{0} ln wet / dry mass ratio \frac{m _{0}}{m _{f}}$

$I_{s p}$ — the specific impulse, measured in seconds. Read it as "how many seconds one unit-weight of propellant can produce one unit of thrust" — a fuel's efficiency score. Bigger $I_{s p}$ means each kilogram of propellant buys you more speed change.
$g_{0} = 9.81 m/s^{2}$ — standard gravity, the constant that converts the seconds of $I_{s p}$ into a real exhaust speed in m/s.
$v_{e} = I_{s p} g_{0}$ — the exhaust speed: how fast gas leaves the nozzle.
$m_{0}$ — the wet mass (structure + all propellant, at ignition); $m_{f}$ — the dry mass (structure alone, tanks empty).

Take a high-performance cryogenic chemical engine (liquid hydrogen / liquid oxygen, quoted in vacuum) — about the best chemical rocketry offers, $I_{s p} \approx 450 s$ . This is a specific, best-case figure, not a universal chemical constant: storable propellants like hydrazine sit far lower (~230 s), and sea-level values are lower still than vacuum. Using this best case, $v_{e} = 450 \times 9.81 = 4414.5 m/s .$ To reach $Δ v = 50000 m/s$ we need $\frac{m _{0}}{m _{f}} = e^{50000/4414.5} = e^{11.33} \approx 8.3 \times 1 0^{4} .$ With a $100 kg$ dry mass that is over 8 million kg of propellant — outside every green band that exists. Measurable ✓, achievable ✗.

Now the achievable counterpart. Suppose a small-satellite mission needs a $Δ v$ of at least $500 m/s$ (enough for orbit maintenance and de-orbit). We write:

Check it against the rocket equation. Hydrazine (a storable propellant, hence the much lower score) has $I_{s p} \approx 230 s$ , so $v_{e} = 230 \times 9.81 = 2256.3 m/s$ . Mass ratio $= (50 + 10) /10 = 6$ : $Δ v = 2256.3 \times ln 6 = 2256.3 \times 1.7918 \approx 4043 m/s,$ which comfortably clears the $500 m/s$ target — so this line lands well inside the green band. (Achievability leans on Technology Readiness Levels (TRL) and the Mass Budget.)

Step 5 — Filter Relevant: connect the boundary upward to why

WHAT: Even a measurable, achievable line can be pointless. Relevant demands the requirement trace up a chain to a real mission objective. If cutting it doesn't hurt the mission, it shouldn't exist.

WHY: Every requirement costs money, mass, and schedule to verify. An orphan requirement — one that traces to nothing — is pure cost with no benefit. Tracing up also protects the mission: if you delete a relevant one, the objective visibly breaks.

PICTURE: A vertical chain of three linked boxes. Top: Mission objective. Middle: System requirement. Bottom: our subsystem requirement (the $150 kg$ bus). Green arrows point upward — "exists because of." We test relevance by covering the top box and asking: does anything below still have a reason to live? If not, cut it.

Step 6 — Filter Testable: pick the proof that closes the loop

WHAT: The final filter asks: how will we prove it? Every good requirement names (or clearly permits) one of four verification methods. Spelled out in full, these are:

T = Test — exercise the real hardware/software and measure the result (e.g. shine a simulated sun on a panel and read the watts).
A = Analysis — prove it with a validated mathematical model or simulation when a full-scale test is impractical (e.g. re-entry heating).
I = Inspection — directly look at or measure the item (e.g. put the structure on a calibrated scale, read a dimension with a gauge).
D = Demonstration — run an operational scenario and observe the correct end-to-end behaviour (e.g. a complete command-and-response sequence).

WHY: A boundary you cannot check is a boundary you hope is met. Hope ships broken hardware. Choosing the method up front forces the requirement to be phrased in checkable language and reserves the budget/schedule for the check.

PICTURE: The four methods as four gates, and the requirement's domain decides which gate it walks through. A mass requirement → Inspection (put it on a scale). A power requirement → Test (shine simulated sun, measure watts). A re-entry heating requirement → Analysis (you can't build a full re-entry on the bench). A complex operational sequence → Demonstration.

Step 7 — The degenerate cases (what SMART looks like when it fails)

WHAT: A derivation isn't complete until you show every way it breaks. Here are the five failure modes — one per SMART letter, each is a filter left open.

WHY: Real requirement documents rot at exactly these gaps. Recognising the shape of a broken requirement is more useful than memorising the good one.

PICTURE: Five mini-panels, one broken filter each:

No S (vague scope): the slice in Step 2 never happens — "the satellite shall be light," so every subsystem thinks it's someone else's number; the cloud never narrows.
No M (fuzzy): the wall in Step 3 is missing — every dot passes, nothing fails, unfalsifiable.
No A (impossible): the wall lands entirely in the coral band — every dot fails, empty design space.
No R (orphan): the trace chain in Step 5 has a broken top link — floating box, no reason.
No T (process not performance): "shall be designed to withstand loads" — no gate to walk through, unverifiable.

The one-picture summary

Here is the entire walkthrough on one canvas: the fuzzy wish enters the funnel at the top, each SMART letter is one narrowing ring, and a single sharp, falsifiable, verifiable sentence drops out the bottom. The whole thing lives inside the Systems Engineering V-Model — SMART is how the left arm of the V (requirements) is written so the right arm (verification) can prove it.

Recall Feynman retelling — say it to a friend in plain words

Imagine you shout a wish across a workshop: "make it light!" That wish is a cloud — a hundred different satellites could all claim to be "light," so nobody knows what to build. SMART is a funnel that squeezes the cloud into one buildable sentence, one squeeze per letter.

Specific cuts away everything about the wrong part — we mean the bus structure, not the fuel. Measurable drops a hard wall onto the survivors — " $\leq 150$ kg, measured to $\pm 0.3$ kg" — so now there's a definite pass side and a fail side, and even a part sitting near the line has a defined verdict; you can weigh it and know. Achievable checks the wall isn't in fantasy land: you can write " $50$ km/s on chemical fuel," but even the best cryogenic engine's rocket equation says you'd need eight million kilograms of propellant, so that wall sits in the forbidden zone. Relevant asks why the wall is even there — it must trace up to a mission goal; if you can delete it and nothing breaks, it was dead weight. Testable picks how you'll prove it — Test it, Analyse it, Inspect it, or Demonstrate it — because a limit you can't check is just a wish wearing a number.

Pass all five filters and you get a sentence that is falsifiable: one experiment, one clean pass-or-fail, no arguments. That single sentence is the contract between what you need and what gets built.

Reveal check:

Why is "the satellite shall be lightweight" not falsifiable?

It names no number, so no measurement can ever contradict it — nothing can prove it false.

Which SMART letter turns the wish into a pass/fail boundary?

Measurable — it supplies the value, unit, comparison operator, and tolerance.

Why must a measurable requirement state a tolerance?

Every measurement has uncertainty; without a tolerance a part sitting on the line is undecidable, and an undecidable case is not falsifiable.

Why does

Δ v = 50 km/s

on chemical propulsion fail Achievable?

Even the best cryogenic engine demands a mass ratio

e^{11.33} \approx 83000

, i.e. ~8 million kg of propellant for a 100 kg dry mass — outside physical/budget reality.

What do the four letters T, A, I, D stand for?

Test, Analysis, Inspection, Demonstration — the four verification methods.

Why is "shall be designed to withstand loads" untestable?

It constrains the design process, not a measurable product performance, so no verification gate applies.