CAST-15

CAST-15
상위 레벨 요구사항과 하위 레벨 요구사항의 병합
Seal of the United States Federal Aviation Administration.svg
FAA 출판물
약어CAST-15
시작한 해2003
조직인증 기관 소프트웨어 팀
도메인항전 장치, 형식 인증

CAST-15, 상위 및 하위 요구사항 병합은 인증 기관 소프트웨어 팀(CAST) 입장 문서입니다.이 문서는 "어떤 기관의 공식 정책이나 지침을 구성하지 않는다"는 FAA 간행물이지만, 교육 및 정보 제공 목적으로만 소프트웨어 및 하드웨어 인증 신청자에게 제공됩니다.

FAA 권고 회람 AC 20-115에 의해 규정된 바와 같이, RTCA 간행물 DO-178B/C는 공기 가능한 소프트웨어의 허용 가능한 인증 수단을 정의합니다.특이하게도 DO-178B는 공기 가능한 [1][2]소프트웨어를 개발할 때 소프트웨어 요구사항 분석 및 설계의 공식 제품으로 높은 수준의 요구사항과 낮은 수준의 요구사항을 구분했습니다.

DO-17B/C는 이 두 가지 수준의 요구사항에 서로 다른 목표 세트를 할당했습니다.규정 준수를 달성하기 위해서는 신청자가 두 가지 목표를 모두 충족해야 합니다.그러나 좁은 조건에서 이 표준의 지침은 이 두 수준을 하나의 요구사항 수준으로 결합하는 것을 허용하지만 [3]일반적으로 관행에 대해 경고합니다.

이 포지션 문서는 이 지침의 관찰된 오용과 관련이 있습니다. 일부 지원자는 "단순한" 제품에 대한 높은 수준의 요구사항과 낮은 수준의 요구사항을 결합하고 있었지만 두 요구사항 [4]모두에 대한 관련 목표를 모두 달성하지 못했습니다.

또한 이 입장 문서는 DO-178B/C가 명확하게 설명하지 않는 높은 수준의 요구사항과[6][7][8] 낮은 수준의 요구사항 사이의 "무엇" 대 "어떻게" 구별을[5] 사용하는 인증 기관의 예입니다.

배경

소프트웨어 정의 및 검증을 위한 다양한 이해 관계자들은 서로 다른 목표와 추상화 수준을 가지고 있습니다.높은 수준의 소프트웨어 제품 기능을 정의하거나 확인하는 책임을 지는 이해 관계자는 일반적으로 제품의 외부 인터페이스 구조와 동작에 관심이 있으며, 내부 소프트웨어 구조의 세부 사항이 이러한 초점을 반드시 지원하는 것은 아닙니다.반면, 모든 내부 코드의 요구 사항 적용 범위를 정의하고 검증하는 담당자는 내부 소프트웨어 구조에 대한 훨씬 더 상세한 정보를 필요로 합니다.이는 DO-178B/C가 대규모 [9]프로젝트에서 추가 요구사항 계층화를 개발하는 지원자를 고려하여 높은 수준과 낮은 수준의 요구사항에 대한 뚜렷한 목표를 설정하는 이유입니다.

그러나 DO-178B는 특히 단순한 시스템에 대한 한 가지 수준의 요구사항만 개발할 수 있는 가능성을 허용했습니다.즉, 인증 기관(예: FAA 지정 엔지니어링 담당자)은 필요 이상의 요구사항 계층을 기대하지 않습니다.그러나 인증 당국의 경험에 따르면 일부 지원자가 이러한 의도를 잘못 사용하거나 남용했으며, 그 결과 해당 지원자는 프로젝트에서 규정 준수를 입증할 수 없고 일부 활동을 반복해야 한다는 것을 뒤늦게 알게 되었습니다.

이는 프로젝트의 요구사항 해결을 잠재적으로 감소시키는 개발 도구의 사용, 특히 UML 또는 블록 흐름 모델링과 같은 상위 추상화 개념을 사용하는 개발 도구의 사용에도 문제가 됩니다.이러한 도구를 사용하는 신청자는 일반적으로 개발 프로세스가 이러한 도구의 표기법을 사용할 경우 높은 수준의 요구사항 또는 낮은 수준의 요구사항을 설명하는 역할을 수행하지만 일반적으로 [10]둘 다 수행하지는 않는다고 선언해야 합니다.

