Skip to main content

Overview

Design requirements bridge the gap between what the system must do (system requirements) and how individual components achieve those behaviors. In aerospace development, they are subject to strict traceability rules under DO-178C (software), DO-254 (hardware), and ARP 4754A (system development assurance). Each design requirement is classified for safety criticality (SC/CC) and linked to DO-160G environmental categories when environmental qualification is required. The classification flows down from parent system requirements and determines verification strategy, evidence requirements, and certification scope.
This reference covers the core desReq type structure and custom fields as defined in the Aerospace Safety Solution RTM model. Implementation-level details should be verified in your Polarion project configuration.

Entity Identity

AttributeValue
Polarion TypedesReq
Document TypedesignRequirementsSpecification
Module Naming PatternDRS-CMP-* (e.g., DRS-CMP-001, DRS-CMP-002)
Outline NumberingYes (hierarchical numbering within document)
Sort Order2 (after customerRequirement=0, sysReq=1)

Custom Fields

Design requirements carry three custom fields that control engineering discipline classification, safety properties, and verification strategy.

Classification (SC/CC)

PropertyValue
Field Nameclassification
TypeEnumeration
ValuesSC (Safety-Critical), CC (Configuration-Control)
Default(none)
MandatoryConditionally — derived from parent requirement
ScopeSafety classification flows from parent system requirement. All desReq under an SC sysReq should be SC; under a CC sysReq, should be CC.
The Classification Consistency Report verifies this alignment. SC requirements receive higher scrutiny in design reviews, testing, and configuration management.

Discipline Subtype

PropertyValue
Field NamesubType
TypeEnumeration
ValuesElectrical, Labeling, Mechanical, Software, Useability
Default(none)
MandatoryNo
ScopeFilters design requirements by engineering discipline for DO-178C (Software) vs DO-254 (Hardware) compliance paths.
Subtype enables traceability segregation: Software design requirements are verified through code inspection, unit testing, and integration testing per DO-178C; Hardware design requirements use design analysis, inspection, and environmental qualification per DO-254.

Environmental Qualification Category

PropertyValue
Field NameenvironmentalCategory
TypeEnumeration
Valuessec4 (Temperature/Altitude), sec5 (Temperature Variation), sec6 (Humidity), sec7 (Altitude), sec8 (Shock), sec9 (Vibration), sec10 (Explosion), sec11 (Water), sec12 (Fluids), sec13 (Sand), sec14 (Fungus), sec15 (Salt), sec16 (Magnetic), sec17 (Power), sec18 (Voltage Spike), sec19 (Conducted Susceptibility), sec20 (Signal Susceptibility), sec21 (RF Susceptibility), sec22 (RF Emission), sec23 (Lightning Transients), sec24 (Lightning Direct), sec25 (Icing), sec26 (ESD), sec27 (Fire/Smoke)
Default(none)
MandatoryNo
ScopeLinks design requirements to DO-160G Environmental Conditions for Test Category. When set, corresponding environmental test cases must be specified.
The DO-160G Environmental Qualification PowerSheet uses this field to expand design requirements into their corresponding environmental specifications (characteristics) and qualification tests.

Standard Fields

Beyond custom fields, design requirements inherit standard Polarion properties:
FieldTypePurpose
IDString (auto)Unique requirement identifier within document (e.g., DRS-CMP-001)
TitleString (required)Requirement statement in imperative mood (e.g., “Power supply shall operate within 5-28 VDC”)
DescriptionText/HTMLDetailed specification, rationale, acceptance criteria
StatusWorkflow Statedraft → review → approved → obsolete
AuthorUserOriginal author (set at creation)
OwnerUserResponsible engineer
PriorityEnumHigh/Medium/Low (optional)
SeverityEnumOptional severity for compliance tracking

Relationships and Traceability

Design requirements participate in four core traceability roles: diagram Design requirements refine (decompose) a parent system or subsystem requirement.
RoleFromToCardinality
refinesdesReqsysReq or subsystemReq1:many (each desReq refines exactly 1 sysReq)
Example: System Requirement SYS-001 “Flight control surfaces shall respond to pilot input within 500ms” is refined by three design requirements:
  • DRS-CMP-001: “Main Flight Processor shall complete sensor polling within 100ms”
  • DRS-CMP-002: “Actuator command transmission shall complete within 200ms”
  • DRS-CMP-003: “Built-in test shall verify response time every flight cycle”
