Systems engineering — V-model, requirements traceability: Question bank

Before we start, let us see the two structures every question below leans on, and pin down the shorthand so you never guess.

The V-model as a picture (figure s01). Read it as a wide letter "V". Down the left arm sit four teal nodes, from top to bottom: ConOps (the mission), then System requirements, then Subsystem requirements, then Component design — abstraction falls as you descend. Up the right arm sit four orange nodes, from bottom to top: Component testing, Subsystem integration & test, System integration & test, and finally Validation at the very top. At the bottom point the two arms meet at "build / implement". The dashed plum arrows are the flat rungs: each links a left-arm requirement to the right-arm test that closes it at the same height, i.e. the same abstraction level.

Figure — Systems engineering — V-model, requirements traceability

A traceability chain as a picture (figure s02). The top row shows five coloured discs joined left-to-right by solid arrows: Mission objective → Requirement → Design item → Test → Result (PASS). That unbroken row is captioned "mission provably met". The bottom row repeats the same five discs, but the arrow between "Design item" and "Test" is replaced by a dotted line with an orange cross — one missing link — and the row is captioned "mission unproven". The picture's whole message: snap any single link and you can no longer prove the mission is met.

Definition Shorthand used on this page (spelled out once, here)

BOL = Beginning-of-Life — the spacecraft's very first day in orbit, before anything has degraded. Solar cells are strongest here.
EOL = End-of-Life — the last day the spacecraft must still meet its requirements (e.g. 15 years later), after radiation has degraded the cells. Requirements are judged at EOL because that is the worst case.
PMAD = Power Management And Distribution — the boxes and wiring that take raw power from the arrays/battery and deliver it to each load. It is imperfect, so a few percent of power is lost as heat along the way.
EMI = Electromagnetic Interference — unwanted electrical noise one box radiates into another (through wires or through the air), which can only appear once parts are wired together.
ICD = Interface Control Document — a single authoritative document that pins down one agreed definition of an interface (connector, voltage, data format) so both sides trace to the same values. See Interface Control Documents.
The symbol $⟹$ (also written $\Rightarrow$ ) reads "logically implies": " $X ⟹ Y$ " means whenever $X$ is true, $Y$ must be true too. The symbol $\land$ reads "and": $X \land Y$ is true only when both $X$ and $Y$ are true.
The symbol $⋀_{i = 1}^{n}$ is just the "and" symbol $\land$ chained over many items at once: $⋀_{i = 1}^{n} R_{i}$ means exactly $R_{1} \land R_{2} \land \dots \land R_{n}$ — every one of the $n$ items must be true.

True or false — justify

The V-model's right arm verifies at the same abstraction level the left arm specified.

True — a component requirement is checked by a component test, a system requirement by a system-level test. The dashed plum rungs of the "V" (figure s01) are those matching levels; that is the whole point of the shape.

If every subsystem passes its own test, the system requirement is automatically verified.

False in general — passing subsystem tests verifies the flow-down logic only if the flow-down was complete and correct. Integration effects (interfaces, EMI — electromagnetic interference, thermal coupling) can still break the system, which is why the V-model keeps a separate system-level test rung.

Verification and validation are two names for the same activity.

False — verification checks a requirement was met (built right); validation checks the mission is met (built the right thing). You can pass every verification test and still fail validation if the requirements themselves were wrong.

A requirement with no test linked to it can still be considered "met" if the design looks correct.

False — with no verification evidence the traceability chain (the dotted, crossed link in figure s02) is broken, so completeness cannot be claimed. "Looks correct" is an opinion; a test result is evidence.

Flow-down uses logical conjunction (AND) because spacecraft subsystems form a serial chain.

True — if any single subsystem fails its allocated requirement the mission can fail, so all of

R_{1} \land R_{2} \land \dots \land R_{n}

must hold to imply

R_{sys}

Traceability is only useful for auditors and paperwork.

False — its biggest engineering value is impact analysis: when one requirement changes you instantly see which designs and tests must be revisited (see Configuration Management).

"Analysis" is always an inferior verification method to "Test".

False — test is most credible for hardware, but some requirements (15-year radiation dose, worst-case orbit) cannot be physically tested and must be verified by analysis or simulation. The method is chosen to fit the requirement.

The bottom of the "V" is where requirements are written.

False — the bottom is implementation/build (the lowest abstraction, most detailed design). Requirements are written on the way down the left arm and closed out on the way up the right.

Spot the error

"We passed the component test, so we can skip the subsystem test to save time."

Error — component tests only prove each part works in isolation; the subsystem test is a different V-model rung that catches interface and integration faults between those parts. Skipping it leaves an unverified level.

"BOL (Beginning-of-Life) output is 840 W and the requirement is 600 W at EOL (End-of-Life), so we have 240 W margin."