상황

일반적으로, CAST Position Paper는 DO-178B 또는 DO-254에 따라 수행된 소프트웨어 프로젝트의 검토를 조화시키기 위해 발행되었습니다.그러나, 그들은 또한 DO-178C와 지원 간행물의 개발과 최종 출시를 알리기 위한 것이었습니다.CAST에 기록된 많은 토론과 이론적 근거는 새로운 출판물에 포함되지 않기 때문에 CAST는 업데이트된 표준에 대한 통찰력의 원천으로 남아 있습니다.

이 CAST-15 입장 문서는 FAA의 간행물 사이트에서 더 이상 제공되지 않습니다. 팀의 우려 사항이 DO-248C의 FAQ #81, DO-178C 및 DO-278A에[11] 대한 지원 정보 및 DO-178 개정 C: 릴리즈의 변경 사항과 명확성으로 해결되었기 때문입니다.

  • FAQ는 유럽 인증 기관에서 지원자의 요구 사항에 추적 불가능하고 검증 불가능한 차이가 발생할 위험을 우려하여 시작되었으며, 높은 수준과 낮은 수준의 요구 사항을 단일 수준으로 통합할 [12]것을 권장하지 않습니다.
  • DO-178C 섹션 5.0,[4][13] 31페이지에 "신청자는 단일 수준의 요구사항을 생성하는 소프트웨어 개발 프로세스를 정당화해야 할 수 있습니다."라는 주석이 추가되었습니다.

그러나 두 출판물 모두 CAST-15에 기록된 "이 [4][6]주제에 대한 완전한 논의"를 완전히 포함하지 않습니다.

원본 CAST-15 Position Paper의 대부분의 동일한 내용은 2012 EASA 인증 메모 EASA CM-SWCEH-002에 게시됩니다(23절 높은 수준과 [14]낮은 수준의 요구사항 병합).

내용물

DO-178C/DO-178B는 높은 수준과 낮은 수준의 소프트웨어 요구사항을 통합하기 위한 지침을 제공합니다.일반적으로, DO-178C/DO-178B 맥락에서, 인증된 소프트웨어 제품에 대한 높은 수준의 요구사항은 낮은 수준의 소프트웨어 요구사항과 구별됩니다. 전자는 소프트웨어 요구사항 프로세스의 출력이고 후자는 소프트웨어 설계 [15]프로세스의 출력입니다.

  • 상위 레벨 요구사항은 기본적으로 소프트웨어 제품에 할당된 시스템 요구사항입니다(전체 소프트웨어 제품이 무엇이 되어야 하며 무엇을 해야 하는지에 대한 외부 견해).
  • Low-Level Requirements는 Low-Level Requirements(로우-Level Requirements)에서 소스 코드를 직접 생성, 검토 및 테스트할 수 있도록 요구 사항을 분해하고 구체화한 결과입니다(소프트웨어 제품이 [16]이를 구현하는 방법에 대한 내부 견해).

일부 응용 프로그램에서는 시스템/고급 요구 사항이 소스 코드를 직접 생성하고 검증할 수 있을 정도로 단순하고 상세합니다.이 경우 시스템/고급 요구사항은 저수준 요구사항으로 간주됩니다. 즉, 고급 요구사항에 대한 목표를 달성하는 것 외에도 동일한 요구사항이 저수준 [16]요구사항에 대한 목표를 달성해야 합니다.

CAST-15를 촉발시킨 우려는 일부 소프트웨어 인증 신청자들이 위의 지침을 단일 소프트웨어 요구사항 문서 또는 기타 아티팩트에 높은 수준의 소프트웨어 요구사항과 낮은 수준의 소프트웨어 요구사항을 모두 결합할 수 있도록 허용하는 것으로 해석했다는 것입니다.이는 낮은 수준이지만 낮은 수준과 높은 수준 요구사항 간의 추적성을 생략하고 시스템 안전을 포함한 시스템 프로세스에 대한 피드백을 위해 파생된 요구사항을 식별하는 것을 게을리합니다.

