• Based on the results of a series of workshops with industrial practitioners, this study proposes the use of causal models as a supplement to natural language requirements for specifying software with ML components. • The paper provides a demonstration of a proposed causality-driven development concept on an industrial use case on anomaly detection in power systems. • The paper reports on initial results from laboratory experiments that indicate positive effects of the use of causal models during software development on the performance and robustness of a trained ML model for anomaly detection in an industrial prototyping setting. Unlike conventional software systems, where rules are explicitly defined to specify the desired behaviour, software components that incorporate machine learning (ML) infer such rules as associations from data. Requirements Engineering (RE) provides methods and tools for specifying the desired behaviour as structured natural language. However, the inherent ambiguity of natural language can make these specifications difficult to interpret. Moreover, it is challenging in RE to establish a clear link between the specified desired behaviour and data requirements necessary for training and validating ML models. In this paper, we explore the use of causal models to address this gap in RE. Through an exploratory case study, we found that causal models, represented as directed acyclic graphs (DAGs), support the collaborative discovery of an ML system’s operational context from a causal perspective. We also found that causal models can serve as part of the requirements specification for ML models because they encapsulate both data and model requirements needed to achieve the desired causal behaviour. We introduce a concept for causality-driven development , in which we show that data and model requirements, as well as a causal description of the operational context, can be discovered iteratively using graphical causal models. We demonstrate this approach using an industrial use case on anomaly detection with ML.

Cognitive biases are often described as "deviations" or "errors" in rationality, interfering with problem-solving and decision-making. In one of the foundational articles by Tversky and Kahneman cognitive biases are defined as: "heuristic principles which reduce the complex tasks of assessing probabilities and predicting values to simpler judgmental operations" [1] . In medical [2] , managerial [3] , and Software Engineering (SE) [4] areas, for instance, the impact of such "heuristics or errors" is assessed in the literature, often focused on presenting mitigation or "debiasing" strategies.

Abstract Large-scale systems development commonly faces the challenge of managing relevant knowledge between different organizational groups, particularly in increasingly agile contexts. Here, there is a conflict between coordination and group autonomy, and it is challenging to determine what necessary coordination information must be shared by what teams or groups, and what can be left to local team management. We introduce a way to manage this complexity using a modeling framework based on two core concepts: methodological islands (i.e., groups using different development methods than the surrounding organization) and boundary objects (i.e., artifacts that create a common understanding across team borders). However, we found that companies often lack a systematic way of assessing coordination issues and the use of boundary objects between methodological islands. As part of an iterative design science study, we have addressed this gap by producing a modeling framework (BOMI: Boundary Objects and Methodological Islands) to better capture and analyze coordination and knowledge management in practice. This framework includes a metamodel, as well as a list of bad smells over this metamodel that can be leveraged to detect inter-team coordination issues. The framework also includes a methodology to suggest concrete modeling steps and broader guidelines to help apply the approach successfully in practice. We have developed Eclipse-based tool support for the BOMI method, allowing for both graphical and textual model creation, and including an implementation of views over BOMI instance models in order to manage model complexity. We have evaluated these artifacts iteratively together with five large-scale companies developing complex systems. In this work, we describe the BOMI framework and its iterative evaluation in several real cases, reporting on lessons learned and identifying future work. We have produced a matured and stable modeling framework which facilitates understanding and reflection over complex organizational configurations, communication, governance, and coordination of knowledge artifacts in large-scale agile system development.

Marine in-situ data is collected by sensors mounted on fixed or mobile systems deployed into the ocean. This type of data is crucial both for the ocean industries and public authorities, e.g., for monitoring and forecasting the state of marine ecosystems and/or climate changes. Various public organizations have collected, managed, and openly shared in-situ marine data in the past decade. Recently, initiatives like the Ocean Decade Corporate Data Group have incentivized the sharing of marine data of public interest from private companies aiding in ocean management. However, there is no clear understanding of the impact of data quality in the engineering of systems, as well as on how to manage and exploit the collected data. In this paper, we propose main architectural decisions and a data flow-oriented component and connector view for marine in-situ data streams. Our results are based on a longitudinal empirical software engineering process, and driven by knowledge extracted from the experts in the marine domain from public and private organizations, and challenges identified in the literature. The proposed software architecture is instantiated and exemplified in a prototype implementation.

The design of complex distributed systems typically follows a hierarchical process, supported by highly specialized views for decomposing the design task. Requirements and architec-ture often evolve simultaneously, requiring an architectural framework that supports integrated and collaborative design, including non-functional requirements and quality views. The framework must ensure the traceability of design decisions in order to build safety cases. Integrating requirements into software development is vital for aligning intended functionality with implemented code. However, extracting data from semi-formal requirements and maintaining alignment poses challenges due to its ambiguity and variability making extracting consistent information challenging. Aligning these requirements with other project artifacts can also be difficult due to interpretation differences, often requiring manual effort and leading to complexity and potential inconsistencies in development [1].

The integration of human factors (HF) knowledge is crucial when developing safety-critical systems, such as automated vehicles (AVs). Ensuring that HF knowledge is considered continuously throughout the AV development process is essential for several reasons, including efficacy, safety, and acceptance of these advanced systems. However, it is challenging to include HF as requirements in agile development. Recently, Requirements Strategies have been suggested to address requirements engineering challenges in agile development. By applying the concept of Requirements Strategies as a lens to the investigation of HF requirements in agile development of AVs, this paper arrives at three areas for investigation: a) ownership and responsibility for HF requirements, b) structure of HF requirements and information models, and c) definition of work and feature flows related to HF requirements. Based on 13 semi-structured interviews with professionals from the global automotive industry, we provide qualitative insights in these three areas. The diverse perspectives and experiences shared by the interviewees provide insightful views and helped to reason about the potential solution spaces in each area for integrating HF within the industry, highlighting the real-world practices and strategies used.

