Understanding this chain is essential because ISO 14971 and IEC 62304 auditors trace individual requirements through design, risk analysis, and testing to confirm that each risk control is implemented, verified, and validated.
The V-Shape
The V-Model has two sides. The left side decomposes what the device must do. The right side proves that each level was built correctly.
Left Side — Requirements Decomposition
The left side of the V defines a three-level requirements hierarchy. Each level adds specificity.
| Level | Work Item Type | Count | Scoping |
|---|
| Top | User Need (userNeed) | 30 | Scoped to Requirements/UserNeedSpecification document |
| Middle | System Requirement (sysReq) | 153 | Scoped by document type systemRequirementsSpecification |
| Bottom | Design Requirement (desReq) | 157 | Scoped by document type designRequirementsSpecification + subsystem constraint |
refines link role connects each level. System requirements refine user needs. Design requirements refine system requirements. Both use many-to-many cardinality, so a single user need can be refined by multiple system requirements, and a design requirement can trace to multiple system requirements.
Design requirements are constrained to the same subsystem as the system requirement they refine. The RTM model uses a $context.source.document.subsystem constraint so the picker only shows design requirements from the matching subsystem document.
Right Side — Verification and Validation
The right side proves that each requirement level was satisfied. Two distinct link roles enforce the ISO 14971 V&V distinction:
validates — Test cases validate user needs (confirming the device meets stakeholder expectations)verifies — Test cases verify system and design requirements (confirming the implementation matches the specification)
| Test Level | Link Role | Target | Test Cases |
|---|
| User Need Validation | validates | User Need | 19 |
| System Verification | verifies | System Requirement | 82 |
| Design Verification | verifies | Design Requirement | 47 |
validates and verifies is not cosmetic. ISO 14971 treats validation (does the device meet the user’s actual need?) and verification (does the implementation match the spec?) as fundamentally different activities.
Parallel Traceability Paths
Beyond the primary requirements chain, two parallel paths support use analysis and process analysis:
| Path | From | Link Role | To |
|---|
| Use analysis | Use Step (useStep) | address | User Need |
| Process analysis | Process Step (processStep) | associates | System Element |
Risk Analysis Overlay
Risk analysis connects to the traceability chain at multiple points:
- Risk records assess use steps and link to hazards and harms
- Risk controls mitigate risk records (and failure modes)
- Requirements implement risk controls — system and design requirements carry the
implements link to risk controls
This creates a closed loop: a user need generates requirements, requirements are analyzed for risk, risk controls are defined, and those controls are implemented back into requirements that are then verified by test cases.
Link Storage
All traceability relationships are stored as native Polarion linkedWorkItems. No custom fields or external databases are used. This means standard Polarion traceability reports, impact analysis, and suspect link detection work out of the box.
The RTM domain model defines 8 entity types and 8 relationships that together form the complete V-shaped graph. For the full relationship table, see Link Roles and Traceability Relationships.
Related Pages
