3.6.27 · D4Spacecraft Structures & Systems Engineering

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

3,020 words14 min readBack to topic

Level 1 — Recognition

Goal: name the five letters and spot which one is broken.

L1.1

(L1) Write out what each letter of SMART stands for, in order.

Recall Solution
  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Testable

Memory hook: "Say My Awesome Rocket's Tested."

L1.2

(L1) For each requirement below, name the one SMART letter it most obviously violates.

(a) "The antenna shall be reasonably efficient." (b) "The propulsion system shall provide using chemical propulsion with dry mass ." (c) "The paint shall look nice."

Recall Solution
  • (a) Measurable — "reasonably efficient" has no number, no units, no operator.
  • (b) Achievable — the Tsiolkovsky Rocket Equation forbids from chemical propulsion at that dry mass (parent note shows the mass ratio ).
  • (c) Testable (and Relevant) — "look nice" has no pass/fail criterion and traces to no mission objective.

L1.3

(L1) A requirement reads: "The bus structure shall have a mass ." Which SMART letters does this satisfy?

Recall Solution
  • S ✅ — names the exact item ("bus structure").
  • M ✅ — number (150), unit (kg), operator ().
  • A — plausible, but you'd need a Mass Budget to confirm it. Cannot judge from the sentence alone.
  • R — need the mission objective to confirm; not shown here.
  • T ✅ — verifiable by inspection (weigh it).

So it clearly satisfies S, M, T; A and R need external context.


Level 2 — Application

Goal: rewrite bad requirements into SMART form, and run the Achievability arithmetic.

L2.1

(L2) Rewrite this vague requirement as a single SMART sentence:

"The solar array should make plenty of power for a long time." Assume: mission needs at end-of-life, , panel pointed at the Sun at , over to .

Recall Solution

"The solar array shall generate electrical power at end-of-life (15 years), when oriented normal to sunlight at , across a temperature range of to ."

Checklist of what we added:

  • S: "solar array … electrical power" (scope).
  • M: , , operator .
  • A: leave to a power-budget analysis.
  • R: implicitly traces to the mission's power need.
  • T: verifiable by test under a solar simulator.

L2.2 — Achievability arithmetic

(L2) A monopropellant hydrazine stage has specific impulse , propellant mass , dry mass . Standard gravity . The requirement is . Is it Achievable?

Recall Solution

Use the Tsiolkovsky Rocket Equation:

  • WHAT/WHY the equation: it is the only relation linking exhaust speed and mass ratio to velocity change — the direct test of "can chemistry deliver this ?"
  • Exhaust speed: .
  • Wet mass ; dry mass ; ratio .
  • .

, so the requirement is Achievable with big margin. ✅

L2.3

(L2) Classify each requirement by its best verification method (Test / Analysis / Inspection / Demonstration):

(a) "Bracket hole diameter shall be ." (b) "Structure shall survive reentry heating of peak." (c) "Ground station shall command the satellite through a full pass." (d) "Solar array shall output ."

Recall Solution
  • (a) Inspection — measure with a coordinate-measuring machine.
  • (b) Analysis — full-scale reentry is impractical to test, so use a thermal model.
  • (c) Demonstration — run the end-to-end operational scenario.
  • (d) Test — measure real output under a solar simulator.

See Verification and Validation for the four-method framework.


Level 3 — Analysis

Goal: audit requirements against all five criteria and trace them.

L3.1 — Full SMART audit

(L3) Audit this requirement against all five letters. State pass/fail with a reason for each:

"The reaction wheel assembly shall provide torque about each axis, with angular momentum storage per wheel, verified by test."

Recall Solution
  • S ✅ — item ("reaction wheel assembly"), axes ("each axis") and quantities are all named.
  • M ✅ — torque , momentum , both with units and operators.
  • A — plausible for flight-qualified wheels (check Technology Readiness Levels (TRL) ); not derivable from the sentence but not obviously violated.
  • R — needs a trace to a pointing/slew objective. Not shown → flag for Requirements Traceability Matrix.
  • T ✅ — "verified by test" plus measurable quantities gives a clear pass/fail.

Verdict: strong on S, M, T. Add a trace (R) and a TRL note (A) to make it airtight.

L3.2 — Build the trace

(L3) You are given a subsystem requirement:

"The GPS receiver shall provide position with () accuracy when integrated over ." Build the upward trace to a plausible system requirement and a plausible mission objective. Why does the trace prove Relevance?

Recall Solution

