Skip to main content

​
Why Traceability Matters

In regulated industries like automotive (ISO 26262), medical devices (IEC 62304), or aerospace, demonstrating traceability isn’t optional—it’s a compliance requirement. Auditors need to see that every identified risk has been assessed, every hazard has been analyzed, and every mitigation task has been implemented. RISKSHEET’s traceability system provides this visibility by making work item relationships explicit and queryable. But traceability isn’t just about compliance. It answers critical project questions:
  • Impact analysis: Which risks are affected if a requirement changes?
  • Coverage gaps: Which hazards haven’t been assessed yet?
  • Mitigation status: Which high-severity risks still lack control measures?
  • Cross-functional visibility: How do system requirements map to software risks?

​
The Two Directions of Traceability

RISKSHEET implements traceability bidirectionally: diagram

​
Upstream Traceability

Upstream links answer “What are we assessing?” They connect risk items to higher-level work items like system requirements, hazards, or functional specifications. These links define the scope of your risk analysis. In a typical FMEA workflow:
  • A Failure Mode links upstream to a System Requirement (what could fail)
  • A Hazardous Situation links upstream to a Hazard (what dangerous condition exists)
  • A Risk links upstream to a Use Case (which usage scenario is being analyzed)
RISKSHEET displays upstream items in the leftmost columns of your sheet. By default, the first column shows linked parent items, but you can configure multiple upstream columns to show different relationship types.
Upstream columns support complex scenarios: loading items from other projects, filtering by status queries, creating new parent items on-the-fly, and even conditional linking based on field values. See Configure Upstream Traceability Columns for implementation details.

​
Downstream Traceability

Downstream links answer “What are we doing about it?” They connect risk items to action items—mitigation tasks, control measures, design changes, or verification activities. These links prove that identified risks are being addressed. In risk management workflows:
  • A Failure Mode links downstream to Risk Control Measures (how we’re mitigating)
  • A Risk links downstream to Verification Tasks (how we’re validating)
  • A HARA entry links downstream to Safety Requirements (what we’re implementing)
RISKSHEET displays downstream items in dedicated sections (often labeled “Mitigations” or “Risk Control”). Each risk item can have multiple downstream tasks, and the sheet shows their status, assignee, and progress inline. RISKSHEET doesn’t invent its own linking mechanism—it uses Polarion’s native work item link roles. When you configure traceability, you’re specifying:
  1. Link Role: The relationship type (e.g., “assesses”, “mitigates”, “verifies”)
  2. Link Types: Which work item types participate (e.g., “systemrequirement”, “task”, “risk”)
  3. Link Direction: Forward link or backlink
An upstream column configuration specifies three key properties: the linkRole (e.g., “assesses”), the linkTypes (which work item types to show, e.g., “systemrequirement,swreq”), and the backLink direction. When a user links items through RISKSHEET, Polarion creates the corresponding relationship (e.g., Risk Item ──[assesses]──> System Requirement). This architecture means your traceability data lives in Polarion’s database, not in RISKSHEET configuration files. Other Polarion tools (Document Studio, LiveDoc, Reports) can query the same relationships.
RISKSHEET doesn’t automatically create links between work items based on document structure or naming conventions. Links must be explicitly created—either manually through the UI or automatically through RISKSHEET’s linking features when you select items from pickers. The sheet displays existing links; it doesn’t infer them.

​
Where Linked Items Come From

Traceability columns can load items from multiple sources:

​
Document-Based Loading

Items are loaded from a specific Polarion document by setting the document property (e.g., “Risks/harms”) along with the linkRole, linkTypes, and an optional query filter. The picker shows only items from that document matching the query. New items created through the picker are placed in the same document.

​
Project-Based Loading

Items are loaded from anywhere in the specified project(s) by setting the project property instead of document. Combined with linkRole, linkTypes, and a query filter, this enables cross-document traceability—your risks in one document can link to tasks scattered across multiple project documents.

​
Query-Factory Loading

The most powerful pattern: dynamically determine which items to show based on other column values. A queryFactory is a named JavaScript function (defined in the queryFactories section) that generates a Polarion query at runtime based on the current row’s field values. For example, a query factory can restrict a hazardous situation picker to only show items linked to the sequence already selected in another column. This creates cascading filters where later columns depend on earlier selections. See Configure Query Factories for implementation details.

