3.6.27Spacecraft Structures & Systems Engineering

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

2,733 words12 min readdifficulty · medium

What is SMART?

WHY this framework? Engineering is collaborative—dozens of teams work in parallel. Without SMART, Team A builds what they think you meant, Team B builds something different, and integration fails. SMART eliminates interpretation.

Breaking Down Each Criterion

Specific

WHAT: The requirement states exactly what component/parameter/function is constrained, with no room for multiple interpretations.

WHY it matters: Vague requirements create design branches that diverge, wasting resources.

Measurable

WHAT: The requirement includes quantitative metrics with units, tolerances, and measurement methods.

WHY it matters: "You can't manage what you can't measure." If you can't put a number on it, you can't verify it or track progress.

Achievable

WHAT: The requirement can be met with current or near-term technology, within budget and schedule, without violating physics.

WHY it matters: Unrealistic requirements waste time in design loops or force costly redesigns when reality hits.

HOW to verify achievability:

  1. Technology Readiness Level (TRL) check: Is the tech at least TRL 6 (system demo in relevant environment)?
  2. Physics limits: Does it violate thermodynamics, structural load limits, Δv budgets?
  3. Cost/schedule: Can you afford it in the program timeline?

Relevant

WHAT: The requirement traces upward to a mission objective or parent requirement—it exists for a reason, not just bureaucracy.

WHY it matters: Irrelevant requirements add cost and complexity with no benefit. Every requirement should answer "Why does the mission need this?"

Testable

WHAT: You can verify the requirement is met through one of four methods:

  1. Test: Physical hardware/software test
  2. Analysis: Mathematical model or simulation
  3. Inspection: Visual check, measurement
  4. Demonstration: Operational scenario run

WHY it matters: Untestable requirements are unverifiable—you ship hardware not knowing if it meets needs. That's how missions fail.

Common Requirements Pitfalls

Writing SMART Requirements: Step-by-Step

HOW to transform a vague need into SMART:

  1. Identify the need (user story): "We need the satellite to stay pointed at Earth."

  2. Make it Specific: What parameter? Attitude pointing.

  3. Make it Measurable: "Pointing error ≤ 0.1° (3σ) nadir-pointing."

  4. Check Achievable: Star tracker + reaction wheels can do0.01° easily, so 0.1° is conservative. ✅

  5. Make it Relevant: Traces to imaging payload requirement for GSD. ✅

  6. Make it Testable: "Verified by attitude determination accuracy in ground test + on-orbit telemetry analysis."

Final SMART requirement: "The ADCS shall maintain nadir-pointing attitude with error ≤ 0.1° (3σ) in pitch and roll axes during imaging operations, verified by post-processed telemetry analysis using star tracker and GPS data."

Recall Explain SMART to a 12-Year-Old

Imagine you ask your friend to bake you a birthday cake. If you just say "bake me a cake," what will you get? Maybe chocolate, maybe vanilla, maybe burnt, maybe tiny, maybe they don't even try because they think it's too hard!

But if you say: "Bake me a round chocolate cake,10 inches across, with 2 layers, that tastes good, by Saturday, and show me a picture when it's done"—now your friend knows exactly what to do!

SMART requirements are like that recipe:

  • Specific: Round, chocolate, 2 layers (not "just a cake")
  • Measurable: 10 inches across (you can measure with a ruler!)
  • Achievable: Your friend knows how to bake and has anoven
  • Relevant: It's for your birthday party, so it matters
  • Testable: You can see the picture and taste it to check if it's good For spacecraft, if you tell engineers "make it work in space" (vague), you might get something that breaks. But "survive temperatures from -150°C to +120°C" (SMART)—now they can build and test it!

Connections

  • Systems Engineering V-Model — SMART requirements feed verification steps
  • Requirements Traceability Matrix — Tracks Relevant criterion
  • Verification and Validation — Testable criterion links to V&V
  • Technology Readiness Levels (TRL) — Used to assess Achievable
  • Mass Budget — Measurable requirements drive budget allocations
  • Failure Modes and Effects Analysis (FMEA) — Identifies missing requirements
  • Interface Control Document (ICD) — Contains interface requirements in SMART format
  • Tsiolkovsky Rocket Equation — Physics limit for Achievable propulsion requirements

#flashcards/physics

What does the S in SMART requirements stand for and why does it matter? :: Specific — unambiguous with clear scope. Matters because vague requirements cause different teams to build incompatible interpretations, wasting resources and causing integration failures.

