Systems engineering — V-model, requirements traceability: Visual walkthrough

Before we start, three little symbols will appear. Let us name them in plain words now, so nothing is a surprise later.

This page is the visual companion to the parent topic. If a word feels unfamiliar, the prerequisite is Systems Engineering Fundamentals.

Step 1 — Start with one sentence at the top

WHAT. We write down a single mission sentence and place it at the very top of an empty page. Nothing below it yet.

WHY. Everything in spacecraft engineering must trace back to what the mission is for. If we start from parts, we might build beautiful hardware that does the wrong job. Starting from the sentence guarantees the whole tree has a single root — this root is the Concept of Operations (ConOps) the parent note listed first.

PICTURE. In the figure, the one blue box at the top is our whole starting point. The empty space beneath it is everything we have not yet decided.

The label $M_{1}$ is just a name tag — the letter $M$ reminds us "mission", the number $1$ says "the first one". No maths yet, just a handle we can point at later.

Step 2 — Ask "what does the whole spacecraft have to do?"

WHAT. We drop one level down and translate the mission sentence into a system requirement: something the entire spacecraft, as one object, must guarantee.

WHY. The mission sentence ("10 m resolution") is about the result seen from the ground. The system requirement is the same idea re-phrased as a promise the built spacecraft makes. We are moving from "the mission wants..." to "the spacecraft shall...". This is the first rung of the left arm of the V.

PICTURE. The figure shows a green box below the blue one, joined by a downward arrow. That arrow is our first $\Rightarrow$ ("breaks down into"). Notice the box sits one step lower and further from the top — lower means less abstract, more concrete.

$M_{1} \Rightarrow S_{1}$

$M_{1}$ — the mission sentence from Step 1 (the thing we want).
$\Rightarrow$ — our fat arrow, read "breaks down into". We just earned it: it points from the abstract wish to the more concrete promise.
$S_{1}$ — the system-level requirement. $S$ for "system", the whole spacecraft treated as one box: "the camera shall achieve 10 m ground sample distance."

This is where Requirements Derivation lives — turning a wish into a testable "shall" statement.

Step 3 — Split the system requirement into subsystems

WHAT. We break $S_{1}$ into several smaller requirements, one per subsystem that helps achieve it.

WHY. No single team builds "the spacecraft". Different specialists build optics, orbit control, structure. So we allocate pieces of the one big promise to each subsystem. This allocation is the heart of the left arm — and each split is another $\Rightarrow$ .

PICTURE. The green box now fans out into three yellow boxes. Each fan-line is a flow-down arrow. This is the widening "V" opening up as abstraction drops.

$S_{1} \Rightarrow {R_{1}, R_{2}, R_{3}}$

$S_{1}$ — the system promise (10 m resolution) from Step 2.
$\Rightarrow$ — "breaks down into", same fat arrow.
${\dots}$ — curly braces mean "the set of these things", i.e. a bundle we consider together.
$R_{1}$ — "focal length shall be 2 m" (optics subsystem).
$R_{2}$ — "orbit altitude shall be 500 km" (propulsion / orbit subsystem).
$R_{3}$ — "detector pitch shall be 5 μm" (electronics subsystem).

Each of these is a child of $S_{1}$ . The boundary between two subsystems is written down in an Interface Control Document so the teams agree on who owns what.

Step 4 — Why "AND", not "OR"? The serial-chain picture

WHAT. We claim that the spacecraft meets $S_{1}$ only if every one of $R_{1}, R_{2}, R_{3}$ is met. Not "some", not "most" — all.

WHY. A spacecraft is a serial chain: the light passes through the optics, then is sampled by the detector, while the orbit sets the distance. Break any link and the 10 m result is lost. There is no "backup path". So the correct connector is AND, which we write with the big $⋀$ symbol.

PICTURE. The figure draws the three requirements as three links of a chain pulling a weight labelled $S_{1}$ . Cut any one link (the red broken link) and the weight falls. That is exactly what "AND" means: all links needed.

$⋀_{i = 1}^{3} R_{i} \equiv R_{1} \land R_{2} \land R_{3}$

$⋀_{i = 1}^{3}$ — the big "AND": "combine, with AND, for $i$ running from $1$ to $3$ ".
$R_{i}$ — the $i$ -th subsystem requirement (the generic member of our set).
$\equiv$ — "is exactly the same as" (a definition-style equals).
$\land$ — the small "AND" between two facts. $R_{1} \land R_{2}$ is true only when both are true.

Step 5 — Close the logic loop: the central result

WHAT. We now state the full promise: if all the children are true, then the parent is forced true.

WHY. This is the payoff of a good flow-down. We do not just hope the pieces add up — we design the split so that meeting every child logically guarantees the parent. When that is true, verifying the children is enough; we never need to test the abstract parent directly.

PICTURE. The chain of Step 4 is redrawn with all three links intact and green — the weight $S_{1}$ is held. An arrow labelled $⟹$ points from "all links hold" to " $S_{1}$ satisfied".

