Boundary artefacts are shared artefacts that support collaboration by allowing different groups to interpret the same information in different ways. Software development activities benefit from them, as a single artefact can support stakeholders across different organisational boundaries. When these artefacts contain inconsistencies, such as incorrect information, practitioners’ trust in them may decrease, leading to inefficiencies in task execution. This study developed and evaluated a guideline to support the creation of boundary artefacts in software engineering contexts. We conducted a longitudinal, multi-phase study embedded in an industrial setting. The guideline was developed based on a literature review and prior findings from a previous case study and was then submitted for practitioner evaluation. A post-implementation analysis of the guideline was carried out after a period without researcher intervention. Our guideline consists of 10 principles grouped into three categories: (1) Scope: stakeholders, boundaries, and terminology; (2) Structure: artefact format, transference, granularity, and additions; and (3) Management: evaluation, ownership, governance, and integration. Practitioner evaluations suggested that these principles support the creation of reliable, predictable, and functional boundary artefacts. However, practitioners also noted challenges during use, including the time-consuming nature of the activity and difficulties in understanding the concept of boundary artefact. Overall, the guideline was well received. After the non-intervention period, it was adopted as a standard by the partner company for artefacts such as security testing, standards documentation, and requirements specifications. Adoption challenges persisted, including cultural barriers and comprehension issues. Further applications across different artefacts could clarify how the principles influence their reliability, functionality, and predictability.

Context: Software systems in regulated domains must continually adapt to legal changes, yet practitioners often handle updates manually with limited support, making compliance work costly and error prone. Recent advances in LLMs prompt the question of how automation can reliably assist this process. Objectives: We aim to (1) characterize the nature of regulatory changes and derive a systematic taxonomy, (2) understand through the lens of practitioners where automation is most useful, and (3) assess the feasibility of using LLMs for detecting and classifying regulatory changes. Method: We conducted a mixed-methods study grounded in the German social security (DEÜV) in collaboration with practitioners from a FinTech company. First, we developed a taxonomy of regulatory changes through manual document analysis of four Regulatory Implementation Specifications (RIS), followed by a workshop and expert interviews. Second, we validated the taxonomy and elicited challenges through semi-structured practitioner interviews. Third, we built a gold-standard dataset of 93 annotated change instances and evaluated seven state-of-the-art LLMs within an automated detection and classification pipeline. Results: The taxonomy defines five change scopes and four optional context dimensions. Practitioners found it intuitive and useful for filtering relevant changes, particularly Data and Field updates, but reported challenges such as tight deadlines, legal ambiguity, limited traceability, and overlapping categories. In automation, proprietary LLMs performed best, while performance dropped on narrative or weakly structured documents, highlighting sensitivity to document format. Conclusion: The proposed taxonomy provides a practical lens for organizing regulatory change information, and LLMs can support the identification and classification of recurring, structurally explicit changes. Their limitations on context-dependent and infrequent categories suggest that automation should complement, rather than replace, expert assessment, motivating future work on human-in-the-loop compliance tooling across broader regulatory ecosystems.

Consistent requirements and system specifications are essential for the compliance of software systems towards the General Data Protection Regulation (GDPR). Both artefacts need to be “grounded” in the original text and conjointly assure the achievement of privacy by design (PbD). There is little understanding of the perspectives of practitioners on specification objectives and goals to address PbD. Existing approaches to GDPR and PbD do not account for the complex intersection between problem and solution space expressed in GDPR. In this study we explore the demand for conjoint requirements and system specification for PbD and suggest an initial version of an approach to address this demand. We reviewed existing secondary and related primary studies on GDPR compliance and conducted interviews with practitioners to (1) investigate the state-of-practice in requirements and system specifications for GDPR compliance and (2) understand the underlying specification objectives and goals (e.g., traceability). We developed and evaluated an initial version of an approach for requirements and systems specification for PbD, and evaluated it against the specification objectives. The relationship between problem and solution space, as expressed in GDPR, is instrumental in supporting PbD. We demonstrate how our approach, based on the modeling GDPR content with original legal concepts, contributes to specification objectives of capturing legal knowledge, supporting specification transparency for roles involved, and traceability. In addition to assuring traceability, GDPR demands need to be addressed throughout different levels of abstraction in the engineering lifecycle to achieve PbD. Legal knowledge specified in the GDPR text should be captured in specifications to address the demands of different stakeholders and ensure compliance. While our results confirm the suitability of our approach to address practical needs, we also revealed specific needs for the future effective operationalization of our suggested approach.

ABSTRACT The COVID-19 pandemic has permanently altered workplace structures, making remote work a widespread practice. While many employees advocate for flexibility, many employers reconsider their attitude toward remote work and opt for structured return-to-office mandates. Media headlines repeatedly emphasize that the corporate world returns to full-time office work. This study examines how companies in software-intensive industry regulate work location, whether corporate policies have evolved in the last five years, and, if so, how, and why. We collected data on remote work regulation from corporate HR and management representatives from 68 companies that vary in size, location, and preferred work modality. Our findings reveal that although many companies prioritize office-oriented work (50%), most companies in our sample permit hybrid work (84%) and only four companies are returning to full-time office work. Remote work regulation does not reveal any particular new “best practice” as policies differ greatly; however, the single most popular arrangement was the three in-office days per week. More than half of the companies (53%) encourage or mandate office attendance centrally, with additional 18% having decentralized mandates. Over a quarter (28%) have changed regulations gradually increasing the mandatory office presence or implementing differentiated conditions. Our key recommendation for office-oriented companies is to consider trust-based recommendations as an alternative to centralized office presence mandates, while for companies oriented toward remote working, we warn about the points of no (or hard) return. Finally, the current state of policies is clearly not final, as companies continue to experiment and adjust their work regulation

[Context] The lack of practical relevance in many Software Engineering (SE) research contributions is often rooted in oversimplified views of industrial practice, weak industry connections, and poorly defined research problems. Clear criteria for evaluating SE research problems can help align their value, feasibility, and applicability with industrial needs. [Goal] In this paper, we introduce the Lean Research Inception (LRI) framework, designed to support the formulation and assessment of practically relevant research problems in SE. We describe its initial evaluation strategy conducted in a workshop with a network of SE researchers experienced in industry-academia collaboration and report the evaluation of its three assessment criteria (valuable, feasible, and applicable) regarding their importance and completeness in assessing practical relevance. [Method] We applied LRI retroactively to a published research paper, engaging workshop participants in discussing and assessing the research problem by applying the proposed criteria using a semantic differential scale. Participants provided feedback on the criteria’s importance and completeness, drawn from their own experiences in industry-academia collaboration. [Results] The findings reveal an overall agreement on the importance of the three criteria – valuable (83.3%), feasible (76.2%), and applicable (73.8%) – for aligning research problems with industrial needs. Qualitative feedback suggested adjustments in terminology with a clearer distinction between feasible and applicable, and refinements for valuable by more clearly considering business value, ROI, and originality. [Conclusion] While LRI still constitutes ongoing research and requires further evaluation, our emerging results strengthen our confidence that the three criteria applied using the semantic differential scale can already help the community assess the practical relevance of SE research problems.

