Skip to main content

​
Entity Types Overview

The Aerospace Safety Solution RTM model organizes work items into four functional categories:
CategoryEntity TypesPurpose
RequirementsCustomerRequirement, SystemRequirement, SubsystemRequirement, DesignRequirementV-model left-side decomposition from stakeholder needs to design specifications
System DecompositionSystemElement, Function, CharacteristicPhysical architecture, functional allocation, and design attributes
Safety AnalysisFailureMode, FailureCondition, RiskControl, SecurityThreat, HazardFHA, FMEA, and security assessment entities
VerificationTestCase, ConfigurationItem, ComplianceObjective, ComplianceRequirementRight-side validation/verification and compliance tracking

​
Requirements Decomposition Chain

The V-model requirements flow follows a strict four-level decomposition hierarchy: 
CustomerRequirement (top-level stakeholder needs, ARP 4754A)
    ↓ refines
SystemRequirement (architecture-level requirements)
    ↓ refines
SubsystemRequirement (subsystem-level requirements)
    ↓ refines
DesignRequirement (detailed implementation specifications)
    ↓ refines
Characteristic (design attributes, tolerances, environmental specs)

​
CustomerRequirement

Internal Type ID: customerRequirement
Space: Requirements
Classification: SC (Safety Critical) or CC (Certification Critical)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., CUST-001)
TitleString—Requirement statement from customer specification
DescriptionText—Detailed requirement text and rationale
ClassificationEnum—SC (Safety Critical) or CC (Certification Critical)
ModuleReferenceCUSTOMER-REQSFixed to customer requirements document
Verified ByLink—TestCase items that validate this requirement (right-side of V-model)
Constraints:
  • Must reside in CUSTOMER-REQS module
  • Constrained to top-level customer specification documents
  • Classification is mandatory for requirements traceability
  • Cannot be directly implemented — must be refined into SystemRequirements

​
SystemRequirement

Internal Type ID: sysReq
Space: Requirements
Classification: SC or CC
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., SR-001)
TitleString—System-level requirement statement
DescriptionText—Detailed specification and design intent
ClassificationEnum—SC (Safety Critical) or CC (Certification Critical)
RefinesLink—Parent CustomerRequirement(s)
Refined ByLink—Child SubsystemRequirement(s) or DesignRequirement(s)
Verified ByLink—TestCase items in SystemReqsVerification module
Constraints:
  • Constrained to systemRequirementsSpecification document type
  • Must reference a parent CustomerRequirement via ‘refines’ link role
  • Classification cascades from parent customer requirement
  • Forms the middle tier of the V-model decomposition

​
SubsystemRequirement

Internal Type ID: sysReq (same as SystemRequirement)
Space: Requirements
Classification: SC or CC
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., SUBSR-SUB-001)
TitleString—Subsystem-level requirement statement
DescriptionText—Specification for a specific subsystem or LRU
ClassificationEnum—SC or CC
Subsystem ContextReference—SystemElement (subsystem) this requirement applies to
RefinesLink—Parent SystemRequirement
Refined ByLink—Child DesignRequirement(s)
Verified ByLink—TestCase items in SubsystemReqsVerification module
Constraints:
  • Constrained to subsystemRequirementsSpecification document type
  • Document must be linked to a SystemElement (subsystem) via systemElementId
  • Context-aware pick lists filter parent SystemRequirements by subsystem
  • Enables multi-level decomposition for complex systems

​
DesignRequirement

Internal Type ID: desReq
Space: Design
Classification: SC or CC
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., DR-CMP-001)
TitleString—Low-level design requirement or specification
DescriptionText—Detailed design specification
SubTypeEnum—system / software / hardware — filters DO-178C (SW) vs DO-254 (HW) views
ClassificationEnum—SC or CC
Environmental CategoryEnum—DO-160G environmental qualification category (e.g., Cat-3A, Cat-3C)
Component ContextReference—SystemElement (component) this requirement applies to
RefinesLink—Parent SystemRequirement or SubsystemRequirement
Refined ByLink—Child Characteristic(s)
Verified ByLink—TestCase items in DesignReqsVerification module
Constraints:
  • Constrained to designRequirementsSpecification document type
  • SubType determines regulatory domain: software → DO-178C, hardware → DO-254
  • Context-aware pick lists filter parent requirements by component
  • Environmental category links to DO-160G qualification matrix

​
Characteristic

