Skip to main content

​
Why Cardinality Matters

Siemens Polarion ALM allows any work item to link to any number of other work items through link roles. This open-ended flexibility means Polarion itself does not enforce limits like “a hazard must link to at least one risk control” or “a system requirement should derive from exactly one user need.” Powersheet’s domain model introduces cardinality as a semantic layer on top of Polarion’s link roles. Think of it like database schema design: just as a relational database enforces foreign key constraints, Powersheet’s cardinality settings enforce relationship multiplicity in the user interface.

​
Cardinality Options

The cardinality property on a relationship definition accepts four values: diagram
CardinalityFrom SideTo SideTypical Use Case
one-to-oneSingleSingleRequirement to unique verification
many-to-oneMultipleSingleMany design reqs derive from one system req
one-to-manySingleMultipleOne user need decomposes into many system reqs
many-to-manyMultipleMultipleHazards linked to multiple risk controls and vice versa

​
How Cardinality Is Defined

Cardinality is set on each relationship in the relationships array of the domain model YAML: 
relationships:
  - from: UserNeed
    to: SystemRequirement
    cardinality: one-to-many
    storage: linkedWorkItems
    linkRole: refines
    fromNavPropName: systemRequirements
    toNavPropName: userNeed
In this example, one UserNeed can link to many SystemRequirement items (one-to-many). The fromNavPropName becomes a collection-valued property on UserNeed, while toNavPropName becomes a single-valued property on SystemRequirement.

​
Impact on the User Interface

Cardinality directly controls the sheet’s editing behavior:
  • Single-value relationships (the “one” side) display a single-select picker. The user can choose exactly one target entity.
  • Multi-value relationships (the “many” side) display a multi-select picker. The user can select multiple related entities.
A many-to-one relationship means the “from” entity can reference exactly one “to” entity, but the “to” entity can be referenced by many “from” entities. The navigation property on the “from” side is single-valued; the navigation property on the “to” side (via toNavPropName) is collection-valued.
Polarion link roles are inherently many-to-many — any work item can create any number of links using a given role. Powersheet’s cardinality setting does not change this at the Polarion level; instead, it enforces the constraint at the UI and validation level within the sheet. This means:
  • If a relationship is defined as many-to-one, the sheet will present a single-value picker and prevent users from creating additional links through the powersheet
  • Links created outside Powersheet (via Polarion’s native UI) are not retroactively constrained
The exact enforcement behavior for cardinality violations (whether existing extra links are hidden or shown with a warning) may vary. Test with your configuration to confirm.

​
Common RTM Cardinality Pattern

A typical Requirements Traceability Matrix uses the following cardinality chain:
FromToCardinalityLink Role
UserNeedSystemRequirementone-to-manyrefines
SystemRequirementDesignRequirementone-to-manyrefines
HazardRiskControlmany-to-manymitigates
This creates a hierarchy where each upstream requirement can decompose into multiple downstream items, while hazard-to-control relationships remain flexible.
Source Code
  • riskmanagement_model.yaml
  • prod-powersheet-src/com.nextedy.powersheet.client/cypress/fixtures/models/constraints_pick_only.yaml
  • sf_model.yaml
  • prod-powersheet-src/com.nextedy.powersheet.client/cypress/fixtures/models/constraints_create_only.yaml
  • Relationship.java