6 Derived requirement not identified as derived
DO-178C expects every high-level and low-level requirement either to trace to the level above or to be identified as derived, with its reason, and passed to the system processes and the system safety assessment. This requirement has no parent and is not flagged as derived.
- the test
- with DO-178C ticked: a requirement below the top level with no parent and no derived flag
- the question
- Is this requirement derived? If so, what is the reason for it, and has it been passed to the system safety assessment?
- asked of
- the requirement owner
- columns it reads
- Parent, Derived and Level
The clauses behind it, by standard
each shown when you tick its standard- DO-178C: 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)
The clause text
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
Each 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