Purpose and Use Cases
The Whole RTM PowerSheet serves as the primary traceability analysis and gap-identification tool for:
- Traceability verification — validate bidirectional links across all V-model levels
- Gap analysis — identify orphaned requirements, undecomposed features, or untraceable design elements
- Impact analysis — understand cascading effects when requirements change
- Coverage reporting — generate traceability statistics for ISO 26262 Part 8 Clause 6 compliance
- Multi-level refinement tracking — visualize how customer needs decompose into executable design specifications
Use Whole RTM for system-wide traceability review, gap analysis, and compliance reporting. Use Component RTM for focused decomposition within a single subsystem or component hierarchy.
Configuration Structure
Data Source and Entity Query
| Property | Value | Notes |
|---|
| Source Entity | CustomerRequirement | Entry point for complete V-model chain |
| RTM Model | rtm (project domain model) | Resolves all link roles and relationships |
| Document Filter | None (all modules) | Queries across entire project scope |
| Initial Sort Order | objectId ascending | Ensures consistent row ordering |
The PowerSheet initializes by querying all CustomerRequirement work items from the Polarion RTM model, then expands through defined link roles to display nested decomposition and traceability chains.
Column Group Architecture
The Whole RTM PowerSheet organizes columns into six progressive color-coded sections, each representing a level in the V-model hierarchy:
Customer Requirements Column Group
| Property | Value | Description |
|---|
| Header Color | #2e7d32 (dark green) | Indicates requirements origin tier |
| Row Background | #c8e6c9 (light green) | Progressive disclosure highlight |
| Columns | objectId, title, rationale | Core customer need metadata |
| Formatting | Read-only with grey background | Prevents accidental modification |
| Collapse Target | title | Shows only customer requirement title when minimized |
| Visible | true | Always displayed in default view |
Notes: Customer requirements are authored by business analysts and product managers. This column group enforces data governance by rendering all fields read-only; traceability engineers view and link requirements but do not edit them.
System Requirements Column Group
| Property | Value | Description |
|---|
| Header Color | #00897b (teal) | Indicates system-level requirements tier |
| Row Background | #b2dfdb (light teal) | Distinguished from customer layer |
| Columns | objectId, description, classification | System-level specifications |
| Expansion Link | refinesCustomerRequirement | RTM traversal from customer to system |
| Row Multiplicity | 1:N | One customer req may have multiple system reqs |
| Formatting | Bold description, read-only ID | Emphasis on requirement intent |
| Collapse Target | description | Shows only system requirement text when minimized |
Notes: System requirements represent “what the system shall do.” Expansion shows all system requirements that refine each customer requirement in sub-rows. Link role refinesCustomerRequirement must be defined in the RTM domain model.
Design Requirements Column Group
| Property | Value | Description |
|---|
| Header Color | #1565c0 (blue) | Indicates design tier |
| Row Background | #bbdefb (light blue) | Distinguished from system layer |
| Columns | objectId, description, requirementType | Design-level specifications |
| Expansion Link | refinesSystemRequirement | RTM traversal from system to design |
| Row Multiplicity | 1:N | One system req may have multiple design reqs |
| Nesting Level | 2 (sub-expansion) | Nested under system requirements |
| Formatting | Bold description, read-only ID | Visual hierarchy |
| Collapse Target | description | Shows only design requirement text when minimized |
Notes: Design requirements represent “how the system shall be designed.” Two-level nesting (customer → system → design) demonstrates PowerSheet’s multi-hop expansion capability.
Functions Column Group
| Property | Value | Description |
|---|
| Header Color | #6a1b9a (purple) | Indicates functional decomposition tier |
| Row Background | #e1bee7 (light purple) | Distinguished from requirements tiers |
| Columns | objectId, title, description | Function identity and intent |
| Expansion Link | implementsDesignRequirement | RTM traversal from design to functions |
| Row Multiplicity | 1:N | One design req may be implemented by multiple functions |
| Nesting Level | 3 (nested expansion) | Nested under design requirements |
| Formatting | Bold title, read-only ID | Emphasis on function purpose |
Notes: Functions represent “what logical capability must be provided.” Functions bridge design requirements and technical characteristics, enabling safety classification allocation.
Characteristics Column Group
| Property | Value | Description |
|---|
| Header Color | #e65100 (orange) | Indicates product/process characteristic tier |
| Row Background | #ffe0b2 (light orange) | Distinguished from logical tiers |
| Columns | objectId, title, targetValue, tolerance | Measurable specifications |
| Expansion Link | characterizesFunction | RTM traversal from functions to characteristics |
| Row Multiplicity | 1:N | One function may be characterized by multiple traits |
| Nesting Level | 4 (nested expansion) | Nested under functions |
| Formatting | Title with units rendering, target/tolerance highlighted | Emphasis on measurable values |
Notes: Characteristics represent “what measurable properties must be achieved.” Characteristics link to FMEA failure modes, enabling SC/CC (Special Characteristic/Critical Component) classification.
Relationship Expansion Pattern
The Whole RTM PowerSheet implements four levels of RTM relationship expansion:
Each expansion creates denormalized rows for related work items:
| Expansion Level | Link Traversal | Cardinality | Visual Nesting |
|---|
| Level 1 | Customer → System | 1:N | Sub-rows under customer requirement |
| Level 2 | System → Design | 1:N | Sub-rows under system requirement |
| Level 3 | Design → Function | 1:N | Sub-rows under design requirement |
| Level 4 | Function → Characteristic | 1:N | Sub-rows under function |
Four-level expansion creates Cartesian product nesting: a single customer requirement with 2 system requirements, each with 2 design requirements, each with 3 functions, each with 2 characteristics results in 2×2×3×2 = 24 rows. Performance monitoring is recommended for large projects.
Read-Only Requirement Fields
Customer and system requirement columns use read-only formatters with grey background to enforce data governance:
formatter:
type: boldReadOnly
backgroundColor: grey100
fontWeight: 600
This prevents accidental modification during traceability review by rendering fields as visually distinct (grey, bold) and disabled in the UI.
Safety Classification Rendering (SC/CC Badge)
When characteristics are linked to failure modes, SC/CC classification appears as inline badges:
formatter:
type: scccBadge
scBackground: orange
ccBackground: red
textColor: white
SC (Safety Critical): Orange badge — characteristic directly impacts ISO 26262 safety
CC (Critical Component): Red badge — component containing characteristic is critical
Target Value and Tolerance Display
Characteristics columns show measurable specifications with unit rendering:
| Column | Format | Example |
|---|
| targetValue | Numeric with units | 120 kph |
| tolerance | ±notation | ±2.5% |
| upperBound | Engineering format | 1.2 V |
| lowerBound | Engineering format | 0.8 V |
Named Views
The Whole RTM PowerSheet provides multiple named views for different use cases:
Default View (Full Details)
| Property | Value | Notes |
|---|
| Visible Columns | All (6 column groups) | Complete V-model traceability |
| Sort Order | Customer ID ascending | Stable ordering |
| Grouping | None | Flat denormalized display |
| Use Case | Comprehensive traceability review, gap analysis | |
Summary View
| Property | Value | Notes |
|---|
| Visible Columns | ID, title (all tiers) | Minimal key identifiers |
| Collapse State | All groups collapsed | Maximizes readability |
| Row Density | High | Fits more items on screen |
| Use Case | Executive overview, quick scan for coverage | |
Verification View
| Property | Value | Notes |
|---|
| Visible Columns | Design Requirements, Functions, Characteristics only | Focuses on lower tiers |
| Hidden Columns | Customer and System Requirements | Hides upper tiers |
| Purpose | Verification planning without requirements clutter | |
Gap Analysis View
| Property | Value | Notes |
|---|
| Visible Columns | All 6 tiers with expansion status | Shows where links are missing |
| Highlight Rule | Red row if expansion returns 0 items | Visual flag for gaps |
| Color Filter | Rows with orphaned requirements | Enables quick navigation to gaps |
SC/CC Focus View
| Property | Value | Notes |
|---|
| Visible Columns | Design Requirements, Characteristics, SC/CC classification only | Focuses on safety aspects |
| Highlight Rule | Orange or red background for SC/CC items | Emphasizes special characteristics |
| Purpose | Safety classification review, AIAG-VDA FMEA linkage verification | |
Configuration Properties Reference
Top-Level Configuration
name: Whole RTM
description: End-to-end requirements traceability matrix (V-model hierarchy)
rtmModel: rtm
sourceEntityType: CustomerRequirement
documentScope: [] # empty = all documents
initialSort: ascending
initialSortField: objectId
maxRows: 5000
Expansion Configuration Syntax
Each expansion level uses dot-notation to traverse RTM relationships:
expand:
- customerReq:
fieldPath: refinesCustomerRequirement
entityType: SystemRequirement
- systemReq:
fieldPath: refinesSystemRequirement
entityType: DesignRequirement
- designReq:
fieldPath: implementsDesignRequirement
entityType: Function
- function:
fieldPath: characterizesFunction
entityType: Characteristic
Column Group Collapse Behavior
columnGroup:
name: "Customer Requirements"
color: "#2e7d32"
collapseTo: "title"
# Remaining columns auto-hidden when collapsed
visible: true
When a column group collapses, all columns except the collapseTo field become hidden, reducing horizontal scrolling while preserving relationship context.
Query Constraints and Filtering
Document Scope Constraint
The Whole RTM PowerSheet queries across all documents by default (empty document array). To scope to a specific document:
documentScope:
- path: "Requirements/System Requirements Specification"
type: module
This filters CustomerRequirement entities to only those defined within the specified SRS module.
Relationship Filtering via queryFactory
For large projects, optional queryFactory filters can constrain which related entities appear:
queryFactory:
systemRequirementFilter: "workItemType:SystemRequirement AND status:Active"
designRequirementFilter: "lifecycle.status != Deprecated"
Query syntax uses Polarion Lucene with field references. Common patterns: workItemType, status, lifecycle.status, severity, customField.
| Factor | Threshold | Impact |
|---|
| Customer Requirements | >100 | Load time increases linearly |
| Average Children per Level | >5 | Exponential row count growth (5^4 = 625 rows per customer req) |
| Total Rows | >10,000 | Browser performance degradation, sorting slowdown |
| Characteristic Expansion | >20 per function | Column width overflow, horizontal scroll unavoidable |
Optimization strategies:
- Use view filtering to hide lower expansion tiers (e.g., hide characteristics for overview)
- Apply document-scope constraints to query specific modules
- Enable server-side pagination (if available in Polarion version)
- Use Summary View for executive reporting (collapsed by default)
Integration with Other Sheets
The Whole RTM PowerSheet coordinates with component-specific RTM sheets:
| Sheet | Relationship | Use Pattern |
|---|
| Component RTM PowerSheet | Sibling — same hierarchy, component-scoped | Use Component RTM for detailed subsystem decomposition |
| System Verification Sheet | Parent-child — requirements to tests | Link test cases from Verification sheet to design requirements |
| Design Verification Sheet | Parent-child — design requirements to tests | Cross-reference design test coverage |
| Characteristics Sheet | Sibling — shows characteristics in detail | Jump to Characteristics sheet for target/tolerance editing |
Traceability Coverage Reporting
The Whole RTM PowerSheet enables calculation of traceability metrics per ISO 26262 Part 8:
| Metric | Calculation | Target |
|---|
| Downward Coverage | Design Reqs with ≥1 System Req parent / Total Design Reqs | 100% |
| Upward Coverage | System Reqs with ≥1 Customer Req parent / Total System Reqs | 100% |
| Function Allocation | Functions with ≥1 Design Req parent / Total Functions | 100% |
| Characteristic Linkage | Characteristics with ≥1 Function parent / Total Characteristics | 100% |
Row highlighting in Gap Analysis View flags items with zero parent or child links, enabling rapid gap identification.
Best Practices
- Start with Customer Requirements (top row)
- Verify each has ≥1 System Requirement child (expand Level 1)
- Verify each System Requirement has ≥1 Design Requirement child (expand Level 2)
- Verify each Design Requirement has ≥1 Function child (expand Level 3)
- Link characteristics to functions for SC/CC classification (expand Level 4)
- Cross-reference functions to FMEA failure modes for safety traceability
- Orphaned Design Requirements: Design requirements not linked to any system requirement (missing
refinesSystemRequirement link)
- Undecomposed System Requirements: System requirements with no child design requirements (may indicate incomplete specification)
- Functions without Characteristics: Functions not characterized by measurable properties (incomplete for verification planning)
- Unlinked Characteristics: Characteristics not traced to failure modes (breaks safety classification chain)
See also: Use Whole RTM Sheet for step-by-step workflow instructions.