About This Guide

This guide walks you through filling in the RTMify template for AS9100 Rev D, the aerospace quality management system standard. AS9100 is an extension of ISO 9001 with additional requirements for design controls, configuration management, and product safety specific to the aerospace, defense, and space industries.

Clause 8.3 (Design and Development) governs how you capture, verify, and manage design requirements. This template covers the traceability artifacts that clause requires: design inputs, design outputs, verification and validation, and configuration management.

For aerospace programs, run RTMify Trace with the aerospace profile. That enables the extra decomposition and configuration-item checks used in regulated aerospace workflows while preserving the generic requirement, test, and risk checks described below.

By the end of this guide, you'll have a complete requirements traceability matrix (RTM) that demonstrates compliance with §8.3.3–8.3.6 and links design decisions to risk mitigation per §6.1.

What AS9100 Requires for Traceability

Design Inputs (§8.3.3)

AS9100 §8.3.3 requires you to establish and document design input requirements. These include:

  • Customer requirements — contractual specifications, delivery schedules, support needs
  • Regulatory requirements — FAA certification (14 CFR Part 25, Part 23), EASA (EASA CS-23, CS-25), military standards (MIL-HDBK-516 for systems; AS5501 for cybersecurity)
  • Lessons learned — field failures, customer feedback, previous design audits, anomaly reports (AR/MRs)
  • Risk considerations — safety-critical functions, failure modes, environmental extremes (DO-160G for avionics)

Your User Needs table captures these inputs. RTMify tags each with a source (Customer, Regulatory, Lessons Learned, Risk) so you can demonstrate traceability during audit.

Design Outputs & Verification (§8.3.4 & §8.3.5)

§8.3.4 requires design outputs to be documented, reviewed for adequacy, and traceable to inputs. §8.3.5 mandates verification (did we build it right?) and validation (did we build the right thing?). RTMify links each Requirement (design output) to:

  • One or more User Needs (design inputs) via the traces field
  • Verification activities (tests, analyses, demonstrations, inspections) via the testGroup field
  • Risk mitigations (§6.1) via the linkedReq field in the Risk table

This chain of traceability proves that every design decision is grounded in customer/regulatory need and verified before release.

Configuration Management (§8.3.6)

AS9100 §8.3.6 adds configuration management: design changes must assess impact on existing artifacts. When you update a Requirement, RTMify's impact analysis shows which Tests, Risks, and dependent Requirements are affected. Document the change rationale and approvals in your change control board (CCB) process — RTMify supports this by providing the traceability backbone.

For deeper standard coverage, see our AS9100 Standard Overview.

Step-by-Step Walkthrough

1

Define User Needs

Capture design inputs per §8.3.3. Sources include customer specifications, regulatory requirements (FAA/EASA/military), lessons learned from previous programs, and internal operational needs. Use ID format UN-nnn.

User Needs Example
ID Description Source Priority
UN-001 Aircraft shall maintain cabin pressure at cruise altitude Regulatory High
UN-002 Maintenance crew shall be able to replace the unit in under 30 minutes Customer Medium
UN-003 System shall operate in temperatures from -55°C to +85°C Regulation (DO-160G) High

Tips: Be specific — include standards references (e.g., "per DO-160G Section 4"). Distinguish between MUST requirements and SHOULD requirements. Link each User Need to at least one Requirement; unlinked needs indicate incomplete design coverage.

2

Write Requirements

Create design outputs per §8.3.4. Each requirement traces to a User Need and is verifiable against it. Use REQ-nnn format with priority, test group linkage, and approval status.

Requirements Example
ID Description Traces Priority Test Group Status
REQ-001 The pressurization controller SHALL maintain cabin altitude below 8,000 ft during cruise UN-001 High TG-001 Approved
REQ-002 The unit SHALL be removable using standard aerospace tooling with no more than 6 fasteners UN-002 Medium TG-002 Approved
REQ-003 The system SHALL operate within specification across the temperature range -55°C to +85°C per DO-160G Section 4 UN-003 High TG-003 Approved

Tips: Use SHALL (mandatory) or SHOULD (desired). Include measurable success criteria (e.g., "below 8,000 ft", "under 30 minutes"). Every requirement must trace to at least one User Need. Empty testGroup fields will trigger NO_TEST_LINKED during RTMify Trace validation.

3

Define Tests

Document verification (§8.3.5) and validation activities. Link each test to a requirement via test group IDs. Methods include Test (hardware/software testing), Analysis (engineering calculations, thermal/stress analysis), Demonstration (bench trials, crew trials), and Inspection (visual, dimensional, FAI).

Tests & Verification Example
Test Group Test ID Type Method Description
TG-001 T-001 Verification Test Altitude chamber test per ATP-001
TG-001 T-002 Verification Analysis Thermal analysis of pressurization valve response
TG-002 T-003 Verification Demonstration Maintenance crew timed replacement trial
TG-003 T-004 Verification Test DO-160G Section 4 temperature cycling