A valid chain (matching the parent's ice-mass example):

  • Mission objective: "Observe Earth's ice-sheet mass balance to ."
  • System requirement: "Maintain radial altitude knowledge to ()."
  • Subsystem requirement: the GPS requirement above.

Why this proves Relevance: gravity-field (ice-mass) recovery needs precise orbit knowledge; orbit knowledge needs precise position fixes. Remove the GPS requirement and the chain snaps — the mission fails its objective. A requirement that traces to nothing can be cut, which is exactly the Relevance test.

L3.3 — Spot the "designed to" trap

(L3) Explain why this fails, then rewrite it:

"The structure shall be designed to withstand launch loads."

Recall Solution

Why it fails: "designed to" is a process requirement (it tells engineers what activity to perform), not a performance requirement (what the product must achieve). You cannot test whether someone "designed to" something — it fails Testable and is vague on Measurable.

Rewrite:

"The structure shall survive quasi-static launch loads of axial and lateral, verified by analysis and by qualification test to design limit load."

Now it constrains an outcome with numbers, a factor of safety, and a verification method — see Systems Engineering V-Model for where this sits in the flow.


Level 4 — Synthesis

Goal: derive requirements from physics and design a small verification plan.

L4.1 — Derive an Achievable Δv requirement

(L4) A CubeSat mission needs for orbit maintenance. Available thruster: . Dry mass is fixed at . Find the minimum propellant mass and write the resulting SMART requirement. (.)

Recall Solution

Step 1 — invert Tsiolkovsky for the mass ratio (WHAT/WHY): we know and want propellant, so solve the rocket equation for .

  • .
  • Exponent .
  • Ratio .

Step 2 — solve for propellant. With :

Step 3 — write the SMART requirement (round up for margin):

"The propulsion subsystem shall provide using the cold-gas thruster () with propellant mass and dry mass , verified by analysis (rocket-equation) and thruster-firing test."

Minimum propellant ; we spec to leave margin.

L4.2 — Verification plan

(L4) Write a four-line verification plan (method, setup, procedure, acceptance) for:

"The reaction wheel shall provide torque about each axis and store per wheel."

Recall Solution
  • Method: Test (with supporting Analysis for the momentum integral).
  • Setup: Wheel mounted on a rigid stand with a calibrated torque sensor () and an angular encoder; ambient temperature, vacuum recommended.
  • Procedure: Command the wheel from to max RPM; log torque vs. time; compute stored momentum from measured inertia and top speed .
  • Acceptance: measured torque sustained and . Fold results into the Requirements Traceability Matrix and Verification and Validation records.

L4.3 — Momentum-storage check

(L4) A wheel has moment of inertia and maximum spin rate . Does it meet "store "?

Recall Solution

Angular momentum (WHY: momentum storage is — that's the quantity a wheel banks to later dump onto the spacecraft). It meets the requirement exactly (). ⚠️ With zero margin, a real spec should demand with margin (e.g. design to giving ). Meeting a requirement "exactly" is a schedule risk — any manufacturing loss drops you below.

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

Level 5 — Mastery

Goal: full chain synthesis with cross-checks and interface awareness.

L5.1 — Build a complete SMART chain

(L5) A mission objective states: "Image coastal erosion at ground resolution from a orbit." Derive a three-level requirement chain (mission → system → subsystem), making each level SMART, and name the interface document that must capture the camera-to-bus boundary.

Recall Solution

Mission objective: "Image coastal erosion at ground sample distance from altitude."

System requirement (points to the whole imaging chain — pointing stability so the ground pixel doesn't smear):

"The spacecraft shall maintain attitude pointing stability ground smear over one integration time (i.e. angular rate ), verified by analysis and hardware-in-loop test."

Subsystem requirement (the actuator that delivers stability):

"The reaction wheel assembly shall provide control torque about each axis with momentum storage , verified by test."

Interface: the camera-to-bus mechanical, electrical, and data boundary must be frozen in an Interface Control Document (ICD). Whole chain lives in the Requirements Traceability Matrix; each level is verified per the Systems Engineering V-Model.

L5.2 — Ground-smear sanity check

(L5) For the system requirement above, check that angular rate actually keeps smear , given altitude and integration time .

Recall Solution

WHY this geometry: a small pointing rate sweeps the line-of-sight across the ground; the ground velocity of that sweep at range is (arc-length radius angle). Smear is that velocity times how long the shutter is open.

  • Ground sweep rate: .
  • Smear over integration: .

Smear , exactly the budget — so at this integration time the rate spec is the binding limit. (Same zero-margin warning as L4.3: in practice tighten or shorten .)

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

L5.3 — Cross-couple two requirements

(L5) The mass budget says the reaction-wheel assembly must fit in . A candidate wheel has , mass per wheel, and you need 4 wheels (3-axis + 1 redundant). Do both the mass requirement and the momentum requirement ( per wheel at ) hold together, or must one requirement change?

Recall Solution
  • Momentum: per wheel → meets (zero margin).
  • Mass: budget → fails by .

Conflict: the two requirements are inconsistent as written. Options, in order of preference:

  1. Negotiate the Mass Budget up to if mission margins allow.
  2. Drop to 3 wheels (no redundancy) — but Failure Modes and Effects Analysis (FMEA) will flag a single-point failure.
  3. Select lighter wheels with higher spin rate (raise to keep while shrinking and mass).

Lesson: individual requirements can each be SMART yet collectively infeasible. Traceability and budgets exist to surface exactly this cross-coupling before hardware is cut.