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 to applicants for software and hardware certification for educational and informational purposes only. The paper is concerned with observed misuse of the guidance originally introduced in DO-178B that suggested combining High-Level and Low-Level Requirements for "simple" products, but warned against the practice in general. The paper is also an example of Certification Authorities using the "what" versus "how" distinction  between high-level and low-level requirements that DO-178B/C does not clearly explain. Background. Various stakeholders for software definition and verification have differing objectives and levels of abstraction. Those stakeholders responsible for defining or verifying high-level software product functionality are generally concerned with structure and behavior of the product's external interface, and details of internal software structure do not necessarily support that focus. On the other hand, those responsible for defining and verifying requirement coverage of all internal code need much finer details of internal software structure. This is the justification for DO-178B/C establishing distinct objectives  for high-level and low-level requirements, with consideration for applicants developing additional requirement layering on large projects. However, DO-178B allowed for the possibility of developing only one level of requirements for "particularly simple" systems. That is, Certification Authorities (e.g., FAA-Designated Engineering Representatives) would not expect any more or fewer requirement layers than necessary. However, the Certification Authorities’ experience was that some applicants misused or abused this intention, and as a result, such applicants discovered late in their projects that they were unable to demonstrate compliance and had to repeat some activities. This is also an issue for any  usage of development tools that potentially reduce the resolution of requirements in a project, particularly those that use notations of higher abstraction (e.g., UML or block flow modeling). Applicants using such tools generally are expected to declare if their development processes use such tool’s notation the role of describing either high-level requirements or low-level requirements, but usually not both. Status. In general, CAST Position Papers were issued to harmonize review of software projects conducted under DO-178B or DO-254. But, they were also intended to inform the development and eventual release of DO-178C and supporting publications. As much  of the discussion and rationale recorded in the CASTs is not included in the newer publications, the CASTs remain a source of insight into the updated standards. This CAST-15 Position Paper is no longer provided on the FAA's publications site as the team's concerns were addressed by FAQ #81 in DO-248C, "Supporting Information for DO-178C and DO-278A" and by changes and clarification in the release of DO-178 Revision C: However, neither publication completely incorporates the "full discussion of this topic" that is recorded CAST-15. Much of the same content of the original CAST-15 Position Paper is published in  the 2012 EASA Certificatoin Memo EASA-CM-SWCEH-002 (Section 23 Merging High-Level and Low-Level Requirements). 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. 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, which means that in addition to accomplishing the objectives for High-Level Requirements, the same requirements must also accomplish the objectives for Low-Level Requirements. The concern that prompted CAST-15 is that some applicants for software certification interpreted the above guidance as permitting combining "both" High-Level Software 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 discusses 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 a shorter list of certification concerns for combining (or merging) these two "what" and "how" levels into a single set of requirements without distinguishing the relevant certification objectives of the two levels. 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.