From complexity to clarity: how to develop requirements for aircraft systems?

In the safety-critical aerospace industry, the development of aircraft systems requires a meticulous approach. The requirements provide the common basis that guides the design and operation of systems, thus the well-defined System Requirement Document or System Specification forms the backbone of successful system development.

Throughout this article, we will delve into the aspects of writing ‘good’ requirements and the set of attributes that should be defined for each requirement in the System Requirements Document/System Specification.

When engaged in the development of system requirements, it is essential to recognize the two primary sources from which they originate:

1. Customer Requirements /Aircraft Requirements
2. Regulations

Note: During the planning phase the certification basis should be determined, and meticulous determination of all pertinent standards and regulations, that are applicable to the system takes place.

Additionally, certain requirements may not have a designated source. These requirements, referred to as derived requirements, emerge through system design considerations, safety assessments, or architectural evaluations.

Presented below is the requirements flow development diagram that illustrates the process outlined in ARP4754A for the development of Aircraft, Systems, and Subsystems. It is important to note that in certain cases, the Line Replaceable Unit (LRU) level is also identified, and the processes defined in ARP4754A are likewise applicable to this level. This article primarily centers around the development of requirements at the System, Subsystem, and LRU levels.

Requirements Flow in the Aviation Domain

In accordance with the ARP4754A all requirements shall be checked for correctness and completeness as part of the validation process, we have identified the key qualities that requirements must possess to successfully pass the validation process.

Unambiguous. The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand [ISO/IEC/IEEE 29148:2018(E)]

Identifiable. The requirement must have a distinct identification (ID) to ensure traceability and enable requirement management throughout the development process.

Unique. The requirement must be unique and not overlap with other requirements.

Singular. The requirement states a single capability, characteristic, constraint or quality factor [ISO/IEC/IEEE 29148:2018(E)]

Verifiable. The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirements exist. Verifiability is enhanced

when the requirement is measurable [ISO/IEC/IEEE 29148:2018(E)]

Complete. The requirement sufficiently describes the necessary capability, characteristic, constraint or quality factor to meet the entity need without needing other information to understand the

requirement [ISO/IEC/IEEE 29148:2018(E)]

Feasible. The requirement can be realized within system constraints (e.g., cost, schedule, technical) with acceptable risk [ISO/IEC/IEEE 29148:2018(E)]

Correct. The requirement is an accurate representation of the entity need from which it was transformed. [ISO/IEC/IEEE 29148:2018(E)]

Consistent. The requirement contains individual requirements that are unique, do not conflict with or overlap with other requirements in the set, and the units and measurement systems are homogeneous. [ISO/IEC/IEEE 29148:2018(E)]

INCOSE-TP-2010-006-03.1 defines an attribute as additional information associated with an entity that is used to aid in its definition and management and provides a comprehensive list of 49 attributes that can be tailored to suit the needs of the developing system. Considering the recommendations outlined in ARP4754A and to ensure the effective capture of the multifaceted aspects of requirements in the aerospace industry, the following list of attributes is recommended:

ID is a unique alphanumeric or numeric label assigned to a requirement within a system development project to maintain the requirement.

Recommendation: To facilitate efficient searching of requirement IDs throughout the document, it is advised to evaluate the scope of the Specification beforehand and utilize an ID format with a leading zero. For instance, consider using “PFD-REQ-001” instead of “PFD-REQ-1”. This practice simplifies the search process and enhances navigability within the document.

Version refers to an alphanumeric or numeric identifier to indicate its specific version to manage the evolution of requirements throughout the project lifecycle.

Recommendation: Requirement Management Systems possess the capability to automatically track changes to requirements, prompting users to provide commentary or reasons for each change. While this field is often overlooked during the initial drafting of the Specification, we strongly advise filling it out to ensure comprehensive change tracking. It is important to emphasize that after the document’s release, completion of this field becomes mandatory to maintain a thorough record of requirement modifications.

Statement is defined as the translation and expression of a need and its associated constraints and conditions [ISO/IEC/IEEE 29148:2018(E)], which makes it a core of the requirement. It is imperative that the requirement statement embodies the qualities of a “good” requirement.

Author tracking promotes accountability and allows stakeholders to directly reach out to the engineer who formulated it to provide relevant explanations or guidance.

Assumption (YES/NO) shall be independently tracked since they can introduce risk to the development process, and the related consequences can jeopardize the satisfactory implementation of safety requirements.

Safety (YES/NO) By Tracking safety requirements Safety Team can ensure that safety requirements are established, validated, and documented properly. Additionally, safety requirements often necessitate specialized validation and verification activities, tracking them allows the Safety Team to plan and execute the appropriate validation and verification processes.

Security (YES/NO) As safety requirements the security requirements are usually under control of the Safety Team, tracking the Security Classification helps the Safety Team effectively manage security-related aspects.

Note: Please follow the ‘Cybersecurity requirements for airborne systems’ article for additional information about Security Risk assessment and Security Assurance Level (SAL)

Parent Trace shall contain the ID of the parent requirement. In accordance with ARP4754A, establishing traceability between requirements at various levels of system architecture is highly emphasized. By tracking the parent requirement, clear and comprehensive traceability can be achieved.

Derived (YES/NO) requirements are additional requirements resulting from design or implementation decisions during the development process that are not directly traceable to higher-level requirements.

Rationale behind a requirement serves as its context, justification, and reasoning for inclusion in the system. This field shall be mandatory for all derived requirements, assumptions, safety, and security requirements; however, it is also can be filled in for other requirements to make them a transparent and comprehensive understanding.

Source provides transparency and traceability, allowing the engineering team to identify and reference the origin of each requirement. It also enables validation efforts by providing evidence of how requirements align with customer requirements or industry standards/regulatory guidelines.

Allocation ensures that each requirement is properly assigned to a specific subsystem or item (HW/SW), enabling a clear understanding of where and how the requirement will be implemented.

FDAL tracking of requirements is necessary since a system may encompass multiple FDALs, in addition, it also drives necessary rigorous validation and verification activities.

Function allows for clear identification and understanding of the intended system functions that each requirement aims to fulfill.

Validation Method. The level of validation rigor depends on the assigned function development assurance level(s) for the aircraft or system (FDAL) and item development assurance level(s) for the item (IDAL). Requirement validation methods, defined in ARP4754A, and their acceptable use are described in the table below:

Requirements validation methods (ARP4754A)

R – Recommended for certification, A – As negotiated for certification, N – Not required for certification

Note: The validation status should be presented in the Validation Matrix and results should summarized in Validation Summary.

Verification Method. The level of verification rigor depends on the assigned function development assurance level(s) for the aircraft or system (FDAL) and item development assurance level(s) for the item (IDAL). Requirement verification methods, defined in ARP4754A, and their acceptable use are described in table below:

R – Recommended for certification, A – As negotiated for certification, N – Not required for certification

Note: The validation status should be presented in the Validation Matrix and results should summarized in Validation Summary.

In conclusion, attributes play a vital role in defining and managing requirements in the aerospace industry. They allow project teams to capture various aspects of requirements and ensure successful implementation. It’s worth noting that additional attributes can be added as needed to accommodate specific system requirements.

We would like to offer you a free downloadable System Requirement Document template, which can be integrated into various Requirements Management Systems such as IBM DOORS, JAMA, JIRA, Valispace, and more.

DMD Solutions  provides a comprehensive range of RAMS solutions to help organizations ensure the reliability, availability, maintainability, and safety of their product. Connect with our expert team for collaborations, we would be happy to assist you. Contact us now to receive support.