RTMify DO-178C Quick Start Guide
Complete walkthrough of filling in the RTMify template for DO-178C, the airborne software certification standard.
About This Guide
This guide walks you through filling in the RTMify template for DO-178C (RTCA/DO-178C, Software Considerations in Airborne Systems and Equipment Certification). DO-178C is the regulatory standard for airborne software used in civil aviation, military, and rotorcraft. It mandates bidirectional traceability from system requirements through high-level requirements (HLR), low-level requirements (LLR), source code, and tests.
This template covers the requirements-to-test traceability portion (§5.5 Software Requirements Process and §6.3–6.4 Verification), the core of every DO-178C software development plan (SDP). You will not find source code or structural coverage metrics here; those are addressed in separate tools and reports (Software Accomplishment Summary, SAS).
When you validate a DO-178C workbook in RTMify Trace, use the aerospace profile. That enables aerospace-specific chain checks for HLR, LLR, decomposition, and related verification evidence instead of stopping at the generic requirement-to-test matrix.
By the end of this guide, you'll have a complete requirements traceability matrix (RTM) that demonstrates bidirectional traceability per §5.5.e and links design decisions to verification methods and risk mitigation. This RTM is evidence for your certification authority (FAA, EASA, or national equivalent).
What DO-178C Requires for Traceability
Software Requirements (§5.5)
DO-178C §5.5 requires a structured Software Requirements Process that produces:
- High-Level Requirements (HLR) — derived from system requirements, describe what the software shall do at a functional/architectural level, independent of implementation
- Low-Level Requirements (LLR) — derived from HLR, describe implementation details sufficient for testing and code review, at or near source-code level
- Bidirectional Traceability (§5.5.e) — every LLR traces upward to an HLR; every HLR traces upward to a system requirement; every system requirement traces downward to at least one HLR or LLR; every test traces to a requirement
RTMify captures this hierarchy through the "Traces" column: SYS-001 traces to User Needs, HLR-001 traces to SYS-001, LLR-001 traces to HLR-001, and tests trace to test groups linked to requirements.
Design Assurance Level (DAL, §2.0 & Table A)
Each requirement is assigned a Design Assurance Level (DAL) based on failure mode effects analysis (FMEA) and safety assessment:
- DAL A — Catastrophic failure condition (loss of aircraft or fatalities). Maximum rigor: §6.3 formal reviews, §6.4 full statement/branch testing, MC/DC coverage ≥100%, independent verification required.
- DAL B — Hazardous failure condition. High rigor: reviews, testing, MC/DC ≥ 100%, independent verification.
- DAL C — Major failure condition. Moderate rigor: reviews, testing, branch coverage, independent verification not always required.
- DAL D — Minor failure condition. Basic rigor: testing, code inspection, branch coverage.
- DAL E — No safety effect. Minimal rigor: statement testing or inspection.
Table A (§2.0) specifies which verification objectives apply to each DAL. RTMify does not enforce these; document your DAL assignments in the Notes column and justify them in your Software Accomplishment Summary (SAS).
Reviews and Analyses (§6.3)
§6.3 requires software requirements review and architecture review by an independent party (for DAL A/B). Capture these as verification methods (Inspection type) in your Tests table. Example: "T-005 | Inspection | LLR-001 code review — filter update rate verification".
Testing (§6.4)
§6.4 mandates testing at the HLR and LLR levels. For DAL A/B, testing must achieve Modified Condition/Decision Coverage (MC/DC); for DAL C, branch coverage; for DAL D/E, statement or branch. RTMify links tests to requirements via Test Group; your test procedures document coverage metrics separately.
Step-by-Step Walkthrough
1 Define User Needs (System Requirements)
Capture system-level design inputs from the Plan for Software Aspects of Certification (PSAC) and Safety Assessment. These are often not truly "user" needs but rather system-level requirements that flow down to software. Sources include:
- Operational requirements (crew interface, flight management, navigation)
- Safety assessment findings (failure conditions, mitigation strategies)
- Regulatory requirements (14 CFR Part 23/25, EASA CS-23/CS-25, DO-160G environmental)
Use ID format UN-nnn (or tag as SYS-level if you prefer explicit "system" labeling).
| ID | Description | Source | Priority |
|---|---|---|---|
| UN-001 | The flight management system shall compute and display the aircraft position | System PSAC | High |
| UN-002 | The system shall alert the crew within 1 second of any navigation sensor failure | Safety Assessment | High |
| UN-003 | The pilot shall be able to enter a flight plan via the CDU | Operational | Medium |
Tips: Be specific and measurable. "The system shall alert the crew within 1 second" is better than "shall alert promptly". Link each User Need to at least one SYS or HLR requirement; unlinked needs indicate incomplete design coverage and will fail RTMify Trace.
2 Write Requirements (SYS → HLR → LLR Hierarchy)
Create the three-level requirement hierarchy per §5.5. Record Design Assurance Level (DAL A–E) in the Notes column.
- SYS (System) — Top-level requirements derived from User Needs. Trace to UN-nnn.
- HLR (High-Level Requirements) — Functional/architectural requirements derived from SYS. Trace to SYS-nnn. Independent of implementation.
- LLR (Low-Level Requirements) — Implementation-level requirements derived from HLR. Trace to HLR-nnn. Directly testable or reviewable at code level.
| ID | Description | Traces | Priority | Test Group | Status | Notes |
|---|---|---|---|---|---|---|
| SYS-001 | The FMS SHALL compute aircraft position using GPS and IRS data | UN-001 | High | TG-001 | Approved | DAL A |
| HLR-001 | The navigation module SHALL fuse GPS and IRS position data using a Kalman filter | SYS-001 | High | TG-002 | Approved | DAL A |
| HLR-002 | The alerting module SHALL generate a crew alert within 500ms of sensor failure detection | UN-002 | High | TG-003 | Approved | DAL A |
| LLR-001 | The Kalman filter SHALL update at 10 Hz with measurement noise covariance R ≤ 0.01 | HLR-001 | High | TG-004 | Approved | DAL A |
Tips: Use SHALL (mandatory). Every HLR must have at least one LLR; every LLR must trace to an HLR (no orphans). Every requirement must have a Test Group link for verification traceability (§6.4). Record DAL in Notes; this ties to your verification plan (§6.3 Table A). See Requirements for detailed guidance on traceability depth.
3 Define Tests (§6.3 Reviews & §6.4 Testing)
Document verification activities per §6.3 (reviews, analyses) and §6.4 (testing). Link each test to a requirement via Test Group. Methods include:
- Test — Functional/integration testing, Monte Carlo simulations, hardware-in-loop (HIL), bench testing
- Analysis — Engineering analysis (thermal, stress, Kalman filter eigenvalue analysis, static code analysis)
- Inspection — Code review, formal inspection, dimensional check, FAI (First Article Inspection)
- Demonstration — Crew trials, operational scenario walk-throughs, bench demonstrations
| Test Group | Test ID | Type | Method | Description |
|---|---|---|---|---|
| TG-001 | T-001 | Verification | Test | FMS position accuracy bench test per ATP-NAV-001 |
| TG-002 | T-002 | Verification | Test | Kalman filter convergence test — simulated GPS/IRS input |
| TG-002 | T-003 | Verification | Analysis | Kalman filter stability analysis — eigenvalue analysis |
| TG-003 | T-004 | Verification | Test | Alert latency test — sensor failure injection |
| TG-004 | T-005 | Verification | Inspection | LLR-001 code review — filter update rate verification |
Tips: Link every Test Group to a Requirement. One requirement may have multiple tests (especially DAL A): for example, HLR-001 Kalman filter is verified by both T-002 (convergence test) and T-003 (eigenvalue analysis). Include test procedure references and coverage metrics in description. For DAL A, document MC/DC coverage; for DAL D, statement coverage. See Tests & Verification for coverage details.
4 Document Risks (Failure Mode Effects, §5.2)
Per §5.2 (Software Safety Assessment) and §5.3 (Software Failure Conditions and Verification), identify failure modes, assess severity (catastrophic to no effect) and likelihood, document mitigations, and track residual risk. Link risks to requirements that implement mitigation.
| Risk ID | Description | Severity | Occurrence | Mitigation | Linked Req | Residual Severity | Residual Occurrence |
|---|---|---|---|---|---|---|---|
| RSK-101 | GPS signal loss over ocean — position degrades to IRS-only | 4 | 3 | Dual-redundant IRS with cross-check, reversion logic | SYS-001 | 4 | 1 |
| RSK-102 | Kalman filter divergence due to sensor bias | 5 | 2 | Covariance monitoring with automatic filter reset | HLR-001 | 5 | 1 |
Tips: Use a severity/occurrence matrix to justify DAL assignments. High-severity failure modes (catastrophic/hazardous) drive DAL A/B requirements and rigorous testing. Mitigation is typically built into design: for example, dual-redundant IRS with cross-check is captured in SYS-001 and verified by tests TG-001. Track residual risk post-mitigation; audit expects mitigation to reduce risk to acceptable levels. See Risk Management for FMEA guidance.
5 Check Status and Generate RTM (Bidirectional Traceability §5.5.e)
Run RTMify Trace to validate the complete matrix. Every row should show OK status. The trace checks bidirectional traceability per §5.5.e:
Use rtmify-trace --profile aerospace your-workbook.xlsx so Trace evaluates the aerospace requirement chain, not just the generic gaps. This is the mode that surfaces missing HLR→LLR or decomposition continuity before certification review.
MISSING_USER_NEED— HLR/LLR with no parent requirement link (traceability upward broken)NO_TEST_LINKED— Requirement with no Test Group (§6.4 verification missing)ORPHAN_TEST— Test Group with no Requirement (scope creep or obsolete test)INCOMPLETE_RISK— Risk with no mitigation or residual risk still unacceptableORPHAN_USER_NEED— User Need with no SYS/HLR link (design input not addressed)
Fix all issues before formal design completion. A clean RTM demonstrates compliance with §5.5 bidirectional traceability and is a key artifact in the Software Accomplishment Summary (SAS) submitted to the certification authority.
Pro tip: Generate a traceability report (Requirements → Tests matrix) and include it in your SAS. This is often requested by FAA/EASA auditors. See Status Codes for full error definitions and remediation.
What This Template Covers vs. Doesn't Cover
Covered
- Software Requirements (§5.5) — SYS/HLR/LLR hierarchy with bidirectional traceability from system requirements through requirements and tests
- Design Assurance Level (DAL) — A through E assignment per failure effects assessment (§5.2–5.3)
- Reviews and Analyses (§6.3) — Software requirements review, architecture review, design review, code inspection, verification analysis (Kalman filter stability, eigenvalue, etc.)
- Testing (§6.4) — HLR-level and LLR-level testing, coverage metrics (MC/DC, branch, statement), test traceability
- Risk Management (§5.2–5.3) — Failure mode identification, severity/occurrence assessment, mitigation design, residual risk tracking
NOT Covered (separate DO-178C documentation)
- Source Code Traceability (§7.0) — RTMify traces requirements to tests. Source code comments linking LLRs to code lines are managed in your code repository and static analysis tools (e.g., Coverity, Polyspace). Your SAS must include a code traceability matrix; RTMify provides the requirements backbone.
- Structural Coverage Analysis (§6.4.4.2, MC/DC) — For DAL A/B, you must achieve ≥100% Modified Condition/Decision Coverage. RTMify does not measure or enforce coverage; use instrumented test harnesses (e.g., VectorCAST, Tessy, Bullseye) to collect and report coverage metrics. Link coverage results to test descriptions.
- Plan for Software Aspects of Certification (PSAC, §2.0) — RTMify supports the design phase; PSAC is a contractual/planning document describing the entire V&V strategy. Reference PSAC in RTMify's "Source" fields where applicable.
- Software Configuration Management (§8.0) — Use your configuration management tool (Git, SVN, CM tools) to version requirements, code, and test artifacts. RTMify helps track change impact; your CM procedures govern baseline, version control, and release.
- Software Accomplishment Summary (SAS, §2.0) — The SAS is the final compliance artifact submitted to FAA/EASA. It summarizes how your design, verification, and configuration management satisfy each objective in DO-178C Table A. RTMify generates the RTM portion of the SAS; you author the narrative and executive summary separately.
- Problem Reports and Corrective Action (§10.0) — Defect tracking, root cause analysis, and corrective action are managed in your QMS defect system. Link problem report IDs to requirements if they drive derived requirements.