TSO authorization
Requirements traceability support for TSO authorization
A TSO requirements trace review confirms the chain from each requirement down to its design implementation and back up through verification holds without a break. Equipment suppliers use it before submission, so derived and changed requirements are in the trace rather than orphaned in someone's notes. It checks that every requirement links to a design element and a verification item, that derived requirements from the design are captured and fed to safety, and that changes propagated through the whole chain. You get a gap assessment on the trace, a map showing where each requirement lands in design and verification, and a closure plan for the links that are missing or stale.
When this review is needed
- The design is stable enough that the trace should be closed, and derived requirements need to be accounted for before submission.
- A late requirement change has to propagate through design and verification and the trace has to prove it did.
- Derived requirements from the software or hardware design were never fed back to the safety process.
- The trace was maintained in a tool whose links broke when the requirement set was renumbered.
The problem
Traceability is easy to assert and hard to keep true through change. Requirements get added, split, and reworded across a program, and each change has to ripple down to design and up through verification, but the links lag the edits. Derived requirements, the ones the design creates rather than the standard, are the ones most often left out of the trace and the safety loop, and they are invisible until a reviewer follows the chain and it dead-ends.
What gets reviewed
- Downward links from each requirement to the design elements that implement it
- Upward links from each requirement to the verification that confirms it
- Derived requirements captured, justified, and fed to the safety assessment
- Change propagation from reworded or split requirements through the full chain
- Trace integrity across DO-178C software and DO-254 hardware requirement sets
- Requirements with no design or no verification link identified as breaks
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Every requirement links downward to at least one design element that implements it
- Every requirement links upward to verification evidence that actually addresses it
- Each derived requirement is recorded with a rationale and passed to the safety process
- A changed requirement shows the change reflected in its design and verification links
- No verification item traces to a requirement the current design has removed or superseded
Evidence normally required
- The requirement set with any derived requirements identified
- Design data for the software and hardware that implements the requirements
- Verification records and the trace links currently maintained
- The change history for the requirement set across the program
- The safety assessment inputs that derived requirements should feed
Common discrepancies
- A derived requirement present in the design but absent from the trace and the safety loop
- A requirement with a design link but no verification addressing it
- A verification item still pointing at a requirement the design has superseded
- A reworded requirement whose downstream links were never updated to match
What is at stake
A broken trace means a requirement can be implemented but never verified, or verified against something the current design no longer does. Derived requirements missing from the trace are missing from the safety assessment too, so a hazard can go unaddressed. Reviewers follow the chain deliberately, and a dead-end there is a finding that reopens design and verification at once.
How the work runs
Walk the chain down
Confirm each requirement reaches a design element that implements it.
Walk the chain up
Confirm each requirement reaches verification that actually addresses it.
Recover the derived
Find derived requirements missing from the trace and route them to safety.
Close the breaks
List the missing and stale links and sequence the work to complete them.
What the buyer receives
- A gap assessment on the requirements trace in both directions
- A trace map showing each requirement's design and verification landing points
- A closure plan for the missing, stale, or one-directional links
Who uses the output
- Certification leads who must show a closed trace to the FAA
- Engineering owners resolving derived requirements the trace exposes
- Safety engineers picking up derived requirements that were never routed to them
How the work fits into the transaction or program
The trace is the spine the compliance matrix, the verification evidence, and the safety assessment all attach to. This review closes it after the design settles and before submission, and its output tells the verification and safety work exactly which links they still have to complete.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The trace is built to the DO-178C and DO-254 expectations the FAA applies for the article, so its structure follows FAA-accepted guidance. The same trace can support a later program under another authority, but the review does not assume the link expectations are identical across authorities.
Regulatory limits
The review checks that the trace is complete and bidirectional. It does not verify the requirements themselves, perform the safety assessment, or make a finding that the design meets its requirements.
What this review does not cover
- Running the verification that closes the upward links
- Performing the safety assessment derived requirements feed
- Authoring or approving the design that implements the requirements
Specific to this review
- Derived requirements are the trace's blind spot: the design creates them, so they never appear in the standard's requirement list and are easy to leave out of both the trace and safety.
- Trace links lag requirement edits, so a program that reworded requirements late almost always has stale downstream links no one updated.
- A verification item pointing at a superseded requirement is worse than a missing link, because it reads as coverage while proving nothing about the current design.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Why do derived requirements get so much attention here?
Derived requirements come from the design rather than the standard, so they are not on any incoming requirement list. Such derived items are the ones most often absent from both the trace and the safety assessment, and a missing one can leave a hazard unaddressed, which is why the review hunts for them specifically.
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.