With the increasing prevalence of open and connected products, cybersecurity has become a serious issue in safety-critical domains such as the automotive industry. As a result, regulatory bodies have become more stringent in their requirements for cybersecurity, necessitating security assurance for products developed in these domains. In response, companies have implemented new or modified processes to incorporate security into their product development lifecycle, resulting in a large amount of evidence being created to support claims about the achievement of a certain level of security. However, managing evidence is not a trivial task, particularly for complex products and systems. This paper presents a qualitative interview study conducted in six companies on the maturity of managing security evidence in safety-critical organizations. We find that the current maturity of managing security evidence is insufficient for the increasing requirements set by certification authorities and standardization bodies. Organisations currently fail to identify relevant artifacts as security evidence and manage this evidence on an organizational level. One part of the reason are educational gaps, the other a lack of processes. The impact of AI on the management of security evidence is still an open question.

Abstract Driving automation systems, including autonomous driving and advanced driver assistance, are an important safety-critical domain. Such systems often incorporate perception systems that use machine learning to analyze the vehicle environment. We explore new or differing topics and challenges experienced by practitioners in this domain, which relate to requirements engineering (RE), quality, and systems and software engineering. We have conducted a semi-structured interview study with 19 participants across five companies and performed thematic analysis of the transcriptions. Practitioners have difficulty specifying upfront requirements and often rely on scenarios and operational design domains (ODDs) as RE artifacts. RE challenges relate to ODD detection and ODD exit detection, realistic scenarios, edge case specification, breaking down requirements, traceability, creating specifications for data and annotations, and quantifying quality requirements. Practitioners consider performance, reliability, robustness, user comfort, and—most importantly—safety as important quality attributes. Quality is assessed using statistical analysis of key metrics, and quality assurance is complicated by the addition of ML, simulation realism, and evolving standards. Systems are developed using a mix of methods, but these methods may not be sufficient for the needs of ML. Data quality methods must be a part of development methods. ML also requires a data-intensive verification and validation process, introducing data, analysis, and simulation challenges. Our findings contribute to understanding RE, safety engineering, and development methodologies for perception systems. This understanding and the collected challenges can drive future research for driving automation and other ML systems.

Abstract The development and operation of critical software that contains machine learning (ML) models requires diligence and established processes. Especially the training data used during the development of ML models have major influences on the later behaviour of the system. Runtime monitors are used to provide guarantees for that behaviour. Runtime monitors for example check that the data at runtime is compatible with the data used to train the model. In a first step towards identifying challenges when specifying requirements for training data and runtime monitors, we conducted and thematically analysed ten interviews with practitioners who develop ML models for critical applications in the automotive industry. We identified 17 themes describing the challenges and classified them in six challenge groups. In a second step, we found interconnection between the challenge themes through an additional semantic analysis of the interviews. We explored how the identified challenge themes and their interconnections can be mapped to different architecture views. This step involved identifying relevant architecture views such as data, context, hardware, AI model, and functional safety views that can address the identified challenges. The article presents a list of the identified underlying challenges, identified relations between the challenges and a mapping to architecture views. The intention of this work is to highlight once more that requirement specifications and system architecture are interlinked, even for AI-specific specification challenges such as specifying requirements for training data and runtime monitoring.

Abstract Good data quality is crucial for any data-driven system’s effective and safe operation. For critical safety systems, the significance of data quality is even higher since incorrect or low-quality data may cause fatal faults. However, there are challenges in identifying and managing data quality. In particular, there is no accepted process to define and continuously test data quality concerning what is necessary for operating the system. This lack is problematic because even safety-critical systems become increasingly dependent on data. Here, we propose a Candidate Framework for Data Quality Assessment and Maintenance (CaFDaQAM) to systematically manage data quality and related requirements based on design science research. The framework is constructed based on an advanced driver assistance system (ADAS) case study. The study is based on empirical data from a literature review, focus groups, and design workshops. The proposed framework consists of four components: a Data Quality Workflow, a List of Data Quality Challenges, a List of Data Quality Attributes, and Solution Candidates. Together, the components act as tools for data quality assessment and maintenance. The candidate framework and its components were validated in a focus group.

Software that contains machine learning algorithms is an integral part of automotive perception, for example, in driving automation systems. The development of such software, specifically the training and validation of the machine learning components, requires large annotated datasets. An industry of data and annotation services has emerged to serve the development of such data-intensive automotive software components. Wide-spread difficulties to specify data and annotation needs challenge collaborations between OEMs (Original Equipment Manufacturers) and their suppliers of software components, data, and annotations.This paper investigates the reasons for these difficulties for practitioners in the Swedish automotive industry to arrive at clear specifications for data and annotations. The results from an interview study show that a lack of effective metrics for data quality aspects, ambiguities in the way of working, unclear definitions of annotation quality, and deficits in the business ecosystems are causes for the difficulty in deriving the specifications. We provide a list of recommendations that can mitigate challenges when deriving specifications and we propose future research opportunities to overcome these challenges. Our work contributes towards the on-going research on accountability of machine learning as applied to complex software systems, especially for high-stake applications such as automated driving.

The VEDLIoT project aims to develop energy-efficient Deep Learning methodologies for distributed Artificial Intelligence of Things (AIoT) applications. During our project, we propose a holistic approach that focuses on optimizing algorithms while addressing safety and security challenges inherent to AIoT systems. The foundation of this approach lies in a modular and scalable cognitive IoT hardware platform, which leverages microserver technology to enable users to configure the hardware to meet the requirements of a diverse array of applications. Heterogeneous computing is used to boost performance and energy efficiency. In addition, the full spectrum of hardware accelerators is integrated, providing specialized ASICs as well as FPGAs for reconfigurable computing. The project's contributions span across trusted computing, remote attestation, and secure execution environments, with the ultimate goal of facilitating the design and deployment of robust and efficient AIoT systems. The overall architecture is validated on use-cases ranging from Smart Home to Automotive and Industrial IoT appliances. Ten additional use cases are integrated via an open call, broadening the range of application areas.

Due to the technical complexity and social impact, automated vehicle (AV) development challenges the current state of automotive engineering practice. Research shows that it is important to consider human factors (HF) knowledge when developing AVs to make them safe and accepted. This study explores the current practices and challenges of the automotive industries for incorporating HF requirements during agile AV development. We interviewed ten industry professionals from several Swedish automotive companies, including HF experts and AV engineers. Based on our qualitative analysis of the semi-structured interviews, a number of current approaches for communicating and incorporating HF knowledge into agile AV development and associated challenges are discussed. Our findings may help to focus future research on issues that are critical to effectively incorporate HF knowledge into agile AV development.

