Requirements traceability
Closing derived requirements missing from the STC trace and safety assessment
This closure work handles derived requirements that a design created but the trace and safety assessment never absorbed. It is run for the modifier when requirements introduced below the top level, by an implementation choice or a design decision, are not linked upward to verification and are not fed back to the safety assessment that must evaluate them. The work identifies the orphaned derived requirements, restores their trace to verification evidence, and confirms each one reached the safety analysis for a decision on its effect. You receive a reconciled trace, an evidence and rationale request list, and a disposition package that shows every derived requirement connected and assessed.
When this review is needed
- Design decisions introduced requirements that appear in specifications but nowhere in the trace.
- The safety assessment was closed before some derived requirements existed.
- A reviewer asked how a derived requirement was evaluated for its safety effect and the link is absent.
- An implementation constraint became a requirement that was never verified or fed upward.
The problem
Derived requirements are the ones the design invents rather than inherits: a timing constraint, a partitioning rule, a bound that an implementation choice forces. Because they do not come from the level above, the normal top-down trace does not carry them, and they have to be pushed back into traceability and up into the safety assessment by hand. When that feedback step is skipped, the requirement lives in a specification with nothing above it and nothing evaluating whether it matters to safety. It is a well-known place for the trace to break, and reviewers know to look there.
What gets reviewed
- Derived requirements identified across the design and specification set
- Each one checked for an upward link and a downward link to verification
- Confirmation that every derived requirement reached the safety assessment
- Trace restored where a derived requirement was orphaned from verification
- Safety-assessment feedback recorded where a derived requirement was never evaluated
What gets validated
- Every derived requirement has a rationale explaining why it exists
- Each derived requirement traces down to a verification result
- Each derived requirement was fed to the safety assessment and evaluated there
- The safety assessment reflects the current derived-requirement set, not an earlier one
- No derived requirement sits in a specification with no link above or below it
Evidence normally required
- The requirements traceability data across levels
- The design specifications where derived requirements are captured
- The safety assessment and its list of evaluated requirements
- Verification results that may already cover derived requirements
- Rationale records for the design decisions that produced them
Common discrepancies
- A derived requirement in a specification with no trace link in either direction
- A safety assessment closed before a set of derived requirements was created
- A derived requirement verified but never fed back to the safety analysis
- An implementation constraint acting as a requirement with no recorded rationale
What is at stake
A derived requirement outside the safety assessment means the analysis was performed against an incomplete requirement set, which is a finding that can force the safety work to be reopened rather than patched. Left unverified, it is a requirement the design depends on with no proof it was met. Reviewers treat missing derived-requirement feedback as a sign the trace discipline broke somewhere upstream, so the finding rarely stays contained to one requirement.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Find the derived set
Identify derived requirements across the specifications and separate them from inherited ones.
Check both directions
Confirm each has a rationale, a downward verification link, and an upward path to the safety assessment.
Restore the feedback
Reconnect orphaned items to verification and record where they must reach the safety analysis.
Package the reconciliation
Show every derived requirement linked and assessed for reviewer disposition.
What the buyer receives
- A reconciled trace with every derived requirement linked up and down
- An evidence and rationale request list for the orphaned items
- A disposition package showing each derived requirement verified and assessed
Who uses the output
- Certification leads confirming the trace and safety assessment agree on the requirement set
- Safety engineers evaluating derived requirements that never reached them
- Program managers scoping any safety rework a late derived requirement triggers
How the work fits into the transaction or program
Derived requirements are the join between requirements traceability and the safety assessment, so closing them keeps those two data sets consistent. This work runs alongside the verification-trace closure and ahead of the finding review, because a derived requirement that reopens the safety assessment is better found before a reviewer relies on the analysis.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
The treatment of derived requirements and their flow into the safety assessment follows the same standards framework for both authorities, but the level of documented rationale a reviewer expects can differ. The closure work notes where a derived requirement accepted with light rationale on one submission needs a fuller justification for the other.
Regulatory limits
This work restores trace links and confirms derived requirements reached the safety assessment. It does not perform the safety assessment, decide a requirement's safety effect, approve the modification, or grant the STC. The safety judgment and the finding remain with the responsible engineers and the authority.
What this review does not cover
- Conducting or re-running the safety assessment itself
- Generating verification evidence for an unverified derived requirement
- Any determination of a derived requirement's acceptability
Specific to this review
- Derived requirements break the trace precisely because they have no parent above them, so the upward feedback is a manual step that is easy to skip.
- A single derived requirement discovered outside the safety assessment can invalidate the analysis, since the analysis is only as complete as its input requirement set.
- The rationale for a derived requirement is as important as its trace, because a reviewer needs to know why the design imposed it before judging how it was handled.
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
Why do derived requirements matter to the safety assessment specifically?
A derived requirement can constrain behavior the safety analysis needs to account for, such as a timing bound or a partitioning rule. If it never reaches the assessment, the analysis was done against an incomplete requirement set, and that is a finding a reviewer will not let pass on trace alone.
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.