Skip to main content
Nextedy RISKSHEET (Risksheet for short) is designed around this expectation. Rather than inventing a proprietary linking layer, Risksheet uses Siemens Polarion ALM’s native work item links to express every relationship in a risk analysis. The grid you see in a LiveDoc is, at its core, a structured editor for those links — a mapping table that aggregates context from elsewhere in Polarion into a single auditable row. This page explains the mental model: how a risk item acts as a mapping table, how traceability is built directly on Polarion’s link infrastructure, and how Risksheet integrates end-to-end with requirements, design, and test data already in your project.

​
A Risk Item Is a Mapping Table

The most useful way to think about Risksheet is not as a “risk database” but as a mapping engine. Each row in the grid is one risk item — typically a Polarion work item of type failureMode, hazard, riskRecord, or whatever your methodology calls it — and the columns of that row aggregate four kinds of information into one auditable record.
diagram
A single Risksheet row therefore performs five jobs at once:
  1. Aggregate upstream context — pulls in the requirement, function, hazard, or use step that this risk derives from.
  2. Hold the risk attributes — captures severity, occurrence, detection, exposure, or whatever parameters your methodology uses.
  3. Compute or store the classification — produces an RPN, an ASIL level, a CVSS score, or a custom risk class.
  4. Reference the mitigations — lists the downstream tasks, controls, or safety requirements that reduce the risk.
  5. Track the residual risk — captures the post-mitigation rating and the verification status.
Because every one of those columns is either a field on the risk work item or a link to another work item, the entire row is a structured projection of data that already lives in Polarion. This is why Risksheet can serve methodologies as diverse as FMEA, HARA, TARA, STRIDE, and CVSS scoring with the same underlying engine: the columns change, but the mapping-table pattern does not.
The same mapping pattern works for requirements traceability. By configuring the main row type as requirement and the downstream type as testcase, a sheet becomes a V&V matrix showing which test cases verify which requirements. “Risk” and “task” are naming conventions inherited from the most common use case — the engine itself is methodology-agnostic and supports any two work item types you wish to relate.

​
Built on Polarion Traceability

A defining design choice of Risksheet is that every link is a native Polarion work item link. There is no separate risk database, no shadow link table, no proprietary identifier scheme. When you connect a risk row to an upstream requirement or a downstream mitigation task, Risksheet creates a standard Polarion link with a configured link role — exactly the same kind of link that the Polarion tracker, traceability reports, suspect-link logic, and impact analysis already understand. This has practical consequences that matter for compliance and for day-to-day work:
  • One source of truth. A link created in the Risksheet grid appears in the Polarion work item’s “Linked Work Items” section, in Polarion document views, and in any custom Lucene query you run against the project.
  • Standard audit trail. Every link creation, change, and deletion is captured in Polarion’s history. Risksheet does not bypass or duplicate this.
  • Standard authorization. Whatever the user is permitted to see and edit in Polarion, that is what they see and edit in Risksheet. There is no separate permission model.
  • Bidirectional navigation. Because links are real, you can jump from the risk into the upstream requirement, then back out from the requirement into every risk that references it — using normal Polarion navigation.
  • Suspect link propagation. When an upstream requirement changes, Polarion’s suspect-link mechanism marks the related risk as suspect, prompting reassessment. This is automatic.
diagram
Risksheet does not maintain its own data store. The grid is a view onto Polarion work items — it visualizes and edits them, but it does not store them separately. Closing the Risksheet does not “save” anything special; the work items and their links are already there.
Risksheet distinguishes two directions of linking, and they are configured in different places. Upstream links point from the risk to a cause or source: the requirement that introduced the hazard, the function being analyzed, the hazardous situation. These are configured as item link columns on the row, using type: itemLink or type: multiItemLink, with a typeProperties block that specifies the link role, the allowed work item types, and the search scope. Downstream links point from the risk to a consequence or response: the mitigation task, safety control, verification activity, or test case. These are configured globally for the sheet using the dataTypes.task section, which declares the work item type, the link role, and how new tasks are created.
The type and role properties tell Risksheet which work item type to create and which link role to apply. The name property is the label shown in the toolbar and menus when creating tasks. The zoomColumn property tells Risksheet which column to focus on after a new task is created. The document property restricts the scope of tasks to a specific LiveDoc path — only tasks inside that document are loaded as downstream items. For configuration syntax details, see the Reference section. Sometimes two upstream items both link to the same risk but do not link to each other. Consider a medical device risk where the same risk record references both a Use Step (from the Instructions for Use) and a Procedure Step (from the clinical procedure). The two upstream items have no direct relationship, but for impact analysis you may want a link between them. Risksheet can build these “horizontal” relationships automatically. A project property defines patterns of the form fromType-linkRole-toType and, whenever a risk row connects two upstream items that match the pattern, Risksheet creates the missing link between them. The mechanism only adds links — it never removes existing ones, so it is safe to apply retroactively. For the exact property syntax, see Configuration properties.

