Skip to main content

​
Overview

Design Requirement Subtype values organize implementable design specifications across the five primary engineering disciplines in automotive safety systems. Each subtype carries distinct traceability implications:
  • Electrical — Requirements for electrical systems, circuits, and embedded control electronics
  • Mechanical — Requirements for mechanical design, structural integrity, and physical assemblies
  • Software — Requirements for embedded firmware, middleware, and application software
  • Labeling — Requirements for product labeling, warnings, symbols, and regulatory markings
  • Usability — Requirements for human-machine interface, ergonomics, and operator interaction

​
Enumeration Values

SubtypeIDDisplay NameColorSort OrderDescription
electricalEElectrical#1976d2 (blue)1Electrical and embedded control system requirements
mechanicalMMechanical#388e3c (green)2Mechanical design and structural requirements
softwareSSoftware#f57c00 (orange)3Embedded firmware and application software requirements
labelingLLabeling#d32f2f (red)4Product labeling, warnings, and regulatory markings
usabilityUUsability#7b1fa2 (purple)5Human-machine interface and operator ergonomics requirements

​
Usage Context

​
Work Item Type Mapping

The subType property is a custom field on Design Requirement work items (Polarion type: desReq). 
<!-- From: .polarion/tracker/fields/desReq-custom-fields.xml -->
<field>
  <name>subType</name>
  <type>enum</type>
  <required>false</required>
  <multivalue>false</multivalue>
  <enumId>designRequirement-subType</enumId>
  <display>Design Requirement Subtype</display>
</field>

​
PowerSheet Column Representation

The Design Requirement Subtype appears in three PowerSheet configurations:
ConfigurationColumn GroupPurpose
Whole RTM ConfigDesign RequirementsShows subtype for each design requirement in the four-level V-model decomposition
Component RTMDesign RequirementsDisplays subtype when viewing subsystem → design requirement refinement
Design Verification SheetDesign RequirementsFilters and groups design requirements by subtype before linking to verification tests
Example from Component RTM configuration: 
columns:
  - id: designRequirementSubType
    header: Type
    width: 120
    displayAs: enumValue
    renderer: "() => { const subtypes = {electrical: '⚡', mechanical: '⚙️', software: '💻', labeling: '🏷️', usability: '👤'}; return subtypes[context.value] + ' ' + context.value; }"

​
Discipline-Specific Guidance

​
!!! tip “Use Subtype to Organize Cross-Functional Teams”

Subtype filtering enables parallel development across engineering disciplines. Safety engineers can view only safety-critical design requirements (typically Software and Electrical), while mechanical teams focus on their own constraints.

​
Electrical Design Requirements

When to use: Control logic, ECU firmware interfaces, sensor/actuator drivers, power distribution, and electrical safety functions. Traceability expectations:
  • Must link upstream to System Requirements or Safety Goals defining the electrical function
  • Must link downstream to Verification Test Cases verifying electrical behavior (circuit tests, software unit tests)
  • May require ASIL propagation if implementing safety-critical functions
  • Often involve SC (Safety Critical) classification under ISO 26262
Example: 
DRS-E-042: Motor Control ECU shall implement field-weakening algorithm 
           per ISO 26262 ASIL B requirements, with watchdog timer 
           monitoring and safe-state transition on fault detection.
Classification: SC (Safety Critical)
Upstream: SYS-CTRL-015 (Motor Speed Control Function)
Downstream: VER-EC-042 (ECU Watchdog Timer Test)

​
Mechanical Design Requirements

When to use: Structural design, material specifications, dimensional tolerances, assembly constraints, and mechanical safety features. Traceability expectations:
  • Link to System Requirements for mechanical system performance
  • Link to Characteristics for dimensional and tolerance specifications
  • Connect to PFMEA (Process FMEA) for manufacturing and assembly control
  • May affect HARA severity if mechanical failure modes impact safety
Example: 
DRS-M-087: Pressure vessel wall thickness shall be 3.5 ± 0.2 mm, 
           material 316L stainless steel, tensile strength ≥ 520 MPa.
Classification: CC (Conformance Critical)
Upstream: SYS-STRUCT-031 (Pressure Containment Requirement)
Downstream: CHAR-THICK-087 (Wall Thickness Characteristic)

​
Software Design Requirements

When to use: Firmware algorithms, middleware interfaces, real-time scheduling, embedded database schemas, and application-level functional requirements. Traceability expectations:
  • HIGHEST priority for ISO 26262 compliance — software design requirements typically carry highest ASIL levels
  • Must link to Safety Goals for safety-critical functions
  • Must link to comprehensive Verification Test Cases (unit tests, integration tests, system tests)
  • Often appear in both DFMEA (Design FMEA) and PFMEA contexts
  • Require strict change control due to verification impact
Example: 
DRS-S-156: Kalman filter state update shall complete within 5 ms, 
           with numerical stability ensured via double-precision IEEE 754 
           arithmetic and condition number monitoring per ISO 26262 ASIL D.
Classification: SC (Safety Critical)
ASIL: D
Upstream: SG-ESTIMATION-012 (Safety Goal: Accurate State Estimation)
Downstream: VER-KFILTER-UNIT (Kalman Filter Unit Test Suite)
            VER-KFILTER-INTEGRATION (Integration Test)

