Use, potential, and showstoppers of models in automotive requirements engineering

Several studies report that the use of model-centric methods in the automotive domain is widespread and offers several benefits. However, existing work indicates that few modelling frameworks explicitly include requirements engineering (RE), and that natural language descriptions are still the status quo in RE. Therefore, we aim to increase the understanding of current and potential future use of models in RE, with respect to the automotive domain. In this paper, we report our findings from a multiple-case study with two automotive companies, collecting interview data from 14 practitioners. Our results show that models are used for a variety of different purposes during RE in the automotive domain, e.g. to improve communication and to handle complexity. However, these models are often used in an unsystematic fashion and restricted to few experts. A more widespread use of models is prevented by various challenges, most of which align with existing work on model use in a general sense. Furthermore, our results indicate that there are many potential benefits associated with future use of models during RE. Interestingly, existing research does not align well with several of the proposed use cases, e.g. restricting the use of models to informal notations for communication purposes. Based on our findings, we recommend a stronger focus on informal modelling and on using models for multi-disciplinary environments. Additionally, we see the need for future work in the area of model use, i.e. information extraction from models by non-expert modellers

Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

From Offshore Operation to Onshore Simulator: Using Visualized Ethnographic Outcomes to Work with Systems Developers

This paper focuses on the process of translating insights from a Computer Supported Cooperative Work (CSCW)-based study, conducted on a vessel at sea, into a model that can assist systems developers working with simulators, which are used by vessel operators for training purposes on land. That is, the empirical study at sea brought about rich insights into cooperation, which is important for systems developers to know about and consider in their designs. In the paper, we establish a model that primarily consists of a ‘computational artifact’. The model is designed to support researchers working with systems developers. Drawing on marine examples, we focus on the translation process and investigate how the model serves to visualize work activities; how it addresses relations between technical and computational artifacts, as well as between functions in technical systems and functionalities in cooperative systems. In turn, we link design back to fieldwork studies

An Empirical Investigation of Using Models During Requirements Engineering in the Automotive Industry

Context:The automotive industry is undergoing a major transformation from a manufacturing industry towards an industry that relies heavily on software. As one of the main factors for project success, requirements engineering (RE) plays a major role in this transition. Similar to other areas of automotive engineering, the use of models during RE has been suggested to increase productivity and tackle increasing complexity by means of abstraction. Existing modelling frameworks often prescribe a variety of different, formal models for RE, trying to maximise the benefit obtained from model-based engineering (MBE). However, these frameworks are typically based on assumptions from anecdotal evidence and experience, without empirical data supporting these assumptions.Objective:The overall aim of our research is to investigate the potential benefits and drawbacks of using model-based RE in an automotive environment based on empirical evidence. To do so, we present an investigation of the current industrial practice of MBE in the automotive industry, existing challenges in automotive RE, and potential use cases for model-based RE. Furthermore, we explore two use cases for model-based RE, namely the creation of behavioural requirements models for validation and verification purposes and the use of existing trace models to support communication.Method:We address the aims of this thesis using three empirical strategies: case study, design science and survey. We collected quantitative and qualitative data using interviews as well as questionnaires.Results:Our results show that using models during automotive RE can be beneficial, if restricted to certain aspects of RE. In particular, models supporting communication and stakeholder interaction are promising. We show that the use of abstract models of behavioural requirements are considered beneficial for system testing purposes, even though they abstract from the detailed functional requirements. Furthermore, we demonstrate that existing data can be understood as a model to uncover dependencies between stakeholders. Conclusions:Our results question the feasibility to construct and maintain large amounts of formal models for RE. Instead, models during RE should be used for a few, important use cases. Additionally, MBE can be used as a means to understand existing problems in software engineering

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

Representing Variability in Software Architecture: A Systematic Literature Review

Variability in software - intensive systems is the ability of a software artefact (e.g., a system, subsystem, or component) to be extended, customised or configured for deployment in a specific context. Software Architecture is a high - level description of a software - intensive system that abstracts the system implementation details allowing the architect to view the system as a whole. Although variability in software architecture is recognised as a challenge in multiple domains, there has been no formal consensus on how variability should be captured or represented. The objective of this research was to provide a snapshot of the state - of - the - art on representing variability in software architecture while assessing the nature of the different approaches. To achieve this objective, a Systematic Literature Review (SLR) was conducted covering literature produced from January 1991 until June 2016. Then, grounded theory was used to conduct the analysis and draw conclusions from data, mini mising threats to validity. In this paper , we report on the findings from the study

Mining Architectural Information: A Systematic Mapping Study

Context: Mining Software Repositories (MSR) has become an essential activity in software development. Mining architectural information to support architecting activities, such as architecture understanding and recovery, has received a significant attention in recent years. However, there is an absence of a comprehensive understanding of the state of research on mining architectural information. Objective: This work aims to identify, analyze, and synthesize the literature on mining architectural information in software repositories in terms of architectural information and sources mined, architecting activities supported, approaches and tools used, and challenges faced. Method: A Systematic Mapping Study (SMS) has been conducted on the literature published between January 2006 and November 2021. Results: Of the 79 primary studies finally selected, 8 categories of architectural information have been mined, among which architectural description is the most mined architectural information; 12 architecting activities can be supported by the mined architectural information, among which architecture understanding is the most supported activity; 81 approaches and 52 tools were proposed and employed in mining architectural information; and 4 types of challenges in mining architectural information were identified. Conclusions: This SMS provides researchers with promising future directions and help practitioners be aware of what approaches and tools can be used to mine what architectural information from what sources to support various architecting activities.Comment: 68 pages, 5 images, 15 tables, Manuscript submitted to a Journal (2022