ECSS-E-ST-10-02C in practice: build the verification matrix while you design the satellite

Every satellite programme ends up with the same document: a table that lists each requirement, how it will be verified, at which level, and whether it has been verified yet. ECSS-E-ST-10-02C, the European standard for space engineering verification, calls the tool that tracks this status the Verification Control Document (VCD). Teams often call it the verification matrix.

The standard does not say when to build it. In practice, many teams fill it in late, in the weeks before the Critical Design Review (CDR), by going back through requirement documents, analysis reports and test plans. This article explains why building it from the first requirement is faster, and what that looks like when requirements, design and verification live in the same model.

What ECSS-E-ST-10-02C asks for

ECSS-E-ST-10-02C sets out the verification process for space products. In short, it asks the project to:

• —Assign a verification method to each requirement: test (T), analysis (A), review of design (R) or inspection (I), alone or combined.
• —Assign a verification level: equipment, subsystem, element or system.
• —Assign a verification stage: for example qualification, acceptance, pre-launch or in orbit.
• —Track the status of each verification until it is closed with evidence: a test report, an analysis report, a review record or an inspection record.

The review sequence is defined in ECSS-M-ST-10C. At each review (PDR, CDR, then the Qualification Review and the Acceptance Review), the project shows where verification stands. The VCD is the document reviewers read to answer one question: for each requirement, do we know how it will be proven, and has it been proven?

Why the matrix is usually built late

Three habits push the matrix to the end of the design phase.

Requirements and verification live in different files. The requirements specification is a document. The verification plan is another document. The test procedures and analysis reports are dozens more. The matrix is the place where they meet, so it can only be filled in once all of them exist.

The method is decided too late. A requirement such as "the reaction wheel assembly shall survive the qualification random vibration levels" has an obvious method (test). Many others do not. When nobody decides the method at the time the requirement is written, the decision is postponed until someone has to fill the matrix.

Changes break the matrix silently. A requirement is reworded after PDR, a subsystem is redesigned, a test is merged with another one. Each change should update the matrix. When the matrix is a spreadsheet maintained by one person, it drifts from the real state of the design, and the drift is found during review preparation.

The result is a familiar crunch: before CDR, systems engineers spend weeks reconciling requirement IDs, chasing analysis reports and checking that every line points to a real piece of evidence.

Building the matrix from the first requirement

The alternative is simple to describe. When a requirement is created, it already carries:

1. 1.Its verification method (T, A, R, I).
2. 2.Its verification level and stage.
3. 3.A link to the verification activity that will close it: a test case, an analysis, a review item or an inspection.

When the verification activity produces its evidence, the evidence is linked to the activity. The matrix is then no longer a document someone writes. It is a view of the model: filter the requirements, show their method, level, stage and status, and export it for the review.

In Koddex, this is how requirements and verification are modelled. Each requirement is an item with its own attributes, linked to the design elements that satisfy it and to the tests or analyses that verify it. The verification matrix is generated from those links, so it is current on the day of the review. The same structure supports the full V-model: the left branch defines and decomposes, the right branch proves, and the links between them are explicit.

What changes at each review

At PDR, the matrix shows the method and level of every requirement. Reviewers can see early which requirements depend on a test that does not exist yet, or on an analysis with no owner. These gaps are cheap to fix at PDR.

At CDR, the matrix shows which verification activities are planned, which have started and which are closed. Because the matrix is generated from the model, preparing it takes hours instead of weeks.

At the Qualification and Acceptance Reviews, the evidence is already attached to each line. The question "where is the report that proves this requirement?" has an answer one click away.

What happens when a requirement changes

Change is where a linked model pays for itself. When a requirement is reworded or its value changes, Koddex lists the design elements, verification activities and evidence that depend on it. The test that verified the old value is flagged as reopened. The engineer decides whether the test must be rerun or whether the existing evidence still holds. This is the impact analysis that teams otherwise do from memory.

Where AI agents help

Much of the verification bookkeeping is repetitive: checking that every requirement has a method, that every test case traces back to at least one requirement, that every closed verification has evidence attached. Koddex agents take these tasks the way a colleague would. An engineer assigns the task, for example "check the verification coverage of the power subsystem before the CDR data package". The agent works on a branch, lists the gaps, comments on each one and proposes the missing links. The engineer reviews the result and merges it. Every action the agent takes is recorded in the activity log, within the rights of its account.

The engineer keeps the decisions: which method is acceptable, whether an analysis is sufficient, whether a deviation is justified. The agent removes the hours of cross-checking around those decisions.

Getting started

You do not need to remodel a whole spacecraft to start. A good first scope is one subsystem and its requirements:

• —Import the subsystem requirements (Koddex structures a PDF or spreadsheet specification into linked requirements, which an engineer reviews).
• —Add the verification method, level and stage to each requirement.
• —Link the existing test cases and analyses.
• —Generate the matrix and compare it with the one you maintain today.

The difference usually shows up immediately: requirements without a method, tests that verify nothing on the list, and evidence that exists but is not referenced. Fixing those gaps at this stage is what shortens the next review.

See how requirements management works in Koddex, or book a demo with one of your own subsystems.