Pre-submittal finding closure
Closing derived requirements that never reached the trace
This work closes a finding where derived requirements, the ones a design generates that no higher requirement asked for, never made it back into the traceability and the safety assessment. An engineer reads the requirements trace, finds the derived requirements that live only in a design document, and links each into verification and into the hazard analysis that must judge its effect. It runs during a pre-submittal review. You receive a closure brief on the untraced derived requirements, an evidence request list for the safety-assessment and verification links still needed, and a disposition package showing each derived requirement carried through trace, verification, and safety review.
When this review is needed
- Derived requirements exist in design or software documents but appear nowhere in the requirements trace.
- A derived requirement was never assessed by the safety analysis for the effect it could have.
- An implementation choice created a constraint that was never captured as a derived requirement at all.
- The trace shows derived requirements with parents, which means they were misclassified rather than genuinely derived.
The problem
Derived requirements are the easiest thing in a program to lose, because by definition nothing upstream points to them. An engineer makes a design or implementation choice, writes the constraint into a lower-level document, and moves on. The requirement is real and it can affect safety, but it never climbs back into the trace or reaches the people running the hazard analysis. The standards are explicit that derived requirements have to be fed to the safety assessment, and that feedback loop is exactly where teams under schedule pressure cut the corner.
What gets reviewed
- The derived requirements identified across design, software, and hardware documents
- Each derived requirement checked for a link into the requirements trace
- Each derived requirement checked for assessment by the safety analysis for its effect
- Verification confirmed present for every derived requirement, matching the rigor applied to parent requirements
- Requirements labeled derived but carrying a parent flagged as misclassified
- A trace showing each derived requirement fed into verification and safety assessment
What gets validated
- Every derived requirement in a design or implementation document is present in the requirements trace
- Each derived requirement has been assessed by the safety analysis for the effect it could introduce
- Verification evidence exists for derived requirements the same as it does for requirements with parents
- No requirement is labeled derived while still carrying an upstream parent link
- Implementation constraints that act as requirements are captured as derived rather than left informal
Evidence normally required
Common discrepancies
- A derived requirement written into a software design document that the trace never captured
- An implementation constraint acting as a requirement but never formalized as a derived one
- A derived requirement in the trace that the safety assessment never evaluated
- A requirement labeled derived that still points to a parent, meaning it was misclassified
What is at stake
A derived requirement missing from the safety assessment means a design decision that no hazard analysis ever judged, which is precisely the failure the assessment process exists to prevent. A reviewer who finds one untraced derived requirement will question whether the safety analysis is complete, and reopening the safety assessment late is one of the most expensive reworks a certification program can face.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Harvest the derived set
Collect derived requirements from design, software, and hardware documents, including informal constraints.
Check both directions
Confirm each derived requirement is in the trace and has reached the safety assessment.
Restore the loop
Link each derived requirement into verification and into the hazard analysis inputs.
Package the disposition
Write the closure brief, list the safety and verification links owed, and deliver the corrected trace.
What the buyer receives
Who uses the output
- Certification engineers restoring the derived-requirement feedback loop before submittal
- Safety engineers assessing derived requirements that never reached the hazard analysis
- Program managers gauging whether reopening the safety assessment affects the schedule
How the work fits into the transaction or program
This closure sits at the junction of requirements engineering and safety assessment, which is where the derived-requirement feedback loop the standards require is supposed to run. It depends on a settled requirements trace and feeds the safety analysis, so closing it protects both the verification argument and the hazard assessment. Left open, it undermines the claim that the design has been fully assessed.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both expect derived requirements to be fed to the safety assessment, but the guidance material each accepts and the depth of trace each samples can differ, so the restored feedback loop is documented in the terms the reviewing authority applies.
Regulatory limits
This work identifies untraced derived requirements and links them into trace, verification, and the safety assessment inputs. It does not perform the safety assessment itself, judge the acceptability of a hazard, approve the trace, or make any compliance finding.
What this review does not cover
- Performing or reissuing the safety assessment or hazard analysis
- Judging whether a derived requirement's effect on safety is acceptable
- Making the compliance finding on any requirement
Specific to this review
- Derived requirements are uniquely easy to lose because nothing upstream references them, so they never surface by tracing down from parents.
- A requirement labeled derived that still has a parent is a classification error that hides a real trace break behind a correct-looking status.
- The standards specifically require derived requirements to be fed to the safety assessment, so a missing link here is a direct process finding, not a bookkeeping one.
Sources
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.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
Do you run the safety assessment on the derived requirements you find?
No. We identify the derived requirements missing from the assessment and route them to the safety engineers with the context they need, then link the result back into the trace. Judging the effect of a hazard is the safety team's work; we make sure nothing reaches submittal without having been given to them.
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.
Talk through the aircraft, records, evidence, deadline, and next useful step.