Design requirements are verified by test cases.
RoleFromToCardinality
verifiestestCasedesReqmany:1 (each testCase verifies 1+ desReq)
Each design requirement must have at least one linked test case. The Design Verification Sheet PowerSheet expands this relationship for management. Hardware design requirements may be assessed (analyzed for failure modes) by characteristics.
RoleFromToCardinality
assessesfailureModecharacteristicmany:1 (DFMEA failure modes assess characteristics)
Indirect relationship: A design requirement linked to a characteristic is implicitly assessed by failure modes targeting that characteristic in the component DFMEA. Design requirements may reference configuration items (CIs) during design verification.
RoleFromToCardinality
linksdesReqconfigurationItemmany:many (optional)

Context-Aware Filtering

Design requirements support document-scoped filtering to improve data quality in multi-subsystem projects.

Subsystem Constraint

When a design requirements document is linked to a specific system element (subsystem or component), the requirement picker applies a context-aware constraint:
  • Allowed Parent: Only system/subsystem requirements for the current subsystem context
  • Purpose: Prevents accidental linking to requirements from other subsystems
  • Implementation: Picker configuration uses applyCurrentDocumentTo with the systemElementId field
Example: The SUBRS-SUB-001 (Sensor Interface Subsystem) requirements document can only refine requirements allocated to the Sensor Interface Module system element — not requirements for Processing Core or Actuator Bus modules.

Document Naming and Organization

Design requirements are organized by system element (subsystem or component):
Document ID PatternScopeCount
DRS-SYS-*System-level design requirements (rare)0–3
DRS-SUB-*Subsystem-level design requirements1–10 per subsystem
DRS-CMP-*Component design requirements1–5 per component
Example from the aero1 project:
  • DRS-CMP-001 – ADCI (Air Data Computer Interface) design requirements
  • DRS-CMP-002 – IRU (Inertial Reference Unit) design requirements
  • DRS-CMP-006 – Power Supply Unit (PSU) design requirements

DO-160G Environmental Linking

Design requirements that specify environmental operating conditions must link to corresponding environmental test categories and verification tests. diagram The DO-160G Environmental Qualification PowerSheet automates this expansion: start with design requirements, expand to characteristics, then expand to test cases — all filtered by environmental category.

Verification Strategy

Design requirements are verified (not just validated) through evidence that demonstrates compliance:
Verification MethodEvidence TypeExample
TestAutomated test execution, test reportUnit test, integration test, system test
AnalysisDesign analysis document, calculationThermal analysis, stress analysis, performance modeling
InspectionCode review, design review checklist, auditSource code inspection against coding standard
DemonstrationLive system demonstration, operational logFeature demo on running system, acceptance test
ReviewDesign review minutes, peer review recordArchitecture review, design walkthrough
The testLevel custom field on test cases further specifies scope:
Test LevelScope
Unit TestIndividual software unit or hardware component in isolation
Integration TestMultiple units integrated together
System TestEnd-to-end system behavior
Acceptance TestCustomer validation against contract requirements
Qualification TestEnvironmental qualification per DO-160G

Usage in PowerSheets

Design requirements appear in four key PowerSheet configurations:

1. Whole RTM Sheet

Shows end-to-end traceability: Customer Requirement → System Requirement → Design Requirement → Test Case

2. Design Verification Sheet

Maps each design requirement to its verification test(s). Enables test case creation directly in the Testing/DesignReqsVerification module. Column Groups:
  • Design Requirements (ID, title, subType, rationale, classification)
  • Verification Tests (test case ID, title, method, level)

3. DO-160G Environmental Qualification PowerSheet

Expands design requirements to environmental specifications and qualification tests: RTM Source: DesignRequirementcharacteristics (expand) → testCases (expand) Column Groups:
  • Design Requirements (ID, requirement, description, SC/CC, DO-160G section)
  • Environmental Specifications (linked characteristics with target values)
  • Qualification Tests (linked test cases)

4. Component RTM Sheet

Component-scoped variant: Subsystem Requirement ↔ Design Requirement (same-document references)

Consistency and Validation

The Aerospace Safety Solution enforces several consistency rules on design requirements:

Classification Alignment

Design requirements must inherit their parent’s SC/CC classification. The Classification Consistency Report flags mismatches:
  • Red flag: desReq classified as SC with parent sysReq classified as CC
  • Resolution: Escalate to system engineer; classify sysReq as SC if child is safety-critical