What does the M in SMART requirements stand for?
Measurable — includes quantitative metrics with units, tolerances, and measurement methods. You can't verify what you can't measure.
What does the A in SMART requirements stand for?
Achievable — technically and economically feasible with current or near-term technology, within budget and schedule, without violating physics (checked via TRL, physics limits, cost/schedule analysis).
What does the R in SMART requirements stand for?
Relevant — traces upward to mission objectives or parent requirements. Every requirement should answer "Why does the mission need this?" to avoid adding unnecessary cost and complexity.
What does the T in SMART requirements stand for?
Testable — can be verified through Test, Analysis, Inspection, or Demonstration. Untestable requirements are unverifiable, leading to potential mission failure.
What are the four verification methods for Testable requirements?
(1) Test - physical hardware/software testing, (2) Analysis - mathematical model or simulation, (3) Inspection - visual check or measurement, (4) Demonstration - operational scenario run.
Why is "shall be designed to..." a bad requirement phrase?
It's a process requirement (tells how to work) not a performance requirement (what outcome to achieve). It's unverifiable — you can't test whether someone "designed to" something. Requirements should constrain outcomes, not design process.
Why is "as much as possible" problematic in requirements?
Not measurable — no clear target or pass/fail criteria. Engineers could spend infinite time optimizing or do nothing and claim they tried. Replace with specific numerical targets (e.g., "≤ 15 W average power").
What formula template makes a requirement Measurable?
Parameter {≤, ≥, =} Value ± Tolerance [units] under Conditions. Includes numerical value, units, comparison operator, and environmental conditions for physical meaning and bounded applicability.
How do you check if a propulsion requirement is Achievable using the rocket equation?
Use Tsiolkovsky equation: Δv = Isp·g₀·ln(m₀/mf). Calculate required mass ratio for given Δv and propellant Isp, verify against mass budget constraints and tank/engine technology limits.

Concept Map

ensures

makes requirements

criterion

criterion

criterion

criterion

criterion

expressed via

derived from

enables

prevents divergent

SMART Requirements Framework

Requirements as Contract

Falsifiable Requirements

Specific: clear scope

Measurable: numbers and units

Achievable: feasible

Relevant: traces to mission

Testable: verifiable

Measurability Template

Parallel Teams Collaboration

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho yaar, is note ka core idea bahut simple hai — jab hum spacecraft (ya koi bhi engineering system) banate hain, to hume batana padta hai ki kya chahiye, aur wo batane ka tareeka clear hona chahiye. Agar tum machinist ko bolo "strong banao" to usko kya samajh aayega? Kitna strong? Kaha tak? Isliye SMART framework aata hai — Specific, Measurable, Achievable, Relevant, aur Testable. Iska matlab hai ki har requirement itni clear honi chahiye ki koi bhi definitively prove kar sake ki wo puri hui ya nahi. Yehi asal cheez hai — requirement ko falsifiable banana.

Ab yeh matter kyun karta hai? Spacecraft engineering mein bahut saari teams parallel mein kaam karti hain. Agar requirement vague hai — jaise "satellite lightweight hona chahiye" — to Team A kuch samjhegi, Team B kuch aur, aur jab sab jodoge to integration fail ho jayega. Lekin agar tum likho "bus structure ka mass ≤ 150 kg hona chahiye", to sabko exactly pata hai ki kya karna hai. Numbers, units, tolerance, aur conditions (jaise temperature ya distance) — yeh sab isliye zaroori hai kyunki har physical requirement ek measurable quantity ko constrain karti hai, aur bina number ke tum na verify kar sakte ho na progress track kar sakte ho.

Toh short mein, SMART ek discipline hai jo vague wishes ko buildable specifications mein badal deta hai. Space missions mein ek chhoti si ambiguity ka matlab billions ka nuksaan ya poori mission ki failure ho sakti hai, isliye Achievable part bhi check karna padta hai — matlab technology ready hai kya (TRL level), physics allow karti hai kya, aur budget-schedule mein fit hoti hai kya. Jab tum yeh sochke requirement likhoge, to tumhara engineering solid, testable, aur reliable banega. Yeh skill sirf space ke liye nahi, kisi bhi engineering ya project ke liye kaam aayegi.

Go deeper — visual, from zero

Test yourself — Spacecraft Structures & Systems Engineering

Connections