What a verifiable requirement actually looks like : an ECSS-E-ST-10-06 worked example

Most requirement documents I have read fail the same test: you cannot tell from reading the requirement alone whether it has been met. The sentence looks like a requirement. It has a subject, a verb, sometimes even a number. But ask "how do you verify this?" and the room goes quiet. That gap, between a requirement that sounds precise and one that actually is, is what ECSS-E-ST-10-06C was written to close.

I want to walk through what the standard actually demands in practice, not as a clause summary, but as a working exercise against two real mission documents. The first is the ICON Level-2 Project Requirements Document, a NASA Explorer mission managed out of UC Berkeley. The second is the ESA MarcoPolo-R Mission Requirements Document, an asteroid sample return proposal from the Cosmic Vision programme. Both are public. Both are worth reading cover to cover if you work in systems engineering and have not yet done so.

I am going to focus on three things: modal verb discipline, the four verification methods, and what a corrected requirement actually looks like compared to the careless version. The ICON document is particularly good for this because it keeps the rationale fields intact and visible, which is rare in publicly released documents.

The 'shall' discipline

ECSS-E-ST-10-06C is strict about modal verbs. Shall imposes a binding obligation that must be verified and formally closed. Should is a recommendation, tradeable under documented justification. May is permission.

The reason this matters is not grammatical pedantry. It is that the wrong modal verb changes the verification status of a requirement invisibly. Consider this version of a data storage requirement which is a constructed example of what careless looks like:

The spacecraft should provide sufficient data storage for two days of observatory data.

If the design delivers 36 hours of storage at PDR, does the project have a non-compliance? Under ECSS, no. "Should" is a goal. The programme can close it with a documented trade and move on. But if the author intended this as a hard floor on fault tolerance, the wrong modal has just dissolved a firm requirement.

The actual ICON document reads:

SC-14: The ICON Observatory shall have sufficient data storage for up to 2 days of Observatory data.

The rationale is explicit: this allows for one day of ground station outtime. It is not a comfortable buffer, it is a design driver. One word changed, completely different verification status.

The failure mode usually runs in the opposite direction too. Engineers write "shall" for what is actually a design intent with no defined threshold. That produces requirements that cannot be closed at CDR, which either forces a waiver or gets quietly absorbed into the configuration baseline without anyone formally verifying it. I have seen both outcomes.

The verifiability test

ECSS defines four verification methods: test, analysis, inspection, and review of design. Every "shall" requirement has to be closed by at least one. The choice is not a formality. Assign the wrong method at the wrong level and you end up with a verification activity that either cannot be executed or proves nothing when it is.

The practical test is to read a requirement and ask:

which method applies, and what exactly would the verification activity look like?

If you cannot describe the activity concretely, the requirement is not verifiable.

Take this requirement from the MarcoPolo-R MRD:

R-ENV-040: The sample shall never be exposed to magnetic field larger than 200 uT.

Test is the primary method. You instrument the sample container location, apply representative electromagnetic sources from every relevant subsystem, and measure. But notice what "never" demands of the test design. It is a temporal claim that spans all mission phases: ground processing, launch, cruise, proximity operations, re-entry, recovery. The verification activity has to be explicitly scoped. Which phases? Which operational modes? Which ground-handling configurations? That scoping work is not administrative overhead. It is forced by taking the requirement's verifiability seriously from the beginning.

Now compare with the top-level mission requirement from the same document:

R-MIS-010: MarcoPolo-R shall safely return to Earth a sample from the primitive Near-Earth Asteroid 1996 FG3.

This is correctly stated for what it is: a mission success criterion, not a subsystem design requirement. You verify it by Review of Design at system level. The trajectory, the sampling mechanism, the ERC, the recovery operations together constitute the evidence. But if this sentence appeared at Level 3 on a subsystem requirements document, it would be unverifiable. No single subsystem test closes it. Level matters as much as wording.

The mechanism is easier to see against a concrete example. Closing R-MIS-010 at system level by Review of Design means the mission systems engineer aggregates evidence at a single gate: re-entry corridor analysis from the trajectory team, thermal and structural margins from the ERC team, capture and retention evidence from the sampling mechanism team. One person assembles the chain and signs the verification record.

Now allocate that same sentence to the sampling mechanism specification. The subsystem verification engineer can prove the mechanism captures material and survives re-entry loads. They cannot compel the trajectory team to produce corridor analysis at their gate. They own one piece of the argument, not the chain. The requirement cannot be closed by the person now responsible for closing it.

It resolves one of two ways: the requirement gets re-leveled, which costs schedule, or someone writes "compliant by inspection" against a subsystem document that only proves half the chain and the tracker moves on. From the outside those outcomes look identical until something fails.

Verifiability is not a property of a sentence. It is a property of a sentence at a specific level, owned by a specific team.

One bad requirement, one corrected

Here is the same intent written carelessly versus written to ECSS standard. The context is attitude control for a spacecraft making limb observations.

Constructed example of a carelessly written requirement:

The spacecraft attitude control system shall maintain accurate pointing during science operations.

"Accurate" is undefined. "During science operations" is unscoped. There is no number to analyse against, no condition to test under, no coordinate frame to make the measurement unambiguous. A verification engineer cannot close this. A supplier can claim compliance with no evidence. It will survive SRR and become a problem at CDR.

Written to ECSS-E-ST-10-06C standard:

The ICON Observatory pointing knowledge of the MIGHTI instrument bottom vector boresight, relative to the LVLH frame of reference, shall be known within a tangent height of 1.85 km (3-sigma).

Rationale: From the MIGHTI wind measurement error budget, achieving wind vector accuracy better than 8.7 m/s requires that pointing knowledge uncertainty contribute no more than 616 m (1-sigma) or 1.85 km (3-sigma) in tangent point altitude.

This is SC-5a from the ICON PRD. Three things make it work.

A number with a statistical qualifier. 1.85 km at 3-sigma is verifiable. You know the pass/fail criterion before you design the test, and you know what distribution you are sampling from.

A coordinate frame. "Relative to the LVLH frame" specifies the reference unambiguously. Without a frame, two teams can measure the same physical quantity and report different numbers in good faith.

A rationale. This is the field most documents omit, and its absence creates problems that are not obvious until the programme is under pressure. The rationale traces 1.85 km back to an 8.7 m/s wind measurement accuracy, which traces back to the Level-2 science requirement. That chain tells you whether SC-5a can be traded if the mass budget cracks. I will get into that in a follow-up post, because it is a longer argument and it deserves its own space.

Why this matters at CDR and not just at SRR

Requirements quality is usually treated as a documentation discipline: something you clean up before the review gate. That framing gets it backwards.

At CDR, the verification matrix becomes the technical baseline. Every requirement without a specified verification method either generates an RFA that consumes schedule, or gets closed by inspection of the document rather than the hardware. The second outcome is worse than it sounds, because it means the requirement was never really verified. It just stopped being tracked.

Writing verifiable requirements from the start is not process compliance. It is the technical work that keeps decisions legible when the programme needs to make hard trades.

The ICON Level-2 PRD (ICN-SYS-001 Rev E) and MarcoPolo-R MRD (SRE-PA/2011.076) are both publicly available. ECSS-E-ST-10-06C is free to download at ecss.nl. Reading all three in parallel is the most efficient way to see where the standard's rules show up in practice, and where they don't.