Tips: Link each testGroup to a REQ. Include test procedure references (e.g., ATP-001, ATP = Acceptance Test Procedure). One requirement may require multiple verification methods; that's expected for safety-critical items. See Tests & Verification for detailed guidance.

4

Document Risks

Per §6.1 (Actions to Address Risks and Opportunities), identify risks, assess severity (1–5) and occurrence (1–5), document mitigations, and track residual risk. Link risks to requirements to show how mitigation is built into design.

Risks & Mitigations Example
Risk ID Description Severity Occurrence Mitigation Linked Req Residual Severity Residual Occurrence
RSK-101 Pressurization valve fails closed at altitude 5 2 Redundant valve with independent actuation REQ-001 5 1
RSK-102 Fastener corrosion in salt-fog environment 3 3 Specify cadmium-plated hardware per NAS1149 REQ-002 3 1

Tips: Use a risk matrix (Severity × Occurrence) to prioritize. High-risk items (Severity 4–5 + Occurrence 3–5) should have corresponding Requirement entries. Document the mitigation approach in the requirement itself. Track residual risk post-mitigation; audit expects residual risk to be acceptable (e.g., ≤4). See Risk Management for FMEA/FTA guidance.

5

Check Status and Generate RTM

Run RTMify Trace to validate the matrix. Every row should show OK status. The trace checks for:

Use rtmify-trace --profile aerospace your-workbook.xlsx when validating an AS9100 workbook. The aerospace profile keeps the standard coverage checks and adds the workbook decomposition/configuration-item checks expected in aerospace audit packages.

  • MISSING_USER_NEED — Requirement with no User Need link (§8.3.3–8.3.4 traceability broken)
  • NO_TEST_LINKED — Requirement with no Test Group (§8.3.5 verification missing)
  • ORPHAN_TEST — Test Group with no Requirement (scope creep or old test; clean up)
  • INCOMPLETE_RISK — Risk with no mitigation or residual risk still unacceptable

Fix all issues before your external audit. A clean RTM demonstrates design discipline and reduces audit findings.

Pro tip: Review the Status Codes reference for full error definitions and remediation steps.

What This Template Covers vs. Doesn't Cover

Covered

  • Design Inputs (§8.3.3) — customer specs, regulatory requirements, lessons learned, risk considerations
  • Design Outputs (§8.3.4) — traceable to inputs, verifiable, with measurable criteria
  • Verification & Validation (§8.3.5) — test/analysis/demonstration/inspection planning and execution
  • Risk Management (§6.1) — identification, assessment, mitigation, residual risk tracking
  • Configuration Management (§8.3.6) — impact analysis when requirements change

NOT Covered (separate QMS documentation)

  • Configuration Management Procedures (§8.3.6) — Use your change control board (CCB) process, Design Authority approval matrix, and baseline management procedures. RTMify provides the traceability backbone; your QMS procedures govern the workflow.
  • Formal Design Reviews — AS9100 requires Preliminary Design Review (PDR), Critical Design Review (CDR), and design release approval. Document review minutes, action items, and sign-offs in your design review SOP; link to RTMify design outputs as evidence.
  • First Article Inspection (FAI) — Per AS9102, FAI demonstrates production readiness. RTMify shows design intent; FAI report shows first-production compliance. Coordinate FAI results with your design baseline.
  • Supplier Quality Requirements — Captured in your supplier management (§8.4) and PPAP procedures. If a design output depends on supplier performance, create a User Need and trace it; supplier qualification is a separate control.
  • Production Process Controls (§8.5) — Manufacturing, assembly, test, and shipping procedures are QMS work instructions. If a production constraint drives a design requirement, capture it as a User Need.

Frequently Asked Questions

Do I need separate rows for customer vs. regulatory requirements?

No, but we recommend tracking the source in your User Needs table. Many requirements will satisfy multiple sources — for example, a design output traced to a regulatory requirement may also satisfy a customer need. The User Needs table (§8.3.3) is where you capture sources; the Requirements table focuses on the design outputs themselves.

How does this relate to my APQP/PPAP process?

RTMify covers design traceability per §8.3.3–8.3.5 (Design and Development). APQP/PPAP governance (advanced product quality planning / production part approval process) is a downstream activity. Use RTMify to document your design phase; PPAP artifacts (such as First Article Inspection reports per AS9102) demonstrate production readiness. Both are required for certification.

What about ITAR/export control requirements?

If your product is subject to ITAR (International Traffic in Arms Regulations) or EAR (Export Administration Regulations), capture export control as a User Need source and link it to requirements. Document your ITAR compliance procedures in your QMS separately; RTMify can help you trace that ITAR requirements are reflected in your design outputs.

Do I need to include manufacturing requirements?

This template covers design traceability per §8.3 (Design and Development). Production process controls, supplier management, and manufacturing requirements are governed by other clauses (§7.5, §8.4) and should be documented in your process control procedures. However, if manufacturing constraints drive design requirements (e.g., "unit must fit standard 19-inch rack"), capture that as a User Need and trace it through the template.