CAST-15

From Wikipedia, the free encyclopedia
Merging High-Level and Low-Level Requirements
US-FederalAviationAdmin-Seal.svg
FAA Publication
AbbreviationCAST-15
Year started2003
OrganizationCertification Authorities Software Team
DomainAvionics, type certification

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,[1] but warned against the practice in general.[2] The paper is also an example of Certification Authorities using the "what" versus "how" distinction[3] between high-level and low-level requirements[4][5][6] 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.[7]

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.[8]

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[9] and by changes and clarification in the release of DO-178 Revision C:

  • The FAQ was originated by European Certification Authorities who were concerned with the risk of applicants developing untraceable and unverifiable gaps in their requirements, and it does not recommend merging high and low levels of requirements into a single level.[10]
  • The note "The applicant may be required to justify software development processes that produce a single level of requirements." was added to DO-178C Section 5.0, page 31.[1][11]

However, neither publication completely incorporates the "full discussion of this topic"[1][4] 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 (Section 23 Merging High-Level and Low-Level Requirements).[12]

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.[13]

  • High-Level Requirements are essentially those System Requirements that are allocated to the Software Product (an outside view of what the full Software Product shall be and do).
  • 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 (an inside view of how the Software Product shall be implemented do it).[14]

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.[14]

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.[15] 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.[16]

References[]

  1. ^ a b c Daniels, Dewi (January 1, 2001). "Are we there yet? A practitioners View of DO-178C/ED-12C". In Chris Dale, Tom Anderson (ed.). Advances in Systems Safety: Proceedings of the Nineteenth Safety-Critical Systems Symposium, Southhampton, UK, 8-10th February 2011. Springer Publishing. p. 299. ISBN 978-0-85729-132-5. 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]
  2. ^ Leanna Rierson (19 December 2017) [7 January 2013]. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance. CRC Press. p. 114. ISBN 9781351834056. Retrieved 2022-02-14. ... 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.
  3. ^ Rierson, p. 113, "In order to avoid this slippery slope, I suggest that engineers ... Clearly define the division between requirements (what) and design (how) .... "
  4. ^ a b Volponi, Allan J.; Rajamani, Ravi (2012). "12. Hybrid Models for Engine Health Management". In Ashok N. Srivastava, Jiawei Han (ed.). Machine Learning and Knowledge Discovery for Engineering Systems Health Management. Data Mining and Knowledge Discovery Series. Chapman & Hall/CRC Press. p. 299. ISBN 978-1-4398-4179-2. ... 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]
  5. ^ Jamie P. White, Hassan Reza (2012). "Deriving DO-178C Requirements Within the Appropriate Level of Hierarchy". ICSEA 2012 : The Seventh International Conference on Software Engineering Advances. p. 432. ISBN 978-1-61208-230-1. Retrieved 2022-02-08. 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]
  6. ^ Raymond G. Estrada, Eric Dillaber, Gen Sasaki (2013). "Best practices for developing DO-178 compliant software using Model-Based Design". AIAA Guidance, Navigation, and Control (GNC) Conference (PDF). Retrieved 2022-02-08. 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)
  7. ^ Jamie P. White, Hassan Reza, p. 432. "The end goal is to place requirements in the requirements document that provides the most visibility to the stakeholders while preserving the scope of the document. Hence, there is a fine line between putting too much information in a high-level requirements document and providing an appropriate amount of visibility to stakeholders."
  8. ^ Raymond G. Estrada, Eric Dillaber, Gen Sasaki, "... [15]. This is because of the different purposes of each level of requirements; HLR state what the system software is to do, while the LLR state how it is done and what components are used to do it. Verification must be performed on the data for both HLR and LLR separately, and merging the two may make this impossible. Note that although Section 5 of DO-178C allows a single level of requirements, it is typically not done because it requires the system level requirements to contain additional detail to allow traceability to the combined HLR/LLR data item."
  9. ^ Rierson, p. 113, "DO-248C's FAQ #81 ... and the ... CAST-15"
  10. ^ Frédéric Pothon, ACG Solutions, "DO-178C/ED-12C versus DO-178B/ED-12B - Changes and Improvements", 2012. "The main concern is possible gaps in the requirement refinement, which prevent a sufficient traceability analysis and thus compliance with verification objectives."
  11. ^ "DO-178B/C Differences Tool" Revision: 008, page 12, etc., 2013. "If the developer is proposing merging of high level and low level requirements, the ASE will find the justification and determine whether the reasoning supports a smooth transition between abstraction layers of system and the single level of requirements. Some indications where this may not be appropriate would be single system requirements tracing to an inordinately large number of merged high/low level requirements."
  12. ^ EASA, CM-SWCEH-002, "Software Aspects of Certification", p. 12, 2012. "The following sections of the guidance of this Certification Memorandum do not correspond to the contents of , but they do correspond to the contents of existing CAST Papers ... Section 21, Merging High-Level and Low-Level Requirements (CAST 15)" [emphasis added]
  13. ^ 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."
  14. ^ a b 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."
  15. ^ Raymond G. Estrada, Eric Dillaber, Gen Sasaki, "Merging the HLR and LLR into a single model or data item is not recommended [15]."
  16. ^ 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, ...."

External links[]


Stub icon

This aviation-related article is a stub. You can help Wikipedia by .

  • v
  • t
Retrieved from ""