Type-design packages
Requirements traceability support for a type-design data package
This review examines whether the requirements in a type-design data package trace cleanly down into design and across into verification. It follows requirements from the certification basis and system level into their allocation, and confirms that derived and changed requirements are captured rather than lost. A certification engineer performs it so the trace holds when a reviewer pulls a thread and follows it end to end. You get a gap assessment against the basis, an annotated trace showing where links break, and a plan to close the missing connections.
When this review is needed
- A supplier has captured requirements across levels and needs the links between them checked before submission.
- Design changes have added derived requirements and the team is unsure they all reached the trace.
- The verification plan is being built and requirements without a clear source or allocation are surfacing.
- An authority has asked to see traceability and the applicant wants gaps found before the request lands.
The problem
Requirements accumulate through the design in layers, and the links between those layers are maintained by hand across tools that rarely agree. A requirement gets refined, split, or superseded, and the trace above or below it is not updated. Derived requirements, the ones the design creates rather than inherits, are the easiest to write and the easiest to leave dangling with no parent and no verification.
What gets reviewed
- System-level and derived requirements traced up to the certification basis where a parent applies
- Requirements traced down into the design elements that implement them
- Each requirement traced across to the verification that confirms it
- Derived and changed requirements checked for capture, parent, and rationale
- Orphaned design or verification with no requirement behind it flagged
- Trace consistency checked across the tools and documents that hold the links
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 certification-basis requirement traces to at least one lower-level requirement or directly to verification
- Each derived requirement has a recorded rationale and a verification path
- No requirement is allocated to design without a corresponding verification link
- Requirements changed during the project reconcile with the current trace, not a stale version
- No design element or test claims a requirement that the requirements set does not contain
Evidence normally required
- The system and lower-level requirements sets with their identifiers
- The certification basis and any allocation of basis requirements to the system
- The design description showing which elements implement which requirements
- The verification plan or matrix linking requirements to evidence
- The change history for requirements added or modified during the project
Common discrepancies
- Derived requirements written into the design but never added to the trace
- Requirements whose parent was superseded, leaving the child pointing at nothing
- Verification links that reference a requirement identifier that no longer exists
- Design elements implementing behavior no requirement calls for
What is at stake
A broken trace lets a requirement slip through unverified, or leaves a piece of design with no requirement to justify it. When a reviewer follows a thread and it stops, the finding is not one broken link but a question about how many others are broken. That turns a spot check into a full trace audit, and the applicant reconstructs links under time pressure that should have been maintained all along.
How the work runs
Anchor at the basis
Start from the certification-basis requirements and confirm each has a downward path into the system requirements.
Walk the links
Follow requirements down into design and across into verification, marking every point the chain breaks.
Hunt derived and orphaned
Check derived requirements for parent and verification, and flag design or tests with no requirement behind them.
Group by root cause
Cluster the breaks by why they happened so the closure plan fixes causes at the source rather than one symptom at a time.
What the buyer receives
- A gap assessment scoring the trace against the certification basis and derived-requirement rules
- An annotated trace marking broken, orphaned, and stale links
- A closure plan grouping the breaks by cause so they can be fixed at the root
Who uses the output
- Certification leads who must show a complete trace during review
- Systems engineers who own the requirements and repair the links
- Configuration managers keeping the trace aligned with the current baseline
How the work fits into the transaction or program
Requirements traceability is the skeleton the compliance map and the verification evidence hang on. This review confirms the skeleton before the verification trace and the software and hardware lifecycle data are checked against it, so downstream reviews start from links that hold. It follows agreeing the basis and precedes closing verification.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both expect bidirectional traceability, and where DO-178C or DO-254 apply, the objectives set specific trace expectations by assurance level. The review reads the trace against the objectives that actually apply to this article rather than a generic expectation, since the depth demanded rises with the assigned level.
Regulatory limits
This work checks the completeness and integrity of the trace. It does not verify the requirements themselves, does not make a compliance finding, and does not determine airworthiness or grant approval. Verification and findings remain with the applicant and the authority.
What this review does not cover
- Performing the verification activities the trace points to
- Writing or correcting the requirements content itself
- Making compliance findings against the certification basis
Specific to this review
- Derived requirements break traces more often than inherited ones, because they have no natural parent and are added late by the people closest to the design.
- A trace kept in more than one tool tends to disagree with itself, and the disagreement is invisible until someone follows a thread across the boundary.
- Orphaned design is as much a finding as a missing verification link, since it implies a requirement was dropped rather than met.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
Do we need traceability if we already have a compliance map?
The compliance map shows a means for each basis requirement. Traceability shows that requirements actually reached the design and were verified, including the derived requirements the map never lists. A reviewer uses both, and a clean map over a broken trace still fails when the thread is pulled.
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.