Naming the pain in requirements engineering : Contemporary problems, causes, and effects in practice

Requirements Engineering (RE) has received much attention in research and practice due to its importance to software project success. Its interdisciplinary nature, the dependency to the customer, and its inherent uncertainty still render the discipline difficult to investigate. This results in a lack of empirical data. These are necessary, however, to demonstrate which practically relevant RE problems exist and to what extent they matter. Motivated by this situation, we initiated the Naming the Pain in Requirements Engineering (NaPiRE) initiative which constitutes a globally distributed, bi-yearly replicated family of surveys on the status quo and problems in practical RE. In this article, we report on the qualitative analysis of data obtained from 228 companies working in 10 countries in various domains and we reveal which contemporary problems practitioners encounter. To this end, we analyse 21 problems derived from the literature with respect to their relevance and criticality in dependency to their context, and we complement this picture with a cause-effect analysis showing the causes and effects surrounding the most critical problems. Our results give us a better understanding of which problems exist and how they manifest themselves in practical environments. Thus, we provide a first step to ground contributions to RE on empirical observations which, until now, were dominated by conventional wisdom only.Peer reviewe

On Evidence-based Risk Management in Requirements Engineering

Background: The sensitivity of Requirements Engineering (RE) to the context makes it difficult to efficiently control problems therein, thus, hampering an effective risk management devoted to allow for early corrective or even preventive measures. Problem: There is still little empirical knowledge about context-specific RE phenomena which would be necessary for an effective context- sensitive risk management in RE. Goal: We propose and validate an evidence-based approach to assess risks in RE using cross-company data about problems, causes and effects. Research Method: We use survey data from 228 companies and build a probabilistic network that supports the forecast of context-specific RE phenomena. We implement this approach using spreadsheets to support a light-weight risk assessment. Results: Our results from an initial validation in 6 companies strengthen our confidence that the approach increases the awareness for individual risk factors in RE, and the feedback further allows for disseminating our approach into practice.Comment: 20 pages, submitted to 10th Software Quality Days conference, 201

Towards Guidelines for Preventing Critical Requirements Engineering Problems

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.Comment: Proceedings of the 42th Euromicro Conference on Software Engineering and Advanced Applications, 201

Supporting Defect Causal Analysis in Practice with Cross-Company Data on Causes of Requirements Engineering Problems

[Context] Defect Causal Analysis (DCA) represents an efficient practice to improve software processes. While knowledge on cause-effect relations is helpful to support DCA, collecting cause-effect data may require significant effort and time. [Goal] We propose and evaluate a new DCA approach that uses cross-company data to support the practical application of DCA. [Method] We collected cross-company data on causes of requirements engineering problems from 74 Brazilian organizations and built a Bayesian network. Our DCA approach uses the diagnostic inference of the Bayesian network to support DCA sessions. We evaluated our approach by applying a model for technology transfer to industry and conducted three consecutive evaluations: (i) in academia, (ii) with industry representatives of the Fraunhofer Project Center at UFBA, and (iii) in an industrial case study at the Brazilian National Development Bank (BNDES). [Results] We received positive feedback in all three evaluations and the cross-company data was considered helpful for determining main causes. [Conclusions] Our results strengthen our confidence in that supporting DCA with cross-company data is promising and should be further investigated.Comment: 10 pages, 8 figures, accepted for the 39th International Conference on Software Engineering (ICSE'17

Continuous and collaborative technology transfer : Software engineering research with real-time industry impact

Context: Traditional technology transfer models rely on the assumption that innovations are created in academia, after which they are transferred to industry using a sequential flow of activities. This model is outdated in contemporary software engineering research that is done in close collaboration between academia and industry and in large consortia rather than on a one-on-one basis. In the new setup, research can be viewed as continuous co-experimentation, where industry and academia closely collaborate and iteratively and jointly discover problems and develop, test, and improve solutions. Objective: The objective of the paper is to answer the following research questions: How can high-quality, ambitious software engineering research in a collaborative setup be conducted quickly and on a large scale? How can real-time business feedback to continuously improve candidate solutions be gained? Method: The proposed model has been created, refined, and evaluated in two large, national Finnish software research programs. For this paper, we conducted thematic interviews with representatives of four companies who participated in these programs. Results: The fundamental change is in the mindset of the participants from technology push by academia to technology pull by companies, resulting in co-creation. Furthermore, continuous cooperation between participants enables solutions to evolve in rapid cycles and forms a scalable model of interaction between research institutes and companies. Conclusions: The multifaceted nature of software engineering research calls for numerous approaches. In particular, when working with human-related topics such as company culture and development methods, many discoveries result from seamless collaboration between companies and research institutes.Peer reviewe

Modeling functional requirements using tacit knowledge: a design science research methodology informed approach

The research in this paper adds to the discussion linked to the challenge of capturing and modeling tacit knowledge throughout software development projects. The issue emerged when modeling functional requirements during a project for a client. However, using the design science research methodology at a particular point in the project helped to create an artifact, a functional requirements modeling technique, that resolved the issue with tacit knowledge. Accordingly, this paper includes research based upon the stages of the design science research methodology to design and test the artifact in an observable situation, empirically grounding the research undertaken. An integral component of the design science research methodology, the knowledge base, assimilated structuration and semiotic theories so that other researchers can test the validity of the artifact created. First, structuration theory helped to identify how tacit knowledge is communicated and can be understood when modeling functional requirements for new software. Second, structuration theory prescribed the application of semiotics which facilitated the development of the artifact. Additionally, following the stages of the design science research methodology and associated tasks allows the research to be reproduced in other software development contexts. As a positive outcome, using the functional requirements modeling technique created, specifically for obtaining tacit knowledge on the software development project, indicates that using such knowledge increases the likelihood of deploying software successfully

Naming the Pain in Requirements Engineering: A Design for a Global Family of Surveys and First Results from Germany

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, they still do not allow for empirical generalisations. To lay an empirical and externally valid 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. We designed a globally distributed family of surveys in joint collaborations with different researchers and completed the first run in Germany. The instrument is based on a theory in the form of a set of hypotheses inferred from our experiences and available studies. We test each hypothesis in our theory and identify further candidates to extend the theory by correlation and Grounded Theory analysis. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from Germany with participants from 58 companies. The results reveal, for example, a tendency to improve RE via internally defined qualitative methods rather than relying on normative approaches like CMMI. We also discovered various RE problems that are statistically significant in practice. For instance, we could corroborate communication flaws or moving targets as problems in practice. Our results are not yet fully representative but already give first insights into current practices and problems in RE, and they allow us to draw lessons learnt for future replications. Our results obtained from this first run in Germany make us confident that the survey design and instrument are well-suited to be replicated and, thereby, to create a generalisable empirical basis of RE in practice