DO-178C Software Requirements for Avionics Engineers and Managers
Download Full 10+ Page DO-178C Software Requirements Whitepaper
Good requirements are the foundation of good software, and the only road to “great” software is via great software requirements. In aviation, requirements are paramount in DO-178C for avionics software and DO-254 for avionics hardware logic. Great software requirements are also the cornerstone to DO-278A for CNS/ATM (ground-based systems) and DO-297, Integrated Modular Avionics. But how can you “prescribe” good software requirements? What should a DO-178C Software Requirements Standard contain? What are examples of weak, satisfactory, good, and great software requirements? These questions and more are answered herein.
First, please consider the following requirements “quiz” – do you know the answers? If you’re developing aviation software, you need to know these answers; these and many more are explained in the following pages.
AFuzion Requirements Quiz: Page 81 of 312-page AFuzion Private Training
Typical Aviation Requirements for ARP4761A, ARP4754A, DO-178C, DO-254, & DO-278A
Each of the above requirement domains likely represents successively increasing granularity, in the order depicted above. Throughout, additional Safety requirements can be decomposed or derived which further clarify necessary aspects of the system, hardware, and software. When systems are particularly complex, any one of the above requirement domains may be further subdivided into two or more levels of requirements. The end result is typified by multiple levels of requirements which enable higher quality through better understandability of the requirement relationships, and the ability to better validate, and then verify, those requirements. Aviation requirement development entails successively more detailed decomposition, with the requirements reviewed at each stage of refinement. For higher development assurance levels (DALs) associated with Hazardous or Catastrophic failure effects, requirement V&V must be proven to be independent, e.g. a different person or team following a process independent from the requirement developer. Safety requirements per ARP4761 (and ARP4754A) should be defined via the PSSA and SSA, and also reviewed by a Designated Engineering Representative (DER) or Compliance Verification Engineer (CVE, for Europe).
As depicted below, there are five inputs to a formal requirements review in ARP4754A, DO-178C, DO-254, and DO-278A; all five must be under configuration control and proven to be used to perform the actual review. These five inputs (which include derived requirements if applicable) to a formal requirements review comprise the entry criteria, whereas the completed requirements review checklist and action item/defect records comprise the exit criteria. This movement from activity entry to exit comprises a “transition”. The requirements verifier for DO-178C and DO-254 performs the transition, then quality assurance audits the transition. This transition is particularly important for DO-178C/DO-254 FAA certification and the equivalent ED-12/ED-80 EASA certification. For reviews, the number of reviewers is unimportant (in fact, it is this author’s experience that the best reviews are accomplished when fewer but better reviewers are used; team size in complex systems is generally inversely proportional to resultant quality and most certainly productivity.) The key to the ARP4754A, DO-178C, andDO-254 requirements review is the application of the corresponding Standard and as well as the Checklist. Typical high-quality safety-critical requirements standards are detailed and 20+ pages in length; high-quality requirements review checklists are similarly detailed and 6-8+ pages in length. This contrasts sharply with non-safety-critical products which often lack requirements standards and checklists, or, when present, are still very light. The following is from AFuzion’s Aviation Requirements Training for DO-178C, DO-254, and ARP4754A:
The figure below depicts the aviation requirement ecosystem; note that “derived” requirements must also be included as such is necessary to address safety aspects (dissimilarity, heath monitoring, etc.) and gap-filler requirements to ensure all functionality is addressed requirements and can thus be fully traced and verified. These derived requirements do not necessarily trace to a parent requirement, therefore require additional Safety review.
Figure: Aviation Requirements Ecosystem for DO-178C, DO-254, DO-278A and ARP4754A
The following diagram created by AFuzion’s founders depicts the relationship between software requirement stages and design:
HLR’s development follows System requirement definition but precedes LLR development; HLR’s must be formally reviewed (see below) prior to development of the associated LLR’s. The following graphic provides the key reasons why HLR’s are necessary for any aviation system potentially having a safety and security impact and thus requiring software and hardware certification:
Key Reasons to Develop High-Level Requirements
HLR’s are the “bridge” between System requirements and LLR’s. Good HLR’s should address and elucidate the following software aspects:
Attributes Addressed by High-Level Requirements
HLR’s (and LLR’s below) which are ascertained via analysis (or decomposition) of System Requirements or System Architecture are termed “non-derived” because of that direct system relationship. HLR’s which come from Safety-Related Requirements are usually called non-derived but the derived/non-derived designation is less relevant because that HLR inherits the “safety” attribute from its safety source, so it must be fed back to the Safety process (this is the real (ARP4754A and DO-178C, but not the former DO-178B) reason for “derived” and “safety” requirements: all such must be independently reviewed by Safety as part of that formal Safety Feedback process (which must also be audited by Software Quality Assurance and by Systems Process Assurance). HLR’s which come from analysis of Safety Assessments (as opposed to analysis of Safety Requirements) are ALWAYS “Derived” requirements (no parent) and also must have the Safety attribute set for requirements management. (For additional details on developing and evaluating HLR’s, see AFuzion’s Requirements Standard template and AFuzion’s Requirements Review Checklist here: https://afuzion.com/plans-checklists/ )
For a discussion and details on DO-178C’s Low-Level Requirements, Design, and Architecture, read the remaining ten pages of this proprietary AFuzion whitepaper by requesting a complimentary copy below.
Download Full 10+ Page DO-178C Software Requirements Whitepaper