​
Labeling Design Requirements

When to use: Safety warnings, regulatory markings, operator documentation, and in-vehicle display messages. Traceability expectations:
  • Link to hazards identified in HARA (Hazard Analysis and Risk Assessment) that require operator mitigation
  • Link to Information-for-Safety control types per ISO 26262 framework
  • Connect to validation evidence (proof of instruction effectiveness)
  • May reference ISO 26262 Clause 5.4 (Functional Safety Concept) and Clause 7.4.10 (ISO 6310 warning symbols)
Example: 
DRS-L-203: Warning label "⚠️ HIGH VOLTAGE" shall appear in yellow/black, 
           ≥ 25 mm height, affixed within 50 mm of battery terminals 
           per ISO 26262-5 Clause 7.4.10.
Classification: SC (Safety Critical)
Upstream: HAZARD-PWR-087 (Electrical Shock Hazard)
           SG-OPERATOR-AWARENESS-015 (Operator shall be aware of voltage hazard)
Downstream: VAL-LABEL-INSPECTION-203 (Inspection Procedure Validation)

​
Usability Design Requirements

When to use: Human factors, operator interfaces, error prevention, and misuse scenario mitigation. Traceability expectations:
  • Link to use cases and operational scenarios from HARA
  • Connect to SOTIF (Safety of the Intended Functionality, ISO 21448) hazard mitigations
  • Link to validation test cases assessing human factors
  • Often involve Controllability assessment from HARA (operator’s ability to manage failure modes)
Example: 
DRS-U-418: Emergency stop button shall be red, ≥ 40 mm diameter, 
           located ≤ 300 mm from operator's normal hand position, 
           require ≥ 3 N activation force to prevent accidental activation.
Classification: SC (Safety Critical)
Upstream: HARA-ACCIDENTAL-STOP-067 (Hazard: Unintended System Shutdown)
Downstream: VAL-ERGONOMICS-BUTTON-418 (Usability Testing with Test Operators)

​
Filtering and Querying

​
PowerSheet Filtering

To filter design requirements by subtype in a PowerSheet view: 
# Design Verification Sheet — Software requirements only view
views:
  - name: Software Design Requirements
    query:
      from: DesignRequirement
      filter: "subType == 'software'"
    expand:
      - name: verificationTestCases
        expand:
          - name: verificationTestCase

​
Lucene Query Syntax

Query design requirements by subtype in Polarion search: 
type:desReq AND subType:"electrical"
type:desReq AND subType:"software" AND classification:"sc"
type:desReq AND subType:"mechanical" AND priority:"high"

​
Visual Decision Matrix

The following matrix shows which subtypes typically require SC/CC classification and ASIL propagation in automotive safety systems:
SubtypeTypical ClassASIL PropagationVerification Complexity
ElectricalSC/CCHIGHVERY HIGH
SoftwareSC/CCVERY HIGHVERY HIGH
MechanicalCC/QMMEDIUMMEDIUM
LabelingSC/CCLOWLOW-MEDIUM
UsabilityCC/QMLOWMEDIUM
Design requirements marked as software typically carry the highest ASIL ratings and require:
  • Exhaustive verification test coverage (unit + integration + system levels)
  • Formal traceability linkage to Safety Goals
  • Code review and static analysis evidence
  • Runtime monitoring and diagnostics verification

​
Integration with RTM Domain Model

Design Requirement Subtype appears in the RTM domain model as a refinement-level property: 
# From: .polarion/nextedy/models/rtm.yaml
DesignRequirement:
  polarionType: desReq
  properties:
    - name: description
      type: text
    - name: classification
      type: enum (sc|cc|qm)
    - name: subType
      type: enum (electrical|mechanical|software|labeling|usability)
  constraints:
    documentType: designRequirementsSpecification
    subsystemScoping: true
  relationships:
    - refines: SubsystemRequirement (many-to-one)
    - verifiedBy: VerificationTestCase (many-to-many)
    - assessedBy: FailureMode (many-to-many, DFMEA context)

​
Relationship to Other Work Item Types

Design Requirement Subtype interacts with:
Work Item TypeRelationshipPurpose
System RequirementUpstream traceability via refines link roleEnsure design requirements implement system-level requirements
Subsystem RequirementUpstream traceability via refines link roleEnsure design requirements decompose subsystem requirements
Verification Test CaseDownstream via verifies link roleDesign requirements must have verification test coverage
Failure ModeDFMEA assessment via assessedBy link roleDesign requirements enter failure mode analysis
CharacteristicRelated via measurement propertiesDesign requirements may define measurable characteristics
Safety GoalUpstream for SC requirementsSafety-critical design requirements trace to safety goals

​
Configuration Properties

The Design Requirement Subtype enumeration is defined in: File: .polarion/tracker/fields/designRequirement-subType-enum.xml Configuration Properties:
PropertyValueDescription
enumIddesignRequirement-subTypeUnique identifier for this enumeration
nameDesign Requirement SubtypeHuman-readable name
multiValuefalseSingle value per design requirement (not multi-select)
requiredfalseOptional field; may be left blank if discipline unknown
orderedtrueValues have defined sort order (1-5)
customtrueCustom field (not a Polarion standard)

​
See Also