Building a Software Requirements Specification and Design for an Avionics System An Experience Report Andrés Paz and Ghizlane El Boussaidi École de Technologie Supérieure Montreal, Canada April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition
Outline • Context, motivation and related work • Methodology for requirements specification and design • Case study • Lessons learned, challenges and issues • Conclusions and future work April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 2
Outline • Context, motivation and related work • Methodology for requirements specification and design • Case study • Lessons learned, challenges and issues • Conclusions and future work April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 3
DO-178C • DO-178C is a guideline identifying the set of best practices for the development of airworthy software. • Certification of compliance is mandatory and evidence-based. - All compliance claims must be backed by evidence artifacts ( a.k.a. data items). • Supplemental document DO-331 and DO-332 modify the guideline to support model-based and object-oriented developments, respectively. April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 4
Motivation • Avionics case studies are rarely publicly available. • Available descriptions of avionics systems rarely talk about the software. • Avionics systems as described in the literature do not allow for their use as benchmarks for avionics software development approaches targeting certification with DO-178C. April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 5
Related Work Case study... Study Representative of Openly Covers requirements specification and Supported by industrial needs available design according with DO-178C methodology Compliance with regulation is not Leveson et al. , 1994 ✓ discussed Zoughbi et al. , 2011 ✓ According with DO-178B Wu et al. , 2015 ✓ Only software architecture Requirements and design have White et al. , 2012 ✓ shortcomings Compliance with regulation is not Schamai et al. , 2015 ✓ discussed Compliance with regulation is not Boniol et al. , 2014 ✓ ✓ discussed Ours (based on Boniol et ✓ ✓ ✓ ✓ al. , 2014) April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition 6 �
Outline • Context, motivation and related work • Methodology for requirements specification and design • Case study • Lessons learned, challenges and issues • Conclusions and future work April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 7
Methodology • No methodology for building software requirements specifications and design following DO-178C has been reported in the literature. • Our methodology encompasses the general flow for requirements specification and design defined in DO-178C. • As a means for quality assurance several industrial experts validated both the methodology and its outputs for the case study. April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 8
Methodology • Exhibits the sequential nature promoted by DO-178C. • 3 major activities: Develop HLRs , Develop Software Architecture and Develop LLRs . • Actions within the activities are organized to form iterative and incremental cycles. act Software requirements specification and design Operational Context SRATS SRATS: System Requirements Allocated To Software Potential Develop Software Develop HLRs Develop LLRs LLRs CFCs Architecture CFC: Contribution to Failure Condition HLR: High-Level Requirement Software HLRs Architecture LLR: Low-Level Requirement April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition 9 �
Develop HLRs Operational Potential SRATS Context CFCs Develop HLRs Review SRATS for Review [else] Review level ambiguities, inconsistencies preclusion of of refinement and undefined conditions CFCs [SRATS need clarification or correction] [SRATS are [SRATS are Request clarification or detailed not detailed correction to system processes enough enough for for software software Clarified/Corrected design] design] SRATS received Define SRATS as the HLRs Develop an HLR in terms of [HLR cannot be controllable and monitorable traced to SRATS] variables, and trace to SRATS Develop Label HLR as rationale a derived [else] requirement Review HLR for ambiguity, Review inconsistencies or undefined preclusion of Clarification or correction conditions CFCs to HLR(s) requested [HLR is detailed enough for software design] Clarified/Corrected HLR(s) [HLR is not detailed Review completeness enough Develop HLR into more for software detailed HLR(s) and trace design] to SRATS [no additional HLRs are required to capture [additional HLRs are required to capture the SRATS’ intent] the SRATS’ intent] April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition 10 �
Develop Software Architecture Operational HLRs Context Develop Software Architecture Identify software [else] Identify/Define components and architectural style allocate to HLRs [clarifications or corrections Request clarification or required in HLRs] correction of HLR(s) Allocate components Identify and define dependencies to HLRs between components in terms of Clarified/Corrected provided and required interfaces HLR(s) received Identify software Review completeness Define data dictionary design patterns [additional components Identify additional are required to cover the HLRs] software components and allocate to HLRs [no additional components are required to cover the HLRs] [no additional classes are Identify class hierarchies realizing a required to realize the component] component and allocate to the component’s associated HLRs [additional classes are required to realize the component] April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition 11 �
Develop LLRs For textual LLRs For model-based LLRs Software Software HLRs HLRs Develop LLRs Develop LLRs Architecture Architecture Clarified/Corrected Clarified/Corrected HLR(s) received HLR(s) received Request clarification or Request clarification or correction of HLR(s) correction of HLR(s) Allocate Allocate LLR [clarifications or [clarifications or element(s) to to HLRs corrections corrections HLRs required in HLR(s)] required in HLR(s)] Define behaviour of a Allocate state machine Develop an LLR in terms of a realizing class’s [else] [else] [else] [else] realizing class in terms elements to the class’s controllable and monitorable variables and trace of a state machine associated HLRs to the class’s associated HLRs [element(s) cannot [LLR cannot be be traced to HLR(s)] traced to HLR(s)] Label LLR(s) Label LLR as a Review level Review level as a derived derived LLR of refinement of refinement LLR(s) [Source code cannot [Source code cannot be directly implemented Refine LLR into more [additional LLRs are be directly implemented without further information] Refine behaviour of required for the class detailed LLR(s) and trace without further information] [additional realizing class into more or additional realizing to HLRs realizing specific behaviour classes need to be [Source code can be [Source code can be classes need to specified] directly implemented be specified] directly implemented without further information] Review completeness without further information] Review completeness [no additional [no LLRs are required and no additional realizing classes need to be specified] additional realizing classes need to be specified] April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition 12 �
Outline • Context, motivation and related work • Methodology for requirements specification and design • Case study • Lessons learned, challenges and issues • Conclusions and future work April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 13
Case Study Overview • We adapted the case study developed by Boniol et al. for the ABZ 2014 Conference. • Our case study addresses the development of the software controlling the operation of a retractable landing gear in a tricycle configuration. - Landing Gear Control Software (LGCS) • We organized the case study in several chapters corresponding to DO-178C data items: - Plan for Software Aspects of Certification (PSAC) - Software Development Standards (contains requirements, design and code standards) - Requirements Data (contains SRATS and HLRs) - Design Description (contains Software architecture and LLRs) April 9 - 13, 2018 33 rd ACM/SIGAPP Symposium on Applied Computing Pau, France Requirements Engineering Track - 11 th Edition � 14
Recommend
More recommend
