TSO finding closure
Closing derived requirements that never fed back into the trace on a TSO program
This helps equipment suppliers close a specific defect: derived requirements that design work created but that never flowed back into requirements traceability and the safety assessment. A specialist collects the derived requirements from wherever they actually live, in design descriptions, review notes, and software and hardware planning data, and links each one into the verification trace and into the failure-condition analysis that has to see it. The work happens during the program, once a reviewer or an internal audit notices requirements in the design that the trace and the safety case never acknowledge. You receive a closure brief, an evidence request list for the links that need substantiation, and a disposition package that shows every derived requirement traced and assessed.
When this review is needed
- A reviewer notes derived requirements in the design that are absent from the safety assessment inputs.
- The software or hardware planning data defines derived requirements that never appear in the system-level trace.
- A design decision introduced a constraint that no parent requirement drove, and it was never recorded as derived.
- The verification matrix has requirements with no upstream link and no evidence of how they were validated.
The problem
Derived requirements are the ones the design invents: choices with no parent requirement above them, made because the implementation needed them. They get written into design descriptions and planning data and then forgotten as certification artifacts, because the person who created one was solving an engineering problem, not maintaining a trace. The safety assessment never sees them, so their failure effects are never analyzed, and the trace shows a clean upstream picture that quietly omits the requirements the design added on its own.
What gets reviewed
- Derived requirements gathered from design descriptions, review records, and software and hardware planning data
- Each derived requirement validated as genuinely derived rather than a mislabeled child of an existing parent
- Traceability links added from each derived requirement down to its verification evidence
- Feedback of each derived requirement into the safety assessment as an input to the failure-condition analysis
- Requirements that turn out to have a parent reclassified and re-linked to it
- A reconciled trace showing no orphan verification items and no derived requirement outside the safety case
What gets validated
- Every derived requirement in the design appears in the requirements set with a derived classification and a rationale
- Each derived requirement has a verification method and evidence, not just a place in the list
- Derived requirements that affect a failure condition are present as inputs to the safety assessment that analyzes it
- A requirement labeled derived genuinely has no parent, rather than a parent that was never linked
- The trace has no verification item whose only source is a requirement missing from the safety case
Evidence normally required
- Design descriptions, architecture documents, and design review records
- Software and hardware planning and design data where derived requirements are defined
- The current requirements set and traceability matrix
- The safety assessment and its list of requirement inputs
- Any reviewer comments identifying missing or unassessed requirements
Common discrepancies
- A derived requirement written into a design description that never entered the requirements database
- A requirement labeled derived that actually descends from an existing parent it was never linked to
- A derived constraint verified in test but never fed to the safety assessment
- Planning-data derived requirements at the software level that the system trace does not reflect
What is at stake
A derived requirement outside the safety assessment is a failure mode nobody evaluated. If a reviewer catches it, the finding forces the safety case to be reopened and re-argued, which is slow and touches every artifact downstream. If a reviewer does not catch it, the article carries an unassessed contribution to a failure condition into service, and that is the finding no supplier wants to explain later.
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 descriptions, review records, and software and hardware planning data.
Classify each one
Confirm each is genuinely derived or reclassify it under the parent it was never linked to.
Link down and across
Add verification traceability and feed each derived requirement into the safety assessment that must see it.
Reconcile and hand over
Deliver a trace with no orphan verification items and a disposition package showing full derived coverage.
What the buyer receives
- A closure brief listing each recovered derived requirement with its trace and safety-assessment status
- An evidence request list for the verification or analysis links that still need substantiation
- A disposition package showing every derived requirement traced downward and fed into the safety case
Who uses the output
- Certification leadership confirming the safety case rests on the complete requirement set
- Engineering leads reconciling design decisions with the certification trace
- Program management closing the finding without reopening the whole safety assessment late
How the work fits into the transaction or program
This closes the loop that development processes leave open when derived requirements are created but not fed back. It connects the design and planning data where derived requirements are born to the trace and safety assessment that certification depends on, so the safety case reflects what the design actually built.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
Both FAA and EASA expect derived requirements to be identified and their effects fed to the safety assessment, and both treat an unassessed derived requirement as a gap in the safety argument. The recovery work is authority-neutral, but the level of process evidence a reviewer expects can differ by article class and assurance level.
Regulatory limits
The work recovers derived requirements and links them into the trace and safety assessment. It does not perform the safety assessment itself, does not judge whether a failure condition is acceptable, and does not grant or recommend any authorization; the airworthiness judgment stays with the authority.
What this review does not cover
- Authoring the safety assessment or its failure-condition analysis
- Redesigning the article to remove an unassessed derived requirement
- Running the verification tests that close an unverified derived requirement
Specific to this review
- Derived requirements are the most likely to be lost because their author was solving an engineering problem, not curating a trace.
- A derived requirement missing from the safety assessment is a failure effect nobody analyzed, which is why reviewers treat it as a safety gap rather than a paperwork gap.
- Some requirements labeled derived are not derived at all; they have a real parent that was never linked, and closing that is cheaper than manufacturing a rationale.
- Software and hardware planning data breed derived requirements that never rise to the system trace, so the gap often lives one level below where the trace is checked.
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 does a derived requirement need to reach the safety assessment at all?
A derived requirement is a design decision with no parent above it, so it introduces behavior the higher-level requirements did not ask for. If that behavior can contribute to a failure condition, the safety assessment has to evaluate it. When the derived requirement never reaches the assessment, its failure effects are unanalyzed, which is exactly the gap a reviewer flags.
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.