The Requirements Traceability Report answers: “Is every requirement justified, decomposed, and verified?” It identifies gaps in the V-model chain and supports formal compliance reviews.
Report Overview
The Requirements Traceability Report validates four primary traceability chains in the automotive safety V-model:
This matrix-style visualization shows:
- Upstream traceability: Each system requirement traces to one or more customer requirements (justified)
- Decomposition traceability: System requirements decompose into design requirements (refined)
- Verification traceability: Requirements link to test cases (verifiable)
- Safety traceability: Safety-critical/cybersecurity-critical design requirements link through characteristics to failure modes (analyzed)
Key Properties
Report Configuration
| Property | Type | Default | Description |
|---|
| Report Title | String | Requirements Traceability Report | Display name in wiki page |
| Project Prefix | String | TA | Polarion project prefix for work item filtering in Lucene queries |
| Include SC/CC Chain | Boolean | true | Enable advanced three-hop traceability validation for safety-critical requirements (desReq → characteristic → failureMode) |
| Upstream Link Role | String | refines | Link relationship role from system requirements to customer requirements (backward direction: sysReq linkedWorkItems.back() refines customerReq) |
| Decomposition Link Role | String | refines | Link relationship role from design requirements to system requirements (forward direction: desReq linkedWorkItems refines sysReq) |
| Verification Link Role | String | verifies | Link relationship role from test cases to requirements (backward direction: req backlinkedWorkItems verifies testCase) |
Query Patterns and Gap Detection
| Traceability Chain | Forward Query | Gap Query | Metric |
|---|
| Customer Reqs → System Reqs | type:sysReq AND linkedWorkItems:refines=TA* | type:customerRequirement AND NOT backlinkedWorkItems:refines=TA* | % of customer reqs with downstream system requirements |
| System Reqs → Design Reqs | type:desReq AND linkedWorkItems:refines=TA* | type:sysReq AND NOT backlinkedWorkItems:refines=TA* | % of system reqs decomposed into design reqs |
| Design Reqs → Test Cases | type:testCase AND linkedWorkItems:verifies=TA* | type:desReq AND NOT backlinkedWorkItems:verifies=TA* | % of design reqs verified by test cases |
| SC/CC → Failure Modes | type:desReq AND classification.KEY:(sc cc) AND backlinkedWorkItems:refines=TA* AND [characteristic].backlinkedWorkItems:assesses=TA* | type:desReq AND classification.KEY:(sc cc) AND NOT backlinkedWorkItems:refines=TA* | % of safety-critical design reqs with failure mode analysis |
The SC/CC to Failure Mode chain requires manual Velocity iteration because nxLinkCoverage macro only supports single-hop coverage. Implementation uses nested #foreach loops:#foreach($req in $desReqs)
#set($chars = $req.fields().linkedWorkItems().back('refines'))
#set($hasFM = false)
#foreach($char in $chars)
#if($char.fields().linkedWorkItems().back('assesses').size() > 0)
#set($hasFM = true)
#end
#end
#if(!$hasFM) ## Gap detected
$req.fields().title()
#end
#end
Coverage Metrics Explained
Traceability Coverage Percentage
Coverage is calculated as: (items with at least one valid link) / (total items) × 100
- Example: System Requirements → Test Cases Coverage
- Found: 26 system requirements with back-linked test cases
- Total: 31 system requirements in project
- Coverage: 26/31 = 83.9%
| Coverage Range | Interpretation | Action |
|---|
| ≥90% | Excellent coverage — all critical items traced | Continue normal operations |
| 70-89% | Good coverage — minor gaps | Investigate gap list, add missing links or justify exceptions |
| 50-69% | Moderate coverage — significant gaps exist | Formal review required before design freeze |
| <50% | Poor coverage — critical compliance risk | Stop work, execute gap remediation plan |
Gap Identification
Gaps are work items without required links identified by the gap query. Examples:
Customer Requirement without System Requirement:
REQ-001: The AEB system shall activate within 500ms → no backlinked sysReq- Root cause: System requirements not yet decomposed from customer spec
- Remediation: Create corresponding sysReq with
sysReq.linkedWorkItems().refines(REQ-001)
System Requirement without Design Requirement:
SYS-015: Sensor fusion algorithm shall process camera and radar inputs → no backlinked desReq- Root cause: Design decomposition incomplete
- Remediation: Create desReq items, link with
desReq.linkedWorkItems().refines(SYS-015)
Design Requirement without Test Case:
DES-042: AEB ECU shall implement ISO 26262 Safe State logic → no backlinked testCase- Root cause: Verification planning incomplete
- Remediation: Create testCase work items, link with
testCase.linkedWorkItems().verifies(DES-042)
Safety-Critical Requirement without Failure Mode Analysis:
DES-101: SC requirement — Sensor calibration data shall be validated → characteristic linked, but characteristic has no backlinked failureMode- Root cause: FMEA not yet performed for this requirement
- Remediation: In Risksheet FMEA module, create failureMode items linked to characteristic with
failureMode.linkedWorkItems().assesses(characteristic)
Report Sections
1. Executive Summary Card
| Metric | Display | Formula | Color Logic |
|---|
| Customer Req Coverage | % | COUNT(customerReq with backlinked sysReq) / COUNT(customerReq all) | Green ≥80%, Yellow 60-79%, Red <60% |
| System Req Coverage | % | COUNT(sysReq with backlinked desReq) / COUNT(sysReq all) | Green ≥90%, Yellow 70-89%, Red <70% |
| Design Req Coverage | % | COUNT(desReq with backlinked testCase) / COUNT(desReq all) | Green ≥95%, Yellow 80-94%, Red <80% |
| Safety-Critical Chain | % | COUNT(SC/CC desReq with char→FM) / COUNT(SC/CC desReq) | Green ≥90%, Yellow 70-89%, Red <70% |
#import('nextedy_solutions.vm')
#nxInit()
#set($custReqs = $query.executeCurrentProject('type:customerRequirement'))
#set($custWithSys = $query.executeCurrentProject('type:customerRequirement AND backlinkedWorkItems:refines=TA*').size())
#set($custCoverage = ($custWithSys / $custReqs.size()) * 100)
#nxKpiCard("Customer Req Traceability", "$custCoverage%", $custCoverage)
2. Requirement Hierarchy Matrix
The matrix displays all requirements organized by level with color-coded coverage indicators:
┌─────────────────────────────────────────────────────────────────────────┐
│ Level │ Requirement │ Status │ Upstream │ Downstream │
├─────────────────────────────────────────────────────────────────────────┤
│ Customer │ REQ-001 │ ✓ Linked │ Baseline │ 2× SysReq │
│ Customer │ REQ-002 │ ✗ Unlinked │ Baseline │ ⚠ Gap │
│ System │ SYS-001 │ ✓ Linked │ ← REQ-001 │ 1× DesReq │
│ System │ SYS-002 │ ✓ Linked │ ← REQ-001 │ 0× DesReq ⚠│
│ Design │ DES-001 │ ✓ Linked │ ← SYS-001 │ 1× Test │
│ Design │ DES-002 │ ⚠ Partial │ ← SYS-002 │ ✗ No Test │
└─────────────────────────────────────────────────────────────────────────┘
Legend:
✓ = Complete bidirectional traceability
⚠ = Partial (missing upstream or downstream)
✗ = No links (critical gap)
3. Traceability Chain Validation
This section uses the nxLinkCoverage macro to compute coverage bars for each chain:
## Chain 1: Customer Req → System Req
#nxLinkCoverage('type:customerRequirement', 'refines', 'sysReq',
'Customer Requirements → System Requirements',
'type:customerRequirement AND NOT backlinkedWorkItems:refines=TA*')
## Chain 2: System Req → Design Req
#nxLinkCoverage('type:sysReq', 'refines', 'desReq',
'System Requirements → Design Requirements',
'type:sysReq AND NOT backlinkedWorkItems:refines=TA*')
## Chain 3: Design Req → Test Case
#nxLinkCoverage('type:desReq', 'verifies', 'testCase',
'Design Requirements → Verification Test Cases',
'type:desReq AND NOT backlinkedWorkItems:verifies=TA*')
- Coverage bar with percentage (green/yellow/red)
- Linked count: “26/31 items traced”
- Gap count (clickable query): “5 gaps”
- Gap list: Expandable table of unlinked work items with type, ID, and title
4. Safety-Critical Requirement Analysis
For requirements classified as Safety-Critical (SC) or Cybersecurity-Critical (CC), displays three-hop traceability:
| Design Req | Classification | Characteristic | Failure Mode | Status |
|---|
| DES-042 | SC (ASIL B) | Sensor Calibration Validation | 3 failure modes identified | ✓ Complete |
| DES-055 | CC (ASIL C) | CAN Message Authentication | 2 failure modes identified | ✓ Complete |
| DES-068 | SC (ASIL A) | Diagnostic Code Validation | No failure modes | ⚠ Gap |
#foreach($req in $query.executeCurrentProject('type:desReq AND classification.KEY:(sc cc)'))
#set($chars = $req.fields().linkedWorkItems().back('refines'))
#set($totalFM = 0)
#foreach($char in $chars)
#set($fms = $char.fields().linkedWorkItems().back('assesses'))
#set($totalFM = $totalFM + $fms.size())
#end
#if($totalFM == 0)
⚠ Gap: $req.fields().title()
#end
#end
Requirements are marked SC/CC via the custom field classification with enum values sc and cc. This field is set during design requirement creation via Design Requirements Specification module templates.
5. Verification Evidence Traceability
Shows the complete chain from requirement through test case to external evidence artifacts:
| Test Case | Test Type | Result | Evidence Link | Verification Date |
|---|
| VERIF-SYS-001 | System Integration Test | PASS | test_report_2026_02_15.pdf | 2026-02-15 |
| VERIF-DES-042 | Component Unit Test | PASS | sensor_unit_test_log.csv | 2026-02-10 |
| VERIF-DES-068 | Hardware-in-Loop | FAIL | hil_diagnostic_log.txt | 2026-02-12 |
Cross-References
Advanced Configuration
Custom Coverage Thresholds
Modify acceptance criteria per project risk profile in project-properties.xml:
<customProperty>
<name>ReqTraceabilityMinCustSysThreshold</name>
<type>Integer</type>
<value>85</value>
<description>Minimum % of customer requirements that must link to system requirements (default 90)</description>
</customProperty>
<customProperty>
<name>ReqTraceabilitySCCCThreshold</name>
<type>Integer</type>
<value>95</value>
<description>Minimum % of SC/CC requirements with complete failure mode chain (default 95)</description>
</customProperty>
Excluding Obsolete Requirements
To exclude obsolete or superseded requirements from coverage metrics, filter by status in gap queries:
Gap Query with Status Filter:
type:desReq AND NOT backlinkedWorkItems:verifies=TA* AND status:(Draft "In Progress" "In Review")
(excludes Rejected, Obsolete, Approved statuses)
Report Access and Refresh
The Requirements Traceability Report is generated as a wiki page in the Documentation space and auto-updates when:
- Any requirement work item is created or linked
- Test case work item status changes to “Passed” or “Failed”
- External evidence is attached to a test case
- Batch link operations complete via PowerSheet
For on-demand refresh, navigate to the report page and click Regenerate Report (requires traceability-manager role).
On projects with >500 requirements, report generation may take 30-60 seconds. Large projects should run report generation outside business hours or use filtered views (e.g., per system element, per ASIL level).
