Skip to main content
diagram

​
Entity Types

The RTM model defines entity types under the domainModelTypes root key. Each entity type maps to a Polarion work item type via polarionType.
PropertyTypeDefaultDescription
domainModelTypesobjectNoneRoot container defining all entity types in the domain model. Each key is an entity type name.
domainModelTypes[].namestringNoneUnique identifier for the entity type. Used in relationships and queries.
domainModelTypes[].polarionTypestringNoneMaps this entity to a Polarion work item type. If omitted, uses a generic work item type.
domainModelTypes[].propertiesarrayNoneList of properties available on this entity type. Each maps to a Polarion work item field.
domainModelTypes[].properties[].namestringNoneName of the property. Must correspond to a Polarion work item field (built-in or custom).

​
Standard RTM Entity Types

domainModelTypes:
  Document:
  Chapter:
  UserNeed:
    polarionType: userNeed
    properties:
      description:
      severity:
      component:
      type:
  SystemRequirement:
    polarionType: systemRequirement
    properties:
      description:
      severity:
      component:
      type:
  DesignRequirement:
    polarionType: designOutput
    properties:
      description:
      severity:
      component:
      type:
Document is a built-in entity type representing Polarion LiveDoc modules and does not require a polarionType mapping. Chapter represents document headings and must be explicitly declared with polarionType: heading.

​
Relationships

Relationships define navigable links between entity types using Polarion link roles.
PropertyTypeDefaultDescription
relationshipsarray[]Defines all navigable relationships between entity types.
relationships[].fromstringNoneSource entity type. Must match a domainModelTypes key.
relationships[].tostringNoneTarget entity type. Must match a domainModelTypes key.
relationships[].cardinalitystringNoneRelationship multiplicity: one-to-many, many-to-one, many-to-many.
relationships[].storagestringNonePersistence mechanism. Use linkedWorkItems for Polarion work item links.
relationships[].linkRolestringNonePolarion link role ID. Must exist in project configuration.
relationships[].directstringNoneNavigation property name on source entity to traverse to target.
relationships[].backstringNoneNavigation property name on target entity to traverse back to source.

​
Standard RTM Relationships

relationships:
  - from: UserNeed
    to: SystemRequirement
    cardinality: one-to-many
    storage: linkedWorkItems
    linkRole: relates_to
    direct: systemRequirements
    back: userNeeds

  - from: SystemRequirement
    to: DesignRequirement
    cardinality: one-to-many
    storage: linkedWorkItems
    linkRole: relates_to
    direct: designRequirements
    back: systemRequirements

​
Constraints

Entity types support three constraint types for scoping data loading and entity creation.
ConstraintDescription
loadQuery filter defining which entities to load. Filters by document properties.
createDefault values applied when creating new entities of this type.
pickPicker filter controlling which entities appear in selection dropdowns.
UserNeed:
  polarionType: userNeed
  properties:
    description:
    severity:
  constraints:
    pick:
      document:
        moduleFolder: Requirements
        type: requirementsDocument
    create:
      document:
        moduleFolder: Requirements
        moduleName: User Needs
Use $context.source.document.component in pick constraints to dynamically filter by the source entity’s component value. This ensures related entities are scoped to the same component.

​
Expansion Paths

In the sheet configuration, the RTM model supports multi-level expansion through navigation properties: 
sources:
  - id: rtm
    title: RTM
    model: rtm
    query:
      from: UserNeed
    expand:
      - name: systemRequirements
        expand:
          - name: designRequirements
This loads UserNeed entities and expands two levels deep through SystemRequirement to DesignRequirement, enabling a full RTM hierarchy view in the sheet.

​
Complete YAML Example

domainModelTypes:
  Document:
  Chapter:
  UserNeed:
    polarionType: userNeed
    properties:
      description:
      severity:
      component:
      type:
    constraints:
      pick:
        document:
          moduleFolder: Requirements
          type: requirementsDocument
  SystemRequirement:
    polarionType: systemRequirement
    properties:
      description:
      severity:
      component:
      type:
    constraints:
      pick:
        document:
          type: requirementsDocument
  DesignRequirement:
    polarionType: designOutput
    properties:
      description:
      severity:
      component:
      type:
    constraints:
      pick:
        document:
          type: designDocument

relationships:
  - from: UserNeed
    to: SystemRequirement
    cardinality: one-to-many
    storage: linkedWorkItems
    linkRole: relates_to
    direct: systemRequirements
    back: userNeeds
  - from: SystemRequirement
    to: DesignRequirement
    cardinality: one-to-many
    storage: linkedWorkItems
    linkRole: relates_to
    direct: designRequirements
    back: systemRequirements

​
Automotive Safety RTM (Extended Example)

