Requirement conflicts commonly o ccur i n soft-ware development, especially for complex systems that involve many requirements. Resolving these conflicts c an b every time-consuming and costly. Moreover, due to the contextual nature of requirements conflicts, resolutionstrategies a re n eeded that can be tailored to a specific conflict an d it s co ntext. Currently, there is a lack of research on what categories of conflicts exist and how practitioners manage these conflicts. Toe nable more adaptive resolution strategies, the aim of this research is to map what types of requirement conflicts a re e ncountered a nd how they are managed in practice. Through an interview study with eleven participants from eight companies in six domains, we identified three levels of conflict ty pes th at co nnect to four types of causes. These types and causes revealed two main dimensions that impact conflict management. One dimension is related to the nature of the conflict, either technical or social, a nd the other dimension is related to the nature of the requirement scope, which is either too constraining or too undefined resulting in stakeholders making assumptions that create conflicts. We found that these two dimensions impact what conflict resolution strategies are most commonly used for different types of conflicts.

Requirement prioritization is recognized as an important decision-making activity in requirements engineering . Requirement prioritization is applied to determine which requirements should be implemented and released. In order to prioritize requirements, there are several approaches/techniques/tools that use different requirements prioritization criteria, which are often identified by gut feeling instead of an in-depth analysis of which criteria are most important to use. Therefore, in this study we investigate which requirements prioritization criteria are most important to use in industry when determining which requirements are implemented and released, and if the importance of the criteria change depending on how far a requirement has reached in the development process. We conducted a quantitative study where quantitative data was collected through a case study of one completed project from one software developing company by extracting 32,139 requirements prioritization decisions based on eight requirements prioritization criteria for 11,110 requirements. The results show that not all requirements prioritization criteria are equally important, and this change depending on how far a requirement has reached in the development process. For example, for requirements prioritization decisions before iteration/sprint planning, having high Business value had an impact on the decisions, but after iteration/sprint planning, having high Business value had no impact. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

The software value chain is knowledge-based since it is highly dependant on people. Consequently, a lack of practice in managing knowledge as a resource may jeopardise its application in software development. Knowledge-Based Resources (KBRs) relate to employees’ intangible knowledge that is deemed to be valuable to a company’s competitive advantage. In this study, we apply a grounded theory approach to examine the role of KBRs in Agile Software Development (ASD). To this aim, we collected data from 18 practitioners from five companies. We develop the Knowledge-Push theory, which explains how KBRs boost the need for change in ASD. Our results show that the practitioners who participated in the study utilise, as primary strategies, task planning, resource management, and social collaboration. These strategies are implemented through the team environment and settings and incorporate an ability to codify and transmit knowledge. However, this process of codification is non-systematic, which consequently introduces inefficiency in the domain of knowledge resource utilisation, resulting in potential knowledge waste. This inefficiency can generate negative implications for software development, including meaningless searches in databases, frustration because of recurrent problems, the unnecessary redesign of solutions, and a lack of awareness of knowledge sources.

As a result of the COVID-19 pandemic, many agile practitioners had to transition into a remote work environment. Despite remote work not being a new concept for agile software practitioners, the forced or recommended nature of remote work is new. This study investigates how the involuntary shift to remote work and how social restrictions imposed by the COVID-19 pandemic have affected agile software development (ASD), and how agile practitioners have been affected in terms of ways of working. An explanatory sequential mixed methods study was performed. Data were collected one year into the COVID-19 pandemic through a questionnaire with 96 respondents and in-depth semi-structured interviews with seven practitioners from seven different companies. Data were analyzed through Bayesian analysis and thematic analysis. The results show, in general, that the aspects of ASD that have been the most affected is communication and social interactions, while technical work aspects have not experienced the same changes. Moreover, feeling forced to work remotely has a significant impact on different aspects of ASD, e.g., productivity and communication, and industry practitioners' employment of agile development and ways of working have primarily been affected by the lack of social interaction and the shift to digital communication. The results also suggest that there may be a group maturing debt when teams do go back into office, as digital communication and the lack of psychological safety stand in the way for practitioners' ability to have sensitive discussions and progress as a team in a remote setting.