Abstract Background Code review, the discussion around a code change among humans, forms a communication network that enables its participants to exchange and spread information. Although reported by qualitative studies, our understanding of the capability of code review as a communication network is still limited. Objective In this article, we report on a first step towards understanding and evaluating the capability of code review as a communication network by quantifying how fast and how far information can spread through code review: the upper bound of information diffusion in code review. Method In an in-silico experiment, we simulate an artificial information diffusion within large (Microsoft), mid-sized (Spotify), and small code review systems (Trivago) modelled as communication networks. We then measure the minimal topological and temporal distances between the participants to quantify how far and how fast information can spread in code review. Results An average code review participants in the small and mid-sized code review systems can spread information to between 72 % and 85 % of all code review participants within four weeks independently of network size and tooling; for the large code review systems, we found an absolute boundary of about 11 000 reachable participants. On average (median), information can spread between two participants in code review in less than five hops and less than five days. Conclusion We found evidence that the communication network emerging from code review scales well and spreads information fast and broadly, corroborating the findings of prior qualitative work. The study lays the foundation for understanding and improving code review as a communication network.

Abstract It is commonly accepted that the quality of requirements specifications impacts subsequent software engineering activities. However, we still lack empirical evidence to support organizations in deciding whether their requirements are good enough or impede subsequent activities. We aim to contribute empirical evidence to the effect that requirements quality defects have on a software engineering activity that depends on this requirement. We conduct a controlled experiment in which 25 participants from industry and university generate domain models from four natural language requirements containing different quality defects. We evaluate the resulting models using both frequentist and Bayesian data analysis. Contrary to our expectations, our results show that the use of passive voice only has a minor impact on the resulting domain models. The use of ambiguous pronouns, however, shows a strong effect on various properties of the resulting domain models. Most notably, ambiguous pronouns lead to incorrect associations in domain models. Despite being equally advised against by literature and frequentist methods, the Bayesian data analysis shows that the two investigated quality defects have vastly different impacts on software engineering activities and, hence, deserve different levels of attention. Our employed method can be further utilized by researchers to improve reliable, detailed empirical evidence on requirements quality.

Machine learning (ML)-enabled systems are being increasingly adopted by companies aiming to enhance their products and operational processes. This paper aims to deliver a comprehensive overview of the current status quo of engineering ML-enabled systems and lay the foundation to steer practically relevant and problem-driven academic research. We conducted an international survey to collect insights from practitioners on the current practices and problems in engineering ML-enabled systems. We received 188 complete responses from 25 countries. We conducted quantitative statistical analyses on contemporary practices using bootstrapping with confidence intervals and qualitative analyses on the reported problems using open and axial coding procedures. Our survey results reinforce and extend existing empirical evidence on engineering ML-enabled systems, providing additional insights into typical ML-enabled systems project contexts, the perceived relevance and complexity of ML life cycle phases, and current practices related to problem understanding, model deployment, and model monitoring. Furthermore, the qualitative analysis provides a detailed map of the problems practitioners face within each ML life cycle phase and the problems causing overall project failure. The results contribute to a better understanding of the status quo and problems in practical environments. We advocate for the further adaptation and dissemination of software engineering practices to enhance the engineering of ML-enabled systems. • International survey gathering insights from 188 practitioners across 25 countries. • Overview of current practices and challenges in engineering ML-enabled systems. • Inferential quantitative analysis reporting the status quo with confidence intervals. • Qualitative analysis mapping ML life cycle challenges and causes of project failure.

Context: As the diversity and complexity of regulations affecting Software-Intensive Products and Services (SIPS) is increasing, software engineers need to address the growing regulatory scrutiny. We argue that, as with any other non-negotiable requirements, SIPS compliance should be addressed early in SIPS engineering—i.e., during requirements engineering (RE). Objectives: In the conditions of the expanding regulatory landscape, existing research offers scattered insights into regulatory compliance of SIPS. This study addresses the pressing need for a structured overview of the state of the art in software RE and its contribution to regulatory compliance of SIPS. Method: We conducted a systematic mapping study to provide an overview of the current state of research regarding challenges, principles, and practices for regulatory compliance of SIPS related to RE. We focused on the role of RE and its contribution to other SIPS lifecycle process areas. We retrieved 6914 studies published from 2017 (January 1) until 2023 (December 31) from four academic databases, which we filtered down to 280 relevant primary studies. Results: We identified and categorized the RE-related challenges in regulatory compliance of SIPS and their potential connection to six types of principles and practices addressing challenges. We found that about 13.6% of the primary studies considered the involvement of both software engineers and legal experts in developing principles and practices. About 20.7% of primary studies considered RE in connection to other process areas. Most primary studies focused on a few popular regulation fields (privacy, quality) and application domains (healthcare, software development, avionics). Our results suggest that there can be differences in terms of challenges and involvement of stakeholders across different fields of regulation. Conclusion: Our findings highlight the need for an in-depth investigation of stakeholders’ roles, relationships between process areas, and specific challenges for distinct regulatory fields to guide research and practice.

Systematic literature studies, such as secondary studies, are crucial to aggregate evidence. An essential part of these studies is the selection phase of relevant studies. This, however, is time-consuming, resource-intensive, and error-prone as it highly depends on manual labor and domain expertise. The increasing popularity of Large Language Models (LLMs) raises the question to what extent these manual study selection tasks could be supported in an automated manner. In this manuscript, we report on our effort to explore and evaluate the use of state-of-the-art LLMs to automate the selection phase in systematic literature studies. We evaluated LLMs for the selection phase using two published systematic literature studies in software engineering as ground truth. Three prompts were designed and applied across five LLMs to the studies’ titles and abstracts based on their inclusion and exclusion criteria. Additionally, we analyzed combining two LLMs to replicate a practical selection phase. We analyzed recall and precision and reflected upon the accuracy of the LLMs, and whether the ground truth studies were conducted by early career scholars or by more advanced ones. Our results show a high average recall of up to 98% combined with a precision of 27% in a single LLM approach and an average recall of 99% with a precision of 27% in a two-model approach replicating a two-reviewer procedure. Further the Llama 2 models showed the highest average recall 98% across all prompt templates and datasets while GPT4-turbo had the highest average precision 72%. Our results demonstrate how LLMs could support a selection phase in the future. We recommend a two LLM-approach to archive a higher recall. However, we also critically reflect upon how further studies are required using other models and prompts on more datasets to strengthen the confidence in our presented approach. • Automation of study selection in Systematic Literature Studies using different LLMs. • Recall of up to 98% indicating the usefulness when using LLMs to assist. • Precision of 27% indicates the need for further research when lacking supervision by experienced researchers.

Artificial Intelligence can make manufacturing organisations more effective and efficient, but it is not clear which AI tasks hold the greatest potential. Make-to-order manufacturers must constantly adapt to customers’ unique and rapidly changing needs, and therefore have different challenges than make-to-stock manufacturers. Our ambition is to develop an AI-enabled software system to support manufacturing organisations in improving their processes. To this end, we first seek to understand the data and technology requirements for key AI-enabled tasks in a make-to-order setting and determine the level of performance and explainability needed to address them. We perform a multiple case study of five make-to-order packaging manufacturers, interviewing personnel from sales, production, and supply chain to identify and prioritise operational challenges suitable for AI approaches. Demand forecasting emerges as the most important task, followed by predictive maintenance, quality inspection, complex decision risk estimation, and production planning. Participants emphasise the importance of explainable techniques to ensure trust in the systems. The results highlight a need for a greater control of the production process and a better understanding of customer needs. Although most of the tasks could be solved with current techniques, some, such as intermittent demand forecasting and complex decision risk estimation, would require further development. The study clarifies the potential of AI-enabled systems in make-to-order manufacturing and outlines the steps required to realise it.

ABSTRACT Recent studies have shown that many software developers do not have sufficient knowledge and understanding of how to develop a privacy‐friendly system. This may become a challenge in developing systems complying with data protection laws. To address this issue, we investigated the factors that influence developers' decision‐making when developing privacy‐sensitive systems. We conducted an empirical study by means of a survey with 109 practitioners. Our data analysis is based on the principles of social cognitive theory, which includes personal, behavioral, and external environmental factors. We identified six personal, five behavioral, and five external environment factors that affect how developers make decisions regarding privacy, including confusion between privacy and security and reliance on informal practices and organizational support gaps. These findings contribute to understanding how practitioners and companies consider privacy, showing improvements in formal training and structured support over previous studies yet highlighting persistent challenges in consistent privacy integration.

