Skip to main content

​
Dashboard Overview

The Requirements Space Dashboard implements ISO 26262 Part 4 (System Design) and Part 8 (Clause 6 — Bidirectional Traceability) by organizing all requirements documents and tracking traceability metrics from customer-level needs through system and design requirements to verification test cases. diagram

​
Statistics Bar

The Requirements Space Statistics Bar displays live counts of all work item types and documents in the Requirements space, updated in real-time as changes are made to the project.
MetricQueryValuePurpose
Customer Requirementstype:customerRequirement25Count of customer-level requirements from system specification
System Requirementstype:sysReq31Count of system-level requirements refined from customer needs
Design Requirementstype:desReq15Count of design-level requirements refined from system requirements
Total DocumentsmoduleFolder:Requirements6Total LiveDoc documents stored in Requirements space
The statistics bar uses Lucene queries executed against the Polarion work item database, ensuring counts reflect the current project state. Updates appear within seconds of work item creation or deletion.

​
Requirements Document Inventory

The Document Inventory Tree provides hierarchical navigation through all requirements documents organized by system element structure. This enables Requirements Engineers to quickly locate specifications for specific system components.

​
Document Inventory Table

System ElementDocumentTypeStatusWork ItemsTool
AEB SystemSystem Requirements SpecificationSystem SpecificationPublished31PowerSheet
ECU Processing SubsystemECU Subsystem RequirementsSubsystem SpecificationPublished12LiveDoc
Sensor Housing SubsystemSensor Subsystem RequirementsSubsystem SpecificationPublished9LiveDoc
Vehicle Interface SubsystemInterface RequirementsSubsystem SpecificationPublished8LiveDoc
Camera ModuleCamera Module Design RequirementsDesign SpecificationPublished5LiveDoc
Radar ModuleRadar Module Design RequirementsDesign SpecificationPublished4LiveDoc
Navigation Features:
  • Expandable tree view organized by system element hierarchy (System → Subsystem → Component)
  • Document type icon indicators (📋 Specification, 📊 PowerSheet, 📋 LiveDoc)
  • Status badges (Published, Draft, Under Review)
  • Work item count per document for rapid assessment of specification scope
  • Direct hyperlinks to open each document in Polarion

​
Traceability Coverage Metrics

The Requirements Space Dashboard tracks five critical traceability chains that verify compliance with ISO 26262 Part 8 (Clause 6) bidirectional traceability requirements and the V-model process coverage.

​
Customer Requirements → System Requirements (Refinement)

MetricValueStatus
Covered14✅
Total25—
Coverage %56%⚠️
Gap Count11—
Gap Querytype:customerRequirement AND NOT backlinkedWorkItems:refines=TA*—
Significance: This metric tracks how many customer requirements have been refined into system requirements. A 56% coverage indicates 11 customer requirements lack system-level refinements, representing potential specification gaps that must be resolved before system design can proceed. Remediation: Gap query identifies unrefined customer requirements. Requirements Engineers should examine each gap and either (1) refine into system requirements, (2) mark as informational/non-binding, or (3) escalate as scope decisions to program management.

​
System Requirements → Design Requirements (Decomposition)

MetricValueStatus
Covered10✅
Total31—
Coverage %32%⚠️
Gap Count21—
Gap Querytype:sysReq AND NOT backlinkedWorkItems:refines=TA*—
Significance: This metric tracks decomposition of system requirements into design-level requirements. At 32%, only one-third of system requirements have been allocated to design elements, indicating the Design Phase is early in execution or that design requirements are managed externally. Remediation: Design engineers should systematically allocate system requirements to design requirements using the PowerSheet “Component RTM” view, which provides side-by-side editing of sysReq ↔ desReq refinement links.

​
System Requirements → Verification Test Cases (Verification)

MetricValueStatus
Covered26✅
Total31—
Coverage %83%✅
Gap Count5—
Gap Querytype:sysReq AND NOT backlinkedWorkItems:verifies=TA*—
Significance: This metric validates that system requirements are verified by test cases, a critical ISO 26262 Part 4 requirement. At 83%, most system requirements have corresponding verification test cases. The 5 unverified requirements represent test case gaps that must be closed before system verification is complete. Remediation: V&V Engineers should review unverified requirements in the “System Verification Sheet” PowerSheet and either create corresponding test cases or document why verification is not required.

​
Design Requirements → Test Cases (Verification)

MetricValueStatus
Covered15✅
Total15—
Coverage %100%✅
Gap Count0—
Significance: All 15 design requirements have been verified by test cases, indicating 100% verification coverage at the design level. This demonstrates strong ISO 26262 Part 5 compliance for Hardware Design and Part 6 compliance for Software Development.

​
Design Requirements → Failure Modes (Safety Analysis)

MetricValueStatus
Covered11✅
Total14—
Coverage %78%✅
Gap Count3—
Classification Filtertype:desReq AND classification.KEY:(sc cc)—
Significance: Safety-critical (SC) and cybersecurity-critical (CC) design requirements should be traced through characteristics to failure modes in DFMEA documents. At 78%, most SC/CC requirements have failure mode coverage, indicating strong connection between design specifications and design FMEA analysis. The Requirements Space Dashboard provides rapid navigation to related reports, sheets, and analysis documents.

​
Reports