Abstract Expert judgement is a common method for software effort estimations in practice today. Estimators are often shown extra obsolete requirements together with the real ones to be implemented. Only one previous study has been conducted on if such practices bias the estimations. We conducted six experiments with both students and practitioners to study, and quantify, the effects of obsolete requirements on software estimation. By conducting a family of six experiments using both students and practitioners as research subjects ( $$N=461$$ N = 461 ), and by using a Bayesian Data Analysis approach, we investigated different aspects of this effect. We also argue for, and show an example of, how we by using a Bayesian approach can be more confident in our results and enable further studies with small sample sizes. We found that the presence of obsolete requirements triggered an overestimation in effort across all experiments. The effect, however, was smaller in a field setting compared to using students as subjects. Still, the over-estimations triggered by the obsolete requirements were systematically around twice the percentage of the included obsolete ones, but with a large 95% credible interval. The results have implications for both research and practice in that the found systematic error should be accounted for in both studies on software estimation and, maybe more importantly, in estimation practices to avoid over-estimations due to this systematic error. We partly explain this error to be stemming from the cognitive bias of anchoring-and-adjustment, i.e. the obsolete requirements anchored a much larger software. However, further studies are needed in order to accurately predict this effect.

Abstract The necessity of software as stand-alone products, and as central parts of non-traditional software products have changed how software products are developed. It started with the introduction of the agile manifesto and has resulted in a change of how software process improvements (SPI) are conducted. Although there are agile SPI methods and several agile practices for evaluating and improving current processes and ways-of-working, no method or practices for evaluating the backlog exists. To address this gap, the Backlog Assessment Method (BAM) was developed and applied in collaboration with Telenor Sweden. BAM enables agile organizations to assess backlogs, and assure that the backlog items are good-enough for their needs and well aligned with the decision process. The results from the validation show that BAM is feasible and relevant in an industrial environment, and it indicates that BAM is useful as a tool to perform analysis of items in a specific backlog.

Abstract With the general trend towards data-driven decision making (DDDM), organizations are looking for ways to use DDDM to improve their decisions. However, few studies have looked into the practitioners view of DDDM, in particular for agile organizations. In this paper we investigated the experiences of using DDDM, and how data can improve decision making. An emailed questionnaire was sent out to 124 industry practitioners in agile software developing companies, of which 84 answered. The results show that few practitioners indicated a wide-spread use of DDDM in their current decision making practices. The practitioners were more positive to its future use for higher-level and more general decision making, fairly positive to its use for requirements elicitation and prioritization decisions, while being less positive to its future use at the team level. The practitioners do see a lot of potential for DDDM in an agile context; however, currently unfulfilled.

Knowledge-intensive companies that adopt Agile Software Development (ASD) rely on efficient implementation of Knowledge Management (KM) strategies to promote different Knowledge Processes (KPs) to gain competitive advantage. This study aims to explore how companies that adopt ASD implement KM strategies utilizing practices that promote the KPs in the different organizational layers. Through a systematic literature review, we analyzed 32 primary studies, selected by automated search and snowballing in the extant literature. To analyze the data, we applied narrative synthesis. Most of the identified KM practices implement personalization strategies (81%), supported by codification (19%). Our review shows that the primary studies do not report KM practices in the strategic layer and two of them in the product portfolio layer; on the other hand, in the project layer, the studies report 33 practices that implement personalization strategy, and seven practices that implement codification. KM strategies in ASD promote mainly the knowledge transfer process with practices that stimulates social interaction to share tacit knowledge in the project layer. As a result of using informal communication, a significant amount of knowledge can be lost or not properly transferred to other individuals and, instead of propagating the knowledge, it remains inside a few individuals’ minds.

In recent years, the influence of open innovation has become more and more important in the development of software products and services. However, open innovation is still unexplored for software-intensive organizations and its potential impact on the organization's innovative performance. In this paper we present the results of an empirical study carried out to gauge common experiences within open innovation in the requirements engineering process, and to understand the barriers and drivers for using open innovation. A web-based questionnaire was sent out to 54 industry practitioners, of which 35 answered. The results show that open innovation as part of the requirements engineering process is becoming more and more fully exploited from both the outside and inside. Moreover, potential drivers for using open innovation include, new generated ideas and higher costumer benefits, while identified barriers include, hard finding the right partner and lack of innovativeness.

