Last reviewed on {formatted}
; }; ## The Traceability Challenge Polarion stores traceability as individual links between work items. While each link is correct in isolation, understanding the full chain -- from a user need through system requirements to design requirements to hazards to risk controls -- requires mentally assembling dozens of separate work item views. This is like reading a book one sentence at a time from different chapters: technically possible, but practically unusable for analysis. Powersheet solves this by rendering the entire traceability chain as a single hierarchical sheet, where parent-child nesting shows the relationships and every level is editable in place. ## How Hierarchy Maps to the Data Model The hierarchy displayed in a Powersheet sheet is defined by two configuration layers working together: 1. **Data model** -- defines entity types (e.g., `UserNeed`, `SystemRequirement`, `DesignRequirement`) and the `relationships` between them, including cardinality, storage mechanism, and navigation property names 2. **Sheet configuration** -- defines which columns to show, how to sort and group rows, and which `sources` with `expand` clauses to use for loading related entities The data model provides the structural skeleton. The sheet configuration decides which parts of that skeleton to display and how.
## Row Levels and Expansion Paths
When a sheet loads data, it starts with a root entity type (defined by `sources[].query.from`) and follows **expansion paths** to load related entities. Each expansion creates a new row level in the hierarchy:
* **Level 0 (upstream)** -- the root entity (e.g., `UserNeed`). Always present, with no back reference.
* **Level 1 (downstream)** -- first-level related entities (e.g., `SystemRequirement`), loaded by expanding a navigation property.
* **Level 2+** -- deeper related entities (e.g., `DesignRequirement`), loaded by nested expansions.
Each downstream level maintains a **back reference** to its parent navigation property, preserving the parent-child relationship for rendering and editing.
```yaml theme={null}
sources:
- id: rtm
title: Requirements Traceability
model: rtm
query:
from: UserNeed
expand:
- name: systemRequirements
title: System Requirements
expand:
- name: designRequirements
title: Design Requirements
```
The nested `expand` structure mirrors the hierarchy you want to see in the sheet. Each `name` must reference a navigation property defined in the data model `relationships` section.
## Cardinality and Row Nesting
The `cardinality` of each relationship determines how many child rows appear beneath a parent:
| Cardinality | Behavior in Sheet |
| -------------- | ----------------------------------------------------------------------------------- |
| `one-to-many` | Parent row expands to show multiple child rows |
| `many-to-one` | Multiple parent rows share a single child reference |
| `many-to-many` | Parent row expands to multiple children; children may appear under multiple parents |
| `one-to-one` | Parent row has exactly one child row |
Most traceability relationships use `one-to-many` or `many-to-many`, as requirements typically refine into multiple downstream items and can be traced to multiple upstream sources.