Background: In-situ marine data has a low reusability rate, primarily due to differences in data usage objectives among stakeholders in data ecosystems. The extreme cost of collecting and maintaining in-situ marine data threatens the sustainable usage of the ocean. Aims: This paper provides an overview of current data and data quality (DQ) requirements. We also investigate limitations in the current practices that obstruct data reusability. The ultimate objective is to improve data requirements elicitation, leading to enhanced data reusability. Method: We interviewed 14 marine practitioners and researchers from 7 organizations with extensive experience in collecting, managing, and utilizing in-situ marine data. Results: We identify 9 representative use cases in the fishery, energy, and marine sciences industries, as well as their data and DQ requirements. The results give guidance to data producers to produce data meeting demands of a wider range of data consumers. At the same time, data consumers can refer to the compilation to identify existing data suiting their needs. Furthermore, we recommend a roadmap taken into account during requirements elicitation to improve 6 limitations in the current practices that obstruct data reusability.

Artificial intelligence (AI) in its various forms finds more and more its way into complex distributed systems. For instance, it is used locally, as part of a sensor system, on the edge for low-latency high-performance inference, or in the cloud, e.g. for data mining. Modern complex systems, such as connected vehicles, are often part of an Internet of Things (IoT). This poses additional architectural challenges. To manage complexity, architectures are described with architecture frameworks, which are composed of a number of architectural views connected through correspondence rules. Despite some attempts, the definition of a mathematical foundation for architecture frameworks that are suitable for the development of distributed AI systems still requires investigation and study. In this paper, we propose to extend the state of the art on architecture framework by providing a mathematical model for system architectures, which is scalable and supports co-evolution of different aspects for example of an AI system. Based on Design Science Research, this study starts by identifying the challenges with architectural frameworks in a use case of distributed AI systems. Then, we derive from the identified challenges four rules, and we formulate them by exploiting concepts from category theory. We show how compositional thinking can provide rules for the creation and management of architectural frameworks for complex systems, for example distributed systems with AI. The aim of the paper is not to provide viewpoints or architecture models specific to AI systems, but instead to provide guidelines based on a mathematical formulation on how a consistent framework can be built up with existing, or newly created, viewpoints. To put in practice and test the approach, the identified and formulated rules are applied to derive an architectural framework for the EU Horizon 2020 project “Very efficient deep learning in the IoT” (VEDLIoT) in the form of a case study.

Automated Vehicle (AV) technology has evolved significantly both in complexity and impact and is expected to ultimately change urban transportation. Due to this evolution, the development of AVs challenges the current state of automotive engineering practice, as automotive companies increasingly include agile ways of working in their plan-driven systems engineering—or even transition completely to scaled-agile approaches. However, it is unclear how knowledge about human factors (HF) and technological knowledge related to the development of AVs can be brought together in a way that effectively supports today’s rapid release cycles and agile development approaches. Based on semi-structured interviews with ten experts from industry and two experts from academia, this qualitative, exploratory case study investigates the relationship between HF and AV development. The study reveals relevant properties of agile system development and HF, as well as the implications of these properties for integrating agile work, HF, and requirements engineering. According to the findings, which were evaluated in a workshop with experts from academia and industry, a culture that values HF knowledge in engineering is key. These results promise to improve the integration of HF knowledge into agile development as well as to facilitate HF research impact and time to market.

Artificial Intelligence (AI), and especially machine learning can be used to find statistical patterns in datasets with thousands of variables with ease. But an understanding of causality is difficult to learn for a machine. For humans however, realising causal relations is often not a difficult process, as we can refer to experience or scientific knowledge. Here we propose the use of structural causal models, represented through direct acyclic graphs, to design, determine, and communicate causal relations hidden beyond the statistical models of an AI. The idea is to make human insight in causal relations explicit and use this knowledge during AI system development. In a joint-industry project we discovered that structural causal models can serve as living boundary objects that facilitate coordination of domain experts, data scientists, systems engineers, and AI experts in AI system development.

The VEDLIoT project targets the development of energy-efficient Deep Learning for distributed AIoT applications. A holistic approach is used to optimize algorithms while also dealing with safety and security challenges. The approach is based on a modular and scalable cognitive IoT hardware platform. Using modular microserver technology enables the user to configure the hardware to satisfy a wide range of applications. VEDLIoT offers a complete design flow for Next-Generation IoT devices required for collaboratively solving complex Deep Learning applications across distributed systems. The methods are tested on various use-cases ranging from Smart Home to Automotive and Industrial IoT appliances. VEDLIoT is an H2020 EU project which started in November 2020. It is currently in an intermediate stage with the first results available.

In automotive, stage-gate processes have previously been the norm, with architecture created mainly during an early phase and then used to guide subsequent development phases. Current iterative and Agile development methods, where the implementation evolves continuously, changes the role of architecture. We investigate how architecture evaluation can provide useful feedback during development of continuously evolving systems. Starting from the Architecture Tradeoff Analysis Method (ATAM), we performed architecture evaluation, both in a national research project led by an automotive Original Equipment Manufacturer (OEM), and at the OEM, in the context of continuous development. This allows us to include the experience of several architects from different organizations over several years. Using data produced during the evaluations we perform a post-hoc analysis to derive initial findings. We then validate and refine these findings through a series of focus groups with architects and industry experts. We propose principles of continuous evaluation and evolution of architecture, and based on these discuss a roadmap for future research. In iterative development settings, the needs are different from what typical architecture evaluation methods provide. Our principles show the importance of dedicated feedback-loops for continuous evolution of systems and their architecture.