​
End-to-End Integration

Because all linking goes through Polarion, Risksheet does not exist in a documentation silo. A risk analysis sits in the same project as the requirements, the design specification, and the test management content, and the links between them are visible from every direction.
diagram
In a typical regulated workflow the chain looks like this:
  • A system requirement describes a function the product must perform.
  • A design element or function block implements that requirement.
  • A risk analysis identifies failure modes of that function, classifies them, and proposes mitigations.
  • A mitigation is itself a work item — often a safety requirement or design constraint — that addresses one or more failure modes.
  • A test case verifies that the mitigation works as intended.
Risksheet makes the middle of this chain a structured editor. Auditors and engineers can trace forward from any requirement to the risks it produces and the mitigations that close them, or backward from any test result to the risks it covers and the requirements those risks were derived from. Because the chain runs through Polarion’s link graph, the same data feeds Polarion’s traceability reports, Live Reports, and Lucene queries.

​
Historical and Revision Traceability

Compliance does not stop at the current state. Auditors regularly need to see what the linking structure looked like at a previous milestone — for example, the set of mitigations linked to a hazard at the moment a release was approved. Risksheet supports this by loading downstream items from a specific document or work item revision when you view a historical baseline. The grid then shows the relationships as they existed at that point in time, with the same row structure and the same column logic, but with the linked work items frozen to the revision you selected. This time-aware traceability is essential for change impact analysis. When a requirement changes, the team can compare the current risk mapping with a previous baseline and identify which risks must be re-evaluated.

​
Task Resolution and Filtering

The downstream side of the chain is rarely a flat list. In real projects, the set of tasks linked to a given risk is filtered by status, type, ownership, or document location. Risksheet supports this in four independent ways: These filters compose: the tasks shown are those that match the configured type and the configured link role and the optional query and (if set) the document scope. The result is a focused view — for example, “all open mitigation tasks for this hazard, drawn from the master mitigation document.”
The exact application of custom queries is governed by a project property that toggles query filtering on tasks. If you have configured a query but do not see it applied, check the project administration settings for the related option.

​
Subsheet Navigation

For complex analyses, a single sheet may not be enough. A master HARA, for example, can list all top-level hazards while each hazard has its own detailed risk analysis in a separate Risksheet document. Risksheet supports this master-detail pattern by making the task link column a clickable hyperlink that opens the child risksheet document directly.
When linkToRisksheet is enabled, clicking the task identifier opens the linked downstream document in a new risksheet view, allowing the user to drill from a top-level hazard into its detailed analysis without leaving Polarion.

​
Common Misconceptions

“Risksheet keeps its own link database.”
It does not. Every Risksheet link is a Polarion work item link with a standard link role. If you delete Risksheet tomorrow, the links remain in Polarion and are usable by any other tool.
“Risksheet only works for FMEA.”
The engine is methodology-agnostic. The same configuration mechanism supports FMEA, HARA, TARA, STRIDE, CVSS scoring, and even non-risk patterns like requirements-to-test-case traceability matrices. Nextedy ships solution templates for the most common methodologies, but the underlying tool does not enforce any one of them.
“If I link a requirement in Risksheet, only Risksheet knows about it.”
The link is created in Polarion and is fully visible in the Polarion tracker, in document views, and in queries. A second team member working on the same requirement will see it linked to the risk record without ever opening Risksheet.
“Upstream and downstream are symmetric — they work the same way.”
They are configured very differently. Upstream links are defined per-column using type: itemLink and a typeProperties block, so different upstream columns can reach different kinds of work items. Downstream links are defined once globally in dataTypes.task, so the entire sheet shares a single downstream type and role. This asymmetry reflects the practical pattern: a risk usually has many kinds of upstream context (requirement, function, hazard) but a uniform kind of downstream response (mitigation tasks).

​
Putting It Together

The mental model to carry forward is this:
  • A risk row is a mapping table — it pulls upstream context in, holds the risk attributes and classification, and points to downstream mitigations and verifications.
  • Every link is a Polarion link, which means everything you build in Risksheet is visible, auditable, and queryable through Polarion’s standard infrastructure.
  • The same engine handles many methodologies because the linking pattern is generic — only the column definitions, work item types, and link roles change between an FMEA, a HARA, and a requirements traceability matrix.
  • Time-aware loading and document-scoped task filtering make the model robust against the real complexities of regulated change control.
For practical configuration of these traceability features, see the Risk Management guides, the Configuration Management guides, and the Integration guides. For complete property syntax, see the Configuration reference and Column Types reference.
Last modified on July 10, 2026