Foundations — Systems engineering — V-model, requirements traceability

Before you can read the parent note V-Model & Traceability, you need to be fluent in the words and symbols it throws at you. Below, each idea is built from nothing, given a picture, and justified. Read top to bottom — every item leans on the one before it.

1. Requirement — the atom of everything

Picture it. A requirement is like a checkbox with a rule written next to it: "☐ Battery shall survive 5 years." Later, someone either ticks it (proven) or not.

Why the topic needs it. Everything in the parent note — the V, the matrix, the flow-down — exists only to manage a pile of these sentences without losing any. If a requirement isn't testable, you can never tick its box, so "testable" is not optional.

2. Abstraction level — how zoomed-in you are

Picture it (figure above): imagine a telescope's zoom. Zoomed all the way out you see "the mission." Zoom in once: "subsystems" (power, thermal, camera). Zoom in again: "components" (one battery, one lens). Same object, different detail.

Why the topic needs it. The letter $n$ in the parent note ("level $n$ on the left is verified at level $n$ on the right") is just a number labelling a zoom setting. Without the idea of levels, the V-model has no rungs.

3. Decomposition and flow-down — splitting a promise

Picture it. One arrow entering a box, several arrows leaving downward — a promise fanning out into sub-promises. See Requirements Derivation.

Two new symbols just appeared. Earn them now.

The symbol $\wedge$ — "AND"

Picture it. Two switches wired in series on one wire: current flows only if both are closed. One open switch → no current.

Why AND and not OR here? A spacecraft is a chain: if the battery fails or the solar panel fails or the electronics fail, the mission dies. You need all to succeed, so you join sub-promises with AND, never OR. (OR would mean "any one is enough" — false for serial systems.)

The symbol $⟹$ — "guarantees / leads to"

Picture it. A domino: if domino $A$ falls, domino $B$ must fall. But $B$ could fall for another reason, so you can't run the arrow backwards.

Why the topic needs it. The whole point of flow-down is this guarantee: if every subsystem keeps its promise, then the system promise is kept. That arrow is the reason verifying small parts lets us trust the big system.

The shorthand $\bigwedge$ — "AND all of them"

Picture it. A row of series switches, $n$ of them, and you need every single one closed.

4. The V-model — decomposition mirrored by verification

Now the letters mean something, so the shape can be drawn.

Picture it (figure above): a giant letter V. Top-left is the mission; you slide down-left getting more detailed; you hit the bottom (you build the hardware); then you climb up-right, assembling and testing bigger and bigger chunks until, at the top-right, you check the whole mission.

Why a V and not a straight line? The two arms sit at matching heights on purpose: the height is the abstraction level. A component-level promise (low, near the bottom) is checked by a component test (also low). This "same height = same level" pairing is what the horizontal rungs mean, and it's why problems get caught at the cheapest possible level. See Verification vs Validation for the crucial difference between the top-right rung (validation) and the lower rungs (verification).

5. Verification vs Validation — two different questions

Picture it. Verification = checking your homework against the rubric. Validation = checking the rubric was even the right assignment. The lower rungs of the V are verification; the very top-right rung is validation. Full detail lives in Verification vs Validation.

ConOps (Concept of Operations) is simply the plain-language story of what the mission does day to day — it sits at the top of both arms.

6. Traceability and the traceability matrix — never lose a promise

Picture it (figure above): every requirement is a bead; strings connect each bead upward to its parent and downward to its design item and its test. Tug any bead and you can trace the whole string.

Why the topic needs it. Two reasons the parent stresses: completeness (an empty cell = a promise with no proof, a launch risk) and impact analysis (change one requirement and every string touching it lights up — you instantly know what to redo). This bookkeeping is close cousins with Configuration Management (tracking versions of these documents) and Interface Control Documents (recording the promises between subsystems).

7. The engineering symbols in the examples

The parent's worked examples use physics shorthand. Earn each:

Picture it (figure above): the BOL power is a full glass; each year you pour out fraction $d$ of the current level, so the curve bends and flattens rather than dropping in a straight line. That bending is exactly why it's $(1-d{)}^t$ and not $1-dt$.

Prerequisite map

Equipment checklist

Test yourself — reveal only after answering.