​
Multi-Type Traceability

Real-world workflows often need flexibility in work item types. A risk might be mitigated by either a Task or an Issue, depending on the project phase. RISKSHEET supports multiple types in a single traceability column. The dataTypes.task section accepts comma-separated values for both type (e.g., “task,issue,actionItem”) and project (e.g., “RiskProject,SafetyProject”), along with the role and display name. When creating new downstream items, users can choose which type and which project to create in. This flexibility mirrors how teams actually work—not all mitigations are “tasks”, and not all mitigations belong in the same project. See Configure Multiple Downstream Types for implementation details.

​
Revision-Based Traceability

When viewing historical document revisions or baselines, RISKSHEET shows the traceability relationships as they existed at that point in time. This enables:
  • Compliance audits: Prove which control measures existed when a product was released
  • Change impact analysis: Compare which requirements were assessed before and after a design change
  • Historical reporting: Generate traceability matrices for archived project phases
The system uses Polarion’s revision metadata to reconstruct historical link relationships. Deleted items, moved items, or changed link roles are all handled transparently.

​
Cross-Project Traceability Patterns

​
Pattern 1: Central Hazard Library

Organizations often maintain a master list of hazards in one project, referenced by risk analyses in multiple product projects. 
Project: HazardLibrary
  └─ Document: MasterHazards
      └─ Hazard items (centrally maintained)

Project: ProductA
  └─ Document: HARA_ProductA
      └─ Risk items ──[assessedHarm]──> HazardLibrary/Hazard-123

Project: ProductB
  └─ Document: HARA_ProductB
      └─ Risk items ──[assessedHarm]──> HazardLibrary/Hazard-456
The upstream column for each product RISKSHEET points to the central library by setting project to “HazardLibrary”, document to “MasterHazards”, and canCreate to false (preventing users from creating library items from product sheets). See Configure Cross-Project Linking for the full configuration reference.

​
Pattern 2: Requirements Decomposition

System requirements in one project map to software requirements in another, and software risks assess those requirements.
  • Project: SystemEngineering └─ System Requirements
  • Project: SoftwareEngineering └─ Software Requirements ──[derivedFrom]──> System Requirements └─ SFMEA Document └─ Failure Modes ──[assesses]──> Software Requirements
RISKSHEET can display system requirements through the software requirement relationship, giving software engineers visibility into system context without switching projects.
RISKSHEET also supports Polarion’s branched documents, where multiple product variants share a common baseline. However, referencing risk items from multiple external risksheets (not through branching) is not yet supported. See Work with Branched Documents for current capabilities.

​
Traceability vs. Hierarchy

A critical distinction: traceability links are not the same as parent-child document structure.
  • Document hierarchy (parent-child in Polarion documents) controls outline structure and numbering
  • Traceability links (work item relationships) define logical dependencies for analysis
A Failure Mode can be a child of a Function in the document outline while simultaneously linking upstream to a System Requirement and downstream to a Mitigation Task. These are three separate relationships serving different purposes. RISKSHEET’s levels configuration controls how document hierarchy affects visual grouping (merging rows by control column), but this doesn’t create or modify traceability links. See Work Item Visibility and Levels for more on this distinction.

​
Practical Applications

​
Impact Analysis Queries

Because traceability lives in Polarion’s link database, you can write queries like:
  • linkedWorkItems:(id:REQ-123 AND type:risk) — Find all risks assessing requirement REQ-123
  • linkedWorkItems:(status:open AND type:task) — Find all risks with open mitigation tasks
  • linkedWorkItems.linkedWorkItems:(type:testcase) — Find risks whose tasks have linked test cases (two-hop query)

​
Coverage Reports

Generate reports showing:
  • Requirements without linked risk assessments (coverage gaps)
  • Risks without mitigation tasks (action item gaps)
  • High-severity risks with incomplete mitigations (priority violations)
When upstream items change, Polarion can mark downstream links as “suspect”, indicating the risk assessment may need review. RISKSHEET can filter or highlight suspect relationships, triggering re-analysis workflows.
KB ArticlesSupport TicketsSource Code
  • DefaultTraceProvider.java
  • RisksheetProjectProperties.java
  • AppConfigParser.ts
  • ExportToPdf.ts