$(⋀_{i = 1}^{n} R_{i}) ⟹ R_{sys}$

$⋀_{i = 1}^{n} R_{i}$ — "all $n$ subsystem requirements true together" (here $n = 3$ , but it works for any count).
$⟹$ — the thin double arrow, "logically forces". Unlike $\Rightarrow$ (a design action of splitting), this is a truth statement: left true guarantees right true.
$R_{sys}$ — the system requirement, our $S_{1}$ , written generically.

Putting Steps 3 and 5 together gives the parent note's central result in one line:

$R_{sys} \Rightarrow {R_{1}, \dots, R_{n}} such that ⋀_{i = 1}^{n} R_{i} ⟹ R_{sys}$

Read it aloud with everything we earned: "the system requirement breaks down into a set of children, chosen such that all children true, together, force the system requirement true."

Step 6 — Flip the page upside down: verification mirrors design

WHAT. We take the downward design tree and reflect it to build an upward verification tree. Every design box on the left gets a partner test box on the right, at the same height.

WHY. We designed top-down (abstract → concrete). We cannot verify in that order — you cannot test "10 m resolution" until the parts exist. So we build and test bottom-up: first each part, then combined subsystems, then the whole. Testing at the same abstraction level we wrote the requirement is what makes the V close neatly. This right arm is the domain of Spacecraft Integration and Testing.

PICTURE. The two arms form the letter V. Horizontal dashed lines connect each left box to its right partner — those dashes are traceability links. Component req ↔ component test; subsystem req ↔ subsystem test; system req ↔ system test.

$R_{i} verified by V_{i}$

$R_{i}$ — a requirement on the left arm.
$verified by$ — the horizontal traceability line: "this requirement is checked by...".
$V_{i}$ — the verification evidence (a test result, an analysis) sitting directly opposite $R_{i}$ .

Step 7 — Degenerate cases: when the tidy V breaks

WHAT. We check the corner cases the clean formula silently assumed.

WHY. The contract says the reader must never hit an unshown scenario. The AND-logic result rests on assumptions; here is what happens when they fail.

PICTURE. Three mini-panels: (a) a missing child — a link that was never drawn, so $S_{1}$ can be "satisfied" on paper but fails in orbit; (b) an orphan requirement — a box with no line to any test, so it is never verified; (c) a changed parent — $M_{1}$ edited, and the red ripple shows every downstream box that must be re-checked.

Case (a) — incomplete flow-down. If the children do not actually cover $S_{1}$ , then $⋀ R_{i} ⟹ R_{sys}$ is false even though we wrote it. The maths is only as good as the split. Cure: a coverage review checking each child against the parent.
Case (b) — orphan / dangling requirement. A requirement with no test link ( $R_{i}$ with no $V_{i}$ ) is unverifiable. In the matrix its "Test Result" cell is empty — an instant red flag. Cure: every requirement must trace to at least one verification.
Case (c) — the parent changes. If $M_{1}$ becomes "5 m resolution", the fat arrows tell us exactly which $R_{i}$ , designs and tests to revisit. This backward walk is impact analysis and it is why Configuration Management freezes and version-controls the whole tree — change one box, and the traceability links list the fallout.

The one-picture summary

Everything above compressed into a single V: the blue mission root, the design arm falling with fat $\Rightarrow$ arrows, the AND-chain at the bottom, the verification arm rising, and the dashed traceability rungs closing the two sides — with the central logic line printed across the middle.

Recall Feynman retelling — say it back in plain words

We start with one sentence: "image Earth at 10 metres." That sentence sits at the top. We ask "what must the whole spacecraft do?" and rewrite it as a system promise — that is one step down and one fat arrow. Then we ask "which teams help keep that promise?" and split it into a bundle of smaller requirements, one per subsystem — more fat arrows fanning out. Now the key idea: the spacecraft is a chain, so we need every small requirement true at once — that is the big "AND". And we are careful to split things so that all children true actually forces the parent true — that is the thin logic arrow. So far we have only gone down and designed. To prove it, we flip the page over and go up: test each part, then each subsystem, then the whole spacecraft, checking each level against the requirement we wrote at that same height. The horizontal dashed rungs join each requirement to its test — that is traceability, and it is what lets us answer "if the mission changes, what do we re-check?" instantly. The tidy picture can break in three ways: a child we forgot to write, a requirement with no test, or a parent that changed — and the very same links that built the V are what we walk to fix each one.

Quick self-checks:

Which arrow means "breaks down into" and which means "logically forces"?

\Rightarrow

breaks down into (a design action);

⟹

logically forces (a truth statement).

Why AND and not OR across subsystems?

A spacecraft is a serial chain — one failed link loses the mission, so every requirement must hold simultaneously.

A requirement box has no dashed line to any test. What is wrong?

It is an orphan / unverifiable requirement — nothing proves it is met.

If mission

M_{1}

changes, how do we find what to re-check?

Walk the traceability links backward (impact analysis); Configuration Management tracks the versions.