Context: The relevance of Requirements Engineering (RE) research to practitioners is vital for a long-term dissemination of research results to everyday practice. Some authors have speculated about a mismatch between research and practice in the RE discipline. However, there is not much evidence to support or refute this perception.Objective: This article presents the results of a study aimed at gathering evidence from practitioners about their perception of the relevance of RE research and at understanding the factors that influence that perception.Method: We conducted a questionnaire-based survey of industry practitioners with expertise in RE. The participants rated the perceived relevance of 435 scientific papers presented at five top RE-related conferences.Results: The 153 participants provided a total of 2,164 ratings. The practitioners rated RE research as essential or worthwhile in a majority of cases. However, the percentage of non-positive ratings is still higher than we would like. Among the factors that affect the perception of relevance are the research's links to industry, the research method used, and respondents’ roles. The reasons for positive perceptions were primarily related to the relevance of the problem and the soundness of the solution, while the causes for negative perceptions were more varied. The respondents also provided suggestions for future research, including topics researchers have studied for decades, like elicitation or requirement quality criteria.Conclusions: The study is valuable for both researchers and practitioners. Researchers can use the reasons respondents gave for positive and negative perceptions and the suggested research topics to help make their research more appealing to practitioners and thus more prone to industry adoption. Practitioners can benefit from the overall view of contemporary RE research by learning about research topics that they may not be familiar with, and compare their perception with those of their colleagues to self-assess their positioning towards more academic research.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Agile methods have become mainstream even in large-scale systems engineering companies that need to accommodate different development cycles of hardware and software. For such companies, requirements engineering is an essential activity that involves upfront and detailed analysis which can be at odds with agile development methods. This paper presents a multiple case study with seven large-scale systems companies, reporting their challenges, together with best practices from industry. We also analyze literature about two popular large-scale agile frameworks, SAFe® and LeSS, to derive potential solutions for the challenges. Our results are based on 20 qualitative interviews, five focus groups, and eight cross-company workshops which we used to both collect and validate our results. We found 24 challenges which we grouped in six themes, then mapped to solutions from SAFe®, LeSS, and our companies, when available. In this way, we contribute a comprehensive overview of RE challenges in relation to large-scale agile system development, evaluate the degree to which they have been addressed, and outline research gaps. We expect these results to be useful for practitioners who are responsible for designing processes, methods, or tools for large scale agile development as well as guidance for researchers.

Driven by the need for faster time-to-market and reduced development lead-time, large-scale systems engineering companies are adopting agile methods in their organizations. This agile transformation is challenging and it is common that adoption starts bottom-up with agile software teams within the context of traditional company structures. This creates the challenge of agile teams working within a document-centric and plan-driven (or waterfall) environment. While it may be desirable to take the best of both worlds, it is not clear how that can be achieved especially with respect to managing requirements in large-scale systems. This paper presents an exploratory case study focusing on two departments of a large-scale systems engineering company (automotive) that is in the process of company-wide agile adoption. We present challenges that agile teams face while working within a larger plan-driven context and propose potential strategies to mitigate the challenges. Challenges relate to, e.g., development teams not being aware of the high-level requirements, difficulties to manage change of these requirements as well as their relationship to backlog items such as user stories. While we found strategies for solving most of the challenges, they remain abstract and empirical research on their effectiveness is currently lacking.

Large-scale system development companies are increasingly adopting agile methods. While this adoption may improve lead-times, such companies need to balance two trade-offs: (i) the need to have a uniform, consistent development method on system level with the need for specialised methods for teams in different disciplines (e.g., hardware, software, mechanics, sales, support); (ii) the need for comprehensive documentation on system level with the need to have lightweight documentation enabling iterative and agile work. With specialised methods for teams, isolated teams work within larger ecosystems of plan-driven culture, i.e., teams become agile "islands". At the boundaries, these teams share knowledge which needs to be managed well for a correct system to be developed. While it is useful to support diverse and specialised methods, it is important to understand which islands are repeatedly encountered, the reasons or factors triggering their existence, and how best to handle coordination between them. Based on a multiple case study, this work presents a catalogue of islands and the boundary objects between them. We believe this work will be beneficial to practitioners aiming to understand their ecosystems and researchers addressing communication and coordination challenges in large-scale development.

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 automotive domain is rapidly changing in the last years. Among the different challenges OEMs (i.e. the vehicle manufacturers) are facing, vehicles are evolving into systems of systems. In fact, over the last years vehicles have evolved from disconnected and “blind” systems to systems that are (i) able to sense the surrounding environment and (ii) connected with other vehicles, the city, pedestrians, cyclists, etc. Future transportation systems can be seen as a System of Systems (SoS). In an SoS, constituent systems, i.e. the units that compose an SoS, can act as standalone systems, but their cooperation enables new emerging and promising scenarios. While this trend creates new opportunities, it also poses a risk to compromise key qualities such as safety, security, and privacy. In this paper we focus on the automotive domain and we investigate how to engineer and architect cars in order to build them as constituents of future transportation systems. Our contribution is an architectural viewpoint for System of Systems, which we demonstrate based on an automotive example. Moreover, we contribute a functional reference architecture for cars as constituents of an SoS. This reference architecture can be considered as an imprinting for the implementations that would be devised in specific projects and contexts. We also point out the necessity for a collaboration among different OEMs and with other relevant stakeholders, such as road authorities and smart cities, to properly engineer systems of systems composed of cars, trucks, roads, pedestrians, etc. This work is realized in the context of two Swedish projects coordinated by Volvo Cars and involving some universities and research centers in Sweden and many suppliers of the OEM, including Autoliv, Arccore, Combitech, Cybercom, Knowit, Prevas, ÅF-Technology, Semcom, and Qamcom.

Practitioners struggle with creating and evolving an architecture when developing complex and safety-critical systems in large-scale agile contexts. A key issue is the trade-off between upfront planning and flexibility to embrace change. In particular, the coordination of interfaces is an important challenge, as interfaces determine and regulate the exchange of information between components, subsystems, and systems, which are often developed by multiple teams. In a fast-changing environment, boundary objects between teams can provide the sufficient stability to align software or systems, while maintaining a sufficient degree of autonomy. However, a better understanding of interfaces as boundary objects is needed to give practical guidance. This paper presents an exploratory case study with an automotive OEM to identify characteristics of different interfaces, from non-critical interfaces that can be changed frequently and quickly, to those that are critical and require more stability and a rigorous change process. We identify what dimensions impact how interfaces are changed, what categories of interfaces exist along these dimensions, and how categories of interfaces change over time. We conclude with suggestions for practices to manage the different categories of interfaces in large-scale agile development.

