Overview
System Requirements (sysReq) form the second level of a 4-level requirements traceability chain: Customer Requirement → System Requirement → Subsystem Requirement → Design Requirement System Requirements translate high-level customer needs into concrete, implementable system-level specifications. They establish what the system must do to satisfy customer expectations, serving as the bridge between stakeholder needs and detailed design specifications.Per ARP 4754A (Certification Specifications for Large Aeroplanes), system requirements form a critical level in the development assurance hierarchy. Each system requirement must be classified for Safety (SC) or Non-Safety (CC) impact and assigned a Design Assurance Level (DAL) that drives downstream verification rigor.
Work Item Properties
Core Fields
| Name | Type | Default | Description |
|---|---|---|---|
| ID | Text (read-only) | Auto-generated | Unique identifier within the systemRequirementsSpecification document (e.g., SYS-001, SYS-002) |
| Title | Text (required) | — | Requirement statement describing system-level capability or constraint (e.g., “Flight Control System shall maintain stable aircraft attitude”) |
| Description | Rich Text | — | Detailed rationale, context, and acceptance criteria. May include design assumptions and performance bounds. |
| Type | Enumeration (read-only) | sysReq | Work item type identifier for system requirement |
| Status | Enumeration | draft | Requirement approval state: draft, review, approved, rework |
| Owner | User Reference | — | Person responsible for requirement definition and approval |
| Created | DateTime (read-only) | — | Timestamp of requirement creation |
| Modified | DateTime (read-only) | — | Timestamp of last modification |
Safety Classification
| Name | Type | Default | Description |
|---|---|---|---|
| SC/CC Classification | Enumeration | — | Safety (SC) or Non-Safety (CC) impact classification. Determines whether requirement contributes to aircraft safety functions per ARP 4754A. SC requirements must be traced through Subsystem/Design levels with verification at each stage. |
Traceability and Relationships
System requirements participate in the standard requirements decomposition link roles:| Link Role | Target Type(s) | Direction | Multiplicity | Purpose |
|---|---|---|---|---|
refines | Customer Requirement | Outbound | 1..* | Links to parent Customer Requirement(s) that this system requirement satisfies |
refined by | Subsystem Requirement | Inbound | 0..* | Linked from child Subsystem Requirement(s) that decompose this system requirement |
verifies | Test Case | Outbound | 0..* | Links to verification test case(s) that validate this requirement |
parent | System Requirement | Outbound | 0..1 | Parent system requirement for hierarchical grouping (same-type decomposition) |
child | System Requirement | Inbound | 0..* | Child system requirements under this parent |
The exact link role names and cardinality constraints should be verified in your project’s link role configuration. See Link Roles and Traceability Relationships for the complete reference.
Document Constraints
System Requirements are constrained to the systemRequirementsSpecification document type and are organized within the Requirements space.Module Naming Convention
Document IDs follow the pattern:SYS-SYS-001— System-level system requirement (FCC overall requirement)SYS-SUB-001— Subsystem-level system requirement (Sensor Interface Module requirement)
The RTM domain model distinguishes between SystemRequirement (system-level,
SYS-SYS-* naming) and SubsystemRequirement (subsystem-level, SYS-SUB-* naming). Both use the Polarion work item type sysReq, but are constrained to different document types:- SystemRequirement → systemRequirementsSpecification document
- SubsystemRequirement → subsystemRequirementsSpecification document
Verification and Validation
System Requirements are verified (not validated) by test cases:- Verification via Test Case: A Test Case work item linked via the
verifieslink role explicitly demonstrates that this requirement’s behavior is correct under specified conditions. - Verification Level: System-level requirements are verified by System Test Cases (created in the Testing/SystemReqsVerification module).
- Traceability: Each SC-classified system requirement must have at least one linked test case to satisfy ARP 4754A verification objectives.
Decomposition in the RTM
The following diagram illustrates how System Requirements fit within the aerospace requirements hierarchy:
Properties Table Example
For a flight control system, a typical system requirement might appear as follows:| Property | Value |
|---|---|
| ID | SYS-SYS-003 |
| Title | Flight Control System shall maintain stable aircraft attitude within ±5 degrees pitch and ±10 degrees roll |
| Description | The Flight Control System shall provide closed-loop control of elevator and aileron surfaces to maintain aircraft pitch attitude within ±5 degrees and roll attitude within ±10 degrees during normal operations. Control shall respond to pilot inputs within 200 milliseconds. |
| Type | sysReq |
| Status | approved |
| SC/CC Classification | SC (Safety-Critical) |
| Owner | Sarah Chen (Lead Safety Engineer) |
| refines | CUST-001 (Customer Requirement: “Aircraft shall maintain stable flight”) |
| refined by | SYS-SUB-010, SYS-SUB-011 (Subsystem requirements for Sensor Interface and Processing Core) |
| verifies | TA-15234, TA-15235 (System Test Cases for attitude control) |
Integration with PowerSheet
System Requirements are displayed and managed in the Whole RTM PowerSheet and Component RTM PowerSheet as part of the standard traceability matrix:- Whole RTM: Shows all Customer → System → Subsystem → Design requirements with test case verification columns at each level
- Component RTM: Scoped variant showing only the current system element’s Subsystem → Design requirements with backward link to System Requirement
- ARP 4754A System Dev Assurance: Shows System Requirements with DAL classification and decomposition tracking across levels
PowerSheet configurations apply document-level filters to show only requirements from specific document types. For System Requirements, the filter targets systemRequirementsSpecification documents. See PowerSheet Configuration Reference for details.
Link to Safety Assessment
System Requirements participate in downstream safety assessment via their Subsystem and Design decompositions:- FHA/PSSA/SSA: Safety requirements derived from Failure Conditions are allocated to system elements, which in turn decompose system requirements. Traceability from System Requirement → Subsystem Requirement → Design Requirement → Safety Requirement establishes the chain of custody for safety.
- FMEA: Failure modes identified in SFMEA/DFMEA of system components must be traced back to the system requirements they could violate, establishing the causal link between failure modes and functional impact.
Workflow and Approval
System Requirements follow the standard requirement approval workflow:- Draft: Requirement authored and undergoing internal review
- Review: Requirement submitted for formal review by stakeholders
- Approved: Requirement formally approved and baseline
- Rework: Requirement returns to draft pending modifications
Best Practices
- Clarity: Write requirements in clear, unambiguous language. Avoid vague terms like “shall support,” “shall handle,” or “shall be suitable.”
- Testability: Each requirement must be verifiable by at least one test case. If a requirement cannot be tested, decompose it further.
- Allocation: Ensure each system requirement is allocated to at least one Subsystem Requirement, and that allocation is traced through design and verification.
- Classification: Mark all safety-related requirements as SC; mark all non-safety-critical requirements as CC. This distinction drives downstream DAL and verification depth.
- Traceability: Maintain bidirectional traceability: upward to Customer Requirements and downward to Subsystem/Design Requirements and Test Cases.
System Requirement behavior, custom field definitions, and link role configurations may vary by project. Refer to your project’s RTM model and document type definitions in RTM Domain Model for authoritative details.
Source References (dev)
Source References (dev)
Code:
.polarion/tracker/fields/workitem-type-enum.xml (0.61) · .polarion/tracker/fields/workitem-link-role-enum.xml (0.57) · .polarion/nextedy/models/rtm.yaml (0.56) · .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.53) · 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.52) · .polarion/nextedy/sheet-configurations/Whole RTM Config.yaml (0.52) · .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.52) · .polarion/pages/spaces/_default/Requirements Traceability Summary/page.xml, Verification Validation Summary/page.xml, Risk Control Effectiveness Report/page.xml, System Decomposition Report/page.xml, FMEA Coverage Report/page.xml, Classification Consistency Report/page.xml, System FMEA Report/page.xml, System Structure Navigator/page.xml (0.50) · .polarion/nextedy/sheet-configurations/ARP 4754A System Development Assurance.yaml (0.50) · .polarion/nextedy/sheet-configurations/DO-178C Software Verification Matrix.yaml (0.48)