Internal Type ID: characteristic
Space: Design
Classification: SC or CC
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., CHAR-CMP-001)
TitleString—Design characteristic (e.g., operating temperature range)
Characteristic TypeEnum—Environmental / Electrical / Mechanical / Thermal / Performance
Target ValueString—Specification value or range (e.g., -40°C to +85°C)
ToleranceString—Acceptable tolerance band
UnitString—Measurement unit (e.g., °C, volts, ohms)
ClassificationEnum—SC or CC — carries forward from parent DesignRequirement
Environmental CategoryEnum—DO-160G category for environmental characteristics
Assessed ByLink—FailureMode items in DFMEA analysis
Constraints:
  • Constrained to characteristicsSpecification document type
  • Classification and environmental category inherited from parent DesignRequirement
  • Bridge between design specifications and DFMEA failure analysis
  • Used in DO-160G Environmental Qualification PowerSheet

​
System Decomposition Entities

​
SystemElement

Internal Type ID: systemElement
Space: Design
Classification: DAL (Design Assurance Level: A, B, C, D, E)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., FCC, FCC-1, FCC-1-1)
TitleString—System/subsystem/component name (e.g., Flight Control Computer)
Element TypeEnum—System / Subsystem / Component / LRU / Module
Design Assurance Level (DAL)Enum—A (most critical) to E (least critical) per ARP 4754A
ParentLink—Parent SystemElement (for subsystems/components)
Outline NumberString—Hierarchical numbering (e.g., 1.2.3) for document outline
FunctionsLink—Function items allocated to this element
Failure ConditionsLink—FailureCondition items assessed against this element
Security ThreatsLink—SecurityThreat items affecting this element
Constraints:
  • Element Type determines decomposition level: System → Subsystem → Component → LRU
  • DAL classification flows from FHA (FailureCondition) severity assessment
  • Parent link enforces hierarchy: no circular dependencies, no orphaned branches
  • Outline number auto-increments based on parent-child relationships

​
Function

Internal Type ID: function
Space: Design
Classification: None (inherits DAL from allocated SystemElement)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., FUNC-001)
TitleString—Function description (e.g., “Provide flight control outputs”)
DescriptionText—Functional specification and operational context
Allocated ToLink—SystemElement(s) this function is allocated to
Failure ModesLink—FailureMode items in SFMEA analysis (causes)
Failure ConditionsLink—FailureCondition items in FHA analysis (assessed via this function)
Constraints:
  • Central to ARP 4761 safety assessment — every failure mode must trace to a function
  • Functions must be allocated to at least one SystemElement
  • No function can exist without allocation
  • Used as the bridge between system decomposition and SFMEA/FHA

​
Safety Analysis Entities

​
FailureMode

Internal Type ID: failureMode
Space: Risks
Classification: Severity, Occurrence, Detection (pre/post mitigation)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., FM-001)
TitleString—Failure mode description (e.g., “Loss of output signal”)
DescriptionText—Detailed failure mechanism
FunctionLink—Function this failure mode affects (SFMEA) or Characteristic (DFMEA)
Failure MechanismString—Root cause or mechanism of failure
Severity (S)EnumPre-mitigationCatastrophic / Hazardous / Major / Minor / No Effect
Occurrence (O)EnumPre-mitigation5 (5+ per 10^5 hrs) to 1 (< 1 per 10^5 hrs)
Detection (D)EnumPre-mitigation5 (not detected) to 1 (always detected)
RPN (Risk Priority Number)CalculatedS × O × DSeverity × Occurrence × Detection
CausesText—Known or potential root causes
Current ControlsText—Existing design features or tests
Mitigated ByLink—RiskControl(s) that reduce this failure mode’s severity/occurrence
Causes Failure ConditionLink—FailureCondition(s) this mode contributes to (FHA linkage)
Constraints:
  • Severity must be assigned (no default to Major)
  • Occurrence and Detection assessed both pre- and post-mitigation
  • RPN = S × O × D (calculated, not manually entered)
  • Every failure mode must link to at least one Function or Characteristic

​
FailureCondition

Internal Type ID: failureCondition
Space: Risks
Classification: Severity, Flight Phase, Probability Target
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., FC-001)
TitleString—Failure condition description (e.g., “Complete loss of flight control”)
DescriptionText—Detailed failure condition and operational impact
ClassificationEnum—Catastrophic / Hazardous / Major / Minor / No Safety Effect (ARP 4761)
Flight PhaseEnum—Ground / Takeoff / Climb / Cruise / Descent / Landing
Affects System ElementLink—SystemElement(s) this failure condition impacts
Affects FunctionLink—Function(s) this failure condition impacts
Contributing Failure ModesLink—FailureMode(s) that can cause this condition (reverse of ‘causeOf’)
DAL AllocationEnum—A to E — allocated DAL for mitigating safety requirements
Probability Target (P)String—Probability of occurrence target per flight hour or operation (e.g., < 1×10⁻⁹ per flight hour)
Mitigated ByLink—SafetyRequirement(s) and RiskControl(s) that mitigate this condition
Constraints:
  • Classification is mandatory (no unclassified failure conditions)
  • Must specify a flight phase (operational context for failure probability)
  • DAL allocation flows from classification severity
  • FHA → PSSA → SSA traceability: FHA identifies conditions, PSSA allocates SAF reqs, SSA verifies evidence