ReportPurposeLocation
Requirements Traceability ReportComprehensive V-model traceability matrix (customer → system → design → test)Risks space
ISO 26262 HARA ReportSafety goals and hazard analysis cross-referenced to requirementsRisks space
HAZID Risk MatrixHazard identification matrix linked to customer requirementsRisks space
FMEA Coverage ReportIdentifies safety-classified requirements without FMEA analysisRisks space

​
PowerSheets

PowerSheetContentUse Case
System Requirements SpecificationComplete RTM: Customer → System → Design → TestRequirements traceability overview
Whole RTM SheetAll work items with all link typesEnterprise-wide traceability analysis
Component RTMSystem Reqs ↔ Design Reqs for specific componentDesign decomposition and allocation
DashboardFocusUser Role
Home DashboardProject-wide overview and statisticsProgram Managers, Project Leads
Design Space DashboardDesign requirements and system structureDesign Engineers
Risks Space DashboardFMEA and risk control analysisSafety Engineers
Testing Space DashboardTest coverage and verification metricsV&V Engineers
Safety Engineer DashboardHARA, safety goals, risk controlsSafety Engineers

​
Configuration Properties

The Requirements Space Dashboard is implemented as a Velocity template page in Polarion, configured with the following properties and macros.

​
Dashboard Template Properties

PropertyTypeValueDescription
pageTypeStringspaceDashboardIdentifies page as space-scoped dashboard (not project-level)
spaceIdStringRequirementsPolarion space folder ID for document filtering
spaceTitleStringRequirementsDisplay title for space branding
spaceSubtitleStringSystem and Subsystem Requirements — Traceability and Coverage DashboardDescriptive subtitle shown in banner
primaryColorString#1565c0Primary brand color (blue) for space identity
secondaryColorString#0d47a1Secondary brand color (darker blue) for accents
showDocumentInventoryBooleantrueDisplay hierarchical document tree
showCoverageMetricsBooleantrueDisplay traceability coverage bars
showQuickLinksBooleantrueDisplay reports and PowerSheets shortcuts

​
Nextedy Macro Library Integration

The dashboard imports the Nextedy Solutions macro library to access standardized dashboard components: 
#import('nextedy_solutions.vm')
#nxInit()
#nxCommonStyles()

## Display space banner with branding
#nxSpaceBanner('Requirements', 'Requirements', 'System and Subsystem Requirements — Traceability and Coverage Dashboard', '#1565c0', '#0d47a1')

## Display statistics bar
#nxStatsBar()
  #nxStatItem('Customer Requirements', $statistics.customerReqCount, 'icon-req', '#1565c0')
  #nxStatItem('System Requirements', $statistics.sysReqCount, 'icon-req', '#1565c0')
  #nxStatItem('Design Requirements', $statistics.desReqCount, 'icon-req', '#1565c0')
  #nxStatItem('Documents', $statistics.docCount, 'icon-doc', '#1565c0')
#end

## Display document inventory tree
#nxDocInventoryTree('Requirements', 'System Element / Document', false)

## Display coverage metrics
#nxLinkCoverage('customerRequirement', 'sysReq', 'refines', 'backward')
#nxLinkCoverage('sysReq', 'desReq', 'refines', 'backward')
#nxLinkCoverage('sysReq', 'testCase', 'verifies', 'backward')
#nxLinkCoverage('desReq', 'testCase', 'verifies', 'backward')
Dashboard administrators can customize colors, metrics, and section visibility by editing the dashboard page properties in Polarion. No Velocity coding knowledge required for common customizations.

​
Traceability Chain Example

The following example illustrates how traceability flows through the Requirements Space: Customer Requirement (CR-001):
“System shall provide autonomous emergency braking when obstacle detected within 100m at speeds > 30 km/h”
Refined to System Requirement (SR-012):
“AEB System shall detect obstacles at range ≥ 100m and activate brake within 500ms”
Decomposed to Design Requirements:
  • DR-045: “Radar sensor shall achieve 100m detection range at ±5° azimuth”
  • DR-046: “ECU shall complete obstacle classification within 400ms”
  • DR-047: “Brake actuator command shall execute within 100ms of ECU signal”
Verified by Test Cases:
  • TC-128: “Radar detection range validation (100m @ 0°/±5° azimuth)”
  • TC-129: “ECU processing latency measurement (< 400ms)”
  • TC-130: “Brake actuator response time (< 100ms)”
Analyzed in FMEA:
  • FM-156: “Radar signal loss → No obstacle detection → No braking” (ASIL D)
  • FM-157: “ECU processing timeout → Delayed braking” (ASIL C)
  • FM-158: “Brake actuator stiction → Incomplete braking force” (ASIL B)
Each link in this chain is tracked and auditable within the Requirements Space Dashboard.

​
Best Practices

  • Never leave requirements with 0 downstream links — All customer requirements must refine to system requirements; system requirements must either refine to design requirements OR be verified by test cases
  • Document traceability gaps — If a requirement cannot be traced, document the exception in the requirement’s description and link to a Risk Record explaining the gap
  • Maintain bidirectional links — Use PowerSheets to edit links; avoid one-way links that can become stale
  • Use the “Gap Query” links in coverage bars to drill down to unlinked requirements
  • Batch-link requirements in PowerSheets using multi-select and “Create Link” action
  • Validate links during document review workflow to catch traceability gaps early