The Big Picture
The data model is organized around four domains that correspond to the product development lifecycle:
Work Item Types by Domain
Requirements Domain
These types capture what the product must do, from stakeholder needs down to system-level specifications.
| Type ID | Label | Description | Custom Fields |
|---|
userNeed | User Need | Customer, business, or stakeholder need the product must fulfill. Top of the requirements hierarchy. | severity, outlineNumber, description |
useStep | Use Step | Operational scenario during which hazards are analyzed in HARA. Addresses user needs. | outlineNumber, description |
sysReq | System Requirement | What the system must do to satisfy user needs and regulatory constraints. | severity, outlineNumber, description |
systemElement | System Element | Physical or logical component of the product. Classified by type hierarchy (system/subsystem/assembly/subassembly/component). | elementType |
Design Domain
These types capture how the product achieves its requirements through technical design.
| Type ID | Label | Description | Custom Fields |
|---|
desReq | Design Requirement | Technical or implementation-level requirement derived from system requirements. Scoped by subsystem. | severity, subType (electrical/labeling/mechanical/software/usability) |
function | Function | What a system element is intended to do — the operational capability assessed by failure modes in DFMEA. | — |
Risk Domain
These types implement the dual risk analysis methodology (HARA + DFMEA).
| Type ID | Label | Description | Key Custom Fields |
|---|
hazard | Hazard | Potential source of harm (energy, motion, software malfunction). Organized in 4-level IEC 60601 taxonomy. | Hazard taxonomy (L1-L4 cascading enums) |
harm | Harm | Specific injury, damage, or adverse effect. Carries severity value for risk matrix calculations. | severity (1-5) |
riskRecord | Risk Record | Single HARA entry combining hazard, use step, harm, and pre/post-mitigation probability fields. Central ISO 14971 entity. | preHazardProbability, preHarmProbability, preRisk, postRisk, benefit, finalRisk (13 custom fields total) |
failureMode | Failure Mode | How a function can fail. Central DFMEA entity with S x O x D = RPN scoring. | failureMode, fmSeverity, premitigationRPN, postmitigationRPN (12 custom fields total) |
riskControl | Risk Control | Measure to reduce risk, classified by the ISO 14971 three-tier hierarchy. | riskControlType (multi-enum) |
cause | Cause | Underlying reason or mechanism producing a failure mode. Can be shared across multiple failures. | — |
Testing Domain
| Type ID | Label | Description |
|---|
testCase | Test Case | Verifies system/design requirements or validates user needs. Three link roles: verifies (system req, design req), validates (user need). |
Process and Change Management
| Type ID | Label | Description |
|---|
processStep | Process Step | Manufacturing/process step for PFMEA with inputs, outputs, equipment, and verification fields. |
task | Task | Engineering or process action to reduce risk. Links to requirements and risk controls via implements. |
changeRequest | Change Request | Formal change request tracking modifications to design, process, or requirements. |
defect | Defect | Confirmed deviation or nonconformance discovered during verification or validation. |
Link Roles: The Traceability Graph
The 18 link roles create a directed graph with strict type constraints. No link can be created between incompatible work item types.
V-Model Traceability Links
| Role | Direction | Purpose |
|---|
refines | sysReq > userNeed; desReq > sysReq | Requirements decomposition |
verifies | testCase > sysReq, desReq | Requirement verification |
validates | testCase > userNeed | User need validation |
address | useStep > userNeed | Use step to need mapping |
Risk Analysis Links
| Role | Direction | Purpose |
|---|
hasHazard | riskRecord > hazard | Risk-to-hazard association |
hasHarm | riskRecord > harm | Risk-to-harm association |
hasCause | riskRecord/failureMode > cause | Root cause identification |
assesses | failureMode/riskRecord > function, systemElement, useStep, processStep | What is being analyzed |
analyzedIn | failureMode > riskRecord | DFMEA-to-HARA cross-reference |
mitigates | task/riskControl > failureMode, riskRecord | Risk reduction measures |
Structural and Implementation Links
| Role | Direction | Purpose |
|---|
parent | Same type only | Hierarchical nesting (sameType enforced) |
allocatedTo | function/failureMode/riskRecord/processStep > systemElement | Component allocation |
implements | task > sysReq, desReq, riskControl; sysReq/desReq > riskControl | Implementation traceability |
Change Management Links
| Role | Direction | Purpose |
|---|
detectedBy | defect > testCase | Defect discovery |
tracks | changeRequest > sysReq, desReq, riskRecord, failureMode, task, defect | Change tracking |
followsUp | task > defect, task, changeRequest | Follow-up actions |
Key Architectural Decisions
Read-Only Enforcement
Risk records and failure modes are configured as fully read-only in the standard Polarion work item form (all fields set to read-only in _default status). This forces all editing through Nextedy Risksheet, ensuring formula consistency and audit trail integrity.
Subsystem-Scoped Picking
The RTM domain model constrains design requirement picking to documents where the subsystem matches the source document’s subsystem ($context.source.document.subsystem). This prevents cross-subsystem pollution when linking design requirements to system requirements.
User Needs use folder+name constraints (Requirements/UserNeedSpecification), while System and Design Requirements use document type constraints. Two different scoping strategies coexist in the same model.
Native Polarion Links
All relationships use Polarion’s built-in linkedWorkItems storage. No custom fields or external databases store traceability data. This means all links are visible in standard Polarion reports, baselines, and exports.
Shared ID Sequence
All 16 work item types share a single tracker prefix (RTM). A user need might be RTM-5 while the next risk record is RTM-6. This is a consequence of Polarion’s single-sequence-per-project architecture.
