Skip to main content

​
Overview

Design Requirements occupy the lowest level of the V-model requirements cascade—they translate Subsystem Requirements into detailed, design-phase specifications that engineering teams can implement and verify. Custom fields on Design Requirement work items support this translation by providing:
  • Classification — Categorical grouping for filtering, reporting, and PowerSheet organization
  • Sub-Type — Fine-grained requirement taxonomy distinguishing functional, interface, performance, safety, and other design requirement categories
  • Document Scoping — Automatic constraint to designRequirementsSpecification document type ensures organizational structure
  • Subsystem Binding — Reference back to parent Subsystem Requirement maintains traceability chain
Design Requirements sit at the implementation boundary. Each design requirement either:
  • Refines a parent Subsystem Requirement (upstream traceability)
  • Refined by a Characteristic or Function (downstream implementation detail)
  • Verified by one or more Verification Test Cases (V-model right-side coverage)

​
Custom Fields

​
Field Reference Table

Field NameTypeDefaultRequiredDescription
classificationEnumeration—NoCategorical designation for filtering and PowerSheet organization (e.g., functional, interface, performance, safety-related, non-functional)
subTypeEnumeration—NoFine-grained requirement type taxonomy via designRequirement-subType enumeration

​
Classification Field

Purpose: Enables sorting and filtering design requirements by their functional or organizational category. Type: Enumeration (designRequirement-classification) Typical Values:
ValueMeaningUsage
functionalSpecifies how the system/component shall behaveCore requirement for normal operation
interfaceDefines interaction boundaries with other components or external systemsProtocol, signal, data format specifications
performanceCaptures quantitative performance targets (timing, throughput, power, latency)Quality attributes and constraint requirements
safety-relatedRequirements explicitly derived from Safety Goals or risk mitigation strategiesTraces to ISO 26262 safety analysis
non-functionalBroad category: reliability, maintainability, testability, or regulatory complianceQuality and operational characteristics
Usage Example: 
Design Requirement: DREQ-042
Title: Brake actuator response time limit
Classification: performance
Description: Brake actuator shall respond to control signal within 100ms ±10ms under all operating conditions
Parent Subsystem: Braking Control Subsystem
Verification Method: Timing test in System Verification Plan
Integration with PowerSheet: The Classification field appears in the Component RTM PowerSheet and Design Verification Sheet as a read-only column. Users can configure PowerSheet views to filter or group design requirements by classification value: 
# Example: Show only safety-related and performance requirements
views:
  - name: "Safety + Performance Focus"
    hiddenColumnIds: [regularDREQs]
    # Implicit filter: classification in (safety-related, performance)
Cross-Reference Relationships:
  • Upstream: Each design requirement with classification: safety-related must trace to at least one Safety Goal through the requirements hierarchy
  • Downstream: Design requirements with classification: performance typically refine into Characteristics with explicit target values and tolerances
  • Verification: All classifications require verification test cases, but safety-related classifications trigger additional ASIL-level coverage reporting

​
SubType Field

Purpose: Provides semantic taxonomy for distinguishing different kinds of design requirements beyond classification. Type: Enumeration (designRequirement-subType) Enumeration Values:
ValueMeaningWhen to Use
functionalSpecifies system/component behavior and algorithmsCore functional transformations; state machines; data processing pipelines
interfaceDefines signals, protocols, timing, or data exchange between componentsCAN/LIN bus messages; electrical connectors; software API contracts
performanceQuantitative targets: timing, throughput, latency, power, memoryReal-time constraints; bandwidth; response time; resource utilization
safetySafety-critical requirements derived from ASIL decomposition or Safety GoalsRequirements allocated ASIL A–D; redundancy specifications; failure detection requirements
reliabilityTargets for mean time between failures (MTBF), failure rates, or fault toleranceFault injection test requirements; degraded-mode operation requirements
maintainabilityService, diagnostics, and repair specificationsOBD (On-Board Diagnostics) requirements; manual service procedures; DTC (Diagnostic Trouble Code) mappings
constraintDesign boundaries and limitations imposed by hardware, software, or external integrationMemory constraints; thermal limits; EMI/EMC restrictions
SubType Selection Decision Matrix:
QuestionIf YESSubType
Does it describe WHAT the system does?Yesfunctional
Does it describe HOW components talk to each other?Yesinterface
Does it define a numeric target or limit?Yesperformance
Is it required by ISO 26262 safety analysis?Yessafety
Does it address system failure behavior?Yesreliability
Does it address service or diagnostics?Yesmaintainability
Is it an external or hardware limitation?Yesconstraint
SubType Examples by Domain: Automotive Braking System: 
DREQ-101 | Brake Pressure Conversion
SubType: functional
Description: ECU shall convert brake pedal pressure to CAN message format per ISO 11898-1

DREQ-102 | CAN Message Format
SubType: interface
Description: Brake pressure message shall be 8 bytes, big-endian, with bytes 0–1 = pressure value × 0.1 kPa

