Requirements traceability in DO-178C
DO-178C asks that high-level requirements trace to the system requirements and low-level requirements to the high-level requirements, derived ones excepted and identified; that every requirement is verifiable; that tests cover every high-level and low-level requirement; and that each test result is checked and every discrepancy explained. The trace data is often kept as a requirements traceability matrix.
- standard
- DO-178C: software considerations in airborne systems and equipment certification
- edition held
- DO-178C / ED-12C, as the export names it
- clauses cited here
- 10 of the 71 held; shown when you tick DO-178C
- every clause we hold
- DO-178C, clause by clause
Where each finding cites it
- 1Requirement with no parent: A-3.6 (high-level requirements) and A-4.6 (low-level requirements)
- 2No verification method or no linked verification: A-7.3 (high-level requirements) and A-7.4 (low-level requirements)
- 3Verification failed, blocked or not run: A-7.2
- 5Test that traces to no requirement: A-6.1
- 6Derived requirement not identified as derived: A-2.2 (high-level requirements), A-2.5 (low-level requirements), A-3.6 (high-level requirements) and A-4.6 (low-level requirements)
- 7Parent outside this export, or an ID used twice: A-3.6 (high-level requirements) and A-4.6 (low-level requirements)
- 8Wording that may not be verifiable: A-3.4 (high-level requirements) and A-4.4 (low-level requirements)
The columns that show it in a requirements traceability matrix
Parent, Level, Derived, Verification Method, Verified By, Justification, the results: Result and Date, the results: Requirements, the results: Type, ID and Requirement Text. The requirements traceability matrix template carries every one.
What it asks, clause by clause
10 clausesEach high-level requirement links to the system requirements it implements, derived ones excepted and identified. Table A-3 objective 6, described in 6.3.1.f; applies at levels A, B, C, D, no independence required; activities 6.3.1; outputs Software Verification Results.
Applies at software level A, B, C, D: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Trace review showing every high-level requirement traces to system requirements
where it usually breaks Orphan high-level requirements
Each low-level requirement links to a high-level requirement, derived ones excepted and identified. Table A-4 objective 6, described in 6.3.2.f; applies at levels A, B, C, no independence required; activities 6.3.2; outputs Software Verification Results.
Applies at software level A, B, C: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Trace review from low-level to high-level requirements
where it usually breaks Orphan low-level requirements not identified as derived
Requirements coverage analysis shows each high-level requirement has test cases. Table A-7 objective 3, described in 6.4.4.a; applies at levels A, B, C, D, independence required at level A; activities 6.4.4.1; outputs Software Verification Results.
Applies at software level A, B, C, D: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements-based coverage analysis showing every high-level requirement is tested
where it usually breaks Requirements with no test case
Requirements coverage analysis shows each low-level requirement has test cases. Table A-7 objective 4, described in 6.4.4.b; applies at levels A, B, C, independence required at level A; activities 6.4.4.1; outputs Software Verification Results.
Applies at software level A, B, C: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements-based coverage analysis at the low-level requirements
where it usually breaks Low-level coverage assumed from high-level tests
Test results are checked for correctness and each discrepancy between expected and actual results is explained. Table A-7 objective 2, described in 6.4.5.c; applies at levels A, B, C, independence required at level A; activities 6.4.5; outputs Software Verification Results.
Applies at software level A, B, C: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Review of test results with every discrepancy explained and dispositioned
where it usually breaks Failures left unexplained or re-run without analysis
Normal-range requirements-based tests on the executable object code show it satisfies the high-level requirements, with trace data between requirements, test cases, procedures and results. Table A-6 objective 1, described in 6.4.a; applies at levels A, B, C, D, no independence required; activities 6.4.2, 6.4.2.1, 6.4.3, 6.5; outputs: Trace Data, Software Verification Results, and Software Verification Cases and Procedures. All tests, normal and robustness, are requirements-based; the purpose of verification trace data (6.5, new) is requirements coverage analysis and proof that every procedure ran.
Applies at software level A, B, C, D: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements-based test cases, procedures and results for high-level requirements, traced
where it usually breaks Tests not derived from requirements
High-level requirements that do not come directly from system requirements, or that specify behaviour beyond them, are marked as derived, given the reason they exist and handed to the system processes, the system safety assessment among them. Table A-2 objective 2, described in 5.1.1.b; applies at levels A, B, C, D, no independence required; activities 5.1.2.h, 5.1.2.i; outputs Software Requirements Data. The revision moved the definition of derived requirements onto content (behaviour beyond the higher level) rather than traceability alone and added the rationale for each.
Applies at software level A, B, C, D: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Derived high-level requirements identified as such and the record of their delivery to the system safety process
where it usually breaks Derived requirements not flagged and never fed back to safety assessment
Low-level requirements that are derived are identified, given a justification and handed to the system processes, the system safety assessment among them. Table A-2 objective 5, described in 5.2.1.b; applies at levels A, B, C, no independence required; activities 5.2.2.b, 5.2.2.c; outputs Design Description.
Applies at software level A, B, C: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Derived low-level requirements identified and their delivery to the system safety process recorded
where it usually breaks Derived low-level requirements not communicated to the safety process
Every high-level requirement can be verified. Table A-3 objective 4, described in 6.3.1.d; applies at levels A, B, C, no independence required; activities 6.3.1; outputs Software Verification Results.
Applies at software level A, B, C: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Review records showing each high-level requirement can be verified
where it usually breaks Requirements phrased so no test can pass or fail them
Every low-level requirement can be verified. Table A-4 objective 4, described in 6.3.2.d; applies at levels A, B, no independence required; activities 6.3.2; outputs Software Verification Results.
Applies at software level A, B: a line at another level does not carry it.
Held text: DO-178C / ED-12C, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Review records showing each low-level requirement is verifiable
where it usually breaks Unverifiable low-level requirements
Named, not quoted
- DO-254 (airborne electronic hardware): the hardware counterpart of DO-178C, with its own requirements capture and traceability objectives. Named, not quoted: we do not hold its text.
- ARP4754B (development of civil aircraft and systems): the aircraft and system development process whose requirements DO-178C and DO-254 receive. Named, not quoted: we do not hold its text.