Error — the numbers are at different conditions, so you cannot subtract them directly. Margin must be judged at EOL: after ~15 years of degradation the array delivers less than its 840 W BOL figure (in the parent note, about 840 W at BOL degrades to well under that at EOL), and only that degraded EOL number should be compared against the 600 W requirement.

"M3 is verified because SS3.1 and SS3.2 passed."

Error — M3 flows down to SS3.1, SS3.2 and SS3.3. Conjunction means all three must pass; omitting SS3.3 (radiators) leaves the chain incomplete and M3 unproven.

"Traceability just means giving each requirement a unique ID."

Error — unique IDs are step one; traceability requires the links (parent-child flow-down, requirement→design→test→result). IDs with no links trace nothing (see Requirements Derivation).

"The camera works in the lab, so validation is complete."

Error — a working camera on a bench is verification of a subsystem, not validation. Validation asks whether the integrated spacecraft in its mission environment achieves the ConOps — Concept of Operations (e.g., 10 m resolution from orbit).

"An interface only needs to appear in one subsystem's requirements."

Error — an interface has two sides; both subsystems must reference the same agreed values, which is exactly why an Interface Control Document (ICD — a single document that pins down one authoritative definition of the interface) exists.

Why questions

Why verify at the same abstraction level you specified the requirement, instead of just testing everything at the end?

Because catching a fault at its own level is far cheaper and pinpoints the cause; a single end-of-line test tells you something failed but not what, and integration mistakes found late are the most expensive to fix.

Why does the requirements flow-down demand

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

— meaning

R_{1} \land R_{2} \land \dots \land R_{n}

, i.e. all child requirements together logically imply the parent — rather than just "some

R_{i}

Because the subsystems are a serial mission chain — one unmet allocation can sink the mission — so the conjunction (every single one true) of all child requirements must logically guarantee the parent.

Why size the solar array at Beginning-of-Life (BOL) rather than at the required End-of-Life (EOL) number?

Because radiation degrades cells every year; you build in BOL headroom so that after degradation (the EOL condition) the array still exceeds the load requirement. Designing exactly to EOL at BOL would leave zero margin.

Why keep a traceability matrix at all when engineers "know" the design?

Because human memory is not auditable or transferable, and impact analysis on a change requires machine-checkable links; the matrix turns tribal knowledge into evidence (ties into Risk Management in Spacecraft Design).

Why is validation placed at the top of the right arm, opposite the ConOps?

Because the ConOps sits at the highest abstraction on the left, so its matching verification — validation against the actual mission — must sit at the highest integration level on the right.

Why do we budget distribution losses (the <5% PMAD, Power Management And Distribution, loss) as an explicit requirement instead of ignoring them?

Because power delivered to loads is always less than power generated; if losses are not traced and allocated, the flow-down would silently under-deliver and the system requirement would fail (see Interface Control Documents for where these budgets live).

Edge cases

A requirement can only be verified by test that is physically impossible to run before launch (e.g. 15-year dose). What happens?

The verification method is switched from Test to Analysis/Simulation — the requirement is still verified, just with a different, appropriate evidence type. The rung is never simply left empty.

A subsystem passes with zero margin (exactly meets its number). Is that acceptable?

Technically it meets the requirement, but zero margin means any modelling error, degradation, or measurement uncertainty pushes it to failure; good practice flags this as a risk item even though the box says PASS.

A mission requirement changes after all tests are already PASS. What does traceability tell you?

Follow the links downward from the changed requirement: every child requirement, design item, and test it touches must be re-examined and possibly re-run — this is impact analysis, and it is why the links, not just the IDs, matter.

Two subsystems each claim ownership of the same interface value, and they disagree. What broke, and where is the fix?

The interface was defined in two places instead of one; the fix is a single authoritative ICD (Interface Control Document) that both subsystems trace to, so there is exactly one true value.

A requirement is written that no design element and no test link to. Is the spacecraft complete?

No — an orphan requirement means completeness is unproven; either the requirement is genuinely unmet, or it is stale and should be formally removed under Configuration Management. Silence is not evidence.

Every verification test passes, yet in orbit the spacecraft fails to do its job. Which discipline failed?

Validation — verification confirmed we built to the requirements, but the requirements themselves did not capture the real mission need, so we built the wrong thing correctly (see Verification vs Validation).

A component test passes, but the same component fails once integrated with its neighbours. Which V-model rung caught it, and why couldn't the lower one?

The subsystem integration rung caught it, because interactions (shared power, heat, EMI — electromagnetic interference, mechanical fit) only exist once parts are combined — the isolated component test had no neighbours to expose the fault.

Recall Quick self-check

One rung, one condition, one chain — say each aloud. What does a horizontal rung of the "V" link? ::: A requirement level on the left to its matching verification level on the right. Verification vs validation in five words each? ::: Built the thing right / built the right thing. What makes a traceability chain valid? ::: An unbroken set of links from mission objective through requirement, design, and test to a result.