While Polarion provides the underlying work item types and link roles through XML configuration, the RTM Domain Model is a PowerSheet-specific YAML configuration that declares which entities and relationships PowerSheet should recognize when building interactive traceability sheets.
Why RTM Models Matter
Without an RTM model, PowerSheet would only know about generic Polarion work items. The RTM model teaches PowerSheet your project’s semantic structure:
- A
DesignRequirement refines a SystemRequirement
- A
FailureMode assesses a Characteristic and is mitigatedBy a RiskControl
- A
VerificationTestCase verifies a DesignRequirement
This semantic understanding enables PowerSheet to automatically generate multi-hop traceability views, enforce cardinality constraints (one-to-many vs many-to-many), and provide intelligent entity creation workflows.
If Polarion work items are like database records, the RTM model is like your database schema. It defines tables (entity types), foreign keys (relationships), and constraints (cardinality, required links). PowerSheet uses this schema to construct JOIN queries across your safety artifacts.
Three-Layer Architecture
Key insight: The RTM model sits between PowerSheet configurations and Polarion’s data model. It translates PowerSheet’s high-level traceability concepts into Polarion’s low-level work item queries and link traversals.
Entity Types
An entity type in the RTM model corresponds to a Polarion work item type that participates in traceability relationships. In TestAuto2, there are 20+ entity types spanning the V-model lifecycle:
| V-Model Phase | Entity Types |
|---|
| Requirements | CustomerRequirement, SystemRequirement, SubsystemRequirement, DesignRequirement |
| Design | SystemElement, Function, Characteristic |
| Risk Analysis | Hazard, Harm, SafetyGoal, FailureMode, ProcessFailureMode, RiskRecord, RiskControl |
| Verification | VerificationTestCase, ValidationTestCase, TestCase |
| Process | ProcessStep, ControlPlanItem |
| Metadata | UserNeed, UseStep |
- workItemType: The Polarion work item type ID
- displayName: Human-readable label for UI
- relationships: Outgoing link roles to other entities
- constraints: Cardinality rules (optional, required, one-to-many)
TestAuto2 has work item types like Task or Issue that are not declared as RTM entities. These artifacts exist in Polarion but don’t participate in formal traceability chains, so they’re excluded from the RTM model. The model only includes types relevant to safety compliance traceability.
Relationships and Link Roles
A relationship defines how one entity type connects to another through a named link role. TestAuto2’s RTM model includes 25+ relationships:
Requirements Decomposition
| Source | Relationship | Target |
|---|
| CustomerRequirement | refines | SystemRequirement |
| SystemRequirement | refines | SubsystemRequirement |
| SubsystemRequirement | refines | DesignRequirement |
| Source | Relationship | Target |
|---|
| CustomerRequirement | validatedBy | ValidationTestCase |
| SystemRequirement | verifiedBy | VerificationTestCase |
| DesignRequirement | verifiedBy | VerificationTestCase |
| Source | Relationship | Target |
|---|
| Hazard | hasHazard | Harm |
| Harm | assesses | RiskRecord |
| RiskRecord | mitigatedBy | RiskControl |
| Source | Relationship | Target |
|---|
| Characteristic | failureModes | FailureMode |
| FailureMode | mitigatedBy | RiskControl |
Cardinality Rules
Each relationship specifies cardinality constraints:
- One-to-many: One
SystemRequirement refines many DesignRequirement entities
- Many-to-one: Many
FailureMode entities assess one Characteristic
- Many-to-many: Many
FailureMode entities are mitigated by many RiskControl entities
PowerSheet uses these rules to render correct UI controls (single-select vs multi-select pickers) and validate traceability completeness.
Expansion Paths
Expansion paths are the RTM model’s most powerful feature. They define multi-hop traceability queries that PowerSheet can traverse automatically.
For example, the Design Verification Sheet expansion path:
This three-level path allows PowerSheet to generate a single view showing:
- Design requirements (primary rows)
- Linked verification test cases (first expansion)
- Evidence artifacts attached to tests (second expansion)
Without expansion paths, you’d need three separate views and manual cross-referencing. The RTM model encodes this traversal logic declaratively.
Expansion paths don’t execute database queries directly. They’re navigation instructions that PowerSheet uses to construct Lucene queries against Polarion’s work item repository. The actual query execution happens at runtime when you open a PowerSheet.
How PowerSheet Consumes the RTM Model
When you configure a PowerSheet YAML (like characteristics.yaml), you reference entities and relationships from the RTM model:
source:
entity: Characteristic # ← Entity type from RTM model
expansion:
- relationship: failureModes # ← Relationship from RTM model
entity: FailureMode
- Queries all
Characteristic work items in the current context
- For each characteristic, follows the
failureModes link role
- Fetches the linked
FailureMode work items
- Renders them in expandable column groups
The RTM model provides the vocabulary (Characteristic, failureModes, FailureMode) that makes this configuration possible.
Real-World Example: Whole RTM Sheet
The Whole RTM Sheet demonstrates the RTM model’s full power. It renders the complete V-model in a single view:
- CustomerRequirement (source entity)
- refines -> SystemRequirement
- refines -> SubsystemRequirement
- refines -> DesignRequirement
- verifiedBy -> VerificationTestCase
- validatedBy -> ValidationTestCase
This PowerSheet configuration declares a five-level expansion path using relationships from the RTM model. The result: engineers see customer needs cascading through four requirement levels with bidirectional test linkage, all in a single scrollable grid.
Without the RTM model, building this view would require writing custom Velocity scripts with hardcoded Lucene queries—fragile and unmaintainable.
RTM Model vs Data Model
A common point of confusion: RTM Domain Model vs Data Model Overview. What’s the difference?
| Aspect | RTM Domain Model | Data Model Overview |
|---|
| Purpose | PowerSheet traceability configuration | Conceptual understanding of work item types and relationships |
| Format | YAML file in .polarion/nextedy/models/ | Conceptual documentation (this docs site) |
| Audience | PowerSheet configuration developers | Safety engineers, system engineers, documentation readers |
| Scope | Entities + relationships + expansion paths | Work item types + link roles + custom fields + workflows |
| Enforces | Cardinality constraints, traceability paths | Schema definitions in Polarion XML |
Modifying the RTM Model
The RTM model is not static. As your project evolves, you may need to:
- Add new entity types for custom work items
- Define new relationships for organization-specific traceability
- Adjust cardinality constraints based on process changes
- Create new expansion paths for custom reports
See Modify RTM Model for step-by-step instructions on editing the YAML configuration and validating changes.
Always validate RTM model changes against Polarion’s XML configuration. If you declare a relationship using a link role that doesn’t exist in tracker-link-roles.xml, PowerSheet queries will fail silently. Use automated consistency checks before deployment.
Learning More