Automotive manufacturers have historically adopted rigid requirements engineering processes. This allowed them to meet safety-critical requirements when producing a highly 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 automotive industry. In particular, the needs of improving development speed are increasingly pushing companies in this domain toward new ways of developing software. In this paper, we investigate how the goal to increase development speed impacts how requirements are managed in the automotive domain. We start from a manager perspective, which we then complement with a more general perspective. We used a qualitative multiple-case study, organized in two steps. In the first step, we had 20 semi-structured interviews, at two automotive manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists. In the second step, we validated our results with 12 more interviews, covering nine additional respondents and three recurring from the first step. In addition 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 requirements engineering approach that impact development speed. These aspects include the negative impact of a requirements style dominated by safety concerns as well as decomposition of requirements over many levels of abstraction. Furthermore, the use of requirements as part of legal contracts with suppliers is seen as hindering fast collaboration. Six additional suggestions for potential improvements include domain-specific tooling, model-based requirements, test automation, and a combination of lightweight upfront requirements engineering preceding development with 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 requirements engineering approaches in the automotive domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical systems.

Summary Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders and makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design‐science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry.

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.

In the last decades, agile methods had a huge impact on how software is developed. In many cases, this has led to significant benefits, such as quality and speed of software deliveries to customers. However, safety-critical systems have widely been dismissed from benefiting from agile methods. Products that include safety critical aspects are therefore faced with a situation in which the development of safety-critical parts can significantly limit the potential speed-up through agile methods, for the full product, but also in the non-safety critical parts. For such products, the ability to develop safety-critical software in an agile way will generate a competitive advantage. In order to enable future research in this important area, we present in this paper a mapping of the current state of practice based on a mixed method approach. Starting from a workshop with experts from six large Swedish product development companies we develop a lens for our analysis. We then present a systematic mapping study on safety-critical systems and agile development through this lens in order to map potential benefits, challenges, and solution candidates for guiding future research.

Automotive companies increasingly include proven agile methods in their plan-driven system development. The adoption of agile methods impacts not only the way individuals collaborate, but also the management of artifacts like requirements, test cases, safety documentation, and models. While practitioners aim to reduce unnecessary documentation, there is a lack of guidance for automotive companies with respect to what artifacts are needed and how to manage them. To close this knowledge gap and create practical guidelines, we conducted a design-science study together with 53 practitioners from six automotive companies. Using interviews, surveys, and focus groups, we analyzed categories of artifacts and practical challenges to create applicable guidelines to collaboratively manage artifacts in agile automotive contexts. Our findings indicate that different practices are required to manage artifacts that are shared among different teams within the company (boundary objects) and those that are relevant within a specific team (locally relevant artifacts).

Context: Historically, automotive manufacturers have adopted rigid requirements engineering processes, which allowed them to meet safety-critical requirements while integrating thousands of physical and software components into a highly complex and differentiated product. Nowadays, needs of improving development speed are pushing companies in this domain towards new ways of developing software. Objectives: We aim at obtaining a manager perspective on how the goal to increase development speed impacts how software intense automotive systems are developed and their requirements managed. Methods: We used a qualitative multiple-case study, based on 20 semi-structured interviews, at two automotive manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists. Results: We found that both a requirements style dominated by safety concerns, and decomposition of requirements over many levels of abstraction impact development speed negatively. Furthermore, the use of requirements as part of legal contracts with suppliers hiders fast collaboration. Suggestions for potential improvements include domain-specific tooling, model-based requirements, test automation, and a combination of lightweight pre-development requirements engineering with precise specifications post-development. Conclusions: We offer an empirical account of expectations and needs for new requirements engineering approaches in the automotive domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical systems.

T-Reqs is a text-based requirements management solution based on the git version control system. It combines useful conventions, templates and helper scripts with powerful existing solutions from the git ecosystem and provides a working solution to address some known requirements engineering challenges in large-scale agile system development. Specifically, it allows agile cross-functional teams to be aware of requirements at system level and enables them to efficiently propose updates to those requirements. Based on our experience with T-Reqs, we i) relate known requirements challenges of large-scale agile system development to tool support; ii) list key requirements for tooling in such a context; and iii) propose concrete solutions for challenges.

Problem: The involvement of external stakeholders in capstone projects and project courses is desirable due to its potential positive effects on the students. Capstone projects particularly profit from the inclusion of an industrial partner to make the project relevant and help students acquire professional skills. In addition, an increasing push towards education that is aligned with industry and incorporates industrial partners can be observed. However, the involvement of external stakeholders in teaching moments can create friction and could, in the worst case, lead to frustration of all involved parties. Contribution: We developed a model that allows analysing the involvement of external stakeholders in university courses both in a retrospective fashion, to gain insights from past course instances, and in a constructive fashion, to plan the involvement of external stakeholders. Key Concepts: The conceptual model and the accompanying guideline guide the teachers in their analysis of stakeholder involvement. The model is comprised of several activities (define, execute, and evaluate the collaboration). The guideline provides questions that the teachers should answer for each of these activities. In the constructive use, the model allows teachers to define an action plan based on an analysis of potential stakeholders and the pedagogical objectives. In the retrospective use, the model allows teachers to identify issues that appeared during the project and their underlying causes. Drawing from ideas of the reflective practitioner, the model contains an emphasis on reflection and interpretation of the observations made by the teacher and other groups involved in the courses. Key Lessons: Applying the model retrospectively to a total of eight courses shows that it is possible to reveal hitherto implicit risks and assumptions and to gain a better insight into the interaction between external stakeholders and students. Our empirical data reveals seven recurring risk themes that categorise the different risks appearing in the analysed courses. These themes can also be used to categorise mitigation strategies to address these risks proactively. Additionally, aspects not related to external stakeholders, e.g., about the interaction of the project with other courses in the study programme, have been revealed. The constructive use of the model for one course has proved helpful in identifying action alternatives and finally deciding to not include external stakeholders in the project due to the perceived cost-benefit-ratio. Implications to Practice: Our evaluation shows that the model is a viable and useful tool that allows teachers to reason about and plan the involvement of external stakeholders in a variety of course settings, and in particular in capstone projects.

