ETSO authorization
Requirements traceability support for an ETSO authorization
This review examines the requirements traceability behind an EASA European Technical Standard Order authorization, meaning the links that connect each requirement down to the design that implements it and up to the verification that confirms it. A certification specialist checks that the chain holds in both directions and that derived and changed requirements were captured rather than lost when the design evolved. It runs while the requirement set can still be corrected, before verification is planned against it. You receive a gap assessment, a bidirectional trace map, and a closure plan for the requirements that fall out of the chain.
When this review is needed
- A supplier wants the requirement chain checked before verification is planned against it.
- Design work generated derived requirements that may not have flowed back into the traceability.
- A requirement change late in development risks orphaning downstream design or verification links.
- The article spans software and hardware and the trace has to hold across both under ARP4754B.
The problem
Traceability is built as the design is built, which means it is always slightly behind the design. A requirement gets refined, a design decision spawns a derived requirement, a change deletes a parent, and the links that were correct last month now point at something that moved. Derived requirements are the usual casualty: they are created inside the design, not handed down from the standard, so they slip out of the formal set and never get a verification assigned.
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 generated during design and their presence in the formal set
- Requirements changed or deleted and the downstream links that changed with them
- Allocation of system requirements across software and hardware under ARP4754B
- Orphan design or verification items that trace to no current requirement
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 to at least one design element that implements it
- Every requirement links to verification that will confirm it is met
- Each derived requirement appears in the formal set with a parent design rationale
- A deleted or changed parent requirement left no orphaned children behind it
- System requirements allocated to software and hardware trace into both trees
Evidence normally required
- The requirements traceability data at its current revision
- The article's requirement set including derived requirements
- The design description and the design decisions that produced derived requirements
- The verification plan or matrix if verification has begun
- The change history for requirements that were modified or removed
Common discrepancies
- Derived requirements created in design but never added to the formal set
- Requirements with a design link but no verification assigned
- Orphaned child requirements left after a parent was deleted
- System requirements allocated to hardware but absent from the hardware trace
What is at stake
A requirement with no design link or no verification link is a hole the authority will find, and each hole reopens the requirement group around it. Derived requirements missing from the trace are worse, because their absence means a real design decision was never verified, and closing them late can force verification work the program never scheduled.
How the work runs
Trace downward
Confirm each requirement links to the design elements that implement it and flag any that do not.
Trace upward
Confirm each requirement links to verification and find requirements marked met with no verification assigned.
Recover the derived set
Compare design decisions against the formal set to surface derived requirements that never flowed back in.
Resolve the orphans
Deliver a gap assessment and a closure plan for orphaned children and missing allocations.
What the buyer receives
- A gap assessment of requirements missing a design or verification link
- A bidirectional trace map showing the chain from requirement to design to verification
- A closure plan for the derived and orphaned requirements the review surfaced
Who uses the output
- Certification leads confirming the requirement set is complete before verification planning
- Compliance managers reconciling the trace to the compliance matrix
- Engineers recovering derived requirements back into the formal set
How the work fits into the transaction or program
Traceability is the spine that verification is planned against, so a hole in it becomes a hole in the verification plan. Checking the chain before verification is scoped means every requirement, including the derived ones, gets a verification assigned, rather than surfacing an unverified design decision after the test campaign is already built.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
EASA expects the ETSO article's requirement set to trace consistently through development, and where ARP4754B governs the development assurance, the allocation between software and hardware has to hold across both. The review reads the trace against that expectation rather than a lighter-touch reading, because a gap in allocation reads as a development assurance finding.
Regulatory limits
The review evaluates the supplier's own traceability data. It does not verify the requirements themselves, grant an authorization, or make a finding that the requirement set is complete in the authority's judgment. Verification and authorization remain with the applicant and EASA.
What this review does not cover
- Performing the verification the trace points to
- Writing or deriving the article's requirements
- Granting or holding the ETSO authorization
Specific to this review
- Derived requirements are the most common thing missing from a trace, because they originate inside the design rather than being handed down from the standard.
- A trace can be complete downward yet broken upward, so checking only requirement-to-design leaves unverified requirements hidden.
- Deleting a parent requirement can orphan its children silently, so change history is read alongside the current trace, not instead of it.
Sources
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
Why do derived requirements matter so much in an ETSO trace?
Derived requirements come from design decisions rather than the standard, so they are easy to leave out of the formal set. When they are missing, a real design choice goes unverified, and closing that late can force verification the program never planned.
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.