Parent Requirement Exists

Every design requirement must have a parent system or subsystem requirement. The Traceability Matrix Report highlights orphaned design requirements.

Verification Coverage

Every design requirement must have at least one linked test case. The Test Coverage Report tracks verification percentage by subsystem: diagram Coverage below 90% triggers a design review gate.

Example: PSU Power Supply Design Requirements

The Power Supply Unit (PSU) component illustrates typical design requirement decomposition: Parent System Requirement (SYS-045):
“The flight control computer electrical power subsystem shall provide regulated power to all components and shall maintain system operability during all flight phases.”
Refining Design Requirements (DRS-CMP-006-xxx):
IDTitlesubTypeenvironmentalCategoryTest Cases
DRS-CMP-006-001PSU input voltage regulation shall maintain output within ±5% of nominalElectricalsec17 (Power)TC-006-001, TC-006-002
DRS-CMP-006-002PSU shall survive -40°C to +85°C ambient without performance degradationElectricalsec4 (Temperature)TC-006-003, TC-006-004
DRS-CMP-006-003PSU shall reject conducted noise per MIL-STD-461 CE101Electricalsec19 (Conducted Susc.)TC-006-005
DRS-CMP-006-004Power supply connectors shall be captive and keyed to prevent reversalMechanicalTC-006-006 (Inspection)
DRS-CMP-006-005PSU case shall be labeled with voltage, current, and safety warningsLabelingTC-006-007 (Inspection)
Each design requirement specifies an implementation detail, links to a verification test, and (where applicable) references an environmental category for qualification scope.
The environmental categories, test standards, and field constraints listed above should be verified against your specific Aerospace Safety Solution configuration, as subType values and environmental test mappings may be customized per project.

See Also

Code: modules/RiskTemplates/DFMEATemplate/module.xml, modules/Risks/DFMEA-CMP-PSU/module.xml, modules/_default/WholeRTMSheet/module.xml, modules/Requirements/CUSTOMER-REQS/module.xml (representative of ~50 module.xml files across all spaces and templates) (0.57) · .polarion/tracker/fields/designRequirement-subType-enum.xml, environmentalCategory-enum.xml, fta-gateType-enum.xml, cca-analysisType-enum.xml, controlType-enum.xml, riskControlType-enum.xml, verificationMethod-enum.xml, testLevel-enum.xml (0.56) · .polarion/tracker/fields/testCase-custom-fields.xml, desReq-custom-fields.xml, processStep-custom-fields.xml, characteristic-custom-fields.xml, systemElement-custom-fields.xml, commonCauseEvent-custom-fields.xml, riskControl-custom-fields.xml, task-custom-fields.xml, custom-fields.xml (0.54) · .polarion/tracker/fields/workitem-type-enum.xml (0.53) · .polarion/nextedy/models/rtm.yaml (0.51) · .polarion/nextedy/sheet-configurations/DO-160G Environmental Qualification.yaml, Component RTM.yaml, Configuration Index.yaml, Design Verification Sheet.yaml, Interface Control Matrix.yaml, Problem Report Tracker.yaml, Process Steps.yaml, Review Action Item Tracker.yaml, SOI Stage Gate Dashboard.yaml, Use Steps Specification.yaml, User Need Validation Sheet.yaml, characteristics.yaml, component-characteristics.yaml, customer-requirements.yaml, design-requirements.yaml, subsystem-functions.yaml, subsystem-verification.yaml, system-elements.yaml, test-verification.yaml (0.51) · .polarion/tracker/fields/severity-enum.xml, status-enum.xml, priority-enum.xml, implementationStatus-enum.xml, riskSpecification-document-status-enum.xml (0.48) · .polarion/pages/spaces/_default/Program Manager Dashboard/page.xml, Safety Engineer Dashboard/page.xml, Design Engineer Dashboard/page.xml, VandV Engineer Dashboard/page.xml, Config Manager Dashboard/page.xml (0.46) · .polarion/tracker/fields/complianceRequirement-custom-fields.xml (0.45) · modules/Risks/COMPLIANCE-001/module.xml, modules/Risks/MIL-STD-882E-HTS-001/module.xml, modules/Risks/SEC-THREAT-001/module.xml, modules/Risks/SFMEA-SUB-001/module.xml, modules/Risks/SFMEA-SUB-002/module.xml, modules/Risks/SFMEA-SUB-003/module.xml (0.45)