We performed a retrospective meeting at a case company to reflect on its decade of Software Process Improvement (SPI) activities for enhancing UX integration. We supported the meeting by a pre-generated timeline of the main activities. This approach is a refinement of a similar approach that is used in Agile projects to improve effectiveness and decrease memory bias of retrospective meetings. The method is evaluated through gathering practitioners' view using a questionnaire. We conclude that UX research and practice can benefit from the SPI body of knowledge. We also argue that a cross-section evidence-based timeline retrospective meeting is useful for enhancing UX work in companies, especially for identifying and reflecting on 'organizational issues'.This approach also provides a cross-section longitudinal overview of the SPI activities that cannot easily be gained in other common SPI learning approaches.

Modern automotive embedded systems are developed by Original Equipment Manufacturers (OEM) together with multiple suppliers. A key problem for a supplier is to allocate an OEM's requirements specification to their own subsystem design. This is a difficult manual task especially on complex systems and it requires expert knowledge about the system design. To address this problem, this paper presents a design science research to develop and evaluate a Requirements Allocation Assistant tool (RAA). The tool provides functionality to search through and filter requirements and system models to enable efficient requirements allocation even in the presence of complexity.RAA is built on top of the EATOP/Eclipse framework using EAST-ADL as system modelling language. The tool was evaluated and validated during a qualitative usability study with 17 engineers active in the Swedish automotive industry. Key findings are that searching is used to learn about a system, whereas filtering is used to narrow down a set of candidate elements of the system design. Engineers request further support in narrowing down a set of candidate elements and in checking that an allocation is correct.

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.

Requirements engineering is recognized as a creative process where stakeholders jointly discover new creative ideas for innovative and novel products that eventually are expressed as requirements. This paper evaluates four different creativity techniques, namely Hall of Fame, Constraint Removal, Brainstorming, and Idea Box, using creativity workshops with students and industry practitioners. In total, 34 creativity workshops were conducted with 90 students from two universities, and 86 industrial practitioners from six companies. The results from this study indicate that Brainstorming can generate by far the most ideas, while Hall of Fame generates most creative ideas. Idea Box generates the least number of ideas, and the least number of creative ideas. Finally, Hall of Fame was the technique that led to the most number of requirements that was included in future releases of the products.

In order to create a successful software product and assure its quality, it is not enough to fulfill the functional requirements, it is also crucial to find the right balance among competing quality requirements (QR). An extended, previously piloted, interview study was performed to identify specific challenges associated with the selection, tradeoff, and management of QR in industrial practice. Data were collected through semistructured interviews with 11 product managers and 11 project leaders from 11 software companies. The contribution of this study is fourfold: First, it compares how QR are handled in two cases, companies working in business-to-business markets and companies that are working in business-to-consumer markets. These two are also compared in terms of impact on the handling of QR. Second, it compares the perceptions and priorities of QR by product and project management, respectively. Third, it includes an examination of the interdependencies among quality requirements perceived as most important by the practitioners. Fourth, it characterizes the selection and management of QR in downstream development activities.

Requirements prioritization is recognized as an important but challenging activity in software product development. For a product to be successful, it is crucial to find the right balance among competing quality requirements. Although literature offers many methods for requirements prioritization, the research on prioritization of quality requirements is limited. This study identifies how quality requirements are prioritized in practice at 11 successful companies developing software intensive systems. We found that ad-hoc prioritization and priority grouping of requirements are the dominant methods for prioritizing quality requirements. The results also show that it is common to use customer input as criteria for prioritization but absence of any criteria was also common. The results suggests that quality requirements by default have a lower priority than functional requirements, and that they only get attention in the prioritizing process if decision-makers are dedicated to invest specific time and resources on QR prioritization. The results of this study may help future research on quality requirements to focus investigations on industry-relevant issues.