Entity Types
The RTM model defines 9 entity types that map to Polarion work item types:
| Entity | Polarion Type | Properties | Description |
|---|
| Document | (built-in) | type, subsystem | Container for work items |
| Chapter | heading | — | Document structure grouping |
| UseStep | useStep | outlineNumber, description | User/operational step for HARA analysis |
| ProcessStep | processStep | outlineNumber, description | Manufacturing step for PFMEA analysis |
| SystemElement | systemElement | outlineNumber, description | Physical or logical product component |
| UserNeed | userNeed | description, outlineNumber, severity | Stakeholder need |
| SystemRequirement | sysReq | description, severity | System-level specification |
| DesignRequirement | desReq | description, severity | Implementation-level requirement |
| TestCase | testCase | — | Verification/validation test |
UserNeed, SystemRequirement, and DesignRequirement all expose a severity property, enabling risk-based prioritization and filtering across the traceability hierarchy.
Pick Constraints
Pick constraints control which items appear in powersheet pickers when creating links:
| Entity | Constraint Type | Constraint Value |
|---|
| UserNeed | Document-scoped | moduleFolder: Requirements, moduleName: UserNeedSpecification |
| SystemRequirement | Type-scoped | document.type: systemRequirementsSpecification |
| DesignRequirement | Type-scoped | document.type: designRequirementsSpecification |
UserNeed uses moduleFolder + moduleName constraints while SystemRequirement and DesignRequirement use document.type constraints. Both strategies prevent cross-document pollution when linking, but use different Polarion mechanisms.
Subsystem-Scoped Design Requirement Picking
The DesignRequirement entity has a special dynamic constraint on its back-link picker:
constraints:
pick:
document:
type: designRequirementsSpecification
subsystem: $context.source.document.subsystem
Relationships
The model defines 8 relationships forming a V-shaped traceability graph:
Relationship Details
| # | From | To | Link Role | Cardinality | Purpose |
|---|
| 1 | UserNeed | Chapter | parent | many-to-one | Document structure grouping |
| 2 | ProcessStep | SystemElement | associates | many-to-many | Process-to-component mapping |
| 3 | UseStep | UserNeed | address | many-to-many | Usage step to need mapping |
| 4 | SystemRequirement | UserNeed | refines | many-to-many | Requirement decomposition |
| 5 | DesignRequirement | SystemRequirement | refines | many-to-many | Design decomposition (subsystem-scoped) |
| 6 | TestCase | SystemRequirement | verifies | many-to-many | System-level verification |
| 7 | TestCase | DesignRequirement | verifies | many-to-many | Design-level verification |
| 8 | TestCase | UserNeed | validates | many-to-many | Need-level validation |
The model uses two distinct link roles for testing: verifies (for requirements) and validates (for user needs). This implements the ISO 14971 verification and validation distinction.
Storage
All relationship storage uses linkedWorkItems — no custom fields or external storage. This means all traceability is based on native Polarion links.
Parallel Traceability Paths
The model creates two traceability paths:
- Primary path (requirements): UseStep -> UserNeed -> SystemRequirement -> DesignRequirement
- Parallel path (process): ProcessStep -> SystemElement
The process path supports PFMEA analysis by linking manufacturing process steps to the physical components they involve.
Configuration File
| Property | Value |
|---|
| File location | .polarion/nextedy/models/rtm.yaml |
| Used by | All powersheet configurations |
| Entity count | 9 (including Document and Chapter) |
| Relationship count | 8 |
Related Pages
