DO-178C requirements management and traceability, explained

DO-178C, Software Considerations in Airborne Systems and Equipment Certification, is the standard that civil aviation authorities like the FAA and EASA use to judge whether airborne software is safe to certify. Published by RTCA in 2011 (and as ED-12C in Europe), it replaced DO-178B and remains the backbone of software assurance in commercial and military aviation.

DO-178C is not a coding standard. It’s an objectives-based assurance framework: it defines what you must demonstrate about your software, with the rigor scaled to how dangerous a failure would be. And at the center of nearly every objective is traceability.

Design Assurance Levels set the rigor

DO-178C assigns each software component a Design Assurance Level (DAL), from A to E, based on the severity of the failure condition it could cause:

• Level A — failure is catastrophic (e.g., loss of the aircraft). The most objectives, the most rigor.
• Level B — hazardous.
• Level C — major.
• Level D — minor.
• Level E — no safety effect. Essentially outside DO-178C’s assurance objectives.

The DAL determines how many of the standard’s objectives apply and how independently they must be satisfied. Level A software, for instance, requires modified condition/decision coverage (MC-DC) in structural coverage analysis; lower levels require less.

The requirements hierarchy

DO-178C structures software development as a flow-down of requirements:

• System requirements allocated to software.
• High-level requirements (HLRs) — what the software must do.
• Low-level requirements (LLRs) — detailed requirements from which source code can be directly written.
• Source code, then executable object code.

Each layer must derive from the one above it, and each must be verified against it. This is where DO-178C becomes demanding: it’s not enough to build the software: you must prove, with evidence, that every requirement is implemented and every piece of implementation traces to a requirement.

Bidirectional traceability and trace data

DO-178C explicitly requires bidirectional traceability — sometimes called trace data — across the entire hierarchy: system requirements ↔ high-level requirements ↔ low-level requirements ↔ source code ↔ test cases ↔ test results.

The two directions answer two certification questions:

• Forward (requirement → code → test): is every requirement implemented and verified? Gaps here mean unverified functionality.
• Backward (code → requirement): does every line of code trace to a requirement? Code with no requirement is unintended function — a red flag for certification authorities, because it represents behavior no one specified or reviewed.

When derived requirements emerge during design (requirements not traceable to a higher level), DO-178C requires them to be identified and fed back to the safety assessment process, precisely because they break the normal trace.

Requirements-based testing and coverage

DO-178C verification is requirements-based: test cases are written against requirements, not against the code as written. Two coverage analyses then check completeness:

• Requirements coverage — every requirement has test cases.
• Structural coverage — the tests actually exercised the code (statement, decision, and for Level A, MC-DC). Code exercised by no requirements-based test is, again, a sign of unintended function.

The standard is supported by supplements for tool qualification (DO-330), model-based development (DO-331), object-oriented technology (DO-332), and formal methods (DO-333).

Why one connected thread matters

The recurring theme is that DO-178C certification stands or falls on the integrity of the trace. When requirements, design, code references, tests, and results live in separate tools stitched together, every gap between tools is a place the trace can break — and a place a certification authority will look.

A complete requirements traceability matrix maintained as living data, rather than reassembled for each stage of involvement (SOI) audit, is what makes the assurance argument hold together. That’s the model TraceUnified is built on: requirements, architecture, tests, and verification status as linked records in one system, so forward and backward traceability — and the coverage and gap analysis that prove them — are intrinsic rather than reconstructed. The certification effort is still yours; the system is engineered to keep the trace data audit-ready by default.