Context: Continuous Software Engineering is increasingly adopted in highly regulated domains, raising the need for continuous compliance. Adherence to especially security regulations – a major concern in highly regulated domains – renders Continuous Security Compliance of high relevance to industry and research.

Requirements engineering aims to fulfill a purpose, i.e., inform subsequent software development activities about stakeholders' needs and constraints that must be met by the system under development. The quality of requirements artifacts and processes is determined by how fit for this purpose they are, i.e., how they impact activities affected by them. However, research on requirements quality lacks a comprehensive overview of these activities and how to measure them. In this paper, we specify the research endeavor addressing this gap and propose an initial model of requirements-affected activities and their attributes. We construct a model from three distinct data sources, including both literature and empirical data. The results yield an initial model containing 24 activities and 16 attributes quantifying these activities. Our long-term goal is to develop evidence-based decision support on how to optimize the fitness for purpose of the RE phase to best support the subsequent, affected software development process. We do so by measuring the effect that requirements artifacts and processes have on the attributes of these activities. With the contribution at hand, we invite the research community to critically discuss our research roadmap and support the further evolution of the model.

Adversarial Machine Learning (AML) discusses the act of attacking and defending Machine Learning (ML) Models, an essential building block of Artificial Intelligence (AI). ML is applied in many software-intensive products and services and introduces new opportunities and security challenges. AI and ML will gain even more attention from the industry in the future, but threats caused by already-discovered attacks specifically targeting ML models are either overseen, ignored, or mishandled. Current AML research investigates attack and defense scenarios for ML in different industrial settings with a varying degree of maturity with regard to academic rigor and practical relevance. However, to the best of our knowledge, a synthesis of the state of academic rigor and practical relevance is missing. This literature study reviews studies in the area of AML in the context of industry, measuring and analyzing each study’s rigor and relevance scores. Overall, all studies scored a high rigor score and a low relevance score, indicating that the studies are thoroughly designed and documented but miss the opportunity to include touch points relatable for practitioners.

Requirements quality research, which is dedicated to assessing and improving the quality of requirements specifications, is dependent on research artifacts like data sets (containing information about quality defects) and implementations (automatically detecting and removing these defects). However, recent research exposed that the majority of these research artifacts have become unavailable or have never been disclosed, which inhibits progress in the research domain. In this work, we aim to improve the availability of research artifacts in requirements quality research. To this end, we (1) extend an artifact recovery initiative, (2) empirically evaluate the reasons for artifact unavailability using Bayesian data analysis, and (3) compile a concise guideline for open science artifact disclosure. Our results include 10 recovered data sets and 7 recovered implementations, empirical support for artifact availability improving over time and the positive effect of public hosting services, and a pragmatic artifact management guideline open for community comments. With this work, we hope to encourage and support adherence to open science principles and improve the availability of research artifacts for the requirements research quality community.

Engineering successful machine learning (ML)-enabled systems poses various challenges from both a theoretical and a practical side. Among those challenges are how to effectively address unrealistic expectations of ML capabilities from customers, managers and even other team members, and how to connect business value to engineering and data science activities composed by interdisciplinary teams. In this paper, we present PerSpecML , a perspective-based approach for specifying ML-enabled systems that helps practitioners identify which attributes, including ML and non-ML components, are important to contribute to the overall system’s quality. The approach involves analyzing 60 concerns related to 28 tasks that practitioners typically face in ML projects, grouping them into five perspectives: system objectives, user experience , infrastructure, model, and data. Together, these perspectives serve to mediate the communication between business owners, domain experts, designers, software and ML engineers, and data scientists. The creation of PerSpecML involved a series of formative evaluations conducted in different contexts: (i) in academia, (ii) with industry representatives, and (iii) in two real industrial case studies . As a result of the diverse validations and continuous improvements, PerSpecML stands as a promising approach, poised to positively impact the specification of ML-enabled systems, particularly helping to reveal key components that would have been otherwise missed without using PerSpecML . Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board .

[Context:] Society increasingly values sustainable corporate behaviour, impacting corporate reputation and customer trust. Hence, companies regularly publish sustainability reports to shed light on their impact on environmental, social, and governance (ESG) factors. [Problem:] Sustainability reports are written by companies and therefore considered a company-controlled source. Contrarily, studies reveal that non-corporate channels (e.g., media coverage) represent the main driver for ESG transparency. However, analysing media coverage regarding ESG factors is challenging since (1) the amount of published news articles grows daily, (2) media coverage data does not necessarily deal with an ESG-relevant topic, meaning that it must be carefully filtered, and (3) the majority of media coverage data is unstructured. [Research Goal:] We aim to automatically extract ESG-relevant information from textual media reactions to calculate an ESG score for a given company. Our goal is to reduce the cost of ESG data collection and make ESG information available to the general public. [Contribution:] Our contributions are three-fold: First, we publish a corpus of 432,411 news headlines annotated as being environmental-, governance-, social-related, or ESG-irrelevant. Second, we present our tool-supported approach called ESG-Miner, capable of automatically analysing and evaluating corporate ESG performance headlines. Third, we demonstrate the feasibility of our approach in an experiment and apply the ESG-Miner on 3000 manually labelled headlines. Our approach correctly processes 96.7% of the headlines and shows great performance in detecting environmental-related headlines and their correct sentiment.

Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored. We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners’ understanding and managing of requirements engineering debt (RED). We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory. We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results. The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.

Boundary Artefacts (BAs) support software development activities in many aspects because it carries lots of information in the same object that can be used and interpreted by several social groups within an organisation. When the BAs are inconsistent regarding their content, such as many meanings or lack of contextual information, their efficiency is reduced because stakeholders won’t trust them. This study aimed to understand the implications of differences in the perception of trust on software projects and their influence on stakeholders’ behaviour. We conducted an exploratory case study to observe the creation and utilisation of one specific BA and the implications of differences in trust and their influence on stakeholders’ behaviour. : Our investigation has shown that practitioners adding and adjusting existing content do not entirely understand the stakeholders’ needs. Together with the partial management of the content, trust is impacted. When the content of BAs does not meet the trust factors, specifically reliability and predictability, the stakeholders can’t execute their tasks appropriately, and several implications affect the software development project. Additionally, they create workarounds to supply their needs. The differences in trust in BAs affect software projects in different areas of the organisation and interfere with the task execution of various stakeholders. The decrease in trust results from inconsistencies in the content associated with the lack of management of the BA. A structured strategy for representing and managing a BA’s content seems appropriate to increase trust levels and efficiency.

In early 2020, the Covid-19 pandemic forced employees in tech companies worldwide to abruptly transition from working in offices to working from their homes. During two years of predominantly working from home, employees and managers alike formed expectations about what post-pandemic working life should look like. Many companies are experimenting with new work policies that balance employee- and manager expectations regarding where, when and how work should be done in the future. In this article, we gather experiences of the new trend of remote working based on the synthesis of 22 company-internal surveys of employee preferences for WFH, and 26 post-pandemic work policies from 17 companies and their sites, covering 12 countries in total. Our results are threefold. First, through the new work policies, all companies formally give employees more flexibility regarding working time and location. Second, there is a great variation in how much flexibility the companies are willing to yield to the employees. The paper details the different formulations that companies adopted to document the extent of permitted WFH, exceptions, relocation permits and the authorisation procedures. Third, we document a change in the psychological contract between employees and managers, where the option of working from home is converted from an exclusive perk that managers could choose to give to the few, to a core privilege that all employees feel they are entitled to. Finally, there are indications that as the companies learn and solicit feedback regarding the efficiency of the chosen strategies, we will see further developments and changes in the work policies concerning how much flexibility to work whenever and from wherever they grant. Through these findings, the paper contributes to a growing literature about the new trends emerging from the pandemic in tech companies and spells out practical implications onwards.

