Overview
Design Requirements occupy a critical position in the ISO 26262 V-model:
Each Design Requirement must:
- Refine exactly one parent Subsystem Requirement (establish upstream traceability)
- Be verified by one or more Design Verification Test Cases (establish downstream traceability)
- Specify implementation constraints, tolerances, or interfaces
- Support IATF SC/CC classification for special characteristics requiring control
Design Requirements are the bridge between what the system must do (Subsystem Requirements) and how to build it (design and implementation). They constrain design choices while remaining independent of specific implementation technologies.
Properties Reference
Core Properties
| Property | Type | Default | Description |
|---|
| ID | String (read-only) | Auto-generated | Unique identifier assigned by Polarion (e.g., DRS-00456). Stable reference for traceability. |
| Title | String | required | Short design requirement name (e.g., “CAN Bus Message Timeout”). Used in RTM reports and traceability matrices. |
| Description | Rich Text | required | Detailed requirement specification including design constraints, acceptance criteria, and rationale. Supports 50,000+ characters for complex requirements. |
| Status | Enumeration | draft | Current requirement status: draft, review, approved, implemented, verified, archived. Controls workflow transitions. |
| Outline Number | String (auto) | Auto-formatted | Hierarchical numbering within requirement document (e.g., 3.2.1.4). Updated automatically as requirements are moved/reordered. |
Classification and Typing
| Property | Type | Default | Description |
|---|
| classification | Enumeration | none | IATF 16949/APQP classification: sc (Special Characteristic) or cc (Cybersecurity Critical). Indicates requirements that require enhanced control and traceability to FMEA/Control Plan. |
| subType | Enumeration | functional | Design requirement category: functional, interface, performance, safety, electrical, mechanical, software, labeling, usability. Controls traceability expectations and PowerSheet filtering. |
Design Requirements classified as sc or cc must:
- Link to Characteristics work items via the
refines relationship
- Have Characteristics linked to Failure Modes in component-level DFMEA
- Be included in Control Plan items for manufacturing inspection/testing
- Appear in regulatory deliverables (IATF PPAP, ISO 26262 Part 8 traceability records)
Traceability Relationships
Upstream Links (Refined By)
Every Design Requirement must establish exactly one refines link to a parent Subsystem Requirement:
Coverage Check: Design requirements without an upstream refines link are treated as unallocated and flagged in traceability gap reports.
Link Role: refines (directional: child → parent)
Example Path:
- Customer Req: “System shall detect obstacles within 100m”
- refines to:
- System Req: “Sensor fusion shall achieve 100m detection range”
- refines to:
- Subsystem Req: “Camera module 50m, Radar module 100m”
- refines to:
- Design Req: “Radar PCB shall implement 10GHz transceiver with 3dB gain”
Downstream Links (Verified By)
Design Requirements are verified through Design Verification Test Cases. One-to-many relationship:
Coverage Check: Design requirements without at least one back-linked test case are marked “unverified” in verification coverage reports.
Link Role: verifies (directional: test → requirement)
Optional Cross-Linking
Design Requirements may also link to:
- Characteristics (via
refines) — SC/CC design requirements should link to measured characteristics used in Control Plans
- Failure Modes (via
assesses) — Software/safety design requirements sometimes directly map to DFMEA failure mode scenarios
- Safety Goals — Design requirements implementing safety mechanisms trace back to safety goals via intermediate characteristics
SubType Enumeration
The subType field categorizes design requirements by engineering discipline and purpose:
| SubType | Usage | Standards Context | Example |
|---|
functional | Behavioral or operational requirements specifying what the system does | ISO 26262, AIAG-VDA FMEA | ”ECU shall execute obstacle detection algorithm every 50ms” |
interface | Interface protocols, data formats, or signal definitions between system elements | IATF 16949 (interface control) | “CAN message shall comply with DBC schema version 2.1” |
performance | Timing, throughput, latency, or resource constraints | ISO 26262 (ASIL-dependent timing) | “Braking response latency shall not exceed 150ms” |
safety | Requirements derived from safety goals and ASIL allocations | ISO 26262 Part 4 | ”Dual-channel redundancy shall be maintained for all safety-critical signals” |
electrical | Electrical/power/signal integrity requirements | IATF 16949, automotive standards | ”Supply voltage tolerance ±5% at all operating modes” |
mechanical | Physical dimensions, materials, vibration, thermal constraints | IATF 16949 (design FMEA) | “Housing material shall withstand -40°C to +85°C temperature range” |
software | Embedded software, firmware, algorithm, or code requirements | ISO 26262 Part 6 | ”Sensor fusion algorithm shall use Kalman filter with Q-matrix tuning per ISO 26262” |
labeling | Markings, warnings, documentation, or regulatory labeling | ISO 26262 Part 2 (labeling), IATF PPAP | ”All safety-critical components shall bear ISO 26262 ASIL D label” |
usability | Human-machine interface, ergonomics, or operator experience | SOTIF (ISO 21448), customer requirements | ”Warning lamp shall illuminate within 200ms of fault detection” |
- Functional requirements map 1:1 to test cases
- Performance requirements require measurement/timing test cases
- Safety requirements often require multi-case verification (nominal + failure scenarios)
- Electrical/Mechanical requirements may verify through design review or supplier test data
- Software requirements require code-level unit/integration testing
Design Requirements in PowerSheet
Design Requirements appear in two PowerSheet configurations:
1. Component RTM PowerSheet
The Component RTM sheet displays design requirements in a two-tier hierarchy:
Left Group (Subsystem Requirements) Right Group (Design Requirements)
─────────────────────────────────────────────────────────────────────────
SubRS-001: Sensor data fusion DRS-001: Radar signal processing
Linked to System Req Linked to Test Case #1, #2, #3
DRS-002: Camera calibration
DRS-003: CAN interface driver
SubRS-002: Safety monitoring DRS-004: Watchdog timer logic
DRS-005: Health monitoring
- Subsystem Requirements (teal, left) — Parent requirements with system-level links
- Design Requirements (blue, right) — Child requirements nested below parent, with type and document location
- System Requirements Upward (green header) — Backward traceability showing parent system requirement
Interactive Features:
- Click DRS ID to open work item editor
- Expand/collapse design requirement groups
- Filter by subType using PowerSheet column filters
- Sort by status, classification, or document
2. Design Verification Sheet
Displays design requirements alongside linked test cases:
Design Requirement ID Description Verification Status Linked Test Cases
DRS-001 Radar signal process ✓ Verified DT-0047, DT-0051, DT-0055
DRS-002 Camera calibration ⚠ Partial DT-0082
DRS-003 CAN interface driver ✗ Unverified (none)
Document Type Constraint
Design Requirements are constrained to documents of type designRequirementsSpecification:
| Setting | Value |
|---|
| Document Type | designRequirementsSpecification |
| Space | Requirements (typically; may vary by project structure) |
| Parent | Subsystem Requirements Specification document |
| Version Control | Polarion document history + SVN |
Design Requirements Specification - [Subsystem/Component Name]
Example: "Design Requirements Specification - CAN Transceiver Module"
Classification Reference
SC/CC Classification
Design Requirements may be classified as Special Characteristics (sc) or Cybersecurity Critical (cc):
| Classification | Meaning | Traceability Requirement | Control Requirement |
|---|
sc | Special Characteristic per IATF 16949 PPAP | Must link to Characteristic via refines link | Must appear in Control Plan (PFMEA) with measurement method and sampling |
cc | Cybersecurity-Critical per ISO 21448 SOTIF or internal security policy | Should trace to Risk Controls or Safety Goals | Security design review + threat analysis documentation |
| (none) | General design requirement | Normal V-model traceability via refines and verifies | No special control requirement |
- SC design requirements → Characteristics → Control Plan inspection/test procedures
- CC design requirements → Security test cases, penetration testing, threat modeling
Custom Fields
Design Requirement work items may include the following custom fields depending on project configuration:
| Field Name | Type | Purpose |
|---|
requirementType | Enum | Maps to subType enumeration; used in PowerSheet grouping |
allocatedASIL | Enum | ASIL level inherited from parent Safety Goal (if safety-related) |
verificationMethod | String | Indicates how requirement is verified: “Test”, “Review”, “Analysis”, “Demo”, “Supplier Data” |
implementationNotes | Text | Design team notes on implementation strategy or constraints |
trackedInChangeControl | Boolean | Whether requirement is under formal change control board process |
.polarion/documents/fields/custom-fields.xml) for the complete list.
Workflow States
Design Requirements follow the standard document workflow:
| State | Transition | Purpose |
|---|
draft | Create new requirement | Initial state; allows free editing |
review | Submit for review | Requires approval before implementation |
approved | Approve after review | Formal baseline; change control triggered |
implemented | Mark when coding begins | Indicates design/implementation in progress |
verified | Complete after test verification | All linked test cases passed |
archived | Move to historical records | Obsolete or superseded by new requirement |
draft state can be freely edited.
Example: Design Requirement Creation
Parent Subsystem Requirement:
SubRS-042: "Radar module shall detect obstacles at ranges 0-100m
with ≤2m range accuracy across ambient temperature -40°C to +85°C"
| Req ID | SubType | Title | Description |
|---|
| DRS-089 | electrical | Radar RF Frontend Gain | ”RF front-end gain shall be tunable 0-30dB with 1dB step resolution to maintain constant signal level across 0-100m detection range per TX power budget analysis” |
| DRS-090 | performance | Radar Signal Processing Timing | ”Doppler velocity calculation and range filtering shall complete within 45ms per frame rate requirement; thermal simulation shows 50°C junction temperature with worst-case processing load” |
| DRS-091 | interface | CAN Bus Message Format | ”Radar module shall transmit detected obstacles via CAN 2.0B extended ID 0x123 with payload: [range(16b), velocity(16b), confidence(8b), reserved(8b)] every 50ms ±5% jitter per ISO 11898-2” |
| DRS-092 | mechanical | Thermal Dissipation Housing | ”LTCC substrate thermal conductivity ≥8 W/mK; solder reflow peak ≤245°C per IPC-A-610; derating curve shows -3dB/°C sensitivity above 60°C” — SC Classification |
| DRS-093 | safety | Watchdog Timeout Mitigation | ”Dual-channel watchdog timers (primary + redundant) shall monitor CPU health every 10ms; timeout trigger shall force safe state (zero braking command) per ASIL B requirement” |
- Refines SubRS-042 (upstream traceability)
- Will be verified by component DFMEA (DRS-089, -090, -091, -093) or Design Verification test case (DRS-090, -091, -092, -093)
- If SC-classified (DRS-092), links to Characteristic work item for Control Plan inclusion
Linking Pattern
Establishing Design Requirement Traceability:
# 1. Create Design Requirement in designRequirementsSpecification document
# ID: DRS-123
# Title: "CAN Transceiver Slew Rate"
# Subtype: electrical
# 2. Create upstream link to parent Subsystem Requirement
DRS-123 --refines--> SubRS-042
# 3. Create or link to Design Verification Test Case
DT-0156 --verifies--> DRS-123
# 4. If SC-classified: link to Characteristic
DRS-123 --classification: sc
DRS-123 --refines--> CHAR-0234 (CAN Bus Slew Rate Measurement)
# 5. In Risksheet: component-level DFMEA links failure modes to characteristics
# FM-0456 (CAN signal reflections) --assesses--> CHAR-0234
Cross-References