본 포지셔닝 문서에서는 인증 기관이 낮은 수준의 요구사항을 높은 수준의 요구사항 모음에 병합할 때 발생하는 몇 가지 문제와 위험에 대해 설명하며, 이를 수행하지 [17]말 것을 권장합니다.DO-178C 및 DO-278A에 대한 DO-248C 지원 정보의 FAQ #81에 게시된 대체 컨텐츠는 두 레벨의 관련 인증 목표를 구별하지 않고 이 두 "무엇" 및 "어떻게" 레벨을 단일 요구사항 세트로 결합(또는 통합)하기 위한 인증 관련 문제 목록을 제공합니다.또한 FAQ #81은 원래 DO-178B/C 지침이 허용하는 대로 요구사항의 "단일 단계"에서 코드를 작성하고 검증할 수 있는 경우에도 High-Level과 Low-Level을 통합하지 않을 것을 권장하지만,[18][19] 우려 사항을 해결하는 방법에 대한 제안을 제공합니다.

모델 기반 개발

높은 수준의 요구사항과 낮은 수준의 요구사항을 구분하거나 조합하는 것은 모델 기반 개발에서 특히 중요한 문제입니다.공급업체와 신청자가 공수 소프트웨어 개발에 모델 기반 개발 도구를 사용함에 따라 자동화 및 인증 증거 수준 제거에 대한 우려가 제기됩니다.어떤 모델 기반 아티팩트가 높은 수준의 요구 사항을 나타내고 어떤 것이 낮은 수준의 요구 사항을 나타내는지에 대한 신중한 지정을 위한 주장이 제기됩니다.마지막으로, DO-178C의 보완물인 표준 DO-331(모델 기반 개발 및 검증)은 높은 수준의 요구사항은 모델이 개발된 모델 이전에 위치한 요구사항이며, 낮은 수준의 요구사항은 모델 자체에 위치한 요구사항임을 명시하면서 이러한 측면을 명확히 했습니다.DO-331은 모델 기반 개발에 대한 문제를 명확히 했고, CAST-15의 레벨 병합 문제는 모델 기반 [20]개발에 적용되지 않습니다.

