Software and systems traceability for safety-critical projects: report from Dagstuhl Seminar 15162

This report documents the program and the outcomes of Dagstuhl Seminar 15162 on “Software and Systems Traceability for Safety-Critical Projects”. The event brought together researchers and industrial practitioners working in the field of safety critical software to explore the needs, challenges, and solutions for Software and Systems Traceability in this domain. The goal was to explore the gap between the traceability prescribed by guidelines and that delivered by manufacturers, and starting from a clean slate, to clearly articulate traceability needs for safety-critical software systems, to identify challenges, explore solutions, and to propose a set of principles and domain-specific exemplars for achieving traceability in safety critical systems

Collaborative traceability management: a multiple case study from the perspectives of organization, process, and culture

Traceability is crucial for many activities in software and systems engineering including monitoring the development progress, and proving compliance with standards. In practice, the use and maintenance of trace links are challenging as artifacts undergo constant change, and development takes place in distributed scenarios with multiple collaborating stakeholders. Although traceability management in general has been addressed in previous studies, there is a need for empirical insights into the collaborative aspects of traceability management and how it is situated in existing development contexts. The study reported in this paper aims to close this gap by investigating the relation of collaboration and traceability management, based on an understanding of characteristics of the development effort. In our multiple exploratory case study, we conducted semi-structured interviews with 24 individuals from 15 industrial projects. We explored which challenges arise, how traceability management can support collaboration, how collaboration relates to traceability management approaches, and what characteristics of the development effort influence traceability management and collaboration. We found that practitioners struggle with the following challenges: (1) collaboration across team and tool boundaries, (2) conveying the benefits of traceability, and (3) traceability maintenance. If these challenges are addressed, we found that traceability can facilitate communication and knowledge management in distributed contexts. Moreover, there exist multiple approaches to traceability management with diverse collaboration approaches, i.e., requirements-centered, developer-driven, and mixed approaches. While traceability can be leveraged in software development with both agile and plan-driven paradigms, a certain level of rigor is needed to realize its benefits and overcome challenges. To support practitioners, we provide principles of collaborative traceability management. The main contribution of this paper is empirical evidence of how culture, processes, and organization impact traceability management and collaboration, and principles to support practitioners with collaborative traceability management. We show that collaboration and traceability management have the potential to be mutually beneficial—when investing in one, also the other one is positively affected

Collaborative traceability management: a multiple case study from the perspectives of organization, process, and culture

Traceability is crucial for many activities in software and systems engineering including monitoring the development progress, and proving compliance with standards. In practice, the use and maintenance of trace links are challenging as artifacts undergo constant change, and development takes place in distributed scenarios with multiple collaborating stakeholders. Although traceability management in general has been addressed in previous studies, there is a need for empirical insights into the collaborative aspects of traceability management and how it is situated in existing development contexts. The study reported in this paper aims to close this gap by investigating the relation of collaboration and traceability management, based on an understanding of characteristics of the development effort. In our multiple exploratory case study, we conducted semi-structured interviews with 24 individuals from 15 industrial projects. We explored which challenges arise, how traceability management can support collaboration, how collaboration relates to traceability management approaches, and what characteristics of the development effort influence traceability management and collaboration. We found that practitioners struggle with the following challenges: (1) collaboration across team and tool boundaries, (2) conveying the benefits of traceability, and (3) traceability maintenance. If these challenges are addressed, we found that traceability can facilitate communication and knowledge management in distributed contexts. Moreover, there exist multiple approaches to traceability management with diverse collaboration approaches, i.e., requirements-centered, developer-driven, and mixed approaches. While traceability can be leveraged in software development with both agile and plan-driven paradigms, a certain level of rigor is needed to realize its benefits and overcome challenges. To support practitioners, we provide principles of collaborative traceability management. The main contribution of this paper is empirical evidence of how culture, processes, and organization impact traceability management and collaboration, and principles to support practitioners with collaborative traceability management. We show that collaboration and traceability management have the potential to be mutually beneficial—when investing in one, also the other one is positively affected

