What ISO 26262 requires for traceability
ISO 26262:2018 is the functional safety standard for automotive electrical and electronic systems. It is structured around the V-model and the concept of Automotive Safety Integrity Level (ASIL), which rates the safety risk of a function from A (lowest) to D (highest). Traceability in ISO 26262 is not optional; it is a prerequisite for the functional safety assessment (FSA) and the safety case.
Part 3 §5, Hazard Analysis and Risk Assessment (HARA): The HARA is the starting point. It identifies hazardous events, assigns severity, exposure, and controllability ratings, derives the ASIL, and produces the safety goals. Every safety goal must trace forward to functional safety requirements. Without this trace, you cannot demonstrate that the safety goals are addressed.
Part 3 §7, Functional Safety Requirements (FSR): FSRs are derived from safety goals. They specify what the system must do (or not do) to mitigate the identified hazards. FSRs must inherit or refine the ASIL from their parent safety goals. An FSR with a lower ASIL than its safety goal requires justification.
Part 4 §6, Technical Safety Requirements (TSR): TSRs are derived from FSRs during system design. They allocate safety requirements to hardware and software elements. For software, TSRs become the input to the software requirements process (Part 6).
Part 6 §7, Software Safety Requirements: Software requirements are derived from TSRs allocated to software. Traceability from FSR → TSR → software requirement must be maintained. The ASIL flows down through this chain.
Part 6 §9, Software Unit and Integration Testing: Tests must be derived from requirements. Coverage criteria depend on ASIL. ASIL C and D require Modified Condition/Decision Coverage (MC/DC). Every software safety requirement must be tested; the trace from requirement to test must be documented.
How the template covers ISO 26262
| Tab | ISO 26262 coverage |
|---|---|
| User Needs | HARA safety goals, FSRs from Part 3 |
| Requirements | TSRs and software safety requirements with ASIL annotation |
| Tests | Software unit and integration tests linked to requirements |
| Risks | HARA hazardous events linked to requirements and mitigations |
The RTMify Status column is critical for ASIL D development, where complete requirements coverage by tests is mandatory. Any NO_TEST_LINKED on an ASIL D requirement is a blocking issue for the safety case.
What it doesn’t cover: ISO 26262 also requires a Safety Plan, DIA (Development Interface Agreement) if you’re a Tier 1/Tier 2 supplier, Functional Safety Assessment, and the full V-model work products from hardware and system levels. The template covers the software-level requirements traceability.
Common ISO 26262 audit / FSA gaps
- ASIL not inherited correctly. ASIL decomposition (splitting a requirement into two independent parts, each at a lower ASIL) must be explicitly documented with justification. Unexplained ASIL reduction is a finding every time.
- Safety goals without HARA linkage. A safety goal that doesn’t trace to a specific hazardous event in the HARA is unsupported. The HARA is the evidence that the safety goal is necessary and sufficient.
- Software requirements derived from TSRs without explicit trace. The chain FSR → TSR → SWR must be documented. A software requirements document that doesn’t reference TSRs cannot be assessed for ASIL compliance.
- Tests with insufficient coverage for ASIL. ASIL C and D require MC/DC. Many teams apply statement or branch coverage and miss the requirement. The RTM must show the coverage type used for each test, not just pass/fail.
- Dependent failure analysis not linked to requirements. For ASIL D, Part 9 (Automotive Safety Integrity Level (ASIL)-Oriented and Safety-Oriented Analyses) requires analysis of dependent failures. These analyses generate requirements (independence requirements, diagnostic coverage requirements) that must appear in your RTM.
ISO 26262 specific guidance
ASIL column: Add an ASIL column (QM / A / B / C / D) to the Requirements tab. This is the single most important metadata field for ISO 26262 compliance. Filter by ASIL to verify testing depth, review independence, and safety measure adequacy.
HARA mapping in User Needs: The User Needs tab should contain one row per safety goal, with columns for the associated hazardous event ID, severity (S0–S3), exposure (E0–E4), controllability (C0–C3), and resulting ASIL. This is your HARA summary. The Requirements tab then references User Need IDs (safety goal IDs) in the parent field.
ASIL decomposition: When you decompose ASIL B into two ASIL A(d) requirements, document it in the Requirements tab with a DecomposedFrom column referencing the parent ASIL B requirement and a note explaining the independence claim.
Supplier / SEooC context: If you’re developing a Safety Element out of Context (SEooC), your RTM must clearly distinguish between assumptions (ASSs) and requirements. Assumptions become requirements on your customers; requirements are what your element must satisfy. Add a Type: ASS / REQ column to the User Needs tab.
Relationship to ASPICE: ISO 26262 is often developed alongside Automotive SPICE. The requirements engineering process (SYS.2, SWE.1) and testing processes (SWE.4, SWE.5, SWE.6) align well with ISO 26262’s V-model. The same RTM serves both; add ASPICE process references to requirement and test rows.