Paper REJ-desafios

Paper REJ-desafios
of 22
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
  Noname manuscript No. (will be inserted by the editor) Requirements Communication in Safety-Critical Systems: ASystematic Literature Review J´essyka Vilela  ·  Jaelson Castro  ·  Luiz Eduardo G. Martins  ·  TonyGorschek  ·  Camilo Almendra Received: date / Accepted: date Abstract Context:  Safety-critical systems (SCS) aremainly controlled by software. Accordingly, the devel-opment of these systems must be carefully plannedsince inadequate or misunderstood requirements havebeen recognized as the major cause of a significantproportion of accidents and safety-related catastrophes.However, requirements engineers, traditionally, are notfamiliar with system safety analysis processes whichare performed by safety engineers. The existing gapamong the traditional development processes, method-ologies, notations and tools used in safety engineeringcontributes to this unfamiliarity.  Objective:  This gapmotivated us to investigate the integration and require-ments communication in the requirements engineering(RE) process among different parties when developingSCS.  Method:  We used a Systematic Literature Re-view (SLR) as the basis for our work.  Results:  Weanalyze the challenges and needs involved in the com-munication, the application context, the research type, J. VilelaCampus Quixad´a, Universidade Federal do Cear´a, Brazil andCentro de Inform´atica, Universidade Federal de Pernambuco,Brazil E-mail: jessykavilela@ufc.brJ. CastroCentro de Inform´atica, Universidade Federal de Pernambuco,Brazil E-mail: jbc@cin.ufpe.brL. MartinsDepartamento de Ciˆencia e Tecnologia, Universidade Federalde S˜ao Paulo, Brazil E-mail: legmartins@unifesp.brT. GorschekBlekinge Institute of Technology (BTH), Sweden E-mail:tony.gorschek@bth.seC. AlmendraCampus Quixad´a, Universidade Federal do Cear´a, Brazil andCentro de Inform´atica, Universidade Federal de Pernambuco,Brazil E-mail: the evaluation methods, the type of contribution, thedomain, the requirements activity as well as the lan-guages and tools used to specify the safety require-ments. Furthermore, we also analyze the stakehold-ers involved, the communication format, and for whatsafety standards have the approaches been proposed.We conclude our investigation with open issues.  Con-clusions : We believe the results of such a study willbenefit both researchers and practitioners. This infor-mation contributes to setting up possible collaborativenetworks and as a reference when developing new re-search projects. Keywords  Safety-Critical Systems  ·  RequirementsCommunication  ·  Requirements Engineering  ·  SafetyEngineering  ·  Systematic Literature Review 1 Introduction Safety-critical systems are mainly controlled by soft-ware nowadays [1][2] [90][91][92]. New generations of medical devices, means of transportation (aircraft, au-tomated trains and cars), nuclear power generating sta-tions, banking and investment systems [92], as well as agrowing number of automated systems rely on softwareto enable new functions, provide pre-existing functionsmore efficiently, and reduce time to service a user needas well as the effort and competence required by peopleproviding services [2] [92].There are many cases in the literature [3][4][1] whereinadequate or misunderstood requirements were themajor cause (not coding or implementation [76]) of a significant proportion of accidents [68] and safety-related catastrophes [52].When developing SCS, RE activities are criticalto avoid the introduction of defects and misunder-  2 J´essyka Vilela et al. standings among engineers and developers [4][5][87].An elaborated RE approach is crucial in order tomeet time, cost, and quality goals in SCS development[91][92]. Therefore, these systems must be carefullyspecified, demanding more rigorous RE approaches[2][4][52][56][65][90].RE focuses on good specification practices but hasyet to find working solutions for effective require-ments communication [88]. An efficient communicationthroughout the entire project life-cycle is a key factor indeveloping and releasing successful software products tothe market [6] [87]. The requirements communication isthe process of informing all stakeholders of the content,meaning and status of requirements. It starts with thecustomer [88] and involves different roles (e.g. require-ments engineers, developers, testers, and safety engi-neers) throughout the project development [2][6][87].Joint and collaborative work [7] activities are oneaspect of the requirements communication in the REprocess [1][87][89][90] [91]. Another critical aspect isthe use of the requirements themselves as informationcarriers that should be understood in the same wayby different roles in the development [92]. Face-to-face[75][87][88][89] and implicit communication can not besolely responsible for coordination and homogenizationof understanding [87][90]. This is true for any develop-ment instance independent of the type of system, how-ever, when it comes to SCS, it is even more critical.Furthermore, the competences of requirements engi-neers and safety engineers normally work independentlyof each other and have inherently different tools andengineering practices [87][91][92] - resulting in a lack of coordination that can compromise the quality of safetyanalysis and safety specifications [1][87][89][90].Some previous works discuss the importance of in-tegration of safety and RE areas in the developmentof SCS. Open issues that pose challenges are presentedin the works of [1][90][91][92], SLRs were conducted byMartins and Gorschek [2] and Vilela et al. [8], and com-munication channels are investigated by Wang et al. [9].The industry challenges about requirements communi-cation of SCS reported in these works motivated us toconduct a SLR.In this work, we investigate the approaches proposedto improve the integration of requirements communica-tion in the RE process among different parties whendeveloping SCS. We analyze the challenges and needsinvolved in the communication, the application context,the research type, the evaluation methods, the type of contribution, the domain, the requirements activity aswell as the languages and tools adopted to specify therequirements. Furthermore, we also analyze the stake-holders involved, the communication format, and forwhat safety standards have the approaches been pro-posed. We conclude our investigation with open issues.This SLR investigates deeply a specific aspect of atopic whose analysis was started earlier [2][8] that doesnot have the level of detail and analysis as investigatedin our paper. To the best of our knowledge, this is thefirst SLR with a specific focus on requirements commu-nication in the RE process for SCS.We believe the results of such novel study willbenefit both researchers and practitioners. The reviewwill provide researchers with important research gapsregarding the requirements communication betweensafety and RE. For the industrial readership, the re-view will provide practitioners with useful informationabout the state-of-the-art and advances so far. This in-formation contributes to setting up possible collabora-tive networks and as a reference when developing newresearch projects.This paper is organized as follows. Section 2 presentsbackground and related work. The research methodol-ogy adopted to conduct the SLR is presented in Section3. The results and the analysis related to our researchquestions are presented in Section 4. Our conclusionsare presented in Section 5. 2 Background and Related Work SCS are those software or system operations that, if notperformed, performed out of sequence, or performed in-correctly could result in improper control functions, orlack of control functions required for proper system op-eration. Such problems can directly or indirectly causeor allow a hazardous condition to exist [2][3].While the traditional approaches worked well for thesimpler systems of the past for which they were devised,significant changes have occurred in the types of sys-tems we are attempting to build today and the contextin which they are being built [4]. These changes arestretching the limits of safety engineering which has todeal with it: Fast pace of technological change [1][4]; Re-duced ability to learn from experience [4]; Changing na-ture of accidents [1][4]; New types of hazards [1][4][92];Increasing complexity and coupling [3][87][92]; Decreas-ing tolerance for single accidents [4][92]; Difficulty in se-lecting priorities and making trade-offs [1][4][87]; Morecomplex relationships between humans and automa-tion; [1][4]; Changing regulatory and public views of safety [4][92]; and developing software for SCS is moreexpensive than non-SCS [66][77].In order to set the scope and make clear the adopteddefinition of requirements communication used in thisSLR, and to ensure consistency throughout this paper,we discuss this concept in the next section.  Requirements Communication in Safety-Critical Systems: A Systematic Literature Review 3 2.1 Requirements CommunicationRequirements communication is a traversal processof exchanging information [7] about the requirementsamong all stakeholders [2][6][87] involved in the systemlifecycle [89]. This concept does not only comprise thecommunication itself but the specification and analysisof all artifacts involved in the RE process. Since changesoccur throughout the project, requirements communi-cation must also continue during the entire life cycle [6][89].This process aims to achieve a shared understand-ing [7][10] of the system’s requirements to increase com-pleteness and correctness of the requirements specifica-tions [89]. It encompasses all the activities [89] neededto inform the stakeholders of the content, meaning andstatus of requirements. The elicited requirements needto be communicated, and changes to those requirementsnegotiated and communicated among all affected roles,e.g. requirements engineers, developers, and testers [6].2.2 Related WorkThe communication of requirements among differentparties in the development of SCS is critical for thequality of the system. This occurs since requirementsshould be understood in the same way by different rolesin the development. We argue that the requirementsengineers and safety engineers should collaborate, ex-change information and work jointly and in an iterativeway. However, they usually work independently of eachother and have inherently different tools and engineer-ing practices - resulting in a lack of coordination thatcan compromise the quality of safety analysis [9], andtherefore, the quality of safety specifications.Communication problems in software developmentwere investigated by some authors such as Cheery andRobillard [11], Brady et al. [12], Pernstal [13], Ras-mussen and Lundell [14], Wang et al. [9] as well asNakamura et al. [15]. The paper of Cherry and Ro-billard [11] recognized that communication is a crucialelement in software engineering, but, unfortunately, itis an aspect which seems to be lacking in global softwaredevelopment. Hence, it presents an empirical study onad hoc collaborative activities in an industrial softwareengineering setting. Their general objective was to in-vestigate the kinds of activities and their content in adistributed software development context.Rasmussen and Lundell [14] present a case analysisbased on interviews to illustrate how communicationgaps can be understood from a communicative perspec-tive, meaning that they treat them as primarily sociallyconstructed. Nakamura et al. [15] examine the impor-tance of communication in community-based disaster-prevention meetings by focusing on participants’ satis-faction with these meetings, which was assessed usinga questionnaire survey.Existing communication channels, the usage fre-quencies, their purposes and challenges during safetyanalysis in the industry were investigated by Wang etal. [9]. They surveyed 39 experts and interviewed 21 ex-perts in SCS companies including software developers,quality engineers and functional safety managers. Di-rect observations and documentation review were alsoconducted.Brady et al. [12] have developed instructional casestudy material in software communication. They ex-posed students to situations they will confront outsidethe classroom, and how they provide opportunities forcritiquing and devising communication strategies. How-ever, they have concentrated on the direct communica-tion between developer and client.Pernstal [13] presents a novel model for postmortemanalysis of problems in organizational communicationevents that focus on inter-departmental communica-tion between Product development (PD) and Manufac-turing (MAN). The evaluation showed that the modelhelped structure and conduct systematic data collectionand analysis of dysfunctional communication patterns.They found that an insufficient understanding of thematters being communicated was prevalent, but alsomore specifically, requirements were insufficiently bal-anced, and detailed over the full system developmentcycle.Few SLRs about the development of SCS arefound in the literature [8][2][16][17]. Queiroz and Braga[16] conducted a SLR with the purpose of obtainingthe state-of-the-art of the approaches, methods andmethodologies whose goal was the combination of prod-uct line engineering and model-driven engineering forthe development of safety-critical embedded systems.They also analyzed the existence of empirical studieson the use of these techniques in this type of develop-ment.A SLR about safety evidence is presented in Nair etal. [17]. The main objective of their work is to synthe-size the existing knowledge in the academic literatureabout safety evidence, concentrating on three facets:the information that constitutes evidence; structuringof evidence; and evidence assessment.RE for SCS is the main investigation topic of asystematic literature review conducted by Martins andGorschek [2]. Their work investigated which approacheshave been proposed to elicit, model, specify and val-idate safety requirements in the context of SCS, as  4 J´essyka Vilela et al. well as to what extent such approaches have been val-idated in industrial settings. Moreover, they analyzedthe usability and usefulness of the reported approacheshad been explored, and to what extent they enabledrequirements communication among the developmentproject/team actors in the SCS domain. Although theyemphasize the need to further investigate the communi-cation in the RE process among different parties whendeveloping SCS, their work does not investigate deeplythe collaboration of requirements and safety engineers.In fact, in this work, we restricted our search string tocapture the results related to requirements communi-cation.Although above works explore several challenges re-lated to the integration of RE and safety [1] [90][91][92],little has been done to date to perform an extensiveidentification and mapping, in a comprehensive man-ner, the state-of-the-art on the communication of re-quirements among different parties in the developmentactivities/process when developing SCS. Hence, to thebest of our knowledge, this is the first SLR with suchspecific focus. In the next section, we detail our researchprotocol. 3 Research Methodology In this section, we present the design and the executionof the SLR. The research methodology used was basedon the guidelines and template proposed by Kitchen-ham and Charters [18]. Figure 1 shows the researchprocess we have adopted and its steps are described inthe next sections.The need for this SLR (Step 1, Figure 1) was pre-sented in the Introduction of this paper. We verifiedwheteher a SLR about communication in the RE pro-cess among parties already exists by searching theACM, Springer, IEEE and Google Scholar libraries(performed in February, 2018). None of the retrievedstudies were directly related to the objectives expressedin the research questions (Step 2, Defining ResearchQuestions). In fact, few systematic literature reviewsabout the development of SCS are found in the litera-ture as discussed in Section 2.3.1 Review scopeThe focus of this review is the integration between REand safety engineering and the requirements communi-cation among different parties during the RE process.We included studies that addressed in their objectivesthe communication in the RE process among differentparties when developing SCS, related Requirements and Fig. 1  SLR steps adapted from [2] and [18]. Safety in the context of RE process, or covered Designin the relationship with Requirements and Safety.Studies whose focus was not the communication inthe RE process among different parties when developingSCS were excluded. The literature about safety casesalso does not belong to the review scope. The safetycases are developed to communicate a clear, compre-hensive and defensible argument that a system is ac-ceptably safe to operate in a particular context [19].Hence, such cases are developed aiming to build argu-ments regarding the safety and security properties of systems [20]. Although they are used in safety require-ments communication and structured safety cases aimto improve communication, they are concerned withcollecting and relating documents that demonstratethat the safety analysis was conducted properly and/orsafety standards were followed. The safety requirementsspecification is one example of such documents whosecontent we describe in another work [8]. Hence, safetycases do not describe in details the content of safetyrequirements specifications and they are usually devel-oped in later stages of system development, i.e design,verification and certification, and not in the RE processwhere the system safety requirements are still being dis-covered.3.2 Research questionsOur study was guided by the following main researchquestion:  Requirements Communication in Safety-Critical Systems: A Systematic Literature Review 5 Table 1  Research questions and motivations. Research Question Description and Motivation RQ1. What challenges have been identified pertaining tothe communication among engineers during the RE pro-cess when developing SCS?The goal is to identify the challenges addressed in the literature regardingthe communication among engineers during the RE process for SCS. Theresults obtained will be useful to identify emerging trends and provide anoverall view of the problems tackled in the literature.RQ2. Which approaches have been proposed to improvethe communication in the RE process among engineerswhen developing SCS?The aim is to identify and analyze the approaches proposed to improvethe communication in the RE process among engineers when developingSCS.RQ2.1. What are the types of these approaches? We want to analyze the types of the approaches to understand how thecommunity is evolving regarding communication in SCS. Therefore, thisquestion intends to classify the approaches by its type, for instance, Ap-proach, Framework, Method, Tool, Process, Model, Methodology, Tem-plate, Comparison, Metrics, Protocol, Checklist and Language, proposedin the approach.RQ2.2. For which domains were these approaches pro-posed?Domain understanding narrows the amount of domain knowledge to beshared and lays the foundation for successfully communicating domainconcepts. Accordingly, this question provides an overview of the domains(Generic, Automotive, Avionics, Medical, Railway and so on) for whichthe approaches were proposed.RQ2.3. What RE activities were supported by these ap-proaches?We are concerned with investigating the proposals in relation to require-ments communication, hence this question provides a starting point tounderstand what are the main activities (elicitation, analysis, specifica-tion, validation and management) of the RE process supported by theapproaches.RQ2.4. Which requirements specification languages areused by these approaches?The languages play an important role in the requirements communicationprocess. Therefore, the intent of this question is to identify the require-ments specification languages adopted in the development of SCS.RQ2.5. Which tools are used for the requirements speci-fication?The process of development of SCS encompasses the elaboration of manydocuments and models. Hence, this question maps the tools used to de-velop the requirements specification of SCS.RQ2.6. For which stakeholder were they proposed? The requirements should be understood by all stakeholders involved inthe development process. Accordingly, this question aims to analyze thestakeholders involved in the proposed approaches.RQ2.7. What are the communication formats used? The intent is to analyze the formats used for the requirements commu-nication (Model-based collaboration, Process support, Awareness, Collab-oration infrastructure, Artifacts-based, Analysis tools, and Face-to-faceverbal communication).RQ2.8. For what safety standards have the approachesbeen proposed?Considering that SCS should be certified by regulatory bodies, this ques-tion intends to analyze for what safety standards have the approachesproposed to improve the communication in the RE process among engi-neers when developing SCS been proposed. What is the state-of-the-art in requirements com-munication in the requirements engineering pro-cess of safety-critical systems?  Accordingly, specific questions were raised accord-ing to aspects that we are interested in. These ques-tions, their descriptions and motivations are describedin Table 1.3.3 Search StrategyThe search strategy included two types of search to findstudies relevant to the scope of the review. The firsttype was an automatic search, using a string validatedby experts on RE and SCS. The second strategy wasthe manual inclusion of papers well-known about re-quirements communication.We developed a review protocol (Step 3, Figure 1),in which the main elements are as follows: the  selected resources  chosen were Science Direct, SpringerLink,ACM Digital Library, IEEE Xplore, Scopus, and Com-pendex; the  search method   used web search engines;the  population   was composed of peer-reviewed pub-lications reporting approaches to improve the commu-nication in the RE process among parties when devel-oping SCS; the aim of the  intervention   was to col-lect empirical evidence in relation to the challengesand needs involved in the communication of require-ments among different parties in the development ac-tivities/process when developing SCS, the applicationcontext, the research type, the evaluation methods, thetype of contribution, the domain, the requirements ac-tivity, the languages and tools used to specify the re-quirements.Furthermore, we also analyze the stakeholders in-volved, the communication format, and for what safetystandards have the approaches been proposed.We developed the search string by specifying themain terms of the phenomena under investigation (SCSand requirements communication). A number of pilotsearches were performed to refine the keywords in thesearch string using trial and error. We removed termswhose inclusion did not yield additional papers in theautomatic searches. After several iterations, we defined
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!