PMA article data
Requirements traceability support for a PMA article approval package
This review examines the requirements traceability in a PMA article approval package, from the top-level requirements down through design to the items that implement them. A certification engineer confirms each requirement flows to design and back, that derived requirements are captured with rationale, and that a change on one end is reflected on the other. It catches derived or changed requirements that never made it into the trace. You receive a gap assessment, a bidirectional trace map, and a closure plan before the package enters formal review.
When this review is needed
- Requirements traceability is being assembled and the team wants it checked before verification builds on it.
- Derived requirements were created during design and may not all appear in the trace.
- A requirement changed late and the downstream design links need re-walking.
- Software and hardware items each carry their own trace and the layers must reconcile.
The problem
Requirements traceability is only as good as its last update, and updates lag design. A derived requirement gets written on a whiteboard and implemented before it reaches the trace, a high-level requirement is reworded and its children keep the old intent, and a deleted requirement leaves design elements pointing at nothing. The trace looks orderly in a tool while the design has moved underneath it, and the gaps are invisible until someone reads a branch end to end.
What gets reviewed
- Top-level requirements traced down to the design elements that implement them
- Design elements traced back up to a requirement so nothing is unaccounted for
- Derived requirements confirmed captured with rationale and allocated correctly
- Requirement changes checked to see their downstream links were updated
- Deleted or superseded requirements confirmed removed from active trace links
- Software and hardware trace layers reconciled where they meet
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 traces to at least one design element that implements it
- Every design element traces up to a requirement that justifies it
- Derived requirements appear in the trace with recorded rationale
- Changed requirements have downstream links updated to match the new intent
- No active link points at a deleted or superseded requirement
Evidence normally required
- The current requirements set at each level of decomposition
- The design definition and the items that implement the requirements
- The derived-requirements list with its rationale
- The requirement change history since the trace was last baselined
- The trace data for software and hardware items where they interface
Common discrepancies
- Derived requirements implemented in design but never entered into the trace
- Changed requirements whose children still carry the superseded intent
- Design elements with no upward link to any requirement
- Deleted requirements left with active downstream links pointing at them
What is at stake
A trace with orphaned or missing links undercuts every verification claim built on it, because verification proves the wrong or an incomplete set of requirements. When a reviewer finds a derived requirement outside the trace, they reasonably assume there are others, and the whole traceability argument comes under question at the moment it most needs to hold.
How the work runs
Walk the trace down
Follow each top-level requirement into design and confirm an implementing element exists for it.
Walk the trace up
Follow each design element back to a requirement so nothing is left unaccounted for.
Check derived and changed items
Confirm derived requirements are captured with rationale and that requirement changes propagated downstream.
Deliver the map and plan
Provide a bidirectional trace map and a closure plan for the gaps found.
What the buyer receives
- A gap assessment listing each broken, missing, or stale trace link
- A bidirectional trace map from requirements through design and back
- A closure plan for the derived, changed, and orphaned items
Who uses the output
- Certification leads defending traceability as the package's backbone
- Engineering leads confirming design is fully requirement-driven
- Verification leads who will build test coverage on this trace
How the work fits into the transaction or program
Requirements traceability underpins the verification trace and the compliance argument, so it is checked before verification claims rest on it. A clean requirements trace means verification proves the right set; a broken one means later work inherits the gap and multiplies it.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
This work supports PMA approval under the FAA framework, and where software or hardware is involved the trace is expected to follow the recognized development assurance guidance. The review keeps the traceability structured for FAA review and does not recast it for another authority's process.
Regulatory limits
This review assesses the completeness and consistency of the requirements trace. It does not author requirements, does not make a compliance finding, and does not grant PMA or any airworthiness approval.
What this review does not cover
- Writing or deriving the requirements themselves
- Performing the verification that the trace supports
- Baselining or managing the requirements tool on the supplier's behalf
Specific to this review
- Requirements traces break most often at derived requirements, which are created in design and reach the trace last, if at all.
- A reworded top-level requirement whose children were not updated is harder to catch than a missing link, because the trace still looks connected.
- Upward orphans, design with no parent requirement, signal either scope creep or a requirement that was deleted without cleaning its links.
- Where software and hardware traces meet, mismatched decomposition levels create seams a reviewer probes first.
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.
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).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
Why check requirements traceability separately from verification traceability?
Because they answer different questions. The requirements trace shows the design implements the right requirements; the verification trace shows those requirements were actually tested. If the requirements trace is broken, verification proves an incomplete set, so this review confirms the foundation before verification claims are built on it.
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.