Software engineering practice has shifted from the development of products in closed environments toward more open and collaborative efforts. Software development has become significantly interdependent with other systems (e.g. services, apps) and typically takes place within large ecosystems of networked communities of stakeholder organizations. Such software ecosystems promise increased innovation power and support for consumer-oriented software services at scale and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings requirements engineering-related challenges within the ecosystem, such as managing dynamic, emergent contributions from the ecosystem stakeholders, as well as collecting their input while protecting their IP. In this paper, we report from a study of requirements communication and management practices within IBM ® ’s Collaborative Lifecycle Management ® product development ecosystem. Our research used multiple methods for data collection, including interviews within several ecosystem actors, on-site participatory observation, and analysis of online project repositories. We chart and describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for “just-in-time” RE—and which relies on emergent contributions from the ecosystem stakeholders—, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about by the openness in software ecosystems: (1) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem and (2) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end users’ context-specific needs in a timely manner. A sufficient level of openness facilitates contributions of emergent stakeholders. The ability to include important emergent contributors early in requirements elicitation appears to be a crucial asset in software ecosystems.

Project success in the automotive industry is highly influenced by requirements engineering (RE), for which communication and organisation structure play a major role, much due to the scale and distribution of these projects. However, empirical research is scarce on these aspects of automotive RE and warrants closer examination. Therefore, the purpose of this paper is to identify problems or challenges in automotive RE with respect to communication and organisation structure. Using a multiple-case study approach, we collected data via 14 semi-structured interviews at one car manufacturer and one supplier. We tested our findings from the case study with a questionnaire distributed to practitioners in the automotive industry. Our results indicate that it is difficult but increasingly important to establish communication channels outside the fixed organisation structure and that responsibilities are often unclear. Product knowledge during early requirements elicitation and context knowledge later on is lacking. Furthermore, abstraction gaps between requirements on different abstraction levels leads to inconsistencies. For academia, we formulate a concrete agenda for future research. Practitioners can use the findings to broaden their understanding of how the problems manifest and to improve their organisations.

Formalising requirements has the potential to solve problems arising from deficiencies in natural language descriptions. While behavioural requirements are rarely described formally in industry, increasing complexity and new safety standards have renewed the interest in formal specifications. The goal of this paper is to explore how behavioural requirements for embedded systems can be formalised and aligned with verification tasks. Over the course of a 2.5-year project with industry, we modelled existing requirements from a safety-critical automotive software function in several iterations. Taking practical limitations and stakeholder preferences into account, we explored the use of models on different abstraction levels. The final model was used to generate test cases and was evaluated in three interviews with relevant industry practitioners. We conclude that models on a high level of abstraction are most suitable for industrial requirements engineering, especially when they need to be interpreted by other stakeholders.

The relevance of Requirements Engineering (RE) research to practitioners is a prerequisite for problem-driven research in the area and key for a long-term dissemination of research results to everyday practice. To understand better how industry practitioners perceive the practical relevance of RE research, we have initiated the RE-Pract project, an international collaboration conducting an empirical study. This project opts for a replication of previous work done in two different domains and relies on survey research. To this end, we have designed a survey to be sent to several hundred industry practitioners at various companies around the world and ask them to rate their perceived practical relevance of the research described in a sample of 418 RE papers published between 2010 and 2015 at the RE, ICSE, FSE, ESEC/FSE, ESEM and REFSQ conferences. In this paper, we summarize our research protocol and present the current status of our study and the planned future steps.

Motivated by their success in software development, companies implement agile methods and their practices increasingly for software-intense, large products, such as cars, telecommunication infrastructure, and embedded systems. Such systems are usually subject to safety and regulative concerns as well as different development cycles of hardware and software. Consequently, requirements engineering involves upfront and detailed analysis, which can be at odds with agile (software) development. In this paper, we present results from a multiple case study with two car manufacturers, a telecommunications company, and a technology company that are on the journey to introduce organization wide continuous integration and continuous delivery to customers. Based on 20 qualitative interviews, 5 focus groups, and 2 cross-company workshops, we discuss possible scopes of agile methods within system development, the consequences this has on the role of requirements, and the challenges that arise from the interplay of requirements engineering and agile methods in large-scale system development. These relate in particular to communicating and managing knowledge about a) customer value and b) the system under development. We conclude that better alignment of a holistic requirements model with agile development practices promises rich gains in development speed, flexibility, and overall quality of software and systems.

The practice of Continuous Integration (CI) has a big impact on how software is developed today. Shortening integration and feedback cycles promises to increase software quality, feature throughput, and customer satisfaction. Thus, it is not a surprise that companies try to embrace CI in domains where it is rather difficult to implement.

Along with technological developments and increasing competition there is a major incentive for companies to produce and market high quality products before their competitors. In order to conquer a bigger portion of the market share, companies have to ensure the quality of the product in a shorter time frame. To accomplish this task companies try to automate their test processes as much as possible. It is critical to investigate and understand the problems that occur during different stages of test automation processes. In this paper we report on a case study on automatic analysis of non-functional test results. We discuss challenges in the face of continuous integration and deployment and provide improvement suggestions based on interviews at a large company in Sweden. The key contributions of this work are filling the knowledge gap in research about performance regression test analysis automation and providing warning signs and a road map for the industry.

Traceability and trace link management are important for various reasons, including managing knowledge about a complex software system, monitoring the progress of its development, and proving that it is developed in accordance to regulations. However, it is difficult to maintain and use trace links in real-world projects where artifacts undergo constant change and multiple stakeholders are involved. In this paper, we extend the current body of knowledge on traceability management by regarding its collaborative aspects in an industrial setting. Based on 15 industrial cases and semi-structured interviews with 24 practitioners, we identify challenges involved in collaborative traceability management, and how traceability management can be used to enable collaboration. Our findings show that main challenges are boundaries between organizations and tools, a lack of common goals and responsibilities, and the difficulty of collaboratively maintaining trace links. We also identify traceability as an important facilitator for communication and knowledge management across these boundaries.

One of the benefits of agile is close collaboration of customer and developer. This ensures good commitment and excellent knowledge flows of information about priorities and efforts. However, it is unclear if this benefit can be leveraged at scale. Clearly, it is infeasible to use practices such as planning game with several agile teams in the room. In this paper, we investigate how a large-scale agile organization manages, what challenges exist, and which opportunities can be leveraged. We found challenges in three areas: (i) the ability to estimate, prioritize, and plan; (ii) the context of planning with respect to working environment, team build-up, and team spirit; and (iii) the ceremonial agreement which promises to allow leveraging abilities in a given context.