Abstract Causal relations in natural language (NL) requirements convey strong, semantic information. Automatically extracting such causal information enables multiple use cases, such as test case generation, but it also requires to reliably detect causal relations in the first place. Currently, this is still a cumbersome task as causality in NL requirements is still barely understood and, thus, barely detectable. In our empirically informed research, we aim at better understanding the notion of causality and supporting the automatic extraction of causal relations in NL requirements. In a first case study, we investigate 14.983 sentences from 53 requirements documents to understand the extent and form in which causality occurs. Second, we present and evaluate a tool-supported approach, called CiRA, for causality detection. We conclude with a second case study where we demonstrate the applicability of our tool and investigate the impact of causality on NL requirements. The first case study shows that causality constitutes around 28 % of all NL requirements sentences. We then demonstrate that our detection tool achieves a macro- $$\hbox {F}_{1}$$ F1 score of 82 % on real-world data and that it outperforms related approaches with an average gain of 11.06 % in macro-Recall and 11.43 % in macro-Precision. Finally, our second case study corroborates the positive correlations of causality with features of NL requirements. The results strengthen our confidence in the eligibility of causal relations for downstream reuse, while our tool and publicly available data constitute a first step in the ongoing endeavors of utilizing causality in RE and beyond.

Abstract High-quality requirements minimize the risk of propagating defects to later stages of the software development life cycle. Achieving a sufficient level of quality is a major goal of requirements engineering. This requires a clear definition and understanding of requirements quality. Though recent publications make an effort at disentangling the complex concept of quality, the requirements quality research community lacks identity and clear structure which guides advances and puts new findings into an holistic perspective. In this research commentary, we contribute (1) a harmonized requirements quality theory organizing its core concepts, (2) an evaluation of the current state of requirements quality research, and (3) a research roadmap to guide advancements in the field. We show that requirements quality research focuses on normative rules and mostly fails to connect requirements quality to its impact on subsequent software development activities, impeding the relevance of the research. Adherence to the proposed requirements quality theory and following the outlined roadmap will be a step toward amending this gap.

Context:There have been numerous recent calls for research on the human side of software engineering and its impact on various factors such as productivity, developer happiness and project success. An analysis of which challenges in software engineering teams are most frequent is still missing. As teams are more international, it is more frequent that their members have different human values as well as different communication habits. Additionally, virtual team setups (working geographically separated, remote communication using digital tools and frequently changing team members) are increasingly prevalent.Objective:We aim to provide a starting point for a theory about contemporary human challenges in teams and their causes in software engineering. To do so, we look to establish a reusable set of challenges and start out by investigating the effect of team virtualization. Virtual teams often use digital communication and consist of members with different nationalities that may have more divergent human values due to cultural differences compared to single nationality teams.Method:We designed a survey instrument and asked respondents to assess the frequency and criticality of a set of challenges, separated in context ”within teams” as well as ”between teams and clients”, compiled from previous empirical work, blog posts, and pilot survey feedback. For the team challenges, we asked if mitigation measures were already in place to tackle the challenge. Respondents were also asked to provide information about their team setup. The survey included the Personal Value Questionnaire to measure Schwartz human values. Finally, respondents were asked if there were additional challenges at their workplace. The survey was first piloted and then distributed to professionals working in software engineering teams via social networking sites and personal business networks.Result:In this article, we report on the results obtained from 192 respondents. We present a set of challenges that takes the survey feedback into account and introduce two categories of challenges; ”interpersonal” and ”intrapersonal”. We found no evidence for links between human values and challenges. We found some significant links between the number of distinct nationalities in a team and certain challenges, with less frequent and critical challenges occurring if 2-3 different nationalities were present compared to a team having members of just one nationality or more than three. A higher degree of virtualization seems to increase the frequency of some human challenges, which warrants further research about how to improve working processes when teams work from remote or in a distributed fashion.Conclusion:We present a set of human challenges in software engineering that can be used for further research on causes and mitigation measures, which serves as our starting point for a theory about causes of contemporary human challenges in software engineering teams. We report on evidence that a higher degree of virtualization of teams leads to an increase of certain challenges. This warrants further research to gather more evidence and test countermeasures, such as whether the employment of virtual reality software incorporating facial expressions and movements can help establish a less detached way of communication.

Background: Modern code review is expected to facilitate knowledge sharing: All relevant information, the collective expertise, and meta-information around the code change and its context become evident, transparent, and explicit in the corresponding code review discussion. The discussion participants can leverage this information in the following code reviews; the information diffuses through the communication network that emerges from code review. Traditional time-aggregated graphs fall short in rendering information diffusion as those models ignore the temporal order of the information exchange: Information can only be passed on if it is available in the first place.

Background: Modern privacy regulations, such as the General Data Protection Regulation (GDPR), address privacy in software systems in a technologically agnostic way by mentioning general ”technical measures” for data privacy compliance rather than dictating how these should be implemented. An understanding of the concept of technical measures and how exactly these can be handled in practice, however, is not trivial due to its interdisciplinary nature and the necessary technical-legal interactions.

Quality factors like passive voice or sentence length are commonly used in research and practice to evaluate the quality of natural language requirements since they indicate defects in requirements artifacts that potentially propagate to later stages in the development life cycle. However, as a research community, we still lack a holistic perspective on quality factors. This inhibits not only a comprehensive understanding of the existing body of knowledge but also the effective use and evolution of these factors. To this end, we propose an ontology of quality factors for textual requirements, which includes (1) a structure framing quality factors and related elements and (2) a central repository and web interface making these factors publicly accessible and usable. We contribute the first version of both by applying a rigorous ontology development method to 105 eligible primary studies and construct a first version of the repository and interface. We illustrate the usability of the ontology and invite fellow researchers to a joint community effort to complete and maintain this knowledge repository. We envision our ontology to reflect the community’s harmonized perception of requirements quality factors, guide reporting of new quality factors, and provide central access to the current body of knowledge.

During the development and maintenance of software-intensive products or services, we depend on various artefacts. Some of those artefacts, we deem central to the feasibility of a project and the product’s final quality. Typically, these central artefacts are referred to as assets. However, despite their central role in the software development process, little thought is yet invested into what eventually characterises as an asset, often resulting in many terms and underlying concepts being mixed and used inconsistently. A precise terminology of assets and related concepts, such as asset degradation, are crucial for setting up a new generation of cost-effective software engineering practices. In this position paper, we critically reflect upon the notion of assets in software engineering. As a starting point, we define the terminology and concepts of assets and extend the reasoning behind them. We explore assets’ characteristics and discuss what asset degradation is as well as its various types and the implications that asset degradation might bring for the planning, realisation, and evolution of software-intensive products and services over time. We aspire to contribute to a more standardised definition of assets in software engineering and foster research endeavours and their practical dissemination in a common, more unified direction.

