Requirements evidence
Derived-requirements review for systems and software
A derived-requirements review checks that an article's derived requirements, the ones a design decision introduces rather than a higher-level requirement, are identified as derived, justified, and fed back to the safety assessment for evaluation. It is used by avionics and equipment suppliers managing systems and software requirements. You receive a reviewed requirements set and a list of derived requirements that are mislabeled, unjustified, or never returned to the safety process where their effect should have been assessed.
When this review is needed
- A design has introduced requirements with no parent and the team needs them identified and justified.
- The safety assessment is closing and it has to account for the derived requirements the design produced.
- A trace shows requirements without parents and the team cannot tell which are genuinely derived.
- An architecture decision created constraints that were never written down as derived requirements.
The problem
A derived requirement is one the design imposes that no higher-level requirement asked for, which means it can carry an effect the safety assessment never saw. The standard process is to mark it as derived, justify why it exists, and send it back to safety for evaluation. In practice derived requirements are mislabeled as ordinary low-level requirements, justified with a circular note, or simply never routed back, so a design choice quietly bypasses the safety process.
What gets reviewed
- Identification of which requirements are genuinely derived versus decomposed from a parent
- The justification recorded for each derived requirement
- Feedback of derived requirements to the safety assessment and the disposition recorded there
- Traceability of derived requirements through design and verification
- Consistency between system-level and software-level treatment of derived requirements
- Whether derived hardware requirements are routed to the same safety evaluation as derived software requirements
What gets validated
- Each requirement without a parent is correctly identified as derived
- Every derived requirement carries a justification that is not circular
- Each derived requirement was fed to the safety assessment and a disposition was recorded
- Every derived requirement is traced through design and verification like any other requirement
- System-level and software-level derived requirements are handled consistently
- A derived requirement with a safety effect is reflected in the failure conditions the assessment considered
Evidence normally required
- The requirements set with parent-child traceability
- The recorded justifications for derived requirements
- The safety assessment and its record of derived-requirement evaluation
- The verification evidence covering the derived requirements
Common discrepancies
- Derived requirements mislabeled as ordinary decomposed requirements
- Justifications that restate the requirement instead of explaining why it exists
- A derived requirement never fed back to the safety assessment
- Genuinely derived requirements absent from the verification trace
- Inconsistent treatment between the system and software requirement sets
What is at stake
A derived requirement that never reaches the safety assessment is a hole in the safety argument that an examiner can open. Closing it late can reach back into the assessment itself, and a change there can ripple through verification that was already considered complete.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Separate derived from decomposed
Examine requirements without a parent and confirm which are genuinely derived rather than decomposition links that broke.
Test the justification
Check that each derived requirement explains why it exists rather than restating what it requires.
Confirm the safety loop
Verify each derived requirement was fed to the safety assessment and a disposition was recorded there.
Reconcile the sets
Return the reviewed set with reclassifications and a feedback note pairing open items to the assessment step they need.
What the buyer receives
- A reviewed requirements set with derived items confirmed or reclassified
- A list of derived requirements that lack justification or safety feedback
- A feedback note pairing each open derived requirement with the assessment step it needs
Who uses the output
- Systems engineering leads reclassifying and justifying derived requirements
- Safety leads closing the assessment with the derived items accounted for
- Certification leads confirming the safety argument has no unrouted derived requirement
How the work fits into the transaction or program
The review protects the link between design decisions and the safety assessment, the point where a derived requirement can otherwise slip past evaluation. It supports the requirements-based test work downstream, since a derived requirement has to be verified like any other once it is properly captured.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The review checks how the applicant identifies, justifies, and routes derived requirements. It does not perform the safety assessment, make compliance findings, or guarantee the authority will agree the safety argument is complete.
What this review does not cover
- Performing the safety assessment or assigning failure-condition classifications
- Making compliance findings on the authority's behalf
- Authoring the missing justifications on the program's behalf
Specific to this review
- A derived requirement carries an effect no parent requirement specified, which is why feeding it back to the safety assessment is the step that protects the safety argument.
- Mislabeling a derived requirement as an ordinary low-level requirement is the most common way a design decision bypasses safety evaluation.
- Justifications that restate the requirement rather than explain its origin are a recurring finding, because they look complete without doing the work.
- Derived hardware and software requirements both need routing to safety; a review that checks one set and not the other leaves a path for an unassessed design choice.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
Frequently asked questions
What makes a requirement derived rather than decomposed?
A decomposed requirement traces up to a parent that asked for it. A derived requirement is introduced by a design decision with no parent, so it can carry an effect the safety assessment has not yet seen.
Why does feedback to the safety assessment matter so much?
A derived requirement can introduce a safety effect no higher-level requirement specified. Routing it back to the assessment is the step that lets that effect be evaluated before it becomes a hole in the safety argument.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Walk through your situation with an engineer who has done this work.