Skip to main content

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

PropertyValueNotes
Source EntityCustomerRequirementEntry point for complete V-model chain
RTM Modelrtm (project domain model)Resolves all link roles and relationships
Document FilterNone (all modules)Queries across entire project scope
Initial Sort OrderobjectId ascendingEnsures 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: diagram

Customer Requirements Column Group

PropertyValueDescription
Header Color#2e7d32 (dark green)Indicates requirements origin tier
Row Background#c8e6c9 (light green)Progressive disclosure highlight
ColumnsobjectId, title, rationaleCore customer need metadata
FormattingRead-only with grey backgroundPrevents accidental modification
Collapse TargettitleShows only customer requirement title when minimized
VisibletrueAlways 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

PropertyValueDescription
Header Color#00897b (teal)Indicates system-level requirements tier
Row Background#b2dfdb (light teal)Distinguished from customer layer
ColumnsobjectId, description, classificationSystem-level specifications
Expansion LinkrefinesCustomerRequirementRTM traversal from customer to system
Row Multiplicity1:NOne customer req may have multiple system reqs
FormattingBold description, read-only IDEmphasis on requirement intent
Collapse TargetdescriptionShows 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

PropertyValueDescription
Header Color#1565c0 (blue)Indicates design tier
Row Background#bbdefb (light blue)Distinguished from system layer
ColumnsobjectId, description, requirementTypeDesign-level specifications
Expansion LinkrefinesSystemRequirementRTM traversal from system to design
Row Multiplicity1:NOne system req may have multiple design reqs
Nesting Level2 (sub-expansion)Nested under system requirements
FormattingBold description, read-only IDVisual hierarchy
Collapse TargetdescriptionShows 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

PropertyValueDescription
Header Color#6a1b9a (purple)Indicates functional decomposition tier
Row Background#e1bee7 (light purple)Distinguished from requirements tiers
ColumnsobjectId, title, descriptionFunction identity and intent
Expansion LinkimplementsDesignRequirementRTM traversal from design to functions
Row Multiplicity1:NOne design req may be implemented by multiple functions
Nesting Level3 (nested expansion)Nested under design requirements
FormattingBold title, read-only IDEmphasis 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

PropertyValueDescription
Header Color#e65100 (orange)Indicates product/process characteristic tier
Row Background#ffe0b2 (light orange)Distinguished from logical tiers
ColumnsobjectId, title, targetValue, toleranceMeasurable specifications
Expansion LinkcharacterizesFunctionRTM traversal from functions to characteristics
Row Multiplicity1:NOne function may be characterized by multiple traits
Nesting Level4 (nested expansion)Nested under functions
FormattingTitle with units rendering, target/tolerance highlightedEmphasis 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: diagram Each expansion creates denormalized rows for related work items:
Expansion LevelLink TraversalCardinalityVisual Nesting
Level 1Customer → System1:NSub-rows under customer requirement
Level 2System → Design1:NSub-rows under system requirement
Level 3Design → Function1:NSub-rows under design requirement
Level 4Function → Characteristic1:NSub-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.

Data Rendering and Formatting

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:
ColumnFormatExample
targetValueNumeric with units120 kph
tolerance±notation±2.5%
upperBoundEngineering format1.2 V
lowerBoundEngineering format0.8 V

Named Views

The Whole RTM PowerSheet provides multiple named views for different use cases:

Default View (Full Details)

PropertyValueNotes
Visible ColumnsAll (6 column groups)Complete V-model traceability
Sort OrderCustomer ID ascendingStable ordering
GroupingNoneFlat denormalized display
Use CaseComprehensive traceability review, gap analysis

Summary View

PropertyValueNotes
Visible ColumnsID, title (all tiers)Minimal key identifiers
Collapse StateAll groups collapsedMaximizes readability
Row DensityHighFits more items on screen
Use CaseExecutive overview, quick scan for coverage

Verification View

PropertyValueNotes
Visible ColumnsDesign Requirements, Functions, Characteristics onlyFocuses on lower tiers
Hidden ColumnsCustomer and System RequirementsHides upper tiers
PurposeVerification planning without requirements clutter

Gap Analysis View

PropertyValueNotes
Visible ColumnsAll 6 tiers with expansion statusShows where links are missing
Highlight RuleRed row if expansion returns 0 itemsVisual flag for gaps
Color FilterRows with orphaned requirementsEnables quick navigation to gaps

SC/CC Focus View

PropertyValueNotes
Visible ColumnsDesign Requirements, Characteristics, SC/CC classification onlyFocuses on safety aspects
Highlight RuleOrange or red background for SC/CC itemsEmphasizes special characteristics
PurposeSafety 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.

Performance Considerations

FactorThresholdImpact
Customer Requirements>100Load time increases linearly
Average Children per Level>5Exponential row count growth (5^4 = 625 rows per customer req)
Total Rows>10,000Browser performance degradation, sorting slowdown
Characteristic Expansion>20 per functionColumn 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:
SheetRelationshipUse Pattern
Component RTM PowerSheetSibling — same hierarchy, component-scopedUse Component RTM for detailed subsystem decomposition
System Verification SheetParent-child — requirements to testsLink test cases from Verification sheet to design requirements
Design Verification SheetParent-child — design requirements to testsCross-reference design test coverage
Characteristics SheetSibling — shows characteristics in detailJump to Characteristics sheet for target/tolerance editing

Traceability Coverage Reporting

The Whole RTM PowerSheet enables calculation of traceability metrics per ISO 26262 Part 8:
MetricCalculationTarget
Downward CoverageDesign Reqs with ≥1 System Req parent / Total Design Reqs100%
Upward CoverageSystem Reqs with ≥1 Customer Req parent / Total System Reqs100%
Function AllocationFunctions with ≥1 Design Req parent / Total Functions100%
Characteristic LinkageCharacteristics with ≥1 Function parent / Total Characteristics100%
Row highlighting in Gap Analysis View flags items with zero parent or child links, enabling rapid gap identification.

Best Practices

  1. Start with Customer Requirements (top row)
  2. Verify each has ≥1 System Requirement child (expand Level 1)
  3. Verify each System Requirement has ≥1 Design Requirement child (expand Level 2)
  4. Verify each Design Requirement has ≥1 Function child (expand Level 3)
  5. Link characteristics to functions for SC/CC classification (expand Level 4)
  6. 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.