​
RiskControl

Internal Type ID: riskControl
Space: Risks
Classification: RiskControlType (InherentSafety, Protective, InfoForSafety)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., RC-001)
TitleString—Risk control description
DescriptionText—Control strategy and implementation approach
Risk Control TypeEnum (multi-select)—InherentSafety (eliminate hazard) / Protective (mitigate hazard) / InfoForSafety (inform user) — per ARP 4761 §5.5
ImplementsLink—SafetyRequirement(s) and/or DesignRequirement(s) implementing this control
MitigatesLink—FailureMode(s) and/or FailureCondition(s) controlled by this action
Verification MethodEnum—Analysis / Test / Inspection / Demonstration
Verification EvidenceReference—Test case, report, or analysis document demonstrating control effectiveness
Effectiveness RatingEnum—High / Medium / Low — subjective assessment
Constraints:
  • At least one RiskControlType must be selected
  • Multi-select allows combination (e.g., both InherentSafety and Protective)
  • Must mitigate at least one FailureMode or FailureCondition
  • Must implement at least one Requirement or be a design feature

​
SecurityThreat

Internal Type ID: securityThreat
Space: Security (DO-326A)
Classification: SAL (Security Assurance Level)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., ST-001)
TitleString—Security threat description (e.g., “Unauthorized code injection”)
DescriptionText—Threat scenario and attack vector
Affects System ElementLink—SystemElement(s) vulnerable to this threat
SAL (Security Assurance Level)Enum—SAL-I (lowest) to SAL-V (highest) per DO-326A
ProbabilityEnum—High / Medium / Low — likelihood of exploitation
ImpactEnum—Critical / Major / Moderate — consequence if exploited
Mitigated ByLink—RiskControl(s) and SecurityRequirement(s)
Constraints:
  • Constrained to Security Assessment and CCA (Common Cause Analysis) documents
  • SAL allocation independent of DAL but often correlated with failure criticality
  • Used in security threat assessment and DO-326A compliance tracking

​
Verification Entities

​
TestCase

Internal Type ID: testCase
Space: Testing
Classification: Method (Test, Analysis, Inspection, Demonstration)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier with prefix (e.g., VER-SR-001, VAL-REQ-001)
Prefix ConventionString—VER- (verification, right-side V-model) or VAL- (validation, system-level)
TitleString—Test case description
Expected ResultsText—Pass/fail criteria
Test MethodEnum—Test / Analysis / Inspection / Demonstration
Environmental CategoryEnum—DO-160G environmental qualification context (if applicable)
ValidatesLink—CustomerRequirement(s) (system-level validation)
VerifiesLink—SystemRequirement / SubsystemRequirement / DesignRequirement(s)
Test LevelEnum—System / Subsystem / Design — matches requirement level
Execution StatusEnum—Not Started / In Progress / Passed / Failed
Constraints:
  • Prefix VER- for verification tests, VAL- for validation tests
  • Constrained to Testing space documents (SystemReqsVerification, SubsystemReqsVerification, DesignReqsVerification, ValidationTests)
  • Test case automatically created when requirement is added (via entityFactory)
  • Test Level must match the requirement level being verified (system req → system test)

​
ConfigurationItem

Internal Type ID: configurationItem
Space: Configuration (SCM)
Classification: Status (Draft, Approved, Rejected, Baselined)
PropertyTypeDefaultDescription
IDStringAuto-generatedUnique identifier (e.g., CI-001)
TitleString—Configuration item name (document, component, software unit)
CI TypeEnum—Document / Software / Hardware / Interface
StatusEnum—Draft / In Review / Approved / Rejected / Baselined
VersionString—Version identifier (e.g., 1.0, 1.1, 2.0)
Baseline DateDate—Date when CI was baselined
Change HistoryLink—Related Change Request(s) and Problem Report(s)
Constraints:
  • Uses built-in Polarion workitem fields for basic tracking
  • Linked to SystemElement(s) via configuration management hierarchy
  • Status transitions follow document workflow (Draft → Review → Approved → Baselined)
The RTM domain model defines 18 link roles connecting the entity types:

​
V-Model Decomposition (Left Side)

Link RoleSourceTargetCardinalityPurpose
refinesCustomerRequirementSystemRequirement1:NV-model decomposition
refinesSystemRequirementSubsystemRequirement1:NSubsystem-level decomposition
refinesSystemRequirementDesignRequirement1:NDirect to design (single-level systems)
refinesSubsystemRequirementDesignRequirement1:NSubsystem to design decomposition
refinesDesignRequirementCharacteristic1:NCharacteristics implement design reqs

​
Verification Chain (Right Side)