Context. The use of standards is considered a vital part of any engineering discipline. So one could expect that standards play an important role in Requirements Engineering (RE) as well. However, little is known about the actual knowledge and use of RE-related standards in industry.Objective. In this article, we investigate to which extent standards and related artifacts such as templates or guidelines are known and used by RE practitioners.Method. To this end, we have conducted a questionnaire-based online survey. We could analyze the replies from 90 RE practitioners using a combination of closed and open-text questions.Results. Our results indicate that the knowledge and use of standards and related artifacts in RE is less widespread than one might expect from an engineering perspective. For example, about 47% of the respondents working as requirements engineers or business analysts do not know the core standard in RE, ISO/IEC/IEEE 29148. Participants in our study mostly use standards by personal decision rather than being imposed by their respective company, customer, or regulator. Beyond insufficient knowledge, we also found cultural and organizational factors impeding the widespread adoption of standards in RE.Conclusions. Overall, our results provide empirically informed insights into the actual use of standards and related artifacts in RE practice and – indirectly – about the value that the current standards create for RE practitioners.

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.

Background: Nowadays, regulatory requirements engineering (regulatory RE) faces challenges of interdisciplinary nature that cannot be tackled due to existing research gaps. Aims: We envision an approach to solve some of the challenges related to the nature and complexity of regulatory requirements, the necessity for domain knowledge, and the involvement of legal experts in regulatory RE. Method: We suggest the qualitative analysis of regulatory texts combined with the further case study to develop an empirical foundation for our research. Results: We outline our vision for the application of extended artefact-based modeling for regulatory RE. Conclusions: Empirical methodology is an essential instrument to address interdisciplinarity and complexity in regulatory RE. Artefact-based modeling supported by empirical results can solve a particular set of problems while not limiting the application of other methods and tools and facilitating the interaction between different fields of practice and research.

Context: Managing Non-Functional Requirements (NFRs) in software projects is challenging, and projects that adopt Model-Driven Development (MDD) are no exception. Although several methods and techniques have been proposed to face this challenge, there is still little evidence on how NFRs are handled in MDD by practitioners. Knowing more about the state of the practice may help researchers to steer their research and practitioners to improve their daily work. Objective: In this paper, we present our findings from an interview-based survey conducted with practitioners working in 18 different companies from 6 European countries. From a practitioner's point of view, the paper shows what barriers and benefits the management of NFRs as part of the MDD process can bring to companies, how NFRs are supported by MDD approaches, and which strategies are followed when (some) types of NFRs are not supported by MDD approaches. Results: Our study shows that practitioners perceive MDD adoption as a complex process with little to no tool support for NFRs, reporting productivity and maintainability as the types of NFRs expected to be supported when MDD is adopted. But in general, companies adapt MDD to deal with NFRs. When NFRs are not supported, the generated code is sometimes changed manually, thus compromising the maintainability of the software developed. However, the interviewed practitioners claim that the benefits of using MDD outweight the extra effort required by these manual adaptations. Conclusion: Overall, the results indicate that it is important for practitioners to handle `NFRs in MDD, but further research is necessary in order to lower the barrier for supporting a broad spectrum of NFRs with MDD. Still, much conceptual and tool implementation work seems to be necessary to lower the barrier of integrating the broad spectrum of NFRs in practice.

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.

Companies adopting agile development tend to face challenges in complying with security norms. Existing research either focuses on how to integrate security into agile methods or on discussing compliance issues of agile methods but independently of the regulation type, in particular of security standards. A comprehensive overview of this scattered field is still missing and we know little about how to achieve security compliance in agile software development. Existing secondary studies (mapping studies and literature reviews) analyze publications on secure agile development, but they do not analyze implications of security standard compliance, e.g., integration of specific standard requirements or compliance assessments. To close this gap, we report on a systematic mapping study. Starting with a set of 2,383 papers, our work distills 11 relevant publications addressing security compliance in agile software development. With this study, we contribute by describing the maturity of the field, as well as domains where security compliant agile software engineering was investigated. Moreover, we make explicit which phases of a secure development process are covered by the field and which agile principles are analyzed when aiming at compliance with international security standards, country-specific security regulations, industry-specific security standards, and other well-known security frameworks.

Background: The detection and extraction of causality from natural language sentences have shown great potential in various fields of application. The field of requirements engineering is eligible for multiple reasons: (1) requirements artifacts are primarily written in natural language, (2) causal sentences convey essential context about the subject of requirements, and (3) extracted and formalized causality relations are usable for a (semi-)automatic translation into further artifacts, such as test cases.

Requirements Engineering (RE) is a means to reduce the risk of delivering a product that does not fulfill the stakeholders' needs. Therefore, a major challenge in RE is to decide how much RE is needed and what RE methods to apply. The quality of such decisions is strongly based on the RE expert's experience and expertise in carefully analyzing the context and current state of a project. Recent work, however, shows that lack of experience and qualification are common causes for problems in RE. We trained a series of Bayesian Networks on data from the NaPiRE survey to model relationships between RE problems, their causes, and effects in projects with different contextual characteristics. These models were used to conduct (1) a post-mortem (diagnostic) analysis, deriving probable causes of suboptimal RE performance, and (2) to conduct a preventive analysis, predicting probable issues a young project might encounter. The method was subject to a rigorous cross-validation procedure for both use cases before assessing its applicability to real-world scenarios with a case study.

Software needs to be secure, in particular, when deployed to critical infrastructures. Secure coding guidelines capture practices in industrial software engineering to ensure the security of code. This study aims to assess the level of awareness of secure coding in industrial software engineering, the skills of software developers to spot weaknesses in software code, avoid them, and the organizational support to adhere to coding guidelines. The approach draws on well-established theories of policy compliance, neutralization theory, and security-related stress and the authors' many years of experience in industrial software engineering and on lessons identified from training secure coding in the industry. The paper presents the questionnaire design for the online survey and the first analysis of data from the pilot study.

Defects in requirements specifications can have severe consequences during the software development lifecycle. Some of them result in overall project failure due to incorrect or missing quality characteristics such as security. There are several concerns that make security difficult to deal with; for instance, (1) when stakeholders discuss general requirements in meetings, they are often unaware that they should also discuss security-related topics, and (2) they typically do not have enough expertise in security. This often leads to unspecified or ill-defined security-related aspects. These concerns become even more challenging in agile contexts, where lightweight documentation is typically involved. The goal of this paper is to design and evaluate an approach for reviewing security-related aspects in agile requirements specifications of web applications. The approach considers user stories and security specifications as input and relates those user stories to security properties via Natural Language Processing. Based on the related security properties, our approach then identifies high-level security requirements from the Open Web Application Security Project to be verified and generates a reading technique to support reviewers in detecting defects. We evaluate our approach via two controlled experiment trials. We compare the effectiveness and efficiency of novice inspectors verifying security aspects in agile requirements using our approach against using the complete list of high-level security requirements. The (statistically significant) results indicate that using our approach has a positive impact (with large effect size) on the performance of inspectors in terms of effectiveness and efficiency.

Open science refers to a movement to make all research artefacts available to the public, thus, increasing transparency and reproducibility of the scientific process. Ultimately, the goal is faster scientific progress since problems can be weeded out more quickly and it is easier for new studies to build on the results of older ones.

Requirements Engineering (RE) has established itself as a software engineering discipline over the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirical theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. We aim at providing an empirical and externally valid foundation for a theory of RE practice, which helps software engineers establish effective and efficient RE processes in a problem-driven manner. We designed a survey instrument and an engineer-focused theory that was first piloted in Germany and, after making substantial modifications, has now been replicated in 10 countries worldwide. We have a theory in the form of a set of propositions inferred from our experiences and available studies, as well as the results from our pilot study in Germany. We evaluate the propositions with bootstrapped confidence intervals and derive potential explanations for the propositions. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from the replication studies conducted in 10 countries with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirical theory of RE practice. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents are common, that requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly internally driven. Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.