The Impact of Requirements on Systems Development Speed: A Multiple-Case Study in Automotive

Automotive\ua0manufacturers have historically adopted rigid\ua0requirements\ua0engineering processes. This allowed them to meet safety-critical\ua0requirements\ua0when producing\ua0a\ua0highly complex and differentiated product out of the integration of thousands of physical and software components. Nowadays, few software-related domains are as rapidly changing as the\ua0automotive\ua0industry.\ua0In\ua0particular, the needs of improving\ua0development\ua0speed\ua0are increasingly pushing companies\ua0in\ua0this domain toward new ways of developing software.\ua0In\ua0this paper, we investigate how the goal to increase\ua0development\ua0speed\ua0impacts how\ua0requirements\ua0are managed\ua0in\ua0the\ua0automotive\ua0domain. We start from\ua0a\ua0manager perspective, which we then complement with\ua0a\ua0more general perspective. We used\ua0a\ua0qualitative\ua0multiple-case\ua0study, organized\ua0in\ua0two steps.\ua0In\ua0the first step, we had 20 semi-structured interviews, at two\ua0automotive\ua0manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists.\ua0In\ua0the second step, we validated our results with 12 more interviews, covering nine additional respondents and three recurring from the first step.\ua0In\ua0addition to validating our qualitative model, the second step of interviews broadens our perspective with technical experts and change managers. Our respondents indicate and rank six aspects of the current\ua0requirements\ua0engineering approach that\ua0impact\ua0development\ua0speed. These aspects include the negative\ua0impact\ua0of\ua0a\ua0requirements\ua0style dominated by safety concerns as well as decomposition of\ua0requirements\ua0over many levels of abstraction. Furthermore, the use of\ua0requirements\ua0as part of legal contracts with suppliers is seen as hindering fast collaboration. Six additional suggestions for potential improvements include domain-specific tooling, model-based\ua0requirements, test automation, and\ua0a\ua0combination of lightweight upfront\ua0requirements\ua0engineering preceding\ua0development\ua0with precise specifications post-development. Out of these 12 aspects, seven can likely be addressed as part of an ongoing agile transformation. We offer an empirical account of expectations and needs for new\ua0requirements\ua0engineering approaches\ua0in\ua0the\ua0automotive\ua0domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical\ua0systems

Integrated lifecycle requirements information management in construction

Effective management of information about client requirements in construction projects lifecycle can contribute to high construction productivity; within budget and schedule, and improve the quality of built facilities and service delivery. Traditionally, requirements management has been focused at the early stages of the construction lifecycle process where elicited client requirements information is used as the basis for design. Management of client requirements does not extend to the later phases. Client requirements often evolve and change dramatically over a facility’s life. Changing client requirements is one of the principal factors that contribute to delays and budget overruns of construction projects. This results in claims, disputes and client dissatisfaction. The problems of current requirements management process also include: lack of integrated and collaborative working with requirements; lack of integrated requirements information flow between the various heterogeneous systems used in the lifecycle processes, and between the multiple stakeholders; inefficient and ineffective coordination of changes within the lifecycle processes; manual checking of dependencies between changing requirements to facilitate assessment of cost and time impact of changes. The aim of the research is to specify a better approach to requirements information management to help construction organisations reduce operational cost and time in product development and service delivery; whilst increasing performance and productivity, and realising high quality of built facilities. In order to achieve the aim and the formulated objectives, firstly, a detailed review of literature on related work was conducted. Secondly, the research designed, developed and conducted three case studies to investigate the state-of-the-art of managing client requirements information. A combination of multiple data collection methods was applied which included observations, interviews, focus group and questionnaires. Following this, the data was analysed and problems were identified; the necessity for a lifecycle approach to managing the requirements information emerged. (Continues...)

Understanding Variability-Aware Analysis in Low-Maturity Variant-Rich Systems