Link RoleSourceTargetCardinalityPurpose
validatesTestCaseCustomerRequirementN:MSystem-level validation (system testing)
verifiesTestCaseSystemRequirementN:MSystem verification testing
verifiesTestCaseSubsystemRequirementN:MSubsystem verification testing
verifiesTestCaseDesignRequirementN:MDesign verification testing
Link RoleSourceTargetCardinalityPurpose
allocatedToFunctionSystemElementN:MFunctions allocated to system elements
assessesFailureConditionFunctionN:MFHA assesses system functions
assessesFailureConditionSystemElementN:MFHA assesses system elements
causeOfFailureModeFailureConditionN:MFMEA → FHA linkage (failure modes cause conditions)
assessedByCharacteristicFailureModeN:MDFMEA assesses design characteristics
mitigatesRiskControlFailureModeN:MRisk controls reduce failure mode severity
mitigatesRiskControlFailureConditionN:MRisk controls mitigate failure conditions
implementsRiskControlDesignRequirementN:MRisk controls implement safety requirements

​
System Decomposition

Link RoleSourceTargetCardinalityPurpose
parentSystemElementSystemElement1:NHierarchical system decomposition (System → Subsystem → Component)

​
PowerSheet Views and RTM Navigation

The RTM domain model is explored via four primary PowerSheet configurations:

​
Whole RTM (Complete Traceability Matrix)

Shows the full four-level requirements chain with verification test cases: diagram Features:
  • 4 color-coded column groups with collapsible headers
  • SC/CC classification renderer
  • Summary view (hides descriptions for dashboard overview)
  • Without Verification view (hides test case columns)

​
Component RTM (Scoped View)

Document-scoped traceability showing SubsystemRequirements and their Design Requirements: diagram Features:
  • Uses applyCurrentDocumentTo constraint to show only current document’s requirements
  • Two column groups: Parent requirements (back-link) and Children (forward expand)

​
DO-160G Environmental Qualification

Maps Design Requirements to environmental specifications and qualification tests: DesignReq (with envCategory) → Characteristic → TestCase (qualification test) Features:
  • 3 column groups: Design Requirements, Environmental Specifications, Qualification Tests
  • envCategory formatter displays DO-160G section codes
  • By DO-160G Section view groups results by environmental category

​
Design Verification Sheet

Maps Design Requirements to verification test cases: DesignReq → TestCase (in DesignReqsVerification module) Features:
  • entityFactory enables test case creation directly in the PowerSheet
  • Scoped to Testing/DesignReqsVerification document

​
Document Organization by System Level

The RTM model constrains documents to specific system decomposition levels, enabling proper separation of concerns:
System LevelRequirements SpaceDesign SpaceRisk Analysis SpaceTesting Space
SystemSRS (System Reqs Spec)Functions SpecFHA, PSSA, SSA, System SFMEA, FTA, CCASystemReqsVerification, ValidationTests
SubsystemSUBRS (Subsystem Reqs Spec)Subsystem Functions, Subsystem CharacteristicsSubsystem SFMEASubsystemReqsVerification
Component—DRS (Design Reqs Spec), Component CharacteristicsDFMEADesignReqsVerification
The complete RTM domain model runtime behavior (cascading DAL/classification updates, automatic test case creation, and cross-document constraint enforcement) should be verified in the live Aerospace Safety Solution application. Thin source coverage available for this reference page — consult project configuration files and the Data Model wiki page in Polarion for complete schema details.

​
Key Constraints and Rules

​
Classification Cascade

  • CustomerRequirement SC/CC → propagates to all refined SystemRequirements
  • SystemRequirement SC/CC → propagates to all refined DesignRequirements
  • DesignRequirement SC/CC → flows to Characteristic(s)
  • FailureCondition Severity → allocates DAL to mitigating SafetyRequirement(s)

​
No Orphaned Items

  • Every DesignRequirement must refine a parent requirement (no unparented design reqs)
  • Every TestCase must verify or validate a requirement (no test cases without traceability)
  • Every FailureMode must link to a Function or Characteristic (no floating failure modes)
  • Every Function must allocate to a SystemElement (no unallocated functions)

​
Environment and Context Awareness

  • DesignRequirement subType (software/hardware) determines regulatory domain (DO-178C vs DO-254)
  • Environmental Category filters DO-160G qualification matrix views
  • Flight Phase context in FailureConditions drives operational risk assessment
  • SystemElement DAL allocation determines verification method rigor
Maintaining RTM integrity requires strict adherence to these constraints. Violating classification cascade, orphaning items, or ignoring environmental context can result in incomplete traceability evidence for certification audits.
Code: .polarion/pages/spaces/_default/Data Model/page.xml (0.59) · .polarion/nextedy/models/rtm.yaml (0.53) · .polarion/nextedy/sheet-configurations/Whole RTM Config.yaml (0.44) · .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.38)