Agile software development (ASD) promotes minimal documentation and often prioritizes functional requirements over quality requirements (QRs). The minimal documentation emphasis may be beneficial in reducing time-to-market for software. However, it can also be a concern, especially with QRs, since they are challenging to specify and document and are crucial for software success. Therefore, understanding how practitioners perceive the importance of QR documentation is valuable because it can provide insight into how they approach this task. It also helps in developing models and guidelines that support the documentation of QRs in ASD, which is a research gap. We aim to understand practitioners’ perceptions of QR documentation and factors influencing this task to derive a model that supports optimal QR documentation in ASD. We conducted a multiple case study involving 12 participants from three cases that apply ASD. Practitioners identify QR documentation as important and perceive it as contributing to ensuring quality, clarifying QRs, and facilitating decision-making. Time constraints, QR awareness, and communication gaps affect QR documentation. Missing and outdated QR documentation may lead to technical debt and a lack of common understanding regarding QRs. We introduce a model to support optimal QR documentation in ASD by focusing on the factors: time constraints, QR awareness, and communication gaps. The model provides a representation and explanation of the factors affecting QR documentation in ASD and identifies mitigation strategies to overcome issues that may occur due to these factors. The study reveals the importance of documenting QRs in ASD. It introduces a model that is based on empirical knowledge of QR documentation practices in ASD. Both practitioners and researchers can potentially benefit from the model. For instance, practitioners can analyze how time constraints or QR awareness affect documentation, see potential issues that may arise from them, and utilize strategies suggested by the model to address these issues. Researchers can learn about QR documentation in ASD and utilize the model to understand the topic. They can also use the study as a baseline to investigate the topic with other cases.

Abstract Agile methods can deliver software that fulfills customer needs rapidly and continuously. Quality requirements (QRs) are important in this regard; however, detailed studies on how companies applying agile methods to manage QRs are limited, as are studies on the rationale for choosing specific QR management practices and related challenges. The aim of this study was to address why practitioners manage QRs as they do and what challenges they face. We also analyzed how existing practices mitigate some of the found challenges. Lastly, we connect the contextual elements of the companies with their practices and challenges. We conducted 36 interviews with practitioners from four companies of varying sizes. Since each company operates in different domains, comparing QR management strategies and related challenges in different contexts was possible. We found that the companies apply proactive, reactive, and interactive strategies to manage QRs. Additionally, our study revealed 40 challenges in six categories that companies applying agile methods may face in QR management. We also identified nine contextual elements that affect QR management practice choices and which, importantly, can explain many related challenges. Based on these findings, we constructed a theoretical model about the connection between context, QR management practices, and challenges. Practitioners in similar contexts can learn from the practices identified in this study. Our preliminary theoretical model can help other practitioners identify what challenges they can expect to face in QR management in different developmental contexts as well as which practices to apply to mitigate these challenges.

Background: Practitioners would like to take action based on software metrics, as long as they find them reliable. Existing literature explores how metrics can be made reliable, but remains unclear if there are other conditions necessary for a metric to be actionable. Context & Method: In the context of a European H2020 Project, we conducted a multiple case study to study metrics' use in four companies, and identified instances where these metrics influenced actions. We used an online questionnaire to enquire about the project participants' views on actionable metrics. Next, we invited one participant from each company to elaborate on the identified metrics' use for taking actions and the questionnaire responses (N=17). Result: We learned that a metric that is practical, contextual, and exhibits high data quality characteristics is actionable. Even a non-actionable metric can be useful, but an actionable metric mostly requires interpretation. However, the more these metrics are simple and reflect the software development context accurately, the less interpretation required to infer actionable information from the metric. Company size and project characteristics can also influence the type of metric that can be actionable. Conclusion: This exploration of industry's views on actionable metrics help characterize actionable metrics in practical terms. This awareness of what characteristics constitute an actionable metric can facilitate their definition and development right from the start of a software metrics program.

Agile software development (ASD) promotes minimal documentation and often prioritizes functional requirements over quality requirements (QRs). This may be beneficial in reducing the time to market of software. When considering QRs in ASD, the minimal documentation practice may be seen as a concern since QRs determine the success of software projects and are as well not easy to specify and document. Nevertheless, what do practitioners think of the necessity of documenting QRs in ASD? How do they perceive factors that may affect documentation of QRs in ASD? We conducted a multiple case study of three cases applying ASD, involving 12 participants. ASD practitioners identify that it is important to document QRs, and perceive that it contributes to ensuring quality, clarifying QRs, and helping in decision making. Time constraint, QR awareness and communication gaps on QRs influence the documentation of QRs in ASD. ASD teams may align their documentation practices to fit the sprint duration. The influence of QR awareness on documentation was dependent on project context and roles. Communication gaps can create confusion on QRs. Missing and outdated QR documentation may result in accruing technical debt, and lack of common understanding on QRs. The study synthesizes empirical evidence on the significance of documenting QRs in ASD and provides an insight into factors affecting documentation of QRs in ASD.

Abstract Requirements volatility is a major issue in software development, causing problems such as higher defect density, project delays, and cost overruns. Software architecture that guides the overall vision of software product is one of the areas that is greatly affected by requirements volatility. Since critical architecture decisions are made based on the requirements at hand, changes in requirements can result significant changes in architecture. With the wide adoption of agile software development, software architectures are designed to accommodate possible future changes. However, the changes has to be carefully managed as unnecessary and excessive changes can bring negative consequences. An exploratory case study was conducted to study the impact of requirements volatility on software architecture. Fifteen semistructured, thematic interviews were conducted in a European software company. The research revealed poor communication, information distortion, and external dependencies as the main factors that cause requirement volatility and inadequate architecture documentation, inability to trace design rationale, and increased complexity as the main implications of requirements volatility on software architecture. Insights from software teams' awareness of the requirement volatility, factors contribute to it, and possible ways to mitigate its implications will be utilized to improve the management of requirement volatility during software architecting process.

Requirements volatility is a major issue in software (SW) development, causing problems such as project delays and cost overruns. Even though there is a considerable amount of research related to requirement volatility, the majority of it is inclined toward project management aspects. The relationship between SW architecture design and requirements volatility has not been researched widely, even though changing requirements may for example lead to higher defect density during testing. An exploratory case study was conducted to study how requirements volatility affects SW architecture design. Fifteen semi-structured, thematic interviews were conducted in the case company, which provides the selection of software products for business customers and consumers. The research revealed the factors, such as requirements uncertainty and dynamic business environment, causing requirements volatility in the case company. The study identified the challenges that requirements volatility posed to SW architecture design, including scheduling and architectural technical debt. In addition, this study discusses means of mitigating the factors that cause requirements volatility and addressing the challenges posed by requirements volatility. SW architects are strongly influenced by requirement volatility. Thus understanding the factors causing requirements volatility as well as means to mitigate the challenges has high industrial relevance.