(2013), who also focused on usability as well. Since the researchers and practitioners did not necessarily use the same terminology when talking about a certain concept, preparations were made to explain the terminology whenever needed. The arrows in Fig. If it is difficult to elicit the right QRs together with the customers or users, it is even more so without access to the customers. However, one strategy of QR management can be more dominant than others. 2010). The acceptance criteria are more detailed. Reconciliation of scrum and the project management process of the ISO/IEC 29110 standard-Entry profilean experimental evaluation through usability measures, An architecture governance approach for Agile development by tailoring the Spotify model, Competencies for Managing Activities in Agile Projects, http://www.qsrinternational.com/nvivo/nvivo-products, https://www.stateofagile.com/#ufh-i-338498988-10th-annual-stateof-agile-report/473508, http://creativecommons.org/licenses/by/4.0/. This framework introduces a new role into Scrum that is responsible for NFRs (Bourimi et al. IEEE Computer Society Press, Butt S, Ahmad WFW, Rahim L (2014) Handling tradeoffs between agile and usability methods. Since Alsaqaf et al. From the organization facet, the element was whether the organizational model was hierarchical. Last Updated on Thu, 02 Mar 2023 | Software Project Many of what are accepted today as software best practices are derived from the development process and technologies summarized in this chapter. In: IFIP Conference on Human-Computer Interaction, pp 762779, Cannizzo F, Clutton R, Ramesh C (2008) Pushing the boundaries of testing and continuous integration. In Company D, review sessions are conducted together with the customers or the users, and thus any QR issues can be corrected before release. Two researchers independently devised coding schemes that were used to code the interview transcripts. J Softw-Evol Proc 30(10):e1954, Kpyaho M, Kauppinen M (2015) Agile requirements engineering with prototyping: a case study. After we had analyzed the contextual impact, the results were shared with the champions of the companies, who reviewed the results. However, the company also elaborates QRs further during development. In Company C, there is also another practice used to manage quality. Testing a large and complex system takes a long time, and finding the right root cause for a fault might also be time-consuming. There is not much more discussion about QRs at this point, unless the feature to be implemented is completely new. The contextual elements relevant for QR management practices and challenges, as we will show later in the findings, are highlighted in Table 1 with an asterisk (*). However, opportunities remain for the further exploration of these connections. As a result, when developers are not involved in carrying out the specification and when they have limited visibility of the original requirementsi.e., they do not see the why partthey might not understand the specification as intended. This issue could be translated into a QR by stating that all elements in the interface should scale when changing its resolution. QRs are prioritized already at an early phase when roadmaps and high-level epics are defined. 2010; Bourimi and Kesdogan 2013). In: 8th International Workshop on Software Specification and Design, p 181, Singh M (2008) U-SCRUM: an agile methodology for promoting usability. For example, if it is not known which communication bands the potential users would need or use, one might implement the use of many different bands, of which some would be unnecessary. The development process is iterative; however, the company does not follow any formalized method, like Scrum. This confirms that practitioners find the QR to be a fuzzy concept. 2015; Inayat et al. The best programmer might not be suitable as an architect or a manager. Sprint length depends on the length of the project but usually lasts one week, from Tuesday to Tuesday. We found that the companies apply proactive, reactive, and interactive strategies to manage QRs. For example, the interoperability QR can be known, but what is not known is exactly how different parts of the product will be affected, and it is thus difficult to analyze dependencies between the tasks of different teams. Additionally, the developers use the product to develop it. Alsaqaf et al. Requirements are managed in terms of features. Here, the gravity of the issue (i.e., the criticality), as some interviewees call it, determines the priority. Features are further divided into sub-features before they are split into tasks for development. Some examples of quality requirements are the software product must have a response time of less . In: 2015 IEEE 23rd International Requirements Engineering Conference (RE), pp 334343, Karhap P, Haghighatkhah A, Oivo M (2017) What do we know about alignment of requirements engineering and software testing? We have three different quality gates in the CI. Test Effort, Test Efficiency, Agile Project Delivery Quality. The results were validated in each company in workshops by the company champions and other key actors who had knowledge about the software development processes. In: AGILE'08 Conference, pp 555560, Siponen M, Baskerville R, Kuivalainen T (2005) Integrating security into agile development methods. Section 4 presents our findings regarding the research questions: how the companies applying agile methods manage QRs, what challenges they face, and to what extent contextual elements can explain their choice of practices and the challenges they face. Evolution of Software Economics: Software Economics, pragmatic software cost estimation. If one QR is addressed from the point of view of one specific component, it might have adverse consequences on another component. Key aspects that conclude software quality include, Tables 7, 8, 9 and 10 summarizes the contextual elements driving the practices that explain the challenges which are summarized in Tables 11, 12, 13, 14, 15 and 16. Should we include paging, infinite scroll, and so on? These details are necessary to be able to provide the requested functionalities. Company C applied a multi-level CI with different quality gates to catch, for example, internal QR issues as soon as possible. General propositions are those that specify relationships not dependent on contextual aspects and, hence, they are susceptible to appear in any context (e.g., In ASD, there is no shared understanding of the concept of QR). For example, the Product facet includes the product name (due to confidentiality, the actual names of the products and companies are not given), product type, maturity of the product, and customization, which characterizes the product as a general product, a tailored product, or a product for a specific niche market. All companies include some QRs in the acceptance criteria, and some are included as items in the DoD. It also shows how limited access to users poses a challenge for elicitation but can later be mitigated by the practice of value stream mapping sessions (VSM, explained later in Section 4.1.2). Commitment to perform For example, future research could examine why some practices are not used despite being apparently beneficial, or why some challenges are not experienced even though they should be expected to occur. (2008) explained that the implementation of continuous integration (CI) can address QRs, particularly robustness and performance. Farid and Mitropoulos (2013) proposed the Non-functional Requirements Planning for Agile Processes (NORPLAN) to improve the planning and prioritization of NFRs. Moreover, there are likely other contextual elements with similar effects that we did not discover in our study. All three analyses reached the same general conclusion: The success rate for software projects is very low. The top-down coding employed the same structure as the interview questions. (2012), Table 1 presents detailed information about the company contexts in our study so that others can understand and make comparisons to our case companies. Accessed 27 Aug 2018, Petersen K, Wohlin C (2009) Context in industrial software engineering research. Project Quality Management software is used to provide a clear understanding of quality expectations, determine how you will measure these expectations, and implement necessary changes . ProjectManager is cloud-based work and project management software that has multiple project . For instance, even though Heikkil et al. However, Kpyaho and Kauppinen did not discuss the potential of this practice in the context of limited access to customers. It is not always easy to see all dependencies up front. We did not ask about specific challenges that have been reported in the scientific literature in order not to bias the interviewees into thinking that they might have experienced those challenges. Initial mock-ups, together with notes on client feedback as well as user stories and epics drawn up in the scoping sessions, serve as a baseline for the following implementation process. Company A relies mostly on Word documents, emails, and whiteboards in documentation and communication. From a particular process, it considers the method taken as a basis (base method, e.g., Scrum, Kanban), its release frequency, the feature language used (e.g., natural language), and its feature management artifacts (e.g., product backlog). The development employs a mixture of Scrum and Kanban. The propositions obtained from our multiple case study can be classified as general, context, or mitigation propositions. Still, there was always the possibility that an interviewee would not want to admit that a concept was unfamiliar. Provided by the Springer Nature SharedIt content-sharing initiative, Over 10 million scientific documents at your fingertips, Not logged in (2019) study, can pose its own set of challenges for the management of requirements, and QRs are no exception. Users can provide feedback through the open source community, and paying customers can utilize a hotline for reporting issues directly to the sales team. Even though Company D utilizes a template to collect details about QRs, the PO felt that elicitation techniques could be improved because there is always a risk that some important QRs might be missed and costly rework would be needed later: If you get everything right from the beginning, you just specify and develop. This is not the case in Company B, which relies on company goals and roadmaps for the product to elicit important QRs. The challenge in this regard would have been present irrespective of the mode of development. A theoretical model for QR management in ASD: constructs, context propositions (solid arrows), and their mitigation propositions (dashed arrows). When we grouped the challenges, compared them between different companies, and then compared the contexts of the companies, we could see that some of the contextual elements could explain some of the challenges and also work as drivers behind some of the practices. Strategies to manage quality requirements in agile software development: a multiple case study. In the case of Company C, we needed to update the flow of reporting to correctly order the activities and recurrence timescale. The company has chosen not to spend much time on specifying or documenting the QRs. Afterward, based on the findings, we discuss the implications for researchers and practitioners alike. Data was collected incrementally through semi-structured interviews by the first two authors. Distributed development of a large and complex system requires some up-front planning of QRs, When interoperability with legacy systems might be challenging to elicit up front, a multi-level CI could help, Knowledge of the experts, i.e., the developers, can be utilized to elicit QRs during development, and the QRs can be proposed for inclusion in the backlog. For example, Kalenda et al. However, in our study, these practices did not always surface as practices for mitigating specific challenges. We present them the mock-up filled with some dummy data. The following three research questions were formulated to determine why practitioners manage QRs as they do, what challenges they face in doing so, and how the contextual elements of the companies are connected with these practices and challenges: RQ1: What strategies and practices are used to manage QRs in ASD? Eventually, the POs are responsible for refining the tasks for teams. The interview then started with warm-up questions, asked regarding the interviewees experience in ASD and the company in question, after which the interviewees were asked about their understanding of QRs. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. After the project is initiated, product management approves the product proposal. Empir Software Eng 26, 28 (2021). A pre-questionnaire was sent to each champion prior to the interviews, in which we asked for domain and context information, as well as for information regarding the methods and tools used in their software life cycle management. Thus, it is easier to address, for example, the main stability issues and address other issues as soon as they emerge. All of the case companies utilize proactive practices in their strategies, albeit a bit differently. Even though part of the challenge may be the fact that customers or users rarely pay attention to software-internal QRs, the interviewees reported the elicitation itself as a problem: How do you make sure that you get all the necessary QRs right from the beginning? It is many times the case that the PO does not have enough domain knowledge to be able to know all the important QRs. Successful software quality assurance is the result of the combination and integration of these practices, and complements SE practices. The development of one of those devices, which started in 2015, is the unit of focus in our case study. With the help of this strategy, which includes the client from the beginning to the end, it can be ensured that the customers get what they ask for, and that the result is of sufficient quality. PubMedGoogle Scholar. Company B utilized VSM sessions periodically, as they explained, to ensure that what they have developed so far was in line with quality goals. This way, time is saved, as details are recorded and given directly to developers, avoiding situations in which a developer has to stop work to get additional details from the PO. In addition, it should be noted that not all the challenges that are similar to those of Asaqaf et al. Company goals and roadmaps can be used for proactive elicitation of high-level QRs, With a mature product, there is a reduced need to specify all QRs up front, When developers use the tool in development, they can interactively evolve QRs during development, Close connection to users enables valuable user feedback for reactive elicitation of QRs, CI and QA can also be utilized for reactively eliciting QRs. While one researcher asked the interview questions, the other used a checklist to ensure that all necessary information was recorded. Inf Syst J 20(5):449480, Rodrguez P, Yage A, Alarcn P, Garbajosa J (2009) Some findings concerning requirements in agile methodologies. The sprint planning, sprint review, and sprint retrospective meetings are held consecutively within one meeting between sprints. We were consequently able to determine whether the same challenges exist in any kind of large-scale ASD, or whether other contributing factors are involved. The company aims to identify the needs of the market and to fulfill those needs with special solutions. Butt et al. In the example in the figure, access to users enables the practice of conducting scoping sessions together with the users and using templates and checklists in the elicitation and analysis of QRs. Trial users, who can be company-internal, may act as users to test usability prior to release. Our model can be used as the basis for explaining the relationship between contextual elements and QR management challenges, and it can thus be used to predict the challenges that companies can face in certain contexts. However, it would seem that the sources for the practices were rather in their own efforts to solve challenges. In: ACM-IEEE International Symposium on Empirical Software Engineering and Measurement pp 1928, Farid W (2012) The NORMAP methodology: lightweight engineering of non-functional requirements for agile processes. Software Quality Defect Management Approach. NVivo used in coding interview transcripts according to themes in interview questions. The PO sets up the project configuration and development team and defines the tasks for developers to complete in one- to two-week sprints. Correspondence to Likewise, although Inayat et al. 3 also shows the together with the client and limited access to user scenarios codes with red underlining. We found only one challenge that we can categorize as a challenge for the activity of specifying QRs. Because of this limitation, one interviewee reported that they receive feedback about QRs too late. However, not all of these practices were used exactly as they were proposed in the literature, or for the exact same purpose. Any issues found at this level can be communicated directly back to developers for them to address. (2008) proposed building software engineering theories in five steps: (1) defining the constructs of the theory, (2) defining the propositions of the theory, (3) providing explanations to justify the theory, (4) determining the scope of the theory, and (5) testing the theory through empirical research. This study is also part of the Q-Rapids project. The interview questions were created by two researchers and reviewed by two other researchers. The first round consisted of two sets of interviews. We found that the practitioners in the studied cases manage quality in general and complement their development processes with any practices necessary for the management of QRs to reach their quality goals. A cross-case analysis of four software teams. What Is Project Quality Management? Another challenge related to the area of QR elicitation was the dependency between business lines, components, and development teams. Company C applies a strategy that utilizes mostly proactive and reactive practices for the management of QRs or quality in general.