What is traceability and why is it critical for ISO 26262 compliance?
Traceability establishes bidirectional relationships between work items across the V-model lifecycle, ensuring every requirement is verified, every design decision is justified, and every safety goal is implemented and tested. ISO 26262 Part 8 Clause 6 mandates complete traceability from hazards through requirements, design, implementation, and verification to demonstrate safety integrity.
See Traceability Model for the complete model and RTM Domain Model for relationship definitions.
How do I establish traceability links between work items?
Use the Linked Work Items section in any work item’s form layout to create relationships. Select the appropriate link role (refines, verifies, validates, mitigates, assesses) from the dropdown, then search for target work items. For bulk linking, use the Whole RTM Sheet or Component RTM Sheet PowerSheets which provide matrix views for rapid link creation.
See Establish Traceability Links for step-by-step instructions.
What’s the difference between “refines”, “verifies”, and “validates” link roles?
- refines: Decomposes a higher-level requirement into more detailed requirements (Customer Req → System Req → Design Req)
- verifies: Links a test case to a requirement/design artifact to confirm correct implementation (Design Req ← Verification Test Case)
- validates: Links a validation test to a customer requirement to confirm user need satisfaction (Customer Req ← Validation Test Case)
These relationships form the V-model structure. See Verification vs Validation for conceptual differences.
How do I check traceability coverage for my project?
Navigate to any space dashboard (Requirements, Design, Risks, Testing) to view live traceability coverage bars showing percentage and gap counts. For comprehensive analysis, use the Requirements Traceability Report which displays full V-model chains with highlighted gaps. You can also run Lucene gap queries like type:sysReq AND NOT backlinkedWorkItems:verifies=TA* to find unverified requirements.
See Check Traceability Coverage for all methods.
Why are my SC/CC design requirements showing low FMEA coverage?
SC/CC (Special Characteristic / Critical Characteristic) design requirements require multi-hop traceability: Design Req → Characteristic → Failure Mode. Coverage appears low if (1) characteristics aren’t linked back to design requirements via “refines”, (2) characteristics aren’t assessed by failure modes via “assesses” link, or (3) the failure mode work items don’t exist yet. Check the Design space dashboard “SC/CC Design Requirements → Failure Modes” coverage metric and use the gap query to identify which items need linking.
See Link Characteristics to Failure Modes and Fix Traceability Gaps.
Yes. PowerSheet configurations provide matrix and tree views optimized for bulk traceability management:
- Whole RTM Sheet: Full requirements traceability matrix showing Customer → System → Design → Test chains
- Component RTM Sheet: Per-component traceability scoped to specific system elements
- Design Verification Sheet: Design requirements with linked verification test cases
- System Verification Sheet: System requirements with linked verification test cases
- User Need Validation Sheet: Customer requirements with linked validation test cases
These sheets display work items in rows with linked items in expandable sub-rows or dedicated columns, enabling rapid link creation/deletion without opening individual forms.
See Use Whole RTM Sheet and PowerSheet Configurations.
How does traceability flow through the ISO 26262 safety lifecycle?
The complete safety traceability chain follows this pattern:
Every arrow represents a mandatory link role that must be populated for 100% compliance. The Safety Readiness Scorecard computes coverage percentages for each chain segment per ISO 26262 part.
See ISO 26262 Functional Safety for standard requirements.
What are the most common traceability gaps and how do I fix them?
| Gap Type | Root Cause | Fix |
|---|
| Customer Reqs → System Reqs low | System requirements created without linking to source customer needs | Open System Requirements Specification PowerSheet, add “refines” links |
| System Reqs → Design Reqs low | Design decomposition incomplete or skipped | Use Component RTM Sheet to map system → design by element |
| Requirements → Test Cases missing | Tests created independently without V-model linking | Use Verification PowerSheet to bulk-link tests |
| SC/CC → Failure Modes gap | Characteristics not created or not assessed in FMEA | Create Characteristics, link in DFMEA “assesses” column |
| Failure Modes → Risk Controls orphaned | FMEA analysis incomplete, mitigations not defined | Complete FMEA Link to Risk Controls step |
Does traceability impact ASIL inheritance and safety goal allocation?
Yes. ASIL values flow downstream through traceability links:
- Hazard ASIL (computed from S×E×C matrix) → derives → Safety Goal ASIL (inherited)
- Safety Goal ASIL → refines → Functional Safety Requirement ASIL (inherited or decomposed)
- FSR ASIL → refines → System Requirement ASIL (ASIL decomposition may split D → B+B)
The link role structure enforces that no lower-level requirement can have a higher ASIL than its source. Risksheet formulas use MAX(parent.ASIL) logic to automatically inherit the highest severity from linked upstream items. Breaking traceability links can orphan requirements and cause ASIL allocation errors.
See ASIL Classification System and Safety Goal Derivation.
How do I generate a traceability report for an audit or submission?
Navigate to Home → Reports section → Requirements Traceability Report which provides:
- Full V-model chain visualization (Customer → System → Design → Test)
- Coverage percentages with gap counts per chain segment
- Highlighted orphaned items (work items with no incoming or outgoing links)
- Compliance mapping to ISO 26262 Part 8 Clause 6 requirements
For FMEA-specific traceability, use the FMEA Coverage Report showing Design Reqs → Characteristics → Failure Modes → Risk Controls chains. Export both reports to PDF via Export Reports to PDF for submission packages.
Traceability Coverage Matrix
Visual reference showing expected link roles across work item types:
| From ↓ / To → | Customer Req | System Req | Design Req | Test Case | Characteristic | Failure Mode | Risk Control |
|---|
| Customer Req | — | refines → | — | ← validates | — | — | — |
| System Req | ← refines | — | refines → | ← verifies | — | — | — |
| Design Req | — | ← refines | — | ← verifies | ← refines | — | — |
| Characteristic | — | — | refines → | — | — | assesses → | — |
| Failure Mode | — | — | — | — | ← assesses | — | mitigates → |
| Risk Control | — | — | — | ← verifies | — | ← mitigates | — |
For projects with 100+ requirements, use PowerSheet RTM configurations instead of individual work item forms. Matrix views enable 10x faster link creation through inline editing and keyboard navigation. See Whole RTM Sheet for setup. Deleting a work item does not cascade-delete traceability links. Orphaned links appear as broken references in PowerSheet and cause Lucene query errors. Always check upstream/downstream dependencies before deletion using the work item’s “Linked Work Items” tab.