[Background] The rapidly changing business environments in which many companies operate is challenging traditional Requirements Engineering (RE) approaches. This gave rise to agile approaches for RE. Security, at the same time, is an essential non-functional requirement that still tends to be difficult to address in agile development contexts. Given the fuzzy notion of "agile" in context of RE and the difficulties of appropriately handling security requirements, the overall understanding of how to handle security requirements in agile RE is still vague. [Objective] Our goal is to characterize the publication landscape of approaches that handle security requirements in agile software projects. [Method] We conducted a systematic mapping to outline relevant work and contemporary gaps for future research. [Results] In total, we identified 21 studies that met our inclusion criteria, dated from 2005 to 2017. We found that the approaches typically involve modifying agile methods, introducing new artifacts (e.g., extending the concept of user story to abuser story), or introducing guidelines to handle security issues. We also identified limitations of using these approaches related to environment, people, effort and resources. [Conclusion] Our analysis suggests that more effort needs to be invested into empirically evaluating the existing approaches and that there is an avenue for future research in the direction of mitigating the identified limitations.

This tutorial presents Design Thinking as a promising approach to creatively elicit human-centered requirements for software-intensive systems. Specifically, it contributes to Requirements Engineering practices by structuring the fuzzy process of developing creative and innovative ideas. The tutorial should be seen as a forum for the interchange of experience and learnings from combining both approaches and should raise awareness for the importance of human-centered methods and experimentation in early phases of software engineering. After the tutorial, the participants get access to all materials, templates, and methods on our website for further usage.

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.

[Context] Problems in Requirements Engineering (RE) can lead to serious consequences during the software development lifecycle. [Goal] The goal of this paper is to propose empirically-based guidelines that can be used by different types of organisations according to their size (small, medium or large) and process model (agile or plan-driven) to help them in preventing such problems. [Method] We analysed data from a survey on RE problems answered by 228 organisations in 10 different countries. [Results] We identified the most critical RE problems, their causes and mitigation actions, organizing this information by clusters of size and process model. Finally, we analysed the causes and mitigation actions of the critical problems of each cluster to get further insights into how to prevent them. [Conclusions] Based on our results, we suggest preliminary guidelines for preventing critical RE problems in response to context characteristics of the companies.

Non-functional requirements (NFRs) are commonly distinguished from functional requirements by differentiating how the system shall do something in contrast to what the system shall do. This distinction is not only prevalent in research, but also influences how requirements are handled in practice. NFRs are usually documented separately from functional requirements, without quantitative measures, and with relatively vague descriptions. As a result, they remain difficult to analyze and test. Several authors argue, however, that many so-called NFRs actually describe behavioral properties and may be treated the same way as functional requirements. In this paper, we empirically investigate this point of view and aim to increase our understanding on the nature of NFRs addressing system properties. We report on the classification of 530 NFRs extracted from 11 industrial requirements specifications and analyze to which extent these NFRs describe system behavior. Our results suggest that most "non-functional" requirements are not non-functional as they describe behavior of a system. Consequently, we argue that many so-called NFRs can be handled similarly to functional requirements.

Abstract Software process lines provide a systematic approach to develop and manage software processes. It defines a reference process containing general process assets, whereas a well‐defined customization approach allows process engineers to create new process variants, for example, by extending or modifying process assets. Variability operations are an instrument to realize flexibility by explicitly declaring required modifications, which are applied to create a procedurally generated company‐specific process. However, little is known about which variability operations are suitable in practice. In this article, we present a study on the feasibility of variability operations to support the development of software process lines in the context of the V‐Modell XT. We analyze which variability operations are defined and practically used. We provide an initial catalog of variability operations as an improvement proposal for other process models. Our findings show that 69 variability operation types are defined across several metamodel versions of which, however, 25 remain unused. The found variability operations allow for systematically modifying the content of process model elements and the process documentation, and they allow for altering the structure of a process model and its description. Furthermore, we also find that variability operations can help process engineers to compensate process metamodel evolution. Copyright © 2015 John Wiley & Sons, Ltd.

Background: Technology transfer is one key to the success of research projects, especially in Software Engineering, where the (practical) impact of the outcome may depend not only on the reliability and feasibility of technologies, but also on their applicability to industrial settings. However, there is limited knowledge on the current state of practice and how to assess the success of technology transfer. Objective: We aim at elaborating a set of hypotheses on how technology transfer takes place in Software Engineering research projects. Method: We designed an exploratory survey with the participants of two large research projects in Germany, which involve both industrial and academic partners in the area of model driven development for embedded systems. Results: Base on the extracted respondents answers of this survey, we defined a resulting theory which is based on the following set of main hypothesis: Most of the technologies developed in research projects are not mature enough for a direct application, but need post-project customisation to fit the industrial contexts (H1). Common models that represent technology transfer as a transaction of an object from a transferor to a transferee does not fit industrial reality (H2). Additionally, technology transfer takes place without an explicit process (H3). Regarding transfer mediums, most used mediums are human-intensive (H5) and industry organisations gain new knowledge mainly within their own confines (H4). Finally the motivations that drive the transfer in industry and academia are heterogenous (H6). Conclusions: From the theoretical perspective, this theory and set of hypotheses extracted from the survey results will be further explored and tested in different follow-up activities. This initial set, however, already may serve as a basis for independent assessments from other researchers to collaboratively shed light on a how technology transfer takes place in Software Engineering research projects, which are the barriers, and how to improve the transfer into practice. From the practical perspective, our results may be used as a basis for an evaluation framework for the transfer of the developed technologies in our projects. This would also help companies in getting new developed technologies transfer easier to their specific context.

Context: Seamless model-based development provides integrated chains of models, covering all software engineering phases. Non-functional requirements (NFRs), like reusability, further play a vital role in software and systems engineering, but are often neglected in research and practice. It is still unclear how to integrate NFRs in a seamless model-based development. Goal: Our long-term goal is to develop a theory on the specification of NFRs such that they can be integrated in seamless model-based development. Method: Our overall study design includes a multi-staged procedure to infer an empirically founded theory on specifying NFRs to support seamless modeling. In this short paper, we present the study design and provide a discussion of (i) preliminary results obtained from a sample, and (ii) current issues related to the design. Results: Our study already shows significant fields of improvement, e.g., the low agreement during the classification. However, the results indicate to interesting points; for example, many of commonly used NFR classes concern system modeling concepts in a way that shows how blurry the borders between functional and NFRs are. Conclusions: We conclude so far that our overall study design seems suitable to obtain the envisioned theory in the long run, but we could also show current issues that are worth discussing within the empirical software engineering community. The main goal of this contribution is not to present and discuss current results only, but to foster discussions on the issues related to the integration of NFRs in seamless modeling in general and, in particular, discussions on open methodological issues.

Background: Successful transfer of the results of research projects into practice is of great interest to all project participants. It can be assumed that different transfer mediums fulfill technology transfer (TT) with different levels of success and that they are impaired by different kinds of barriers. Objective: The goal of this study is to gain a better understanding about the different mediums used for TT in software engineering, and to identify barriers weakening the success of the application of such mediums. Method: We conducted an exploratory study implemented by a survey in the context of a German research project with a broad range of used mediums. Results: The main reported barriers were low expectations of usefulness, no awareness of existence, lack of resources, or inadequateness in terms of outdated material or being in an immature state. Conclusions: We interpreted our results as symptoms of a lack of a dissemination plan in the project. Further work will be needed to explore the implications for the transfer of research results (knowledge and techniques) to practice.

