What AS9100 Rev D requires for traceability
AS9100 Rev D is the aerospace quality management standard built on top of ISO 9001, layered with additional requirements specific to aviation, space, and defense. Section §8.3 governs design and development, and it is where auditors spend most of their time.
§8.3.3 Design and Development Inputs requires that inputs related to the intended function, applicable statutory and regulatory requirements, and information from previous design efforts be determined and documented. Every requirement must have an origin. An RTM with no source column fails this clause immediately.
§8.3.4 Design and Development Outputs must be verifiable against the inputs. This is the direct mandate for bidirectional traceability: each output (a design artifact, a drawing, a software specification) must link back to one or more inputs. Outputs that cannot be traced to an input are suspect; inputs that have no corresponding output are a gap.
§8.3.5 Verification and Validation distinguishes the two: verification confirms that outputs meet inputs; validation confirms that the resulting product meets its intended use. AS9100 requires records of both. Your RTM needs a test column. The test must reference the requirement it covers. The coverage must be demonstrable, not inferred.
§6.1 Actions to Address Risks and Opportunities mandates that the organization determine risks and opportunities relevant to its quality management system. In engineering practice, this means every requirement with safety or mission-critical implications should have a corresponding risk record. The RTM is where that linkage lives.
§8.3.6 Design and Development Changes requires that changes be controlled and that the impact of changes on requirements, verifications, and previously validated items be evaluated. Without an RTM that links requirements to tests, an impact analysis is guesswork.
How the template covers AS9100
The RTMify Requirements Tracking Template maps directly to AS9100’s §8.3 structure:
| Tab | AS9100 clause covered |
|---|---|
| User Needs | §8.3.3: documents the source and intent of each design input |
| Requirements | §8.3.3 / §8.3.4: links each requirement to its parent need and design output |
| Tests | §8.3.5: maps each verification/validation activity to its requirement |
| Risks | §6.1: links risks to the requirements they affect |
The RTMify Status column surfaces gaps: if a requirement has no linked test, the row shows NO_TEST_LINKED. If a requirement ID is referenced in Tests but doesn’t exist in Requirements, it shows MISSING_ID. These are exactly the gaps an AS9100 auditor will flag.
What it doesn’t cover: AS9100 also requires a documented design and development plan (§8.3.2), customer communication records, and supplier controls. The template covers traceability. It is not a complete QMS.
Common AS9100 audit gaps
- Requirements with no source. Auditors ask “where did this come from?” If the answer is “we assumed it,” you have a §8.3.3 finding. The User Needs tab forces you to document the source.
- Tests that reference non-existent requirements. A test suite that grew independently of the requirements document creates phantom coverage. The
MISSING_IDstatus catches this. - V&V records that don’t distinguish verification from validation. “We tested it” is not sufficient. The test record must show which requirement was covered and whether the test was a verification (meets spec) or validation (meets intended use).
- Requirements changed without impact analysis. When a requirement changes, which tests are now invalid? Without an RTM, this is unknowable. §8.3.6 findings here are common.
- Risks not linked to requirements. A risk register that floats free of the requirements is not actionable. Auditors want to see which requirements carry risk and what mitigations are in place.
AS9100-specific guidance
ID prefix convention: Use a prefix that reflects the standard and project. Example: AS-UR-001 for user requirements, AS-SR-001 for system requirements, AS-TC-001 for test cases. Consistent prefixes make cross-reference errors visually obvious.
DAL/criticality annotation: Although AS9100 doesn’t use Design Assurance Level terminology (that’s DO-178C), it does require risk-based thinking. Add a criticality column (Safety-Critical / Mission-Critical / Non-Critical) and ensure every Safety-Critical requirement has at least one linked test and one linked risk entry.
Customer-specific requirements (CSRs): AS9100 is used throughout the aerospace supply chain. If your customer has imposed additional requirements (a Boeing D6-82479, Airbus SQCG, or NADCAP supplement), those are §8.3.3 inputs. Track them in the User Needs tab with the customer document reference in the Source column.
Configuration management: AS9100 §8.5.6 requires control of changes. Version your RTM file. The filename should include the project identifier and revision: RTMify_Requirements_Tracking_Template_ProjectAlpha_Rev3.xlsx. Never overwrite a released revision.