TECHNICAL NOTES · REQUIREMENTS & CERTIFICATION
Requirements traceability that survives a certification audit
Traceability is easy to have and hard to have well. Most programmes can produce a matrix; fewer can produce one that answers an auditor's questions without a week of rework. Here is what the guidance asks for, and what tends to fail.
What the guidance asks for
ARP4754A frames development assurance from aircraft functions down through system requirements to the items that implement them, and expects each level's requirements to trace to the level above, with validation and verification evidence linked to them. DO-178C carries the chain into software: system requirements allocated to software, high-level requirements, low-level requirements and source code — with trace data that runs both ways. Every requirement traces down to what implements and verifies it; everything implemented traces back up to a requirement.
Two details catch teams out. Derived requirements — those not directly traceable to a higher level, often born from design decisions — must be identified as such and provided to the system processes, including the system safety assessment. And verification is requirements-based: tests trace to requirements, and structural coverage analysis then exposes code that no requirements-based test exercised.
The questions an auditor actually asks
- Pick any requirement: where is it implemented, and which test verifies it?
- Pick any function in the code: which requirement does it exist for?
- Which requirements are derived, why, and did the safety assessment see them?
- A requirement changed last month: what was re-verified, and why only that?
- Where coverage analysis found unexercised code, how was each gap resolved?
Each should be answerable from the trace data itself, quickly, for whichever item the auditor chooses.
Five patterns that fail
- Traces to documents, not requirements. “See SRS section 4” is not a trace; the link must run between identified requirements.
- Catch-all links. One test linked to forty requirements, or one requirement linked to “all tests”, says nothing about what was verified.
- Unflagged derived requirements. A low-level requirement with no parent and no derived flag is either an orphan or an undocumented design decision — both are findings.
- Traceability built at the end. Matrices assembled just before an audit mirror the documents rather than the reasoning, and break on the first change.
- No change impact. If the trace can't say what a change touches, every change means re-verifying everything — or quietly re-verifying too little.
A trace record that holds up
| FIELD | EXAMPLE |
|---|---|
| Requirement | HLR-NAV-112 |
| Parent | SYS-NAV-031 — or DERIVED, with rationale |
| Implemented by | LLR-NAV-112.1, LLR-NAV-112.2 → nav_filter.adb |
| Verified by | TC-NAV-112-01 (normal range), TC-NAV-112-02 (robustness) |
| Verification method | Test |
| Status · baseline | Verified · baseline 4.2 |
Fine-grained links with identifiers on both ends, a stated method and a baseline: the record answers the auditor's questions without a narrative around it.
Where tooling helps
Requirements that can be traced start as requirements that can be verified — see our note on writing verifiable requirements with EARS. TELOS authors and checks requirements and their trace links; THEMIS maps the evidence to the objectives of the standard you are working to. Neither replaces what an auditor is really testing: that the team knows why every line exists.
Related notes
- Writing verifiable requirements with EARS
- AI-generated flight code under DO-178C
- EASA's AI concept paper Issue 03: what it means for LLMs in aerospace
Published · 7 October 2026 · All technical notes