J. Software Engineering & Applications, 2010, 3, 894-900 doi:10.4236/jsea.2010.39105 Published Online September 2010 (http://www.SciRP.org/journal/jsea) Introduction to a Requirements Engineering Framework for Aeronautics Robert Abo Cedric Laboratory, Conservatoire National des Arts et Métiers, Paris, France. Email: [email protected] ABSTRACT This paper introduces a framework to produce and to manage quality requirements of embedded aeronautical systems, called the ‘Requirements Engineering Framework’ (REF). It aims at making the management of the requirement lifecy- cle easier, from the specification of the purchaser’s needs, to their implementation in the final products, and also their verification, while controlling costs. REF is based on the main standards of aeronautics, in particular RTCA DO-254, and RTCA DO-178B standards. An implementation of REF, using the IBM Rational DOORS and IBM Rational Change tools, is also presented in this paper. Keywords: Aeronautics, Requirements Engineering, RTCA DO-254 and RTCA DO-178B Standards, V-Model 1. Introduction presents an implementation of REF, which uses the IBM Rational DOORS tool [6] to manage requirements and to To ensure the safety and the reliability of the aircraft’s carry out requirement traceability, and IBM Rational embedded systems, airworthiness authorities (e.g. US Change tool [7] to manage changes between work teams. Federal Aviation Administration [1], European Aviation Section 4 is dedicated to the safety activities, while Sec- Safety Agency [2], UK Civil Aviation Authority [3], etc.) tion 5 concludes this paper. require that they are built under control of processes based on international standards. Among these standards, 2. Requirements Management the main two used in the civilian domain are the 2.1. System Lifecycle Model well-known RTCA DO-254 ‘Design Assurance Guid- ance for Airborne Electronic Hardware’ standard (aka DO-254 does not prescribe a preferred lifecycle model, EUROCAE ED-80) [4] for hardware components and the nor imply a structure for the performing organization. In RTCA DO-178 ed. B ‘Software Considerations in Air- the same manner, DO-178B does not designate a pre- borne Systems and Equipment Certification’ standard ferred software lifecycle, but describes the separate (aka EUROCAE ED-12) [5] for software components. processes that comprise most lifecycles and the interac- They are referred to as the ‘DO standards’ throughout tion between them. The lifecycle for each project should this paper. be based on selection, and arrangement of processes and In this article, we introduce the ‘Requirements Engi- activities determined by the attributes of the project. neering Framework’ (REF for short), which aims at Several system lifecycle models exist in system engi- producing and managing quality requirements, in order neering, with different approaches on the manner of to produce safe and secure embedded aeronautical sys- leading a project to develop a system: waterfall, V-model, tems, that must adhere to the rigorous constraints of in- iterative, spiral, agile, and so on. Each one has its pros ternational standards, while controlling costs. This is and cons, and it is up to the chief technical officer and achieved by using formalized and mature processes as project leaders to determine the most suitable model to presented in the following sections. The REF described lead the projects of their company. in this article, does not refer to the practices of a particu- REF is based on V-model [8] (aka “Vee model”), lar supplier or a particular firm in aeronautics. which is a variation of the waterfall model. This choice is The rest of this paper is organized as follows. In Sec- explained by its advantages. First, it is simple, well or- tion 2, we present the basic notions of requirements ganized, and easy to use and to implement. In particular, management, which form REF foundations. Section 3 it highlights the correspondences between the develop- Copyright © 2010 SciRes. JSEA Introduction to a Requirements Engineering Framework for Aeronautics 895 ment phases (i.e. the descending stages, from the early system requirements are collected in the ‘System specification to the implementation) and the verification Specification’ (SyS) document. It is possible to phases (i.e. the ascending stages, from the implementa- refine this level, by considering a sub-level dedi- tion to the product delivery). Thus, it facilitates not only cated to the embedded equipment. requirement traceability, but also the production of the 3) The ‘high-level requirements (HLR) level’. The certification documents required by DO standards, as we notion of sub-system appears, and hardware re- will explain in the following sections. Another great ad- quirements are distinguished from software ones vantage of V-model is it can be tailored into a specific at this level. High-level requirements are devel- project-oriented V-model, because it is independent from oped from the analysis and refinement of system any organization and any project. It also provides assis- requirements, system architecture, safety-related tance on the way to implement an activity, and it sup- needs and derived requirements. The latter cor- ports a wide range of development methodologies, in respond to requirements that are the result of the particular formal methods [9-11] often use to develop sub-system development process, and may not be critical parts of systems. directly traceable to high-level requirements. The Among disadvantages of V-model, it is project-oriented HLR are collected in the ‘Hardware Requirement instead of addressing the development of systems within Specification’ (HRS) and the ‘Software Re- a whole organization. Another V-model disadvantage is quirement Specification’ (SRS) documents. it fails at covering the maintenance of systems. But, these 4) The ‘low-level requirements (LLR) level’. disadvantages do not impact REF. Low-level requirements are developed from the high-level requirements, sub-system architecture, 2.2. Basics and design constraints, by refinement and refor- The concept of requirement is in the middle of systems mulation. The hardware and software subsystems engineering, as the abundant literature on the subject are directly developed from the LLR. The LLR attests it [12-15]. We define a ‘requirement’ as a cus- are collected in the ‘Hardware Design Document’ tomer’s elementary need that is to be implemented in the (HDD) and the ‘Software Design Document’ product or service that he receives1. In systems engineer- (SDD). ing, we can refine this rough definition by distinguishing 5) The ‘implementation level’ is the last level and the characteristics of the system to be built, known as the marks the end of the descending phase of the functional requirements, from the ways the system V-model. It corresponds to the hardware compo- achieves its functions, known as the non-functional re- nents and the source code. The implementation of quirements (e.g. performance, quality, interface require- a requirement consists in giving this requirement ments, etc.). We can also differentiate the customer’s an existence from its specification as it appears in needs, from which the supplier’s distributed requirements the HDD (for hardware components) or in the are issued, among three hierarchical levels, which are the SDD (for software components). system, the high-level and the low-level requirements Requirements are fundamental. Firstly, the supplier’s sets. From now on, by “customer”, we mean not only the requirements formalize the customer’s needs. The sup- purchaser of the building system, but also the supplier’s plier ensures the comprehension of the customer’s needs, teams who require services from other ones along an that he has translated this into a form he can use without enterprise workflow dedicated to requirements manage- any misunderstanding. Secondly, requirements allow the ment. Thus, we distinguish four main requirement levels identification of the characteristics of the customer’s according to their refinement level, plus a requirement needs. Finally, requirements simplify the taking into ac- implementation level as shown in Figure 1: count of customer’s needs along V-model by formalizing 1) The ‘purchaser’s level’ corresponds to the pur- them. They show the customer that the final product an- chaser’s specifications seen as a set of rough swers the needs he has expressed. needs developed in the ‘Purchaser Specification’ 2.3. Requirements Specification (PuS) document. 2) The ‘system level’: the purchaser’s needs are re- It consists of specifying the requirements. In particular, fined and reformulated, by using technical terms engineers have to define the bi-directional and vertical understandable for the development teams. The traceability between the upper and lower requirements. The main objective of the requirement traceability is to 1DO-254 defines a requirement as “an identifiable element of a speci- fication that is verifiable” [4]. DO-178B defines a software require- show that the purchaser’s needs are satisfied by system ment as “a description of what is to be produced by the software given requirements, high-level requirements, and low-level the inputs and constraints” [5]. requirements; and then implemented into the hardware Copyright © 2010 SciRes. JSEA 896 Introduction to a Requirements Engineering Framework for Aeronautics ferred to as Level A or Level B by the DO-178B stan- dard2. Project managers and team leaders must organize the work of the engineers taking this into account. A spe- cific team performs the safety activities as described in Section 4. 2.6. Requirements Verification This activity deals with the rise of V-model. It consists in evaluating the implementation of the supplier’s require- ments to determine, whether or not, they have been met. There are several means of verification: tests, code analysis, model checking, simulation, etc. For aeronau- tics real-time embedded software, the low-level require- ments are often implemented by using the Esterel Tech- nologies’ SCADE Suite [16]. This tool complies with DO-178B, and allows for generation of a certified source Figure 1.