What DO-178C requires for traceability
DO-178C (Software Considerations in Airborne Systems and Equipment Certification) is the standard by which the FAA and EASA certify that airborne software is safe to fly. It is not a quality management standard; it is a certification basis. Every objective in DO-178C must be satisfied, and for most objectives, satisfaction is demonstrated through documented evidence. The RTM is that evidence.
§5.1.1 establishes that system requirements allocated to software are the starting point for the software development process. Every software requirement must have a parent system requirement. Orphan software requirements (those that exist in the SRS but have no system-level parent) are a finding. The RTMify template’s User Needs tab captures the system requirements; the Requirements tab captures the allocated software requirements with parent linkage.
§5.2 Software Requirements Process produces the Software Requirements Data. High-level requirements (HLRs) are derived from system requirements. Low-level requirements (LLRs) are derived from HLRs via the design process. DO-178C requires bidirectional traceability: HLR → LLR and LLR → HLR. The Requirements tab supports this with a parent requirement field.
§6.3 Software Testing Process requires that tests be derived from requirements, not from code. Each test case must trace to one or more LLRs. Each LLR must be covered by at least one test case. DO-178C Table A-7 lists the testing objectives; traceability data is required at all DALs.
§11.9 Traceability Data is an explicit life cycle data item: a document showing the bidirectional trace from system requirements to HLRs to LLRs to source code to tests. The RTM is this document. At DER review, this is one of the first things examined.
How the template covers DO-178C
| Tab | DO-178C coverage |
|---|---|
| User Needs | §5.1.1: system requirements allocated to software |
| Requirements | §5.2: HLRs and LLRs with parent links, DAL annotation |
| Tests | §6.3: test cases linked to LLRs, test type annotation |
| Risks | Derived requirements tracking, safety impact annotation |
The RTMify Status column is particularly valuable for DO-178C because 100% coverage is not optional. Every LLR at DAL A through C requires at least one test. The NO_TEST_LINKED status identifies exactly which requirements are uncovered before you submit to your DER.
What it doesn’t cover: DO-178C also requires a Software Development Plan, Software Verification Plan, Software Configuration Management Plan, and Software Quality Assurance Plan. The template covers traceability data (§11.9). It does not replace the planning documents.
Common DO-178C audit / DER review gaps
- Derived requirements not flagged. A derived requirement is one that has no parent in the system requirements; it was introduced by design decisions. DO-178C requires that derived requirements be identified and fed back into the system safety assessment. If you don’t flag them, the DER will ask why.
- Test cases written from code, not requirements. The most common structural gap. Developers write tests that exercise the code they wrote, not the requirements they were supposed to implement. Coverage metrics look good; requirement coverage is actually partial.
- LLR-to-code traceability missing. DO-178C §6.3.4 requires test coverage of code. The RTM covers requirement-to-test. You also need code coverage data (MC/DC at DAL A, Decision coverage at DAL B). This is separate tooling but should reference the same test IDs.
- Bidirectional trace not maintained. Adding a test without updating the RTM breaks the trace. Adding a requirement without updating the test plan creates an uncovered requirement. The trace must be kept current through code freeze.
- DAL not annotated per requirement. At mixed-DAL levels, some requirements are DAL A and some are DAL B. Verification rigor depends on this. Requirements with no DAL annotation make it impossible to verify that appropriate rigor was applied.
DO-178C specific guidance
ID prefix convention: Use a structured prefix: SYS-001 for system requirements, HLR-001 for high-level requirements, LLR-001 for low-level requirements, TC-001 for test cases. This makes the parent-child relationships visually traceable and makes the §11.9 traceability data easy to generate.
DAL annotation: Add a DAL column to the Requirements tab. Valid values: A, B, C, D, E. Every requirement must have a DAL. The DAL drives which Table A objectives apply. A mixed-DAL system needs partition evidence; if you’re claiming a lower DAL for some software, document the basis.
Derived requirements: Add an isDerived boolean column. Filter this column when generating the §11.9 traceability data. Derived requirements get flagged in a separate section of the Software Requirements Data and reviewed in the system safety assessment.
Tool qualification: If you use the RTMify binary to generate your RTM PDF as a verification artifact, assess whether it requires tool qualification under DO-330. A tool that generates data used to satisfy a DO-178C objective may require qualification at TQL-4 or TQL-5. Document the assessment. A one-page memo is usually sufficient.
Relationship to DO-278A: For CNS/ATM ground systems, DO-278A applies instead of DO-178C. The structure is similar; the template applies directly with the same ID conventions.