3.6.27 · D5Spacecraft Structures & Systems Engineering
Question bank — Requirements — SMART (Specific, Measurable, Achievable, Relevant, Testable)
The whole page rests on three ideas — the figure below makes them visual before you start.
- Performance vs process — a requirement should constrain what the product achieves, not what engineers do.
- Verifiable — someone must be able to point to a test/analysis/inspection/demonstration that says pass or fail. (Verification and Validation = the discipline of proving a requirement is met (verification) and that it was the right requirement (validation).)
- Traceable — every child requirement exists because a parent needs it. (A Requirements Traceability Matrix is simply a table linking each requirement to its parent objective and its verification method — see the picture below.)
Two abbreviations recur; here they are once, in plain words:
- TRL — Technology Readiness Level: a 1–9 maturity scale for a technology, where 1 is "just an idea" and 9 is "flown successfully"; roughly TRL 6 means "demonstrated in a relevant environment".
- FMEA — Failure Modes and Effects Analysis: a systematic table of how each part can fail and what happens to the mission if it does.
The verification "V" that several answers refer to looks like this:
True or false — justify
The requirement "the satellite bus mass shall be ≤ 150 kg" is a good requirement purely because it uses the word "shall".
False — "shall" only signals a binding requirement; goodness comes from the number, unit and clear scope (bus, not payload). The verb alone verifies nothing.
A requirement can be Measurable without being Testable.
False in practice — if you can attach a number and unit you have almost always defined what to measure, but a requirement is only Testable once a method (test/analysis/inspection/demo) can produce that number. Measurable is the metric; Testable is the means to obtain it.
"The structure shall be robust" is Specific because "robust" clearly means strong.
False — "robust" has no number, no axis, no load case, so two engineers picture different structures. Specific means no room for interpretation, which "robust" fails by inviting it.
An Achievable requirement is one that is cheap.
False — Achievable means feasible with current/near-term tech, budget AND schedule without violating physics. Cost is one leg of it; a requirement can be affordable yet physically impossible, or expensive yet perfectly achievable.
A requirement that traces to a mission objective is automatically Testable.
False — Relevance and Testability are independent axes. "Shall be reliable" can trace beautifully to a mission and still be untestable because "reliable" has no pass/fail metric.
Adding "± 5%" to a number always makes a requirement better.
False — a tolerance only helps if it reflects real manufacturing/degradation physics. A meaningless or contradictory tolerance (e.g. tighter than the sensor can measure) just creates unverifiable requirements.
Two requirements that constrain the same parameter with different values are fine as long as both are SMART.
False — each may be SMART individually, but together they are inconsistent, which is a system-level defect a Requirements Traceability Matrix exists to catch. SMART is necessary, not sufficient.
If a requirement is verified by Analysis rather than Test, it is not really Testable.
False — Testable means verifiable by one of four methods: Test, Analysis, Inspection, Demonstration. Analysis (e.g. an FEA or thermal model) is a legitimate verification path, chosen when full-scale test is impractical.
Spot the error
"The propulsion system shall be designed to survive vibration." — what SMART criterion breaks?
Testable (and Specific) — "designed to" is a process requirement describing engineer activity, not a performance outcome you can pass/fail. Fix by stating the vibration spectrum the system shall survive, verified by shaker test.
"The solar array shall generate 2.5 kW." — what is missing?
Measurability context — no operator direction is fine (implied minimum), but there are no conditions: at what point in life, sun angle, distance, temperature? Power depends on all of them, so without conditions the number is unfalsifiable.
"The GPS receiver shall provide accurate position." — which two letters fail?
Measurable and Testable — "accurate" is not a number. Replace with "±3 m (3σ) integrated over 10 s" so a test can produce a comparable value.
"The battery shall last a long time." — beyond Measurable, what deeper problem lurks?
It also isn't Relevant-traceable as written — "a long time" hides which mission need (eclipse survival? end-of-life margin?). Without the parent objective you cannot even pick the right number.
"The thermal control shall keep the payload cool." — what's the error and the fix?
"Cool" is not measurable and "keep" is process-flavoured. Fix: "shall maintain payload baseplate temperature between −20°C and +40°C during all mission phases, verified by thermal-vacuum test and thermal model." (Verification and Validation supplies that proof.)
A subsystem requirement is written that no mission objective points to. What SMART letter fails and what do you do?
Relevant fails — an orphan requirement adds cost and complexity with zero benefit. Either find its true parent in the trace or cut it.
"The structure shall withstand 8g." — what's incomplete about the load statement?
It omits axis (axial vs lateral), whether it is quasi-static or dynamic, and the qualification margin. A complete version specifies each axis, the load type, and the test factor (e.g. 1.25× design limit).
Why questions
Why does SMART insist requirements be falsifiable rather than merely well-intentioned?
Because dozens of teams build in parallel; only a pass/fail statement lets integration confirm each piece is correct. An unfalsifiable requirement can neither succeed nor fail, so it protects nothing.
Why is "Achievable" checked against the TRL (the 1–9 technology maturity scale) specifically?
TRL turns "can we build it?" into a measurable maturity scale; requiring roughly TRL 6 (demonstrated in a relevant environment) gives objective evidence that the tech is feasible within the program, not just hoped for.
Why must a Measurable requirement carry units and not just a number?
Every physical law relates dimensioned quantities, so a bare number is ambiguous — "2.5" could be watts or kilowatts. Units give the number physical meaning and follow directly from dimensional analysis.
Why does the framework separate Relevant from the other four criteria?
The other four ask "is this a good requirement?"; Relevant asks "should this requirement exist at all?" A perfectly Specific/Measurable/Achievable/Testable requirement that serves no mission need is pure waste.
Why do we test power output but analyse re-entry heating?
You verify by Test what can be directly and safely measured (array output under simulated sun), and by Analysis what is impractical or dangerous to reproduce at full scale (re-entry). The method follows the physical domain, not preference.
Why is constraining outcome preferred over constraining design process?
Outcome requirements let engineers freely choose the best way to meet a target and remain verifiable on the delivered hardware; process requirements ("shall be designed to…") lock in method yet cannot be tested on the product.
Edge cases
Can a requirement have zero tolerance (an exact "=" with no ±)?
Only if the measurement can meaningfully hit that value — most physical quantities need a band because manufacturing and instruments have spread. A true "=" usually belongs to counts or discrete states (e.g. "shall have = 4 thrusters"), not continuous physical values.
A requirement is trivially met on day one and stays met forever with huge margin. Is it still useful?
Marginally — it is testable but may be non-binding, meaning it never actually drove a design decision. Such requirements are candidates to relax or cut so they stop adding trace and verification cost for no benefit.
What happens at a mission's end-of-life boundary that makes conditions essential?
Performance degrades (radiation cuts solar output, batteries fade), so "≥ 2.5 kW" is only falsifiable if you state EOL vs BOL. The same hardware can pass at beginning-of-life and fail at end-of-life without any error — the condition decides which you meant.
A requirement is physically possible but demands 8 million kg of propellant for a small sat. SMART verdict?
It fails Achievable, not physics — the Tsiolkovsky Rocket Equation permits it, but budget, mass and schedule reality forbid it. Achievable is bounded by the program, not just the laws of nature.
Is "the software shall never crash" Testable?
No — "never" over infinite inputs is unverifiable; you cannot exhaust all cases. Recast as bounded, demonstrable behaviour: "shall recover to a safe mode within 5 s of any single fault, verified by fault-injection test." (A FMEA — the table of failure modes and their mission effects — tells you which faults to inject.)
Two subsystems reference the same signal but assume different voltages. Which SMART property caught nothing, and what document should?
SMART checks each requirement in isolation and can pass both; the inconsistency is an interface defect belonging to the Interface Control Document (ICD), enforced through the Systems Engineering V-Model integration side.
Recall Quick self-test
A colleague writes "the antenna shall be light and steerable." Name every SMART letter it violates. ::: Specific (light? steerable how far?), Measurable (no numbers/units), and Testable (no pass/fail), while Relevant is unclear because the parent need is unstated. Which verification method fits a dimensional tolerance requirement? ::: Inspection — a coordinate-measuring measurement gives a direct pass/fail against the tolerance band.