Traceability Chain
The four tabs in the RTMify template form a directed graph. User Needs flow down to Requirements, which link to Test Groups containing individual Tests. Risks link sideways to the Requirements that mitigate them. Every regulated standard requires this chain to be complete and bidirectional.
The graph
Four tabs, four node types, three link types. Every arrow is created by a cell reference in the template.
User Need (UN-001) │ │ Requirements tab, Column C ("User Need ID") ▼ Requirement (REQ-001) │ ◄──── Risk (RSK-101) │ Requirements tab, Risks tab, │ Column E ("Test Group IDs") Column F ("Linked REQ") ▼ Test Group (TG-001) │ │ Tests tab, Column A ("Test Group ID") ▼ Tests (T-001, T-002…)
How the links work
There are no hidden formulas. Every link is a plain-text ID in a cell. RTMify reads these IDs and builds the graph.
| Link | Where it lives | Direction |
|---|---|---|
| Requirement → User Need | Requirements tab, Column C | Up — to parent need |
| Requirement → Test Group | Requirements tab, Column E | Down — to verification |
| Test → Test Group | Tests tab, Column A | Down — group membership |
| Risk → Requirement | Risks tab, Column F | Sideways — to mitigation |
If an ID in any of these cells doesn't match a row in the target tab, RTMify flags it as UNRESOLVED. If the cell is blank where a link is expected, RTMify flags the appropriate warning (MISSING_USER_NEED or NO_TEST_LINKED). See Status Codes for the full reference.
Bidirectional traceability
Auditors check the chain in both directions. Forward traceability proves every need is implemented and verified. Backward traceability proves every test traces to a real need — no gold-plating, no orphan tests.
Forward traceability
User Need → Requirement → Test
Proves: every stakeholder need is decomposed into a verifiable requirement and covered by at least one test. Nothing falls through the cracks.
Backward traceability
Test → Requirement → User Need
Proves: every test exists for a reason. Every requirement traces to a real stakeholder need. No unnecessary work, no scope creep embedded in the test suite.
Most standards require both directions explicitly. DO-178C calls it out by name. ASPICE requires bidirectional traceability at Capability Level 2 and above. ISO 13485 auditors verify that every design output (§7.3.4) maps back to a design input (§7.3.3) and forward to verification activities (§7.3.5).
What "suspect" means
When an upstream artifact changes, everything downstream becomes suspect. A suspect item isn't necessarily wrong — it needs re-evaluation. Someone has to look at it and confirm it's still valid, or update it.
Example: You change UN-003 from "Battery shall last 8 hours" to "Battery shall last 12 hours." Now REQ-003 (which implements UN-003), TG-003 (which tests REQ-003), and RSK-103 (which assesses battery-related risk) are all suspect. The requirement text might need updating. The test pass criteria definitely need updating. The risk assessment might change.
RTMify Live handles suspect-propagation automatically — when you edit a cell in Google Sheets, Live re-evaluates the chain and flags everything downstream. In the static template, you need to trace the links manually. This is why the template includes cross-reference IDs in every tab: so you can follow the chain by searching for an ID.
ISO 13485 §7.3.9 specifically requires that design changes assess the effect on existing artifacts. AS9100 §8.3.6 requires impact assessment before changes. RTMify's suspect-propagation satisfies these requirements automatically.
Impact analysis
Before changing any artifact, trace the chain to see what's affected. This is impact analysis — and it's required by every standard before approving a design change.
❯ What breaks if I change UN-002?
UN-002 is referenced by REQ-004, REQ-005, and REQ-012.
REQ-004 links to TG-002 (3 tests) and RSK-101.
REQ-005 links to TG-004 (2 tests).
REQ-012 links to TG-007 (1 test) and RSK-205.
⚠ Total downstream impact: 3 requirements, 3 test groups, 6 tests, 2 risks.
With RTMify Live and its MCP server, you can ask this question conversationally from Claude, Cursor, or any MCP-compatible client. With the static template, search for the ID across tabs manually — Column C in Requirements, Column F in Risks — and follow each chain downstream.
What each standard requires
| Standard | Required chain | Bidirectional? | Key clauses |
|---|---|---|---|
| AS9100 | Inputs → Outputs → V&V | Yes (implied by §8.3.4) | §8.3.3, §8.3.4, §8.3.5 |
| ISO 13485 | Inputs → Outputs → V&V + Risk (14971) | Yes (§7.3.3/4 cross-ref) | §7.3.3–§7.3.6, §7.3.9 |
| DO-178C | SYS → HLR → LLR → Source → Test → Results | Yes (explicit requirement) | §5.5, §6.3, §6.4, Table A |
| IEC 62304 | Needs → SW Req → Architecture → Test | Yes (safety class B/C) | §5.2, §5.3, §5.5, §5.7 |
| ISO 26262 | HARA → Safety Goals → Safety Req → Design → Test | Yes (V-model) | §8, §10, Part 6 §9–§11 |
| ASPICE | SYS.1 → SYS.2 → SWE.1 → SWE.2/3 → SWE.4–6 | Yes (CL2+ requirement) | SYS.1–2, SWE.1–6, SYS.4 |
The common thread: every standard requires that you can start from a stakeholder need and trace all the way to the test that verifies it — and back. The RTMify template's four-tab structure satisfies this for all six standards. The ID cross-references in each tab are the links that auditors follow.
Frequently asked questions
What happens if the traceability chain is broken?
A broken chain means an auditor can't follow the thread from a user need to the test that verifies it — or from a test back to the need that justifies it. RTMify flags breaks with MISSING_USER_NEED, NO_TEST_LINKED, or UNRESOLVED status codes. Every regulated standard treats incomplete traceability as a finding. See Status Codes for how to fix each one.
Do I need traceability for every single requirement?
Yes. Every requirement should trace up to at least one User Need (Column C) and down to at least one Test Group (Column E). Requirements with no upstream traceability are "orphans" — they have no justification. Requirements with no downstream traceability are unverified. Both are audit findings.
What's the minimum traceability for a first audit?
Every requirement traces to a user need (Column C filled). Every requirement has a test group (Column E filled). Every risk has a linked requirement (Column F filled). All referenced IDs resolve — zero UNRESOLVED status codes. This gives you forward and backward traceability across the full chain. It won't be perfect, but it'll pass.
How is traceability different from coverage?
Traceability answers "can I follow the thread from need to test?" Coverage answers "how much of the requirement does the test actually exercise?" You can have 100% traceability (every requirement links to a test) with poor coverage (the tests don't adequately exercise the requirements). The RTMify template tracks traceability. Coverage analysis requires reviewing what each test actually verifies — structural coverage tools (for code) or test adequacy reviews (for system tests).
Can I add intermediate levels (e.g., subsystem requirements)?
Yes. Use ID prefixes to encode levels — for example SYS-001 for system requirements, SUB-001 for subsystem, SWE-001 for software. Chain them through the User Need ID column: a software requirement's "parent" is the subsystem requirement above it. DO-178C programs routinely use SYS/HLR/LLR prefixes this way. The template handles any depth of decomposition — it's just more rows in the Requirements tab with the right cross-references.