DREQ-103 | Brake Response Time
SubType: performance
Description: Brake actuator shall respond to valid CAN message within 100ms

DREQ-104 | Fail-Safe Brake Release
SubType: safety
Description: Brake shall transition to safe state (full release) upon loss of CAN communication (ASIL B requirement)

DREQ-105 | Brake System Power Consumption
SubType: constraint
Description: Brake ECU shall consume <10W during normal operation and <2W in sleep mode
RTM Model Constraint: Design Requirements are constrained to designRequirementsSpecification document type. The RTM model query factory automatically restricts Design Requirement picks to documents matching this type: 
# From rtm.yaml
DesignRequirement:
  polarionType: desReq
  constraints:
    documentType: designRequirementsSpecification
    subsystemScoped: true  # Cross-references stay within same subsystem
PowerSheet Integration: The Design Verification Sheet and Component RTM PowerSheet display subType as a visible column in the Design Requirements section. This enables:
  1. Filtering — Users can configure views showing only safety or interface requirements
  2. Sorting — Requirements can be organized by subType for focused engineering review
  3. Coverage Analysis — Safety engineers verify that all safety subtypes have corresponding Risk Records and Risk Controls
Example PowerSheet View Configuration: 
# Design Verification Sheet excerpt
columns:
  - id: objectId
    header: ID
    formatter: boldTitle
  - id: description
    header: Description
    collapseTo: true
  - id: subType
    header: Type
    formatter: requirementSubTypeRenderer
  - id: verificationTestCases
    header: Verification Tests
    expand: true

​
Field Interactions and Traceability Patterns

The Design Requirement custom fields work together to support a complete V-model requirements flow: All Design Requirements with classification: safety-related or subType: safety must:
  1. Trace Upstream — Link to a parent Safety Goal through the requirements chain
  2. Map to ASIL — Inherit ASIL level from parent Safety Goal (typically ASIL A–D)
  3. Generate FMEA — Appear in Failure Mode analysis as assessed entities (via Characteristic or Function)
  4. Create Controls — Link to Risk Control items that mitigate identified failure modes
  5. Verify Coverage — Have one or more Verification Test Cases that validate the safety requirement is implemented
Verification Configuration: The Design Verification Sheet automatically organizes verification test cases: 
# Design Verification Sheet RTM expansion
query:
  from: DesignRequirement
constraints:
  applyCurrentDocumentTo: DesignRequirement
expand:
  - name: verificationTestCases
    expand:
      - name: verificationTestCase
        entityFactory:
          modulePath: "Testing/DesignVerificationSpecification"

​
Performance and Interface Requirements Path

Design Requirements with subType: performance or subType: interface:
  • Typically Refined by Characteristics with measurable target values and tolerances
  • Appear in Component Characteristics Sheet PowerSheet for target/tolerance specification and FMEA linkage
  • Are Verified by test cases that validate numerical targets or protocol compliance
Example – Performance Requirement Flow: 
DREQ-103 (performance): "Brake response time ≤ 100ms"
    ↓ refined by
CHAR-015: Brake Actuator Response Time
    targetValue: 100ms
    tolerance: ±10ms
    ↓ assessed by (FMEA)
FMEA-042: Delayed brake actuation (100ms timeout)
    ↓ mitigated by
RISKCTRL-018: Add watchdog timer; verify response time in integration tests
    ↓ verified by
DVTEST-081: Integration Test: Brake Response Time Under Load

​
Document Type Constraint

All Design Requirements are constrained to the designRequirementsSpecification document type. This constraint:
  • Enforces Organization — Ensures design requirements live in appropriate DRS documents, preventing accidental creation in other modules
  • Enables Scoping — PowerSheet queries filter to only show design requirements from the current document (or related subsystem documents in cross-document views)
  • Supports Modular Development — Large projects can partition design requirements across multiple DRS documents (one per subsystem or component) while maintaining clear ownership
# RTM Model: Design Requirement entity constraint (from rtm.yaml)
DesignRequirement:
  polarionType: desReq
  constraints:
    documentType: designRequirementsSpecification
    subsystemScoped: true
Document Folder Structure Example:
  • Requirements/
    • CUSTOMER-REQS/ — Customer Requirements
    • systemRequirementsSpecification/ — System Requirements
      • SRS-Braking.module
    • subsystemRequirementsSpecification/ — Subsystem Requirements
      • SUBRS-BrakeControl.module
      • SUBRS-BrakePower.module
    • designRequirementsSpecification/ — Design Requirements
      • DRS-BrakeControl.module
      • DRS-BrakePower.module

​
Version and Standards Compliance

StandardVersionRelevant Sections
ISO 26262Part 1, Part 3, Part 4Requirements decomposition, ASIL allocation, traceability verification
IATF 169492016Engineering change management, design FMEA traceability to production control plans
AIAG-VDA FMEA2019Design FMEA integration; system/subsystem/component decomposition
Design Requirement fields align with the V-model methodology described in V-Model Methodology and support ISO 26262 requirements traceability per Traceability Model.