Skip to main content

​
Purpose and Role

Customer requirements capture what the customer (or user organization) needs the system to do, independent of how it will be implemented. In aerospace safety projects following ARP 4754A, customer requirements are classified by safety criticality and serve as the input to system-level requirement derivation. Key characteristics:
  • Constrained to the CUSTOMER-REQS module
  • Required for validation (not verification) against customer specifications and user needs
  • Classified for safety criticality using the classification field
  • Start of the requirements traceability chain leading to design requirements and test cases
  • Used in the User Need Validation PowerSheet to map customer needs to validation evidence

​
Entity Relationships

Customer requirements participate in the following links in the RTM domain model:
Link RoleTarget TypeDirectionPurpose
refinesSystem RequirementoutboundDerives system-level requirements from customer needs
validatesTest CaseinboundTest cases provide validation evidence
specifiedByCharacteristicinboundEnvironmental or design characteristics supporting the requirement
The relationship hierarchy shows: diagram

​
Custom Fields

Customer requirements include the following custom field:
Field NameTypeDefaultDescription
classificationEnumeration (multi-select)—Safety criticality marking. Allowed values: SC (Safety Critical), CC (Criticality Classification applied per relevant standard). A customer requirement must be classified to support DAL allocation downstream.
The classification field supports multi-select in the data model. Verify the exact enum values and display labels in your Polarion project configuration at .polarion/tracker/fields/classification-enum.xml.

​
Standard Polarion Fields

In addition to custom fields, customer requirements include these standard Polarion work item fields:
Field NameTypeTypical Use
IDStringWork item identifier (e.g., CR-001, REQ-CUS-025)
TitleStringConcise description of the customer need
DescriptionText (Rich)Detailed requirement statement, acceptance criteria
StatusEnumerationWorkflow state: draft, inReview, approved, obsolete
OwnerUserRequirement author or owner
CreatedTimestampCreation date
ModifiedTimestampLast modification date

​
Document Constraints

Customer requirements are stored exclusively in the CUSTOMER-REQS Polarion module. The module has:
  • Document Type: customerSpecification
  • Module ID: CUSTOMER-REQS
  • Space: Requirements
  • Outline Structure: Hierarchical outline numbers (e.g., 1, 1.1, 1.1.1)
This single-module constraint ensures all customer requirements are co-located and easy to query.

​
Requirements Decomposition

Customer requirements are the apex of a four-level decomposition:
  1. Customer Requirement — Stakeholder/user need (this type)
  2. System Requirement — System-level derivation (sysReq type) → stored in systemRequirementsSpecification document
  3. Subsystem Requirement — Subsystem-level derivation (sysReq type with document constraint) → stored in subsystemRequirementsSpecification documents
  4. Design Requirement — Implementation-level specification (desReq type) → stored in designRequirementsSpecification documents
Each customer requirement typically refines into one or more system requirements, which further refine into subsystem and design requirements. This decomposition chain is the foundation of ARP 4754A Systems Engineering assurance.

​
Validation and Traceability

Unlike lower-level requirements (which are verified by test cases), customer requirements are validated by test cases. Validation evidence may include:
  • Customer acceptance tests or demonstrations
  • User needs analysis reviews
  • Stakeholder sign-off documentation
The User Need Validation PowerSheet provides an interactive view linking customer requirements to validation evidence and test cases.

​
Example: Customer Requirement Attributes

A typical customer requirement in the Aerospace Safety Solution might appear as:
AttributeExample Value
IDCR-001
TitleFlight Control Computer shall provide stable aircraft control in normal operation
ClassificationSC (Safety Critical)
DescriptionThe FCC must maintain stable control authority across the aircraft’s operational envelope, including takeoff, cruise, and landing phases. Stability shall be demonstrated across ±15° pitch and roll angles.
Statusapproved
Refines toSYS-001 (System Requirement: “FCC control law shall maintain stability margins per MIL-STD-1797…”)
Validated byTEST-VAL-001, TEST-VAL-002 (pilot evaluation test, simulation test)

​
Safety Classification

The classification field marks customer requirements with safety relevance:
  • SC (Safety Critical): Requirements that, if not met, could contribute to a hazardous or catastrophic failure condition
  • CC (Criticality Classification): Requirements classified per the relevant safety standard (ARP 4754A, DO-178C, DO-254, MIL-STD-882E)
Classification at the customer requirement level cascades downstream: a safety-critical customer requirement typically results in safety-critical system, subsystem, and design requirements, which in turn allocate DAL (Design Assurance Level) and drive certification activities.

​
Integration with PowerSheets

Customer requirements are visible in two interactive PowerSheet views:
  1. User Need Validation Sheet — Maps customer requirements to user needs and validation test cases
  2. Whole RTM Sheet — Shows the full traceability chain from customer requirements through design requirements to test cases
These views enable interactive filtering, relationship verification, and coverage gap analysis. For more information on requirements management in the Aerospace Safety Solution, see:
Customer requirements must be stored in the CUSTOMER-REQS module. Creating customer requirements in other modules (such as system or design requirement specification documents) will break traceability and automated queries.
Code: .polarion/nextedy/models/rtm.yaml (0.68) · .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.60) · 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.58) · .polarion/tracker/fields/workitem-type-enum.xml (0.51) · .polarion/documents/fields/document-type-enum.xml (0.44) · .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.43) · .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.42) · .polarion/tracker/fields/complianceRequirement-custom-fields.xml (0.41) · .polarion/nextedy/sheet-configurations/ARP 4754A System Development Assurance.yaml (0.41) · .polarion/nextedy/sheet-configurations/Whole RTM Config.yaml (0.40)