The automotive industry is currently going through an enormous change, transitioning from being pure hardware and mechanical companies to becoming more software focused. Currently, software development is embedded into a V-Model process that defines how software requirements are extracted from system requirements. In recent years, OEMs have come to recognize the importance and opportunities offered by software, which include better management and shorter time-to-market of distinguishing features. Strategies to better utilize software include in-house software development and new ways to collaborate with suppliers. However, in their effort to take advantage of these opportunities, engineers struggle with the formal process imposed on software development. In this paper, we investigate the impact of this struggle on the flow of requirements, including challenges and practices. We found that new ways of working with requirements had emerged that are partly not supported, partly hindered by the old tooling and processes for requirements engineering. Requirements flow both vertical and horizontal in the organization and across the supply-chain. Support for the new way of working should allow us to refine requirements iteratively throughout their life-cycle, handle the discussion of rationales, and to manage assumptions. We found strategies of achieving this to differ not only between OEMs, but also between different divisions inside the OEMs.

AUTOSAR has changed significantly how software is developed in the automotive sector. As a central standard, AUTOSAR enables reuse of software components as well as their interoperability. For AUTOSAR compliant ECU development, car manufacturers source Electronic Control Units (ECUs) from Tier-1 suppliers, but ask those Tier-1 suppliers to install AUTOSAR compliant basic software from a certified AUTOSAR-Tier-2 supplier. In this setup (to which we refer as the AUTOSAR ecosystem), the OEM has a direct business relationship with the Tier-1, but only an indirect relationship to the AUTOSAR-Tier-2 supplier, which leads to complex flows of requirements and related information between the organizations involved. In this extended abstract, we summarize preliminary results of a qualitative investigation of Requirements Engineering challenges in the AUTOSAR ecosystem. In particular, we interviewed 7 project managers from an AUTOSAR-Tier-2 supplier, and triangulated our results with 6 additional interviews with subjects from two Tier-1 suppliers and one OEM. We found that most of the requirements towards the AUTOSAR-Tier-2 supplier can be directly mapped to standard AUTOSAR components. However, a significant amount of requirements were new requirements and specific to the OEM or even a project. The well-known requirements engineering challenges we found to surface in the AUTOSAR ecosystem were mainly connected to these non-standard requirements. Standard and non-standard requirements are usually mixed, which makes it hard to fully leverage the potential benefits of reuse within the AUTOSAR standard. We argue that the holistic ecosystem perspective allows exploration of new strategies for mitigating this challenge.

A growing number of software systems is characterized by continuous evolution as well as by significant interdependence with other systems (e.g. services, apps). Such software ecosystems promise increased innovation power and support for consumer oriented software services at scale, and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings some challenges to Requirements Engineering (RE) within the ecosystem. We report from a mixed-method study of IBM®'s CLM®ecosystem that uses an open commercial development model. We analyzed data from from interviews within several ecosystem actors, participatory observation, and software repositories, to describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for `just-in-time' RE, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about the openness in software ecosystems: i) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem, and ii) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end-users' context specific needs in a timely manner.

In this extended abstract, we present the ecosystemability assessment method as a means to assess the extent to which a software system, represented by its architecture and its development environment, supports the vision of ecosystem.

