Analysis of information sources in references of the Wikipedia article "CAST-15" in English language version.
... For the most part, software system requirements can be traced back to ... system requirements. Software requirements can be further broken down into high level requirements and detailed (low-level) requirements. High level requirements describe functional aspects of the system; i.e., they describe "what" is being designed. Low level requirements describe the actual design of the software; i.e., "how" the software is designed. Traceability ensures that all the requirements have been implemented as software functions (forward traceability) and, conversely, that all implemented functions are linked to a requirement (backward traceability). For an interesting discussion on this topic the reader may look at a short position paper issued by the Federal Aviation Administration [8] ... [8] FAA Certification Authorities Software Team (CAST), Merging High-Level and Low-Level Requirements, Position Paper, CAST-15, February 2003 [emphasis added]
... Certification Authorities Software Team (CAST)* paper CAST-15 ... warn against merging software requirements into a single level. There are a few projects where one level of software requirements is needed (...) but they are in the minority.
Another related issue is that DO-178B allowed for the possibility of a single level of requirements, in which case the high-level requirements are also considered low-level requirements. The intent was to avoid forcing the creation of two levels of requirements even for trivially simple software applications. Applicants sometimes misuse this paragraph to justify producing a single level of requirements for complex software applications. This may result in a development process that does not comply with DO-178B. This was the topic of Certification Authorities Software Team (CAST) positions paper CAST-15 …. A note was added to section 5 that the applicant may be required to justify software development processes that produce a single level of requirements. A full discussion of this topic may be found in CAST-15. [emphasis added]
[citing CAST-15] In safety-related applications these principles usually drive the software requirement decomposition to two distinct levels. High-Level Requirements (HLR) detail 'what is required' in the design. These are then systematically decomposed into Low-Level Requirements (LLR), which provide coders with information on 'how to implement' that design. To minimize ambiguity LLR often include pseudo-code or mathematical formulae. ... Certification Authorities Software Team (CAST). 2003. Merging High-Level and Low-Level Requirements. Position Paper CAST-15, completed February 2003.
The following sections of the guidance of this Certification Memorandum do not correspond to the contents of FAA Order 8110.49, but they do correspond to the contents of existing CAST Papers ... Section 21, Merging High-Level and Low-Level Requirements (CAST 15)
DO-178B [27] specifies that the software requirements should be organized into high-level and low-level software requirements. Also, the high-level software requirements should comply with the system requirements (objective 1 of table A-3 in appendix A), and the low-level software requirements should comply with the high-level software requirements (objective 1 of table A-4 in appendix A). These are defined in DO-178B as
High-level requirements: Software requirements developed from analysis of system requirements, safety-related requirements, and system architecture.
Low-level requirements: Software requirements derived from high-level requirements, derived requirements, and design constraints from which source code can be directly implemented without further information.
According to Position Paper CAST-15 (Certification Authorities Software Team) [15], the HLR generally represent "what" is to be designed and LLR represent "how" to carry out the design. [emphasis added]
{{cite book}}: CS1 maint: multiple names: authors list (link)The DO-178B defines two levels of software requirements. The SW-HLR usually represents "what" is to be designed and SW-LLR represents "how" to carryout the design. .... This formalized design should contain sufficient details of such aspects as code structures and data/control flow for source code to be produced directly from it, either manually or by the use of a tool, without any further information.
{{cite journal}}: CS1 maint: multiple names: authors list (link)In addition, the CAST-15 position paper provides guidance that for software requirements a high-level requirements document should describe the "what" and a low-level requirements document should describe the "how". [emphasis added]
Example 4 is reasoned with the higher abstraction of Design Models compared to LLRs. For example, traditional HLRs often contain figures of state diagrams or truth tables. These diagrams are very close to the implementation in SF. In such cases, separate HLRs are just an artificially introduced level leading to "copy-and-paste development". Important to mention is that this workflow does not merge HLRs and LLRs, since the system requirements take over the role of HLRs including all necessary activities and objectives (cf. DO-331 MB.5.0). The concerns of Position Paper CAST-15 "Merging High-Level and Low-Level Requirements" [87] are not applicable.