[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.

The speed of innovation and the global allocation of resources to accelerate development or to reduce cost put pressure on the software industry. In the global competition, especially so-called high-price countries have to present arguments why the higher development cost is justified and what makes these countries an attractive host for software companies. Often, high-quality engineering and excellent quality of products, e.g., Machinery and equipment, are mentioned. Yet, the question is: Can such arguments be also found for the software industry? We aim at investigating the degree of professionalism and systematization of software development to draw a map of strengths and weaknesses. To this end, we conducted as a first step an exploratory survey in Germany, presented in this paper. In this survey, we focused on the perceived importance of the two general software engineering process areas project- and quality management and their implementation in practice. So far, our results suggest that the necessity for a systematic software development is well recognized, while software development still follows an ad-hoc rather than a systematized style. Our results provide initial findings, which we finally use to elaborate a set of working hypotheses. Those hypotheses allow to steer the adaptation of our instrument in the future to eventually facilitate replications toward a more comprehensive theory on systematic globally distributed software development in practice.

Software energy efficiency is a research topic where experimentation is widely adopted. Nevertheless, current studies and research approaches struggle to find generalizable findings that can be used to build a consistent knowledge base for energy-efficient software. To this end, we will discuss how to combine the traditional hypothesis-driven (top-down) approach with a bottom-up discovery approach. In this technical briefing, participants will learn the challenges that characterize the research in software energy efficiency. They will experience the complexity in this field and its implications for experimentation.

Background/Context: Gathering empirical knowledge is a time consuming task and the results from empirical studies often are soon outdated by new technological solutions. As a result, the impact of empirical results on software engineering practice is often not guaranteed.Objective/Aim: In this paper, we summarise the ongoing discussion on "Empirical Software Engineering 2.0" as a way to improve the impact of empirical results on industrial practices. We propose a way to combine data mining and analysis with domain knowledge to enable fast feedback cycles in empirical software engineering research.Method: We identify the key concepts on gathering fast feedback in empirical software engineering by following an experience-based line of reasoning by argument. Based on the identified key concepts, we design and execute a small proof of concept with a company to demonstrate potential benefits of the approach.Results: In our example, we observed that a simple double feedback mechanism notably increased the precision of the data analysis and improved the quality of the knowledge gathered.Conclusion: Our results serve as a basis to foster discussion and collaboration within the research community for a development of the idea.

Agile software development has become well known to the community and is nowadays frequently used for the development of different kinds of software systems. Agile methods are widely spread and often adapted to the context-specific needs. The adaptations constitute reductions and/or extensions of agile practices. Yet, we have limited knowledge about the impact of some of the individual practices, which is crucial to justify organizational changes. To systemize the knowledge of the impact of agile practices, we launch this workshop and invite researchers and practitioners to work on a documenting and accumulating their experiences in a knowledge base.

Model-Driven Development (MDD) is no longer a novel development paradigm. It has become mature from a research perspective and recent studies show its adoption in industry. Still, some issues remain a challenge. Among them, we are interested in the treatment of non-functional requirements (NFRs) in MDD processes. Very few MDD approaches have been reported to deal with NFRs (and they do it in a limited way). However, it is clear that NFRs need to be considered somehow in the final product of the MDD process. To better understand how NFRs are integrated into the existing MDD approaches, we have initiated the NFR4MDD project, a multi-national empirical study, based on interviews with companies working on MDD projects. Our project aims at surveying the state of the practice for this topic. In this paper, we summarize our research protocol and present the current status of our study. The discussion will focus on the peculiarities of our study's context and organization involving about 20 researchers from 8 European countries.

Context] Many software projects fail due to problems in requirements engineering (RE).[Objective] The goal of this paper is to gather information on relevant RE problems and to represent knowledge on their most common causes.[Method] We replicated a global family of RE surveys in Brazil and used the data to identify critical RE problems and to build probabilistic causeeffect diagrams to represent knowledge on their common causes.[Results] The survey was answered by 74 different organizations, including small, medium and very large sized companies, conducting both, plan-driven and agile development.The most critical RE problems, according to those organizations, are related to communication and to incomplete or underspecified requirements.We provide the full probabilistic cause-effect diagrams with knowledge on common causes of the most critical identified RE problems online.[Conclusion] We believe that the knowledge presented in the diagrams can be helpful to support organizations in conducting causal analysis sessions by providing an initial understanding on what usually causes critical RE problems.

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.

Context: Requirements engineering process improvement (REPI) approaches have gained much attention in research and practice. Goal: So far, there is no comprehensive view on the research in REPI in terms of solutions and current state of reported evidence. We aims to provide an overview on the existing solutions, their underlying principles and their research type facets, i.e. their state of empirical evidence. Method: To this end, we conducted a systematic mapping study of the REPI publication space. Results: This paper reports on the first findings regarding research type facets of the contributions as well as selected methodological principles. We found a strong focus in the existing research on solution proposals for REPI approaches that concentrate on normative assessments and benchmarks of the RE activities rather than on holistic RE improvements according to individual goals of companies. Conclusions: We conclude, so far, that there is a need to broaden the work and to investigate more problem-driven REPI which also targets the improvement of the quality of the underlying RE artefacts, which currently seem out of scope.

Software process lines provide a systematic approach to construct and manage software processes. A process line defines a reference process containing general process assets, whereas a well-defined customization approach allows process engineers to create new process variants by, e.g., extending or altering process assets. Variability operations are a powerful instrument to realize a process line. However, little is known about which variability operations are suitable in practice. In this paper, we present a study on the feasibility of variability operations to support process lines in the context of the German V-Modell XT. We analyze which variability operations were defined and used to which extent, and we provide a catalog of variability operations as an improvement proposal for other process models. Our findings show 69 variability operations defined across several metamodel versions of which 25 remain unused. Furthermore, we also find that variability operations can help process engineers to compensate process metamodel evolution.

Software processes have become inherently complex to cope with the various situations we face in project environments. In response, the research area of method engineering arose in the 1990s aiming at the systematization of process construction and application. Although the research area has gained much attention and offered a plethora of contributions so far, we still have little knowledge about which basic concepts are finally established and what their feasibility is. To overcome this shortcoming, we need a systematic investigation of the publication flora in method engineering. To reach this aim, we contribute a systematic mapping study and investigate, inter alia, which contributions were published over time and which research type facet they address to distill a common understanding about available method engineering concepts and their maturity. On the basis of the review of 83 publications, our results show that even if a high number of contributions is available, most of those contributions only repeat and discuss formerly introduced concepts, whereas reports on empirically sound evidence on the feasibility are still missing. Although the research area constitutes a many contributions, yet missing are a common understanding of method engineering and empirically sound investigations that would allow for practical application and experience extraction. Copyright © 2014 John Wiley & Sons, Ltd.

Context: For many years, we have observed industry struggling in defining a high quality requirements engineering (RE) and researchers trying to understand industrial expectations and problems. Although we are investigating the discipline with a plethora of empirical studies, those studies either concentrate on validating specific methods or on single companies or countries. Therefore, they allow only for limited empirical generalisations. Objective: To lay an empirical and generalisable foundation about the state of the practice in RE, we aim at a series of open and reproducible surveys that allow us to steer future research in a problem-driven manner. Method: We designed a globally distributed family of surveys in joint collaborations with different researchers from different countries. The instrument is based on an initial theory inferred from available studies. As a long-term goal, the survey will be regularly replicated to manifest a clear understanding on the status quo and practical needs in RE. In this paper, we present the design of the family of surveys and first results of its start in Germany. Results: Our first results contain responses from 30 German companies. The results are not yet generalisable, but already indicate several trends and problems. For instance, a commonly stated problem respondents see in their company standards are artefacts being underrepresented, and important problems they experience in their projects are incomplete and inconsistent requirements. Conclusion: The results suggest that the survey design and instrument are well-suited to be replicated and, thereby, to create a generalisable empirical basis of RE in practice.