레퍼런스

  1. ^ David L. Lempia and Steven P. Miller (2009). DOT/FAA/AR-08/32 Requirements Engineering Management Handbook (PDF). Federal Aviation Administration. Retrieved 2022-07-09. 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.
  2. ^ Johnny Cardoso Marques, Sarasuaty Megume Hayashi Yelisetty, Luiz Alberto Vieira Dias,Adilson Marques da Cunha (2012). "Using Model-Based Development as Software Low-Level Requirements to Achieve Airborne Software Certification". Conference: Information Technology: New Generations (ITNG). Retrieved 2022-07-09. 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 유지보수: 다중 이름: 작성자 목록(링크)
  3. ^ 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.
  4. ^ 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, Southampton, 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]
  5. ^ Rierson, 페이지 113, "이 미끄러운 경사를 피하기 위해, 저는 기술자들이...요구사항(무엇)과 설계(방법) 사이의 구분을 명확히 정의합니다."
  6. ^ 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]
  7. ^ 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]
  8. ^ 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 유지보수: 다중 이름: 작성자 목록(링크)
  9. ^ 제이미 P.White, Hassan Reza, p. 432. "최종 목표는 문서의 범위를 유지하면서 이해관계자에게 가장 많은 가시성을 제공하는 요구사항 문서에 요구사항을 배치하는 것입니다.따라서 높은 수준의 요구사항 문서에 너무 많은 정보를 넣는 것과 이해관계자에게 적절한 가시성을 제공하는 것 사이에는 미묘한 차이가 있습니다."
  10. ^ 레이먼드 G. 에스트라다, 에릭 딜라버, 사사키 장군, "... [15].이는 각 요구 사항 수준의 목적이 다르기 때문입니다. HLR은 시스템 소프트웨어가 수행해야 할 작업을 명시하고 LLR은 수행 방법과 수행에 사용되는 구성 요소를 명시합니다.HLR과 LLR의 데이터에 대해 개별적으로 검증을 수행해야 하며, 두 데이터를 병합하면 검증이 불가능해질 수 있습니다.DO-178C의 섹션 5는 단일 수준의 요구사항을 허용하지만, 결합된 HLR/LLR 데이터 항목에 대한 추적 가능성을 허용하기 위해 시스템 수준 요구사항에 추가 세부사항이 포함되어야 하기 때문에 일반적으로 수행되지 않습니다."
  11. ^ Rierson, 페이지 113, "DO-248C의 FAQ #81... 그리고...CAST-15"
  12. ^ Fredéric Pothon, ACG Solutions, "DO-178C/ED-12C 대 DO-178B/ED-12B - 변경 및 개선", 2012."주요 관심사는 요구사항 개선에 있어 충분한 추적성 분석을 방해하여 검증 목표를 준수하지 못할 수 있다는 것입니다."
  13. ^ "DO-178B/C 차이점 도구" 개정판: 008, 12페이지 등, 2013."개발자가 높은 수준과 낮은 수준의 요구사항을 병합할 것을 제안하는 경우, ASE는 정당성을 찾고 추론이 시스템의 추상화 계층과 단일 요구사항 수준 간의 원활한 전환을 지원하는지 여부를 결정합니다.이것이 적절하지 않을 수도 있는 몇 가지 징후는 단일 시스템 요구사항을 지나치게 많이 병합된 상위/하위 레벨 요구사항으로 추적하는 것입니다."
  14. ^ "Software Aspects of Certification" (PDF). Certification Memorandum. EASA (CM-SWCEH-002 Issue 1): 12. 9 March 2012. Retrieved 2023-04-19. 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)
  15. ^ RTCA/DO-248C "DO-178C 및 DO-278A 지원 정보", FAQ #81, 43-44페이지"공중 소프트웨어 구성요소가 크거나 복잡할 때 소프트웨어 요구사항 프로세스는 HLR을 생성하고 소프트웨어 설계 프로세스는 LLR과 아키텍처를 생성합니다.따라서 HLR과 LLR은 동일한 개발 프로세스의 결과물이 아닙니다."
  16. ^ a b RTCA/DO-178C "항공 시스템 및 장비 인증의 소프트웨어 고려사항", 페이지 31. "저수준 요구사항은 추가 정보 없이 소스 코드를 직접 구현할 수 있는 소프트웨어 요구사항입니다." ... "그러나 소스 코드가 고수준 요구사항에서 직접 생성된 경우,높은 수준의 요구사항도 낮은 수준의 요구사항으로 간주되며 낮은 수준의 요구사항에 대한 지침도 적용됩니다."
  17. ^ Raymond G. Estrada, Eric Dillaber, Gen Sasaki, "HLR과 LLR을 단일 모델 또는 데이터 항목으로 통합하는 것은 권장되지 않습니다 [15]."
  18. ^ RTCA/DO-248C "DO-178C 및 DO-278A 지원 정보", FAQ #81, 43-44페이지"시스템 레벨 요구사항이 한 번의 개선 단계에서 코딩에 적합한 소프트웨어 요구사항으로 세분화되는 시스템이 있을 수 있습니다.이 경우 단일 수준의 소프트웨어 요구사항이 실현 가능할 수 있지만..."
  19. ^ Alec Banks and Rob Ashmore (2019). "Requirements Assurance in Machine Learning" (PDF). CEUR Workshop Proceedings. CEUR Workshop (CEUR-WS.org). 2301 (paper 8). Retrieved 2022-07-09. [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.
  20. ^ Markus Tobias Hochstrasser (2020). Modular model-based development of safety-critical flight control software (PDF). Universitätsbibliothek der TU München. Retrieved 2022-07-09. 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.

외부 링크

  • 웨이백 머신의 CAST-15 (2017-08-29(Date mismatch) 아카이브).2021-12-03을 검색했습니다.