Architecture

This page builds a mental model of how Risksheet fits into Siemens Polarion ALM, how data flows between the grid and the platform, and where the boundaries of the product lie. If you understand this picture, the rest of the documentation — configuration, traceability, review workflows, export — will fit together naturally.

​

The Core Idea: A View Onto Polarion

A useful analogy: think of Risksheet the way you would think of a spreadsheet view over a relational database. The spreadsheet is a workspace for analysis — sorting, filtering, formulas, conditional formatting — but the rows are records in the database. Closing the spreadsheet does not delete the records, and opening a different spreadsheet over the same table shows the same data, possibly arranged differently. In our case, the “database” is Polarion’s work-item store, and the “spreadsheet” is the risksheet grid embedded in a Polarion LiveDoc. Risksheet adds three things on top of Polarion:

1. A grid renderer that turns work items into rows and fields into columns, with cell merging, calculated values, conditional formatting, and saved views.
2. A sheet configuration that declares the structure of that grid — which columns to show, how to group rows visually, how to calculate values, how to style cells.
3. A small server-side component that loads the configuration, mediates communication between the browser grid and Polarion’s work-item APIs, and handles export.

That is the entire product surface. There is no Risksheet database, no Risksheet user directory, no Risksheet permission system.

​

The Two Halves: Browser Grid and Server Extension

Risksheet has two cooperating parts:

• Client-side grid — JavaScript code that runs in the user’s browser inside the Polarion LiveDoc page. It renders rows, evaluates JavaScript formulas, applies cell decorators, handles editing, and drives the review UI.
• Server-side extension — a Polarion plugin that exposes endpoints for the grid to load configurations, fetch work-item data, save edits in batches, and generate PDF and Excel exports.

This split has practical consequences:

• Formulas and conditional formatting are JavaScript that runs in the browser. They can react instantly to user input without a server round-trip, but they can only see data Polarion has already loaded into the page.
• Edits are saved through the server extension, which writes work items via Polarion’s own APIs. Risksheet does not bypass workflow, signatures, or field-level permissions — if Polarion would have rejected a write, Risksheet’s save will fail in exactly the same way.
• The grid behaves the same regardless of how the user reached it (LiveDoc page, direct link, embedded view). The configuration is attached to the document, not to a session.

​

What a Risksheet Actually Contains

When you open a risksheet, three layered ingredients combine: Risksheet keeps these three concerns separate on purpose. The work items are the audited record. The sheet configuration is a declarative description of how to show those records. Custom logic — risk matrices, complex conditional rendering, branded PDF layouts — lives in separate Velocity templates so that changes to it do not perturb the declarative configuration. This separation matters in regulated industries (ISO 26262, ISO 14971, IEC 61508, ISO/SAE 21434), where the scope of validation is smaller when configuration and custom code change independently. For details about how the configuration is loaded and inherited, see Configuration Hierarchy.

​

The Risk Item as Aggregation Point

Looking at a risksheet from a methodology angle (FMEA — Failure Mode and Effects Analysis, HARA — Hazard Analysis and Risk Assessment, TARA — Threat Analysis and Risk Assessment, STRIDE, CVSS — Common Vulnerability Scoring System), the central object is the risk item — a single Polarion work item that ties together everything an analyst needs to assess one failure mode, hazard, threat, or vulnerability. The risk item is best understood as a mapping table: A single row in the grid maps:

• Context — the function, system item, hazard, or scenario the risk applies to (typically a linked upstream work item)
• through risk attributes — the failure mode, cause, effect, or threat description
• to a classification — numeric or categorical scoring (severity, occurrence, detection, ASIL — Automotive Safety Integrity Level, RPN — Risk Priority Number, CVSS score)
• with mitigations — linked downstream tasks, safety requirements, or controls
• to a residual risk — the reassessed scoring after mitigations are applied.

All of these are fields or link roles on the same Polarion work item, surfaced as columns in the grid. Reading the row left to right traces the analytical chain from “what could go wrong” through “what we did about it” to “what risk remains”. This shape is the same whether the methodology is FMEA, HARA, TARA, STRIDE, or CVSS — only the column names, scales, and standards change. Risksheet is a generic tool that supports any of these methodologies; Nextedy provides solution templates for typical methodologies across industries. For the underlying work-item structure and the two-entity data model (risk items plus linked task items), see Data Model and Work Items.

​

Data Flow at a Glance

In one sentence: the server loads the configuration and the work items, the browser renders the grid and evaluates formulas, and edits travel back through the server, where Polarion enforces its normal rules before persisting them. A few properties follow directly from this flow:

• No separate cache or shadow store. What you see in the grid is the result of a fresh query against Polarion’s work-item store, scoped to the document and the current view.
• All edits go through Polarion. Workflow transitions, field validations, custom-field constraints, permissions, signatures, and history are all applied by Polarion on save. Risksheet does not have a back door.

​

Security: Polarion Is the Source of Truth

Because every piece of data is a Polarion work item, Risksheet inherits the platform’s security model wholesale. Risksheet does not add a parallel permission system. If a user cannot edit a particular field in Polarion’s own form view, they cannot edit it in the risksheet either — the server rejects the save the same way. If a user cannot read a work item, that work item does not appear in their grid. Administrative actions (changing the sheet configuration, managing licensing, registering documents as risksheets) are gated on Polarion administrative roles. For day-to-day expectations about who can do what, see User Roles and Permissions and Data Model and Work Items (which covers work item visibility and levels).

​

Traceability Without Replication

Risk analysis only matters if it connects to the rest of the engineering record: requirements, hazards, and design elements upstream; mitigations, controls, and tests downstream. Because Risksheet’s rows are real work items, traceability is implemented with Polarion’s own link roles — not by copying data into the grid or maintaining a parallel reference table.

• Upstream context (functions, hazards, requirements) is loaded through link roles defined in the sheet configuration. The values shown in upstream columns are read from the linked items in real time.
• Downstream mitigations (safety requirements, controls, tests) are also linked work items, optionally created inline from the grid. Their fields can be edited through the same grid if the configuration allows.
• Cross-project links are supported wherever Polarion supports them, so shared libraries (a harms catalog, a function catalog, a requirements library) can be referenced from many risksheets without duplication.

This means an existing change-impact analysis in Polarion still works: if you trace a requirement, the risksheets that reference it appear naturally as linked work items. See Traceability and Linking for the link patterns and the configuration options that drive them.

​

Misconceptions Worth Naming

• “Risksheet has its own database.” It does not. The grid is a presentation of Polarion work items.
• “Risksheet is only for FMEA.” Risksheet is a generic risk-analysis grid that supports FMEA, HARA, TARA, STRIDE, CVSS, and other methodologies. Nextedy provides solution templates for typical methodologies across industries; the engine itself is methodology-agnostic.
• “Configuration changes affect all risksheets.” The sheet configuration is attached per document, with inheritance from templates. See Configuration Hierarchy for the resolution order.
• “Approval reviews lock a document.” Risksheet’s approval review records approval-tagged comments — it does not by itself drive Polarion’s formal document workflow states (draft to reviewed to approved). When formal state transitions are required, they remain a Polarion document-workflow action. See Review Workflows for the three review styles and their boundaries.

​

Where to Go Next

• For a higher-level positioning of the product, read What is Risksheet?.
• For the data shape behind the grid, read Data Model and Work Items.
• To put the model to work, see the How-To Guides, in particular Risk Management and Configuration Management.