Requirements traceability in ISO 26262
ISO 26262 asks for safety requirements specified through a hierarchy, from safety goals down to hardware and software safety requirements, each traceable to the level above and to its verification, each with a unique identifier, a status and an ASIL, and verified to a plan that sets its acceptance criteria in advance. The requirements traceability matrix is where an assessor at a confirmation review expects to see that hierarchy and its verification in one place.
- standard
- ISO 26262: road vehicles functional safety
- edition held
- ISO 26262:2018, as the export names it
- clauses cited here
- 11 of the 137 held; shown when you tick ISO 26262
- every clause we hold
- ISO 26262, clause by clause
The exact wording of ISO 26262 is not held in full. Each line below is our statement of the clause, drawn from the parts we hold and the published objectives, and each says so.
Where each finding cites it
- 1Requirement with no parent: Part 8, 6.4.1 and Part 8, 6.4.3
- 2No verification method or no linked verification: Part 8, 6.4.3, Part 8, 9.4.1, Part 8, 9.4.2, Part 5, 10 (hardware requirements), Part 6, 10.4 (software requirements and high-level requirements) and Part 6, 9.4 (software unit or detailed designs and low-level requirements)
- 3Verification failed, blocked or not run: Part 8, 9.4.3, Part 5, 10 (hardware requirements), Part 6, 10.4 (software requirements and high-level requirements) and Part 6, 9.4 (software unit or detailed designs and low-level requirements)
- 4Changed after its last passing verification: Part 8, 6.4.3 and Part 8, 8.4.5
- 5Test that traces to no requirement: Part 8, 9.4.2
- 7Parent outside this export, or an ID used twice: Part 8, 6.4.2 and Part 8, 6.4.3
- 8Wording that may not be verifiable: Part 8, 6.4.2
- 10Safety-rated requirement with no hazard or risk link: Part 3, 7.4.2 and Part 8, 6.4.1
The columns that show it in a requirements traceability matrix
Parent, Level, Derived, Verification Method, Verified By, Justification, the results: Result and Date, Last Changed, the result dates, Revision and the results: Requirement Revision, the results: Requirements, the results: Type, ID, Requirement Text, Hazard or Risk and Safety rating. The requirements traceability matrix template carries every one.
What it asks, clause by clause
11 clausesSafety requirements are specified through the hierarchy from safety goals to functional, technical, hardware and software safety requirements, with each requirement derived from and traceable to the level above, allocated to an element, and specified in natural language or in an informal, semi-formal or formal notation per the standard's table by ASIL. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Safety requirements hierarchy with derivation and allocation
where it usually breaks Requirements written at one level with no traceability to the safety goals
Safety requirements are managed under configuration and change management with traceability to their source and to their verification, and are verified for correctness, completeness and consistency against the level above. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements management tool records with traceability and verification status
where it usually breaks Requirements held in documents with no traceability
Verification is planned for each phase and sub-phase: the work products to be verified, the objectives, the methods and their ASIL-dependent selection, the pass and fail criteria, the environment and tools, the actions on anomalies and the regression strategy. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Verification plan per phase
where it usually breaks Verification methods chosen ad hoc
The verification specification selects and specifies the methods, test cases with inputs, conditions and expected results, the equipment and environment, and the criteria, derived from the requirements and the design. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Verification specification with test cases and expected results
where it usually breaks Tests run without specified expected results
The hardware is integrated and verified against the hardware safety requirements using the methods of the part's tables for deriving test cases and for test methods by ASIL (part 11 Tables 27 and 28 interpret Tables 10 and 11 for semiconductors), including safety mechanism verification, environmental and stress tests and fault injection where applicable. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Hardware integration and verification plan and results by ASIL-selected methods
where it usually breaks Hardware verified functionally with the safety mechanisms never exercised
The software elements are integrated per the architectural design and the integration verified against it using the methods the standard recommends by ASIL (requirements-based test, interface test, fault injection, resource usage evaluation, back-to-back test), with structural coverage at the function and call level and the verification of freedom from interference and timing. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Software integration verification results with function and call coverage
where it usually breaks Integration verified with unit tests re-run
Software units are verified against the unit design and the software safety requirements using the methods of Table 7 (walk-through, pair programming, inspection, semi-formal and formal verification, control flow analysis, data flow analysis, static code analysis, static analyses based on abstract interpretation, requirements-based test, interface test, fault injection test, resource usage evaluation, back-to-back comparison test between model and code), with test cases derived per Table 8 (analysis of requirements, equivalence classes, boundary values, error guessing) and structural coverage measured per Table 9 (statement, branch, MC/DC by ASIL). Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Unit verification specification with methods by ASIL; Static analysis results against the coding guidelines; Structural coverage measurements with the target per ASIL
where it usually breaks Coverage measured at statement level for an ASIL D unit; Static analysis run without MISRA or an equivalent rule set
Verification is executed per the specification, the results evaluated against the expected results and criteria, deviations and anomalies analysed, and the verification report produced. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Verification reports with evaluation of every deviation
where it usually breaks Failed tests closed without analysis
Accepted changes are implemented, the affected work products updated and verified, the confirmation measures repeated as needed and the change documented with its effect on the safety case. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Implemented change records with updated work products and verification
where it usually breaks Change implemented and the safety case left unchanged
Each safety requirement carries a unique identifier, a status and an ASIL, and the requirements are unambiguous, comprehensible, atomic, internally consistent, feasible, verifiable, necessary, implementation-free and, as a set, hierarchical, complete, externally consistent, non-redundant and maintainable. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements attributes (identifier, status, ASIL) and characteristic checks
where it usually breaks Requirements with no ASIL attribute; Compound requirements that cannot be verified individually
Functional safety requirements are obtained from the safety goals together with the preliminary architectural assumptions, stating for each the operating modes, the fault tolerant time interval, the safe states, the emergency operation interval and the functional redundancies where relevant, and assigned to parts of the system architecture, to external measures or to driver actions, with the ASIL inherited from the safety goal or decomposed per part 9. Sub-clause title from the held contents page; the clause's objectives quoted by a certification body; requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Functional safety requirements with ASIL, safe state and FTTI; Allocation of functional safety requirements to architectural elements
where it usually breaks Functional safety requirements left unallocated or allocated to elements with no stated ASIL
Named, not quoted
- IEC 61508 (functional safety of electrical, electronic and programmable electronic systems): the generic functional safety standard ISO 26262 was adapted from. Named, not quoted: we do not hold its text.