Overview
| Property | Value |
|---|
| Type ID | desReq |
| Sort Order | 2 |
| Domain | Design (Design space) |
| Managed In | Design Requirements Specification documents (DRS-SYS-001, DRS-SUB-001..006) |
| ISO Standard | ISO 14971, IEC 62304, IEC 60601 |
Custom Fields
Design requirement work items use a subtype field for engineering discipline classification:
| Field ID | Display Name | Type | Enum |
|---|
subType | Sub Type | enum | designRequirement-subType |
designRequirement-subType Values
| Enum ID | Display Name | Description |
|---|
electrical | Electrical | Circuit design, power electronics, electrical safety |
labeling | Labeling | Labels, markings, instructions for use (IFU) |
mechanical | Mechanical | Physical and structural design specifications |
software | Software | Firmware, application code (IEC 62304 compliance) |
usability | Usability | Human factors and usability engineering (IEC 62366) |
The subType field is the source side of a cascade mapping to FMEA occurrence ratings (subType_-__fmOccurrence). When a design requirement subtype is selected, it filters the available occurrence values in DFMEA, enabling discipline-specific occurrence scoring.
Standard Fields
| Field | Type | Description |
|---|
title | String | Requirement statement |
description | Rich text | Detailed technical specification |
status | Enum (status) | Lifecycle state: Draft through Obsolete |
severity | Enum (severity) | General severity classification (exposed in RTM model) |
priority | Enum (priority) | Priority level (Highest through Lowest) |
Link Roles
Design requirements complete the left side of the V-Model and connect to risk controls and verification:
| Link Role | Direction | Connected Type | Purpose |
|---|
parent | Both | desReq | Hierarchical nesting (same-type only) |
refines | Forward | sysReq | Traces back to the system requirement this design requirement implements |
implements | Forward | riskControl | Risk controls implemented by this requirement |
verifies | Reverse (from testCase) | testCase | Test cases that verify this requirement |
RTM Domain Model
In the RTM domain model (rtm.yaml), DesignRequirement has a subsystem-scoped pick constraint:
| Property | Value |
|---|
| Polarion Type | desReq |
| Exposed Properties | description, severity |
| Pick Constraint | Documents of type designRequirementsSpecification where subsystem = $context.source.document.subsystem |
| Relationships | DesignRequirement --[refines]--> SystemRequirement (many-to-many) |
The $context.source.document.subsystem constraint ensures that when linking design requirements to system requirements, the picker only shows design requirements from the same subsystem as the source document. This prevents cross-subsystem contamination of traceability links.
PowerSheet Views
Design requirements appear in multiple powersheet configurations:
| Sheet | Role | Column Group |
|---|
| Whole RTM Config | Linked entity | Design Reqs (blue) via refines chain |
| Component RTM | Linked entity | Design Reqs (blue) downstream from system requirements |
| Design Verification Sheet | Root entity | Design Reqs (blue) + Verification Tests (orange) + Verification Evidence (red) |
Document Organization
Design requirements follow the same SYS/SUB pattern as system requirements:
| Document | Space | Document Type | Focus |
|---|
| DRS-SYS-001 | Design | designRequirementsSpecification | System-level design requirements |
| DRS-SUB-001..006 | Design | designRequirementsSpecification | Subsystem-level design requirements |
Related Pages