This demo introduces V:ISSUE:LIZER, a tool for exploring online communication and analyzing clarification of requirements over time. V:Issue:lizer supports managers and developers to identify requirements with insufficient shared understanding, to analyze communication problems, and to identify developers that are knowledgeable about domain or project related issues through visualizations. Our preliminary evaluation shows that V:Issue:lizer offers managers valuable information for their decision making. (Demo video: http://youtu.be/Oy3xvzjy3BQ).

During acceptance testing customers assess whether a system meets their expectations and often identify issues that should be improved. These findings have to be communicated to the developers -- a task we observed to be error prone, especially in distributed teams. Here, it is normally not possible to have developer representatives from every site attend the test. Developers who were not present might misunderstand insufficiently documented findings. This hinders fixing the issues and endangers customer satisfaction. Integrated feedback systems promise to mitigate this problem. They allow to easily capture findings and their context. Correctly applied, this technique could improve feedback, while reducing customer effort. This paper collects our experiences from comparing acceptance testing with and without feedback systems in a distributed project. Our results indicate that this technique can improve acceptance testing -- if certain requirements are met. We identify key requirements feedback systems should meet to support acceptance testing.

In current project environments, requirements often evolve throughout the project and are worked on by stakeholders in large and distributed teams. Such teams often use online tools such as mailing lists, bug tracking systems or online discussion forums to communicate, clarify or coordinate work on requirements. In this kind of environment, the expected evolution from initial idea, through clarification, to a stable requirement, often stagnates. When project managers are not aware of underlying problems, development may proceed before requirements are fully understood and stabilized, leading to numerous implementation issues and often resulting in the need for early redesign and modification. In this paper, we present an approach to analyzing online requirements communication and a method for the detection and classification of clarification events in requirement discussions. We used our approach to analyze online requirements communication in the IBM®Rational Team Concert®(RTC) project and identified a set of six clarification patterns. Since a predominant amount of clarifications through the lifetime of a requirement is often indicative of problematic requirements, our approach lends support to project managers to assess, in real-time, the state of discussions around a requirement and promptly react to requirements problems.

In practice, more and more software development projects are distributed, ranging from partly distributed teams to global projects with each stakeholder located differently. Teaching actual practice in software engineering at university needs a proper mixture of theory and practice. But setting up practical exercises for global software engineering is hard, because students have to cooperate across different locations and situations reflecting the teaching intentions have to be provoked explicitly. This paper presents the concepts behind our common teaching environment for global software engineering - the GloSELab. It describes the experiences on setting up a distributed course and reports our teaching intentions based on each universities main focus: project management, requirements engineering & quality assurance, architecture, and implementation. Furthermore, we discuss our setup - a stage-gate process, where each location takes care of a different phase - and report occurred problems and how they supported or interfered with our teaching intentions.

Distributed software development is more difficult than co-located software development. One of the main reasons is that communication is more difficult in distributed settings. Defined processes and artifacts help, but cannot cover all information needs. Not communicating important project information, decisions and rationales can result in duplicate or extra work, delays or even project failure. Planning and managing a distributed project from an information flow perspective helps to facilitate available communication channels right from the start - beyond the documents and artifacts which are defined for a given development process. In this paper we propose FLOW Mapping, a systematic approach for planning and managing information flows in distributed projects. We demonstrate the feasibility of our approach with a case study in a distributed agile class room project. FLOW Mapping is sufficient to plan communication and to measure conformance to the communication strategy. We also discuss cost and impact of our approach.

Today, people find themselves surrounded by IT systems in their everyday life. Often they are not even aware that they are interacting with an IT system. More and more of these systems are context adaptive. Requirements to such systems may change for various reasons: The context may fundamentally change when other systems are introduced. New trends and fashions may evolve. Operators need to react quickly to such changes if they want to keep their systems competitive. Traditional approaches to requirements elicitation start to fail in this situation: context adaptive systems serve many users with different profiles. In addition, users may be reluctant to participate in improving it. Thus, it is hard to establish a representative model of requirements. Furthermore, it is hard to capture the context of requirements by subsequent interviews. In this paper we present a systematical approach for requirements elicitation based on observing anonymous users. The interaction of users with the system is observed in the normal working context. Observation is based on assumptions on how interaction should take place. Deviations from these assumptions point to new requirements. Observing a large number of users leads to a quantitative map of requirements in context. Preliminary evaluation shows that the approach is promising. It allows efficient observation of many stakeholders and the derivation of new requirements.

Adapting new software processes and practices in organizational and academic environments requires training the developers and validating the applicability of the newly introduced activities. Investigating process conformance during training and understanding if programmers are able and willing to follow the specific steps are crucial to evaluating whether the process improves various software product quality factors. In this paper we present a process model independent approach to detect process non-conformance. Our approach is based on non-intrusively collected data captured by a version control system and provides the project manager with timely updates. Further, we provide evidence of the applicability of our approach by investigating process conformance in a five day training class on eXtreme Programming (XP) practices at the Leibniz Universität Hannover. Our results show that the approach enabled researchers to formulate minimal intrusive methods to check for conformance and that for the majority of the investigated XP practices violations could be detected.

Global software engineering has become a fact in many companies due to real necessity in practice. In contrast to co-located projects global projects face a number of additional software engineering challenges. Among them quality management has become much more difficult and schedule and budget overruns can be observed more often. Compared to co-located projects global software engineering is even more challenging due to the need for integration of different cultures, different languages, and different time zones-across companies, and across countries. The diversity of development locations on several levels seriously endangers an effective and goal-oriented progress of projects. In this position paper we discuss reasons for global development, sketch settings for distribution and views of orchestration of dislocated companies in a global project that can be seen as a ldquovirtual project environmentrdquo. We also present a collection of questions, which we consider relevant for global software engineering. The questions motivate further discussion to derive a research agenda in global software engineering.

The complexity of today's software systems is constantly increasing. As a result, requirements for these systems become more comprehensive and complicated. In this setting, requirements engineers struggle to capture consistent and complete requirements of high quality. We propose a feedback-centric requirements editor to help analysts controlling the information overload. Our HeRA tool provides analysts with important data from various feedback facilities. The feedback is directly given based on the input to the editor. On the one hand, it is based on heuristic rules, on the other hand, on automatically derived models. Thus, when new requirements are added, the analyst gets important information on how consistent these requirements are with the existing ones.

Writing good requirements is difficult. Authors of requirements specifications need to acquire specific habits and professional writing styles to avoid ambigu-ities. However, gaining and sharing related experience and abilities is challenging. Heuristic Critiques offer help in this situation. Experience on writing good re-quirements can be codified as heuristic critiques. When integrated in a requirements tool, a heuristic critique can automatically check requirements specifications and provide constructive feedback (critique), whenever a piece of experience is applicable. Observing this feedback helps requirements authors to transfer expe-rience in writing, and internalize it. In this paper we describe the concept of learning to write better re-quirements through heuristic critiques - both, on an individual level and on an organizational level. The proposed concept has been applied in several dedicat-ed requirements support tools; it can also be used to improve existing tools and methods.

When developing a Service-Oriented Architecture(SOA), analyzing the business process is even more important than in normal software projects. Nevertheless, most of the requirements artifacts used in normal software projects apply to SOA-projects, too. This results in competing requirement models (like use cases and business processes) that duplicate information in parts. Even worse, these models are often contradictory, belong to different types of stakeholders, and need much effort to be synchronized. However, these inconsistencies are an important source for requirements. We propose to deliberately switch between different perspectives onto the requirements to clarify them as soon as possible. In this way we a) enrich feedback and b) improve existing models as a by-product by confronting stakeholders with new perspectives. User interface mockups, data models, and business processes complement, enrich, and facilitate a pure use case perspective. We present a set of computer-supported techniques that leverage this friction between models and share our experiences in applying them.

Teaching (and therefore learning) eXtreme Programming (XP) in a university setting is difficult because of course time limitations and the soft nature of XP that requires first-hand experience in order to see and really learn the methods. For example, iterations are either shorter or fewer than appropriate. In this paper we present the properties to tune when designing an eXtreme Programming course. These are the properties we gathered by conducting three XP labs as part of our software engineering teaching. Within this paper we describe our set-up as well as the important properties. Lecturers and teachers can use this property system and combine it with their own constraints in order to derive a better XP lab for their curriculum.

Software requirements specifications (SRS) are hard to compare due to the uniqueness of the projects they were created in. In practice this means that it is not possible to objectively determine if a projects SRS fails to reach a certain quality threshold. Therefore, a commonly agreed-on quality model is needed. Additionally, a large set of empirical data is needed to establish a correlation between project success and quality levels. As there is no such quality model, we had to define our own based on the goal-question-metric (GQM) method. Based on this we analyzed more than 40 software projects (student projects in undergraduate software engineering classes), in order to contribute to the empirical part. This paper contributes in three areas: Firstly, we outline our GQM plan and our set of metrics. They were derived from widespread literature, and hence could lead to a discussion of how to measure requirements quality. Practitioners and researchers can profit from our experience, when measuring the quality of their requirements. Secondly, we present our findings. We hope that others find these valuable when comparing them to their own results. Finally,we show that the results of our quality assessment correlate to project success. Thus, we give an empirical indication for the correlation of requirements engineering and project success.