Context: Software systems often exist in many variants to support varying stakeholder requirements, such as specific market segments or hardware constraints. Systems with many variants (a.k.a. variant-rich systems) are highly complex due to the variability introduced to support customization. As such, assuring the quality of these systems is also challenging since traditional single-system analysis techniques do not scale when applied. To tackle this complexity, several variability-aware analysis techniques have been conceived in the last two decades to assure the quality of a branch of variant-rich systems called software product lines. Unfortunately, these techniques find little application in practice since many organizations do use product-line engineering techniques, but instead rely on low-maturity \clo~strategies to manage their software variants. For instance, to perform an analysis that checks that all possible variants that can be configured by customers (or vendors) in a car personalization system conform to specified performance requirements, an organization needs to explicitly model system variability. However, in low-maturity variant-rich systems, this and similar kinds of analyses are challenging to perform due to (i) immature architectures that do not systematically account for variability, (ii) redundancy that is not exploited to reduce analysis effort, and (iii) missing essential meta-information, such as relationships between features and their implementation in source code.Objective: The overarching goal of the PhD is to facilitate quality assurance in low-maturity variant-rich systems. Consequently, in the first part of the PhD (comprising this thesis) we focus on gaining a better understanding of quality assurance needs in such systems and of their properties.Method: Our objectives are met by means of (i) knowledge-seeking research through case studies of open-source systems as well as surveys and interviews with practitioners; and (ii) solution-seeking research through the implementation and systematic evaluation of a recommender system that supports recording the information necessary for quality assurance in low-maturity variant-rich systems. With the former, we investigate, among other things, industrial needs and practices for analyzing variant-rich systems; and with the latter, we seek to understand how to obtain information necessary to leverage variability-aware analyses.Results: Four main results emerge from this thesis: first, we present the state-of-practice in assuring the quality of variant-rich systems, second, we present our empirical understanding of features and their characteristics, including information sources for locating them; third, we present our understanding of how best developers\u27 proactive feature location activities can be supported during development; and lastly, we present our understanding of how features are used in the code of non-modular variant-rich systems, taking the case of feature scattering in the Linux kernel.Future work: In the second part of the PhD, we will focus on processes for adapting variability-aware analyses to low-maturity variant-rich systems.Keywords:\ua0Variant-rich Systems, Quality Assurance, Low Maturity Software Systems, Recommender Syste

Maps of Lessons Learnt in Requirements Engineering

Both researchers and practitioners have emphasized the importance of learning from past experiences and its consequential impact on project time, cost, and quality. However, from the survey we conducted of requirements engineering (RE) practitioners, over 70\% of the respondents stated that they seldom use RE lessons in the RE process, though 85\% of these would use such lessons if readily available. Our observation, however, is that RE lessons are scattered, mainly implicitly, in the literature and practice, which obviously, does not help the situation. We, therefore, present ``maps” of RE lessons which would highlight weak (dark) and strong (bright) areas of RE (and hence RE theories). Such maps would thus be: (a) a driver for research to ``light up” the darker areas of RE and (b) a guide for practice to benefit from the brighter areas. To achieve this goal, we populated the maps with over 200 RE lessons elicited from literature and practice using a systematic literature review and survey. The results show that approximately 80\% of the elicited lessons are implicit and that approximately 70\% of the lessons deal with the elicitation, analysis, and specification RE phases only. The RE Lesson Maps, elicited lessons, and the results from populating the maps provide novel scientific groundings for lessons learnt in RE as this topic has not yet been systematically studied in the field

Hardware Certification for Real-time Safety-critical Systems: State of the Art

This paper discusses issues related to the RTCA document DO-254 Design Assurance Guidance for Airborne Electronic Hardware and its consequences for hardware certification. In particular, problems related to circuits’ compliance with DO-254 in avionics and other industries are considered. Extensive literature review of the subject is given, including current views on and experiences of chip manufacturers and EDA industry with qualification of hardware design tools, including formal approaches to hardware verification. Some results of the authors’ own study on tool qualification are presented