The Problem Risksheet Solves
Risk analysis, traceability matrices, and compliance assessments share a structural pattern: a table where each row represents a structured record (a failure mode, a hazard, a requirement, a threat), each column captures a specific property (severity, occurrence, mitigation, parent function), and certain columns are computed from others (RPN = severity × occurrence × detection). Historically, organizations have solved this in two ways:- Spreadsheets (Excel, Google Sheets) — familiar and flexible, but disconnected from the rest of the engineering lifecycle. No traceability to requirements, no link to design or test artifacts, no formal review history, no enforced workflow, and frequent versioning chaos.
- Generic ALM tables — traceable and versioned, but row-oriented editing is slow, formulas are weak or non-existent, conditional formatting is limited, and hierarchical analyses (failure mode → cause → effect) become awkward.
A Methodology-Agnostic Tool
A common misconception — reinforced by demos and marketing — is that Risksheet is “for FMEA” or “for HARA”. It is not. Risksheet is a generic tool supporting any risk management methodology, including FMEA, HARA, TARA, STRIDE, and CVSS. The methodology comes from the sheet configuration: the columns you define, the formulas you write, the levels you organize, and the styling rules you apply. Because Risksheet does not constrain methodology, Nextedy ships solution templates for typical methodologies across industries:
You start from a solution template that matches your industry and methodology, then adapt the columns, formulas, and scales to your organization’s process. You do not start from a blank configuration.
The two underlying entity slots — internally called “risk” and “task” — are abstract. They can hold any two Polarion work item types. A “risk” can be a requirement; a “task” can be a test case. With this configuration Risksheet becomes a requirements traceability matrix or a V&V matrix. The name “Risksheet” reflects the most common use case, not the limit of the tool.
What Is Risk Management, Briefly?
Risk management — as practiced under ISO 14971, ISO 26262, IEC 61508, ISO/SAE 21434, and similar standards — is a structured process of identifying things that could go wrong, evaluating how bad and how likely they are, deciding what to do about them, and proving that the residual exposure is acceptable. The process is broadly the same across standards, even when the terminology differs:- Identify items, functions, hazards, threats, or failure modes that could harm safety, security, mission, or business.
- Analyze each one by assigning ratings — typically severity, occurrence/likelihood, and detectability — drawn from a defined scale.
- Score the combined risk (an RPN, ASIL, SIL, CVSS value, or qualitative classification).
- Mitigate unacceptable risks by adding controls, design changes, requirements, or tests.
- Reassess after mitigations to confirm residual risk is acceptable.
- Trace every risk to its source (function, requirement, hazard) and every mitigation to its evidence (task, test, design).
- Review and approve the analysis as a controlled, audited artifact.
RPN = S × O × D, ASIL lookup tables, CVSS calculators) live in the sheet configuration.
How Risksheet Works — The Mental Model
There are five core ideas that make Risksheet feel coherent once you see them together.1. The Grid Is a View Over Polarion Work Items
Each row in a risksheet is a Polarion work item. The work item’s type, fields, links, and permissions are defined in Polarion. The grid simply renders these as cells and lets the user edit them. When you change a cell value, Risksheet updates the work item field. When you save, Polarion writes a new revision. There is no separate store. This is the most important architectural fact: Risksheet visualizes and edits Polarion data — it does not store data separately.2. Columns Are Defined Per-Document
Each LiveDoc that uses Risksheet has its own sheet configuration describing which columns appear, what they bind to, how they are styled, and how they compute. The configuration covers:- Which Polarion field each column reads (
bindings) - The column type (enum, rating, text, number, item link, formula)
- Headers, widths, header groups
- Default sort order and saved column visibility presets (called views)
- Named formulas that calculate derived values like RPN
- Named cell decorators that apply conditional CSS styling
3. Visual Levels Group Rows by Cell Merging
In an FMEA, an “Item” can have many “Failure Modes”, and each Failure Mode can have many “Causes”. A naive grid would repeat the Item text on every row — visually noisy and error-prone. Risksheet uses levels (a configuration concept) to merge cells: when consecutive rows share the same Item value, the Item cell is merged into one tall block; when they share the same Failure Mode, that cell is merged at the next level down.
4. Formulas Compute Derived Values
Most risk methodologies involve computed values. A classic example is the Risk Priority Number:RPN = Severity × Occurrence × DetectionIn Risksheet, this is a named formula in the sheet configuration. A column references the formula and Risksheet recomputes the value when any input changes. Formulas are written in JavaScript and receive the row data; they can express anything from simple multiplication to ASIL lookup tables, CVSS calculators, or qualitative classification logic. Computed values are typically paired with cell decorators: small functions that apply CSS classes based on the value. Low RPN gets a green background; high RPN gets red. This produces the familiar “traffic light” risk view without manual cell coloring.
For regulated environments, the recommended pattern is to keep the sheet configuration declarative (column structure, references to named formulas) and externalize complex calculations — risk matrices, multi-field classifiers, conditional formatting helpers — into the top panel configuration (a Velocity template displayed above the grid). The sheet configuration then contains thin wrappers like
function(info){ return getInitialRE(info); }. This separates auditable structure from custom logic and shrinks the validation scope when matrices change.5. Traceability Is Built In
Every Risksheet row is a Polarion work item, so every Polarion link is available. Risksheet exposes this in two directions:- Upstream — a column can show a linked requirement, function, hazard library entry, or any other reference work item. Typically these columns are read-only displays of properties from the linked item.
- Downstream — separate “task” rows below a risk represent mitigations, safety requirements, controls, or test cases. They are real Polarion work items linked via a configured link role.
Common Misconceptions
Several patterns of confusion appear consistently in support discussions. Clearing them up early prevents structural mistakes.How Configuration Reaches a Document
Each LiveDoc loads a sheet configuration. The configuration can come directly from the document, or it can be inherited from a global template attached to the document. Template inheritance is what makes solution templates effective: an administrator maintains the canonical FMEA template centrally, and every new FMEA document picks up its columns, levels, formulas, and styles automatically. For deeper detail on where configuration files live, how template inheritance works, and how the three configuration files relate to each other (sheet configuration, top panel, PDF export), see:Where Risksheet Fits in the Polarion Picture
Risksheet does not replace any of Polarion’s core capabilities — it gives risk-analysis-style work the editing surface that pure work item editing lacks, while keeping the data inside Polarion.
Choosing the Right Risksheet Workflow
Summary
Risksheet is best understood as the spreadsheet experience for Polarion-tracked structured analyses — methodology-agnostic, configuration-driven, traceability-native, and grounded in real Polarion work items. Methodology (FMEA, HARA, TARA, STRIDE, CVSS, requirements traceability, V&V matrices) is a function of configuration, not a property of the tool. Solution templates ship the typical configurations so you can start from a known-good baseline and tailor it to your process rather than starting from scratch. What is constant across every Risksheet deployment is the foundation:- One LiveDoc, one risksheet, one configuration
- All data lives in Polarion work items with full permissions, history, and audit
- The grid is a view, not a separate database
- Columns, formulas, levels, and decorators are declarative in the sheet configuration
- Traceability is intrinsic — upstream and downstream links are columns, not afterthoughts
- Methodology is configurable — the same engine produces FMEA, HARA, TARA, CVSS, or a generic traceability matrix depending on how it is set up