Context: Software processes have become inherently complex to cope with the various situations we face in industrial project environments. In response to this problem, the research area of Method Engineering arose in the 1990s aiming at the systematization of process construction. Objective: Although the research area has gained much attention and offered a plethora of contributions so far, we still have little knowledge about the feasibility of Method Engineering. To overcome this shortcoming, necessary is a systematic investigation of the respective publication flora. Method: We conduct a systematic mapping study and investigate, inter alia, which contributions were made over time and which research type facet they address to distill a common understanding of the state-of-the-art. Results: Based on the review of 64 publications, our results show that most of those contributions only repeat and discuss formerly introduced concepts, whereas empirically sound evidence on the feasibility of Method Engineering, is still missing. Conclusion: Although the research area constitutes many contributions, yet missing are empirically sound investigations that would allow for practical application and experience extraction.

Artefact-based requirements engineering (RE) describes the idea of establishing a company-wide RE reference model by putting the focus on the RE artefacts and their dependencies rather than dictating a strict process with interconnected methods. Previously conducted case studies already strengthen our confidence in certain advantages and shortcomings of the paradigm. Still, our case studies by now remain isolated focussing on particular socio-economic contexts and, thus, the findings can hardly be generalised. Therefore, we need further replications. In this paper, we contribute the design of a replication case study to better understand the impact of artefact-based requirements engineering and, as a long term goal, strengthen an initial theory of expectation we could already infer from results and experiences we made in previous case studies. The replications shall lead to a reliable empirical base due to comparability among the studies. This allows for a (still restricted) generalisability of conclusions on artefact-based requirements engineering.

Empirical research has become an important means in any science and continues to grow in importance also in software engineering research. The ISERN and ESEM community together with the Empirical Software Engineering Journal have advanced the state of the art in how empirical research is conducted today in software engineering. We now have a plethora of empirical research techniques at our disposal, and it sometimes becomes challenging to choose the appropriate one. Also the application of the techniques, such as experiments, case studies, surveys or systematic literature reviews, is complicated and needs detailed understanding. This doctoral symposium aimed at supporting PhD students who are already conducting or plan to conduct empirical research as part of their research project. Experienced empirical researchers form the board of advisors reviewed the research plans from PhD students and gave them detailed feedback and guidance. The most promising research plans were invited for presentation at the symposium where the students could get more direct feedback in the discussion. Each of the presenting PhD students was assigned a mentor from the board of advisors who supported them in improving the research plan.

Much effort has been spent to investigate the organization of distributed teams and their collaboration patterns. It is, however, not fully understood to which extent and how agile software processes are feasible to support distributed software projects. Practices and challenges that arise from the demands for communication are often in scope of current research. Still, it remains unclear what is necessary to monitor a project and to track its progress from a management perspective. A solution is to monitor projects and their progress on basis of the current quality of the created artifacts according to a given reference model that defines the artifacts and their dependencies. In this paper, we present an artifact model for agile methods that results from of a systematic literature review. The contribution serves as an empirically grounded definition of process interfaces to coordinate projects and to define exchanged artifacts while abstracting from the diverse local software processes.

Most university curricula consider software processes to be on the fringes of software engineering (SE). Students are told there exists a plethora of software processes ranging from RUP over V-shaped processes to agile methods. Furthermore, the usual students' programming tasks are of a size that either one student or a small group of students can manage the work. Comprehensive processes being essential for large companies in terms of reflecting the organization structure, coordinating teams, or interfaces to business processes such as contracting or sales, are complex and hard to teach in a lecture, and, therefore, often out of scope. We experienced tutorials on using Java or C#, or on developing applications for the iPhone to gather more attention by students, simply speaking, as these are more fun for them. So, why should students spend their time in software processes? From our experiences and the discussions with a variety of industrial partners, we learned that students often face trouble when taking their first “real” jobs, even if the company is organized in a lean or agile shape. Therefore, we propose to include software processes more explicitly into the SE curricula. We designed and implemented a course at Master's level in which students learn why software processes are necessary, and how they can be analyzed, designed, implemented, and continuously improved. In this paper, we present our course's structure, its goals, and corresponding teaching methods. We evaluate the course and further discuss our experiences so that lecturers and researchers can directly use our lessons learned in their own curricula.

A software process metamodel (SPMM) defines a language to describe concrete software processes in a structured manner. Although agile methods gained much attention in recent years, we still need to provide process engineers with adequate tools to design, implement, publish and deploy, and manage comprehensive software processes. In response to this need, several SPMMs have been developed. It remains, however, unclear, which of those SPMMs are disseminated to which extent. In this paper, we contribute first results of a study on the state-of-the-art in the systematic development of software processes using standardized SPMMs and their corresponding infrastructure. Our results show that only a few documented standards exist and, furthermore, that among those standards only two are disseminated into practice. We focus on those standardized SPMMs, show their process ecosystem, and sketch a first picture on the state-of-the-art in SPMM-based software process develop- ment in order to foster discussions on further problem-driven research.

A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the discipline of RE is lacking an official Requirements Engineering Body of Knowledge (REBoK). This working session brings together researchers and practitioners to elaborate the goals, requirements and constraints for a REBoK that shall serve as commonly agreed basis for developing a draft over the following months.

Quality requirements are an often neglected part of requirements engineering. If specified at all, they tend to be either too abstract or very technical and without a rationale. In this paper, we evaluate a quality requirements approach, which makes use of activity-based quality models. To this end, we conduct a comparative case study at Siemens in which we compare the requirements resulting from applying our quality model with the requirements previously used in the same environment. The results indicate an improvement of the requirements regarding, e.g., structured ness and trace ability, but also that the productivity perceived by the industry participants could not be increased. The study thus gives first insights into strengths and limitations of using a quality model in an industrial requirements engineering process.

Background: Little is yet known about how to qualitatively analyse development processes to steer their further optimisation. Thereby, companies are often left to the expertise of third parties when performing such an analysis. Aim: We aim at elaborating a way of empirically analysing development processes on basis of 9 empirical studies we performed at our research group. Method: We analyse 9 empirical studies for commonalities in their research objectives, research methodologies, cases, and methods used to infer a set of research methodology patterns. Results: We discover and discuss three methodology patterns, which we embed into a first experience-based guideline to conduct qualitative analyses of development processes. Conclusion: Our guideline is inferred from a series of successful studies. However, since qualitative analyses always will depend on many aspects that cannot be standardised, we lay with this contribution a first, but fundamental step to be further discussed, evaluated, and extended.

[Background:] Nowadays, industries are facing the problem that the Requirements Engineering (RE) process is highly volatile, since it depends on project influences from the customer's domain or from process models used. Artefact-based approaches promise to provide guidance in the creation of consistent artefacts in volatile project environments, because these approaches concentrate on the artefacts and their dependencies, instead of prescribing processes. Yet missing, however, is empirical evidence on the advantages of applying artefact-based RE approaches in real projects. [Aim:] We developed a customisable artefact-based RE approach for the domain of business information systems. Our goal is to investigate the advantages and limitations of applying this customisable approach in an industrial context. [Method:] We conduct a case study with our artefact-based RE approach and its customisation procedure. For this, we apply it at a software development project at Siemens following the steps of the customisation procedure. We assess our approach in direct comparison with the previously used RE approach considering possible improvements in the process and in the quality of the produced artefacts. [Results:] We show that our approach is flexible enough to respond to the individual needs in the analysed project environment. Although the approach is not rated to be more productive, we find an improvement in the syntactic and the semantic quality of the created artefacts. [Conclusions:] We close a gap in the RE literature by giving empirical evidence on the advantages of artefact orientation in RE in an industrial setting.