Background: The artifacts used in Agile software testing and the reasons why these artifacts are used are fairly well-understood. However, empirical research on how Agile test artifacts are eventually designed in practice and which quality factors make them useful for software testing remains sparse. Aims: Our objective is two-fold. First, we identify current challenges in using test artifacts to understand why certain quality factors are considered good or bad. Second, we build an Activity-Based Artifact Quality Model that describes what Agile test artifacts should look like. Method: We conduct an industrial survey with 18 practitioners from 12 companies operating in seven different domains. Results: Our analysis reveals nine challenges and 16 factors describing the quality of six test artifacts from the perspective of Agile testers. Interestingly, we observed mostly challenges regarding language and traceability, which are well-known to occur in non-Agile projects. Conclusions: Although Agile software testing is becoming the norm, we still have little confidence about general do's and don'ts going beyond conventional wisdom. This study is the first to distill a list of quality factors deemed important to what can be considered as useful test artifacts.

The assessment of new vulnerabilities is an activity that accounts for information from several data sources and produces a 'severity' score for the vulnerability. The Common Vulnerability Scoring System (CVSS) is the reference standard for this assessment. Yet, no guidance currently exists on which information aids a correct assessment and should therefore be considered. In this paper we address this problem by evaluating which information cues increase (or decrease) assessment accuracy. We devise a block design experiment with 67 software engineering students with varying vulnerability information and measure scoring accuracy under different information sets. We find that baseline vulnerability descriptions provided by standard vulnerability sources provide only part of the information needed to achieve an accurate vulnerability assessment. Further, we find that additional information on assets, attacks, and vulnerability type contributes in increasing the accuracy of the assessment; conversely, information on known threats misleads the assessor and decreases assessment accuracy and should be avoided when assessing vulnerabilities. These results go in the direction of formalizing the vulnerability communication to, for example, fully automate security assessments.

The number of papers and articles on goals would suggest that goal-oriented requirements engineering is a well understood and mature area within the requirements engineering discipline. In particular, there is a wealth of published material on formal goal modelling approaches. However, the uptake of the goal approaches advocated by academics and researchers within real world settings appears to be quite low. Where goals are used in industrial practice their use is mainly informal and the methods used are inconsistent. There appears to be a significant gap between research and practice in the use of goals within requirements engineering. A two-part study was undertaken to check whether there is evidence to support this view of a disconnection between research and industry. Firstly, a literature survey of requirements engineering papers about goals reveals a large body of published material, but the majority has little industrial involvement. Secondly, a questionnaire completed by experienced requirements engineering practitioners suggests that use of goals in practice is inconsistent, informal, and rarely utilises formal modelling approaches. This paper proposes future work that would close the gap between research and practice in the use of goals within requirements engineering.

Performance requirements play an important role in software development. They describe system behavior that directly impacts the user experience. Specifying performance requirements in a way that all necessary content is contained, i.e., the completeness of the individual requirements, is challenging, yet project critical. Furthermore, it is still an open question, what content is necessary to make a performance requirement complete. To address this problem, we introduce a framework for specifying performance requirements. This framework (i) consists of a unified model derived from existing performance classifications, (ii) denotes completeness through a content model, and (iii) is operationalized through sentence patterns. We evaluate both the applicability of the framework as well as its ability uncover incompleteness with performance requirements taken from 11 industrial specifications. In our study, we were able to specify 86% of the examined performance requirements by means of our framework. Furthermore, we show that 68% of the specified performance requirements are incomplete with respect to our notion of completeness. We argue that our framework provides an actionable definition of completeness for performance requirements.

Automotive software systems are often characterized by a set of features that are implemented through a network of communicating components. It is common practice to implement or adapt features by an ad hoc (re) use of signals that originate from components of another feature. Thereby, over time some components become so-called implicit communal components. These components increase the necessary efforts for several development activities because they introduce feature dependencies. Refactoring implicit communal components reduces these efforts but also costs refactoring effort. In this paper, we provide empirical evidence that implicit communal components exist in industrial automotive systems. For two cases, we show that less than 10% of the components are responsible for more than 90% of the feature dependencies. Secondly, we propose a refactoring approach for implicit communal components, which makes them explicit by moving them to a dedicated platform component layer. Finally, we characterize implicit communal components as technical debt, which is a metaphor for suboptimal solutions having short-term benefits but causing a long-term negative impact. With this metaphor, we describe the trade-off between accepting the negative effects of implicit communal components and spending the necessary refactoring costs.

[Background] Requirements Engineering is crucial for project success, and to this end, many measures for quality assurance of the software requirements specification (SRS) have been proposed. [Goal] However, we still need an empirical understanding on the extent to which SRS are created and used in practice, as well as the degree to which the quality of an SRS matters to subsequent development activities. [Method] We studied the relevance of SRS by relying on survey research and explored the impact of quality defects in SRS by relying on a controlled experiment. [Results] Our results suggest that the relevance of SRS quality depends both on particular project characteristics and what is considered as a quality defect; for instance, the domain of safety critical systems seems to motivate for an intense usage of SRS as a means for communication whereas defects hampering the pragmatic quality do not seem to be relevant as initially thought. [Conclusion] Efficient and effective quality assurance measures must be specific for carefully characterized contexts and carefully select defect classes.

Requirements change and so (should) do requirements artifacts, such as use cases. However, we have little knowledge about which changes requirements engineers actually perform on use cases. We do not know what is changing, at which locations use cases change and need a deeper understanding of which changes are problematic in terms of difficult or risky.

Many requirements engineering approaches structure and specify requirements based on the notion of modes or system states. The set of all modes is usually considered as the mode model of a system or problem domain.

Context: For many years, researchers and practitioners have been proposing various methods and approaches to Requirements Engineering (RE). Those contributions remain, however, too often on the level of apodictic discussions without having proper knowledge about the practical problems they propagate to address, or how to measure the success of the contributions when applying them in practical contexts. While the scientific impact of research might not be threatened, the practical impact of the contributions is. Aim: We aim at better understanding practically relevant variables in RE, how those variables relate to each other, and to what extent we can measure those variables. This allows for the establishment of generalisable improvement goals, and the measurement of success of solution proposals. Method: We establish a first empirical basis of dependent variables in RE and means for their measurement. We classify the variables according to their dimension (e.g. RE, company, SW project), their measurability, and their actionability. Results: We reveal 93 variables with 167 dependencies of which a large subset is measurable directly in RE while further variables remain unmeasurable or have too complex dependencies for reliable measurements. We critically reflect on the results and show direct implications for research in the field of RE. Conclusion: We discuss a variety of conclusions we can draw from our results. For example, we show a set of first improvement goals directly usable for evidence-based RE research such as "increase flexibility in the RE process", we discuss suitable study types, and, finally, we can underpin the importance of replication studies to obtain generalisability.

Background/Context: The objective of achieving higher sustainability in our lifestyles by information and communication technology has lead to a plethora of research activities in related fields. Consequently, Software Engineering for Sustainability (SE4S) has developed as an active area of research. Objective/Aim: Though SE4S gained much attention over the past few years and has resulted in a number of contributions, there is only one rigorous survey of the field. We follow up on this systematic mapping study from 2012 with a more in-depth overview of the status of research, as most work has been conducted in the last 4 years. Method: The applied method is a systematic mapping study through which we investigate which contributions were made, which knowledge areas are most explored, and which research type facets have been used, to distill a common understanding of the state-of-the-art in SE4S. Results: We contribute an overview of current research topics and trends, and their distribution according to the research type facet and the application domains. Furthermore, we aggregate the topics into clusters and list proposed and used methods, frameworks, and tools. Conclusion: The research map shows that impact currently is limited to few knowledge areas and there is need for a future roadmap to fill the gaps.

Context: The requirements specification is a central artefact in the software engineering (SE) process, and its quality (might) influence downstream activities like implementation or testing. One quality defect that is often mentioned in standards is the use of passive voice. However, the consequences of this defect are still unclear. Goal: We need to understand whether the use of passive voice in requirements has an influence on other activities in SE. In this work we focus on domain modelling. Method: We designed an experiment, in which we ask students to draw a domain model from a given set of requirements written in active or passive voice. We compared the completeness of the resulting domain model by counting the number of missing actors, domain objects and their associations with respect to a specified solution. Results: While we could not see a difference in the number of missing actors and objects, participants which received passive sentences missed almost twice the associations. Conclusion: Our experiment indicates that, against common knowledge, actors and objects in a requirement can often be understood from the context. However, the study also shows that passive sentences complicate understanding how certain domain concepts are interconnected.

The organization of projects with distributed teams is a demanding task for every project manager. Requirements need to be collected, documented, and discussed, and the resulting tasks must be distributed to the responsible sites. These activities require an efficient and continuous communication. Furthermore, it is necessary to monitor a project and to track its progress from a management perspective. As a solution, we opt for a monitoring strategy that is based on the project artifacts and corresponding reports. For this, we defined in a previous work a generic artifact model for agile methods to enable seamless communication and data exchange between projects and teams. In this paper, we present a concrete instance aiming at providing the backbone of the information and data exchange subsystem of a SaaS-based collaborative project management and governance software for distributed software development. We present the artifact model, give insights into its development, and discuss its feasibility. Our findings show that while the previously defined reference model adequately reflects basic concepts and thus allows for coupling distributed projects, we need to refine the artifact model to emphasize project management/governance and its implementation in tools.

Maintenance of unused features leads to unnecessary costs. Therefore, identifying unused features can help product owners to prioritize maintenance efforts. We present a tool that employs dynamic analyses and text mining techniques to identify use case documents describing unused features to approximate unnecessary features. We report on a preliminary study of an industrial business information system over the course of one year quantifying unused features and measuring the performance of the approach. It indicates the relevance of the problem and the capability of the presented approach to detect unused features.

Exchangeability between software components such as operating systems, middleware, databases, and hardware components is a common requirement in many software systems. One way to enable exchangeability is to promote indirect use through a common interface and an implementation for each component that wraps the original component. As developers use the interface instead of the underlying component, they assume that the software system will behave in a specific way independently of the actual component in use. However, differences in the implementations of the wrappers may lead to different behavior when one component is changed for another, which might lead to failures in the field. This work reports on a simple, yet effective approach to detect these differences. The approach is based on tool-supported reviews leveraging lightweight static analysis and machine learning. The approach is evaluated in a case study that analyzes NASA's Operating System Abstraction Layer (OSAL), which is used in various space missions. We detected 84 corner-case issues of which 57 turned out to be bugs that could have resulted in runtime failures.

To create a common understanding of a software system, for users and developers, we believe that run-time visualization of both behavior and internal structure is critical. This is particularly true for distributed embedded systems, which are designed to be unobtrusive, making them difficult to comprehend for people who are not familiar with them. We suggest a novel method to visualize software behavior in real-time flexibly and comfortably, facilitating understanding of software. We conducted a feasibility study with a proof of-concept prototype. Our results indicate that visualizing structure and behavior in real-time supports software comprehension for new architects, developers and users, and can even provide new insights to experienced developers.