Overview
Component RTM is a two-tier PowerSheet configuration that displays:
- Left section: Subsystem requirements with links to parent system requirements
- Right section: Design requirements decomposed from each subsystem requirement
This structure supports the V-Model decomposition workflow, showing how high-level subsystem requirements flow down to implementable design requirements while maintaining bidirectional traceability to system-level requirements.
Subsystem Requirements Column Group
The left section organizes all subsystem requirement metadata under a dark teal header.
| Property | Type | Default | Description |
|---|
| Subsystem Requirement ID | column | objectId | Read-only identifier (e.g., SUBRS-123) managed by Polarion; serves as stable reference for traceability links |
| Subsystem Requirement Description | column | description | Editable subsystem-level requirement text; primary field for requirement authoring; configured with focus capability and 250px width for optimal readability |
| System Requirements Upward Link | expansion | systemRequirements | Multi-item expansion showing parent system requirements linked via upstreamRequirements link role; green header styling indicates traceability validation direction |
| collapseTo | behavior | description | When column group minimized, subsystem requirement description remains visible for quick scanning without horizontal scrolling |
| backgroundColor | theme | teal | Color-coded column group background (teal) to distinguish subsystem requirements from design requirements (blue) in the same view |
Key Properties
Read-Only Enforcement:
All subsystem requirement fields configured as read-only to enforce single source of truth. Subsystem requirements are authored in the Subsystem Requirements Specification document; this sheet enforces view-only access to prevent inconsistent edits during design refinement.
readOnly: true
formatter: boldReadOnly
backgroundColor: grey100
fontWeight: 600
expand:
- link: systemRequirements
display:
- objectId
- title
Design Requirements Column Group
The right section displays design requirements decomposed from each subsystem requirement, organized under a dark blue header.
| Property | Type | Default | Description |
|---|
| Design Requirement ID | column | objectId | Read-only identifier (e.g., DRS-456) for design requirements; first column in design group for quick reference |
| Design Requirement Description | column | description | Editable design requirement detailed specification text; configured with hasFocus: true to make it the keyboard navigation anchor within design requirements group; serves as collapse target field |
| Design Requirement Type | column | subType | Enumeration field showing requirement subtype (functional, interface, performance, safety, non-functional); enables filtering and reporting by requirement category |
| Design Requirement Document | column | document.titleOrName | Read-only display of parent Design Requirements Specification document location (e.g., ‘Design Requirements Specification - Braking’); shows document origin for each requirement when working across multiple DRS documents |
| collapseTo | behavior | description | When design requirements group minimized, description column remains visible to preserve context while reducing horizontal scrolling |
| backgroundColor | theme | blue | Color-coded column group background (blue) to visually distinguish design requirements from parent subsystem requirements (teal) |
Key Properties
Document Location Tracking:
The document column uses titleOrName formatter to display the parent DRS document, enabling traceability across multi-document projects. Large automotive projects often split design requirements across multiple specifications per subsystem/component; this column provides clear document context for each requirement.
display: document.titleOrName
readOnly: true
formatter: titleFormatter
| Type | Description |
|---|
| Functional | Core system behavior requirements |
| Interface | Hardware/software interface specifications |
| Performance | Timing, throughput, resource constraints |
| Safety | Safety-critical design specifications (ISO 26262 Part 5) |
| Non-Functional | Quality attributes (reliability, maintainability, testability) |
RTM Model Configuration
Source Query:
source:
rtmModel: true
entityType: SubsystemRequirement
orderBy: title
expand:
- link: designRequirements
display:
- objectId
- description
- subType
- document
expand:
- link: systemRequirements
display:
- objectId
- title
- link: designRequirements
expand:
- link: systemRequirements
Workflow Views
The Component RTM sheet supports multiple named views for different workflow phases:
| View Name | Purpose | Visible Columns |
|---|
| Default | Full requirement detail view | All subsystem + design requirement columns + upward system requirements |
| Design Focus | Focused on design requirement specification | Subsystem ID, Design ID, Description, Type, Document |
| Traceability Check | Verify all design requirements link to subsystem | Subsystem ID + System Requirements, Design ID + Subsystem Requirement link |
| Document Origin | Organize by source DRS document | Design Requirement Document (groupBy), ID, Description, Type |
Progressive Disclosure Pattern
The collapseTo behavior for both column groups enables progressive disclosure:
- Expanded view: All requirement metadata visible for detailed review
- Collapsed subsystem group: Shows only subsystem requirement ID and description
- Collapsed design group: Shows only design requirement description
- Summary view: Both groups collapsed, showing only key identifiers for high-level scans
Start with all columns visible for initial requirements decomposition and traceability linking. Once design requirements are stable, switch to Design Focus view for design specification authoring. Use Traceability Check view before document review to verify complete chain: System → Subsystem → Design.
Design Pattern: Requirement Decomposition
The Component RTM implements the ISO 26262 Part 4 system design requirements decomposition:
Each design requirement specifies a concrete implementable constraint derived from the subsystem requirement. The sheet enables verification that:
- All design requirements link to exactly one subsystem requirement (no orphaned design requirements)
- Each subsystem requirement has at least one design requirement (complete decomposition)
- Design requirements maintain upward traceability to system requirements (end-to-end V-Model chain)
Column Group Organization
Design requirements are typically authored in separate Design Requirements Specification (DRS) documents organized per subsystem or component. The Component RTM sheet can display design requirements from multiple DRS documents in a single view. The Design Requirement Document column shows which DRS each requirement comes from, preventing confusion when working with multi-document projects.
| Group | Header Color | Row Background | Collapse Target |
|---|
| Subsystem Requirements | Dark Teal | Teal highlight | Description field |
| System Requirements (Upward) | Green | Green highlight | System Req ID |
| Design Requirements | Dark Blue | Blue highlight | Description field |
- Teal = Requirements level (subsystem)
- Green = Validation/traceability direction (upward to system)
- Blue = Design level (design requirements, implementable specifics)
Entity Factory: Inline Design Requirement Creation
The PowerSheet supports inline creation of new design requirements:
entityFactory:
entityType: DesignRequirement
targetModule: Design/DesignRequirementsSpecification
autoLink: true
linkRole: designRequirements
- Creates a new DesignRequirement work item in the target DRS module
- Automatically links it to the parent subsystem requirement via designRequirements link role
- Populates the parent document reference, maintaining document hierarchy
Use inline creation during design requirements planning when decomposing subsystem requirements into design constraints. This avoids context switching between the Component RTM sheet and Design Requirements Specification documents, improving workflow efficiency.
Common Tasks
Verify Complete Decomposition:
Filter the Component RTM to show subsystem requirements with empty Design Requirements Upward Link expansion. These subsystem requirements have not yet been decomposed into design requirements.
Check Design Requirement Orphans:
Identify design requirements that do not link to any subsystem requirement. These are typically created in error or represent obsolete requirements not yet cleaned up.
Multi-Document Traceability:
Use the Design Requirement Document column to organize requirements by their source DRS document. Large projects with multiple subsystems typically have separate DRS documents per subsystem; this organization enables efficient navigation.
Upward Traceability Validation:
The green-highlighted System Requirements column validates that every subsystem requirement traces to at least one parent system requirement. Missing upward links indicate incomplete requirement allocation.
Related Pages