Production automotive projects typically extend the basic RTM with subsystem decomposition, verification at multiple levels, and characteristics traceability. The following example demonstrates a 4-level requirements hierarchy used for ISO 26262 compliance. 
domainModelTypes:
  Document:
    properties:
      type:
      subsystem:

  Chapter:
    polarionType: heading

  CustomerRequirement:
    polarionType: customerRequirement
    properties:
      description:
      outlineNumber:
      classification:
    constraints:
      create:
        document:
          moduleFolder: Requirements
          moduleName: CUSTOMER-REQS

  SystemRequirement:
    polarionType: sysReq
    properties:
      description:
      classification:
    constraints:
      pick:
        document:
          type: systemRequirementsSpecification

  SubsystemRequirement:
    polarionType: sysReq
    properties:
      description:
      classification:
    constraints:
      pick:
        document:
          type: subsystemRequirementsSpecification

  DesignRequirement:
    polarionType: desReq
    properties:
      description:
      classification:
      subType:
    constraints:
      pick:
        document:
          type: designRequirementsSpecification

  TestCase:
    polarionType: testCase

  Characteristic:
    polarionType: characteristic
    properties:
      targetValue:
      tolerance:
      classification:

  FailureMode:
    polarionType: failureMode
    properties:
      description:
      fmSeverity:
      premitigationFMOccurrence:
      postmitigationFMOccurrence:
      postmitigationAP:

relationships:
  - from: CustomerRequirement
    to: Chapter
    cardinality: many-to-one
    storage: linkedWorkItems
    linkRole: parent
    direct:
      name: chapter
    back:
      name: customerRequirements

  - from: SystemRequirement
    to: CustomerRequirement
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: refines
    direct:
      name: customerRequirements
    back:
      name: systemRequirements

  - from: SubsystemRequirement
    to: SystemRequirement
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: refines
    direct:
      name: systemRequirements
    back:
      name: subsystemRequirements

  - from: DesignRequirement
    to: SubsystemRequirement
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: refines
    direct:
      name: subsystemRequirements
    back:
      name: designRequirements
      constraints:
        pick:
          document:
            subsystem: $context.source.document.subsystem

  - from: TestCase
    to: CustomerRequirement
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: validates
    direct:
      name: customerRequirements
    back:
      name: testCases

  - from: TestCase
    to: SystemRequirement
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: verifies
    direct:
      name: systemRequirements
    back:
      name: testCases
      constraints:
        create:
          document:
            moduleFolder: Testing
            moduleName: SystemReqsVerification

  - from: TestCase
    to: DesignRequirement
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: verifies
    direct:
      name: designRequirements
    back:
      name: testCases

  - from: Characteristic
    to: DesignRequirement
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: refines
    direct:
      name: designRequirements
    back:
      name: characteristics

  - from: FailureMode
    to: Characteristic
    cardinality: many-to-many
    storage: linkedWorkItems
    linkRole: assesses
    direct:
      name: characteristics
    back:
      name: failureModes
This sheet configuration renders the full traceability chain with color-coded column groups and collapsible sections:
columnGroups:
  customerRequirements:
    groupName: Customer Requirements
    groupStyle: darkgreen
    headerStyle: green
    collapseTo: title
  systemRequirements:
    groupName: System Requirements
    groupStyle: darkpurple
    headerStyle: purple
    collapseTo: systemRequirements.systemRequirement.description
  subsystemRequirements:
    groupName: Subsystem Requirements
    groupStyle: darkteal
    headerStyle: teal
    collapseTo: >-
      systemRequirements.systemRequirement
      .subsystemRequirements.subsystemRequirement.description
  designRequirements:
    groupName: Design Requirements
    groupStyle: darkblue
    headerStyle: blue
    collapseTo: >-
      systemRequirements.systemRequirement
      .subsystemRequirements.subsystemRequirement
      .designRequirements.designRequirement.description

sortBy:
  - columnId: outlineNumber
    direction: asc

columns:
  chapter:
    display: title
    title: Chapter
    width: 150
    groupBy: true
    formatter: readOnly

  outlineNumber:
    title: "#"
    width: 80
    formatter: readOnly
    columnGroup: customerRequirements

  title:
    title: Title
    sort: asc
    hasFocus: true
    width: 230
    formatter: boldTitle
    columnGroup: customerRequirements

  classification:
    title: Classification
    width: 150
    columnGroup: customerRequirements
    formatter: classification
    render: classificationRenderer

  description:
    title: Description
    hasFocus: true
    width: 230
    columnGroup: customerRequirements

  testCases.testCase:
    title: Validation Plan
    sort: asc
    minWidth: 230
    multiItem: true
    columnGroup: customerRequirements
    header: &orange
      style: orange

  systemRequirements.systemRequirement:
    title: ID
    width: 100
    columnGroup: systemRequirements

  systemRequirements.systemRequirement.description:
    title: Description
    formatter: boldTitle
    width: 200
    columnGroup: systemRequirements
    hasFocus: true

  systemRequirements.systemRequirement.testCases.testCase:
    title: Verification Plan
    sort: asc
    minWidth: 230
    multiItem: true
    columnGroup: systemRequirements
    header: *orange

views:
  - title: Full RTM
  - title: Without V&V
    hiddenColumns:
      - testCases.testCase
      - systemRequirements.systemRequirement.testCases.testCase
  - title: Summary
    hiddenColumns:
      - description
      - document
Key patterns in this configuration:
  • YAML anchors (&orange / *orange) avoid repeating the same header style across verification columns
  • collapseTo lets users collapse entire requirement levels to a single description column
  • multiItem: true on test case columns renders multiple linked test cases in a single cell
  • groupBy: true on the chapter column organizes rows by document chapter structure
  • Named views provide pre-configured column visibility for different audiences

​
See Also

Source Code
  • powersheet.yaml