Intuition What this page is for
The parent note gave you the five letters. But a real requirements document throws many different kinds of broken requirement at you, and each kind fails for a different reason and needs a different fix .
This page is a case matrix : we list every category of scenario the topic can hand you, then work one full example per category — guessing first, fixing step by step, then verifying the fix actually passes. By the end you should never meet a requirement you don't know how to attack.
Before anything, one word we will use constantly: a requirement is verifiable (or falsifiable ) if there exists a concrete measurement or calculation whose result definitively says "pass" or "fail". A requirement you can argue about forever is not verifiable. Keep that picture: a requirement is a locked gate — either the key fits or it doesn't.
One term will recur too: FEA stands for finite-element analysis — a computer method that chops a structure into thousands of tiny blocks ("elements") and solves the physics on each, so you can predict stresses and vibration frequencies before building hardware. Whenever you see FEA below, picture a mesh of little tiles covering the part.
Every broken (or checkable) requirement you'll meet falls into one of these cells. Each row is a distinct failure mode or edge case ; the last column names the worked example that covers it.
#
Case class
The trap / edge
Which SMART letter it stresses
Example
1
Vague adjective
"lightweight", "robust" — no number
Specific + Measurable
Ex 1
2
Number but no conditions
value given, but when/where missing
Measurable
Ex 2
3
Physics-impossible
violates a hard law (rocket eq.)
Achievable
Ex 3
4
Degenerate / zero input
tolerance = 0, or "exactly" with no margin
Measurable + Achievable
Ex 4
5
Orphan requirement
traces to nothing — bureaucracy
Relevant
Ex 5
6
Process not performance
"shall be designed to..."
Testable
Ex 6
7
Real-world word problem
derive a number from a mission goal
all five
Ex 7
8
Exam twist
requirement that looks fine but hides a limiting-value failure
Achievable (limit)
Ex 8
We will hit every cell . Read a statement, cover the fix, make your Forecast , then check yourself.
Worked example Ex 1 — Case 1: the vague adjective
Statement (broken): "The antenna boom shall be stiff."
Forecast: Which two SMART letters does this fail, and what single quantity would you pin a number to?
Step 1 — Name the failure.
Why this step? Before fixing, you must say why it's broken, or you'll fix the wrong thing. "Stiff" is an adjective with no number → fails Specific (stiff how ? against what load?) and Measurable (no quantity, no units).
Step 2 — Choose the physical quantity that means "stiff".
Why this step? "Stiff" for a boom means it doesn't sag or wobble — i.e. its first natural bending frequency f 1 is high (a floppy boom vibrates slowly). We pick f 1 because it is directly measurable on a shaker table.
Step 3 — Pick a number with justification.
Why this step? A number needs a reason , or it fails Relevant. Launch vehicles put most vibration energy below ∼ 100 Hz ; to avoid resonance we demand f 1 ≥ 120 Hz (comfortably above that band).
Step 4 — Add units + a verification method.
"The antenna boom's first bending mode shall be f 1 ≥ 120 Hz , verified by modal analysis (FEA) and confirmed by a sine-sweep vibration test."
Verify: Read it back — is there a measurement that returns pass/fail? Sweep the shaker, read the first resonance peak, compare to 120. Yes. Units are Hz. Gate now locks. ✅
The Verification and Validation step here uses two methods (analysis + test) — that's normal for structural requirements.
Worked example Ex 2 — Case 2: a number, but no conditions
Statement (broken): "The solar array shall generate 3 kW."
Forecast: It has a number and units. So what's still missing — and could a panel that outputs 3 kW on the ground still fail this exact wording in orbit ?
Step 1 — Spot the unbounded condition.
Why this step? Power depends on when (beginning vs end of life), where (distance from Sun), how oriented (angle to sunlight), and how hot (a cell's voltage, hence power, falls as it heats). "3 kW" without these is unverifiable — you can't build a test that means anything.
Step 2 — Bound each condition.
Why this step? Each missing condition is a way the number could silently change:
Time: panels degrade from radiation → specify end-of-life (EOL) , the worst case.
Distance: solar flux falls as 1/ d 2 → fix at 1 AU (flux S = 1367 W/m 2 ).
Orientation: power ∝ cos θ where θ is the angle off normal → specify normal (θ = 0 ) .
Temperature: silicon-cell output drops roughly 0.4% per ∘ C of heating, so the same panel makes less power hot than cold → we must bound the thermal range the requirement holds over, e.g. − 100 ∘ C to + 120 ∘ C (the panel's cold eclipse exit up to hot full-sun soak).
Step 3 — Add a tolerance.
Why this step? No real cell hits an exact number; manufacturing spread and measurement error need a band. Use ± 5% .
Step 4 — Assemble.
"The solar array shall generate ≥ 3 kW ± 5% electrical power at EOL, oriented normal to sunlight at 1 AU, over − 100 ∘ C to + 120 ∘ C ."
Verify — sanity-check the physics is self-consistent. If the array is instead tilted at θ = 6 0 ∘ , power drops by cos 6 0 ∘ = 0.5 , i.e. to 1.5 kW . So the "normal" condition is not cosmetic — it changes the answer by a factor of 2. The condition earns its place. ✅
The figure above shows why each condition matters : the orange curve is power versus off-normal angle θ (the cos θ law — halved at 6 0 ∘ ), and the teal curve is power versus cell temperature (the gentle downward slope). A "3 kW" with no conditions could land anywhere along either curve.
Worked example Ex 3 — Case 3: physics-impossible (the Achievability wall)
Statement (broken): "The propulsion system shall provide Δ v = 20 km/s using chemical propulsion with dry mass ≤ 200 kg ."
Forecast: Guess the required mass ratio m 0 / m f . More than 10? More than 100?
Step 1 — Pick the tool: the Tsiolkovsky Rocket Equation .
Why this tool and not another? Δ v , exhaust speed and mass are linked by exactly one law:
Δ v = v e ln ( m f m 0 )
where m 0 = wet (full) mass, m f = dry (empty) mass, and v e = I s p g 0 is exhaust speed. It's the only equation that answers "is this Δ v possible with this propellant?" — so it decides Achievable .
Step 2 — Get v e for the best chemical propellant.
Why this step? Achievability is a best-case test: if the best chemistry can't do it, none can. Best chemical specific impulse I s p ≈ 450 s , and g 0 = 9.81 m/s 2 , so
v e = 450 × 9.81 = 4414.5 m/s .
Step 3 — Invert the rocket equation for the mass ratio.
Why this step? We want the demand the requirement places on the design:
m f m 0 = exp ( v e Δ v ) = exp ( 4414.5 20000 ) = e 4.530 ≈ 92.8.
Step 4 — Translate to propellant mass.
Why this step? A ratio is abstract; kilograms are not. With m f = 200 kg :
m 0 = 92.8 × 200 ≈ 18 560 kg , m prop = m 0 − m f ≈ 18 360 kg .
Over 18 tonnes of propellant to move a 200 kg spacecraft — physically legal, but absurd for anything but a giant stage. Fails Achievable for a small satellite.
Step 5 — Rewrite to something feasible.
"The propulsion system shall provide Δ v ≥ 500 m/s using monopropellant hydrazine (I s p ≈ 230 s ), propellant mass ≤ 50 kg , dry mass ≤ 10 kg ."
Verify the fix delivers. v e = 230 × 9.81 = 2256.3 m/s , mass ratio = ( 50 + 10 ) /10 = 6 :
Δ v = 2256.3 × ln 6 = 2256.3 × 1.7918 ≈ 4043 m/s ≥ 500. ✓
Comfortable margin. ✅
Read the plot carefully. The horizontal axis is mass ratio m 0 / m f and the vertical axis is Δ v in km/s. The orange curve is the rocket equation itself: it bends over because ln grows ever more slowly — doubling the ratio adds a fixed chunk of Δ v , never a proportional one. The teal dashed line marks the impossible 20 km/s demand; drop straight down and you land near ratio 93 , out where the curve is almost flat, i.e. where each further km/s costs a wall of propellant. The plum dot is the feasible fix (ratio 6). This is the whole reason Case 3 fails: the log makes high Δ v exponentially expensive.
Worked example Ex 4 — Case 4: the degenerate / zero-tolerance input
Statement (broken): "The optical bench alignment shall be exactly 0.000 000 rad (perfectly parallel)."
Forecast: What's mathematically wrong with a tolerance of exactly zero , before any physics?
Step 1 — Test the boundary case: tolerance → 0 .
Why this step? A requirement is verified by measuring, and every measurement has finite precision δ > 0 . The pass condition is
∣ measured − target ∣ ≤ tolerance .
If tolerance = 0 , this can be satisfied only when your instrument reads a perfect zero — but no instrument resolves below its own noise floor. So the probability of a pass is effectively 0 . A zero-tolerance requirement is unverifiable → fails Measurable in the limit.
Step 2 — Replace zero with the smallest meaningful tolerance.
Why this step? The right tolerance is set by (a) what the mission actually needs and (b) what you can measure. Suppose the science needs parallelism within 50 μ rad , and your autocollimator resolves 5 μ rad (i.e. the smallest angle change it can read is 5 μ rad ). Choose the science value (50 μ rad ), because it is the looser, driving number and it is comfortably coarser than what the instrument can see.
Step 3 — Rewrite.
"The optical bench alignment shall be 0 ± 50 μ rad about each axis, verified by autocollimator inspection (resolution ≤ 5 μ rad )."
Verify — is the instrument good enough? Rule of thumb: the tolerance must be several times the instrument resolution, or you can't tell pass from noise. Here 50/5 = 10 × headroom — plenty. Had we instead demanded 0 ± 2 μ rad with that same 5 μ rad instrument, the ratio would be 2/5 = 0.4 < 1 → the tolerance is finer than the instrument can read , so it is unmeasurable — another degenerate failure. This is exactly why Step 2 kept the tolerance (50 ) well above the resolution (5 ). ✅
Common mistake The zero-tolerance trap
"Exactly", "perfectly", "zero" are red flags. They read as high quality but are actually impossible to verify . Every real quantity needs a band as wide as the mission allows, no wider — and never finer than your measuring instrument can resolve.
Worked example Ex 5 — Case 5: the orphan (fails Relevant)
Statement (suspicious): "The onboard computer shall log every CPU temperature reading to permanent storage at 100 Hz for the full mission."
Forecast: Nothing here is vague or impossible. So why might a reviewer delete it?
Step 1 — Ask "what mission objective does this trace to?"
Why this step? Relevant means every requirement links upward through a Requirements Traceability Matrix to a mission need. If nothing above it needs this, it's dead weight — cost and mass with no payoff.
Step 2 — Compute the burden it imposes.
Why this step? Show the cost so "cut it" is defensible. A temperature word is 2 bytes. At 100 Hz over a 2 -year mission:
N = 100 × ( 2 × 365 × 24 × 3600 ) = 100 × 63 072 000 = 6.307 × 1 0 9 samples ,
storage = 2 bytes × 6.307 × 1 0 9 = 1.261 × 1 0 10 bytes ≈ 12.6 GB (decimal, 1 0 9 bytes) .
Around 12.6 GB of non-volatile memory — real mass, power, and downlink cost.
Step 3 — Decide: retie or cut.
Why this step? If thermal engineers only need trend data, 1 Hz with a rolling buffer suffices. Retie it to a real objective and slash the rate:
"The computer shall record CPU temperature at 1 Hz into a 24 -hour rolling buffer, to support in-flight thermal-anomaly diagnosis (traces to Mission Obj. Maintain safe thermal state )."
Verify — recompute the burden. 1 Hz × 86 400 s × 2 bytes = 172 800 bytes ≈ 0.17 MB . From 12.6 GB down to ∼ 0.17 MB — a ∼ 73 000 × reduction, and now it traces . ✅
Worked example Ex 6 — Case 6: process, not performance (fails Testable)
Statement (broken): "The bracket shall be designed to withstand launch vibration."
Forecast: How would you test whether something was "designed to" do anything? (Trick: you can't.)
Step 1 — Separate process words from performance words.
Why this step? "Designed to", "intended to", "shall consider" describe what engineers do , not what hardware achieves . You can inspect a hardware outcome; you cannot test an intention. So this fails Testable .
Step 2 — State the performance the hardware must reach, and where the number comes from.
Why this step? Replace intent with a measurable survival condition — but the number can't be invented, it must come from the launch environment. Launch-vehicle user manuals publish a quasi-static design limit load : the steady acceleration a payload feels during peak thrust and transients. A typical small-launcher value is 8 g axial (along the thrust axis). We adopt the manual's 8 g because that is the load the hardware will actually see; then qualification testing goes to 1.25 × that (a standard margin factor, 10 g ) to prove margin beyond the flight case.
Step 3 — Rewrite with a verification method.
"The bracket shall survive ≥ 8 g axial quasi-static load without yielding, verified by FEA and by vibration qualification testing to 1.25 × limit load (10 g )."
Verify — is the pass/fail concrete? Compute the qualification level: 1.25 × 8 g = 10 g . Test to 10 g on a shaker, inspect for yield/crack — a binary result. Compare to the process version: there is no test that returns pass/fail. The rewrite is testable, the original isn't. ✅
This mirrors the Systems Engineering V-Model : every requirement on the left descending arm must have a matching verification on the right ascending arm. A process requirement has no partner to climb back up to.
Worked example Ex 7 — Case 7: the real-world word problem (all five letters)
Statement (goal, not yet a requirement): "Our Earth-observation mission must geolocate each image pixel to within ± 30 m on the ground. The camera flies at 500 km altitude. Turn this into a SMART pointing requirement for the attitude control system."
Forecast: Guess — will the allowed pointing error be around 60 μ rad , or 600 μ rad ?
Step 1 — Pick the geometry tool.
Why this tool? A pointing error is an angle θ ; the ground miss Δ x it causes at slant range h obeys, for small angles,
Δ x ≈ h ⋅ θ .
We use the small-angle form because θ here is microradians — tan of a microradian equals the microradian itself to 12 decimal places, so the linear form is exact enough.
Step 2 — Solve for the allowed angle.
Why this step? Invert to get the constraint the ACS must meet:
θ ≤ h Δ x = 500 000 m 30 m = 6.0 × 1 0 − 5 rad = 60 μ rad .
(So the Forecast's first guess wins.)
Step 3 — Convert to arcseconds (attitude-control specs are often written in these).
Why this step? 1 rad = 206 265 arcsec , so
θ = 6.0 × 1 0 − 5 × 206 265 ≈ 12.4 arcsec .
Step 4 — Write it SMART.
"The attitude control system shall control line-of-sight pointing to ≤ 60 μ rad (≤ 12.4 arcsec , 3 σ ) per axis during imaging, verified by star-tracker telemetry analysis and closed-loop simulation."
Specific: line-of-sight, per axis, during imaging.
Measurable: 60 μ rad , 3 σ .
Achievable: modern star trackers reach a few arcsec — comfortably below 12.4 .
Relevant: traces directly to the ± 30 m geolocation objective.
Testable: telemetry + simulation.
Verify — round-trip the number. Plug θ = 60 μ rad back in: Δ x = 500 000 × 6.0 × 1 0 − 5 = 30 m . Exactly the objective — so no margin is lost and none is wasted. ✅
The figure shows why the small-angle tool is legitimate here: the true miss h tan θ (teal dashed) and the linear h θ (orange) are visually one line across the whole microradian range, and the plum dot marks 60 μ rad → 30 m .
Worked example Ex 8 — Case 8: the exam twist (a hidden limiting-value failure)
Statement (looks fine): "The reaction wheel shall store angular momentum ≥ 10 N⋅m⋅s and be sized so that saturation is reached no sooner than once per orbit under a disturbance torque of 2 × 1 0 − 4 N⋅m ."
Forecast: Every word is quantitative and testable — so it looks SMART. But is it Achievable ? Compute how long 10 N⋅m⋅s actually lasts against that torque.
Step 1 — Pick the accumulation tool.
Why this tool? A constant torque τ builds stored momentum linearly: H = τ t . So the time to saturate is
t sat = τ H m a x .
This is the only relation linking the stated capacity, the stated torque, and the "once per orbit" claim — so it's the one that exposes the trap.
Step 2 — Compute the saturation time.
t sat = 2 × 1 0 − 4 N⋅m 10 N⋅m⋅s = 5 × 1 0 4 s .
Step 3 — Compare to one orbit.
Why this step? The requirement demands t sat ≥ one orbit. A low-Earth orbit is about 90 min = 5400 s . Then:
5 × 1 0 4 s = 50 000 s ≫ 5400 s .
The wheel lasts about 50 000/5400 ≈ 9.3 orbits — far more than required. The "twist" is that the requirement is not impossible; it is loosely over-specified : the momentum floor of 10 N⋅m⋅s is ∼ 9 × larger than the once-per-orbit condition needs.
Step 4 — Find the matched number.
Why this step? The just-sufficient capacity for exactly one orbit is
H need = τ ⋅ t orbit = 2 × 1 0 − 4 × 5400 = 1.08 N⋅m⋅s .
So a tighter, still-safe requirement (with, say, a 2 × margin) would be H ≥ 2.2 N⋅m⋅s — a lighter, cheaper wheel that still meets the intent.
Verify — check the margin ratio both ways. Original: 10/1.08 ≈ 9.3 × margin (wasteful). Proposed: 2.2/1.08 ≈ 2.0 × margin (healthy). Both are Achievable; the exam point is that passing SMART's letters is necessary but not sufficient — you still audit for silent over-design. ✅
Recall Self-test: which cell is each requirement in?
"The panel shall be robust." ::: Case 1 — vague adjective (fails Specific + Measurable).
"The thruster gives Δ v = 20 km/s on hydrazine, dry mass ≤ 200 kg ." ::: Case 3 — physics-impossible (fails Achievable via the rocket equation).
"Alignment shall be exactly 0 rad ." ::: Case 4 — zero tolerance is unverifiable.
"The bracket shall be designed to survive launch." ::: Case 6 — process not performance (fails Testable).
Why does Δ v grow only logarithmically with mass ratio? ::: Because Δ v = v e ln ( m 0 / m f ) — the log flattens, so extra speed costs exponentially more propellant.
In Ex 7, why is small-angle (Δ x = h θ ) valid? ::: Because θ ≈ 60 μ rad , and tan θ = θ to ~12 decimals at that size.
What does FEA stand for? ::: Finite-element analysis — dividing a part into tiny elements to predict stress and vibration by computer.
Mnemonic Attack any requirement in order
V-A-P-T-O — read it and ask: is it V ague? A gainst physics? A degenerate P oint (zero tolerance)? A process word (T estable?)? An O rphan (traces to nothing)? Walk the five and you cover every cell of the matrix.
See also: Mass Budget (Achievability of mass requirements), Technology Readiness Levels (TRL) (the TRL-6 gate for Achievable), Interface Control Document (ICD) (where interface requirements live), Failure Modes and Effects Analysis (FMEA) (which failures justify a requirement's Relevance).