CAST-15

CAST-15, Merging High-Level and Low-Level Requirements is a Certification Authorities Software Team (CAST) Position Paper. It is an FAA publication that "does not constitute official policy or guidance from any of the authorities", but is provided for educational and informational purposes only for applicants for software and hardware certification. The Position Paper has been withdrawn, replaced by FAQ #81 in DO-248C, Supporting Information for DO-178C and DO-278A, but much the same content of Position Paper is published in the present EASA-CM-SWCEH-002 (Section 23 Merging High-Level and Low-Level Requirements).

Merging High-Level and Low-Level Requirements
FAA Publication
AbbreviationCAST-15
Year started2003
OrganizationCertification Authorities Software Team
DomainAvionics, type certification

Contents

DO-178C/DO-178B provides guidance for merging High-Level and Low-Level Software Requirements. Nominally, in the DO-178C/DO-178B context, the High-Level Requirements for a Certified Software Product are distinct from the Low-Level Software Requirements, the former being outputs of the Software Requirements Process and the latter being outputs of the Software Design Process.[1] High-Level Requirements are essentially those System Requirements allocated to the Software Product ("what" the full Software Product shall be and do), while Low-Level Requirements are the results of decomposition and elaboration of requirements such that the source code may be produced, reviewed, and tested directly from the Low-Level Requirements ("how" the software shall do it).[2]

In some applications, the System/High-Level Requirements are of sufficient simplicity and detail that the Source Code can be produced and verified directly. In this situation, the System/High-Level Requirements are also considered to be Low-Level Requirements, and so, the objectives for Low-Level requirements also apply to those System/High-Level Requirements.[2]

The concern that prompted CAST-15 is that some applicants for software certification interpreted the above guidance as permitting combining both High-Level Requirements and Low-Level Software Requirements in a single software requirements document or other artifact without making any indication of which requirements are High-Level and which are Low-Level, but also omitting traceability between the Low-Level and High-Level Requirements and neglecting to identify derived requirements for feedback to System Processes, including System Safety.

This Position Paper discussed several problems and hazards that Certification Authorities see arising from merging Low-Level Requirements into the collection of High-Level Requirements, recommending that this not be done. The replacement content published in FAQ #81 in DO-248C Supporting Information for DO-178C and DO-278A provides the a shorter list of certification concerns for combining (or merging) these the "what" and "how" two levels into a single set without distinguishing the two levels of requirements and their certification objectives. FAQ #81 also recommends against merging High-Level and Low-Levels even in cases where the code can be written and verified in a "single step" of requirements as the original DO-178B/C guidance allows, but does offer suggestions on how to address concerns.[3]

References
  1. RTCA/DO-248C "Supporting Information for DO-178C and DO-278A", FAQ #81, pages 43-44. "When airborne software components are large or complex, the software requirements process produces the HLRs and the software design process produces the LLRs and architecture. Thus, HLRs and LLRs are not the outputs of the same development processes."
  2. RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", p. 31. "Low-level requirements are software requirements from which Source Code can be directly implemented without further information." ... "However, if Source Code is generated directly from high-level requirements, then the high-level requirements are also considered low-level requirements and the guidance for low-level requirements also apply."
  3. RTCA/DO-248C "Supporting Information for DO-178C and DO-278A", FAQ #81, pages 43-44. "There may be some systems where the system level requirements are refined into software requirements suitable for coding in one refinement step. In this case, a single level of software requirements may be feasible; however, ...."


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.