Keywords

1 Introduction

Agile methods are becoming increasingly popular in the software industry [1,2,3]. Customer satisfaction through early and continuous delivery of valuable software, adaptability to late requirements changes, short and iterative development cycles are some principles of agile software development (ASD) methods [4]. Another important aspect of software development that has attracted a lot of attention is software quality, mainly represented by the quality requirements (QRs; also referred to as non-functional requirements –NFRs) of the product [5]. However, it has been documented that the management of QRs in software development in general [5] and in ASD in particular [6] is problematic, e.g. important QRs might be neglected in ASD [7].

One aspect of ASD is that agile principles put emphasis on communication and linking of people [4]. The closer collaboration between people within a development team, e.g. requirements engineers and testers, helps in generating an understanding of the requirements so that development can progress and testing can be conducted properly despite lower quality of the requirements and lack of documentation [8]. Agile practices can also help the QR elicitation by reducing vagueness of requirements through communication [9], QRs in particular, since defining good, verifiable, and complete QRs is quite difficult.

Improving the management of QRs in agile projects is the ultimate goal of the Q-Rapids (Quality-aware Rapid Software Development) projectFootnote 1. In order to achieve this goal, we aim at defining a set of guidelines for integrating QR management into the ASD life cycle. There are several methods, techniques and models that can be applied for managing QRs, making difficult the definition of a unique method to be applied in any organization. In the context of ASD, Qumer and Henderson-Sellers applied Situational Method Engineering (SME) to create a software development method combining agile and formal practices in a large software development organization [10]. Following the same approach, in this paper we propose using SME to identify, complement, and classify a portfolio of best industrial practices in order to define a method for QR management in agile environments.

The rest of the paper is organized as follows. Section 2 introduces the research approach followed, including the background necessary to apply SME. The construction of the method is based in the software development process detailed in Sect. 3. Section 4 includes the definition of the method requirements, and Sect. 5 includes an example of the guidelines associated to the QRs prioritization. Finally, Sect. 6 concludes the presentation of the work included in this paper and discusses our future work.

2 Situational Method Engineering

2.1 Background

In this work we apply the assembly-based Situational Method Engineering (SME) approach [11] as underpinning theory for capitalizing best practices in the domain of QR management in ASD, and for reusing them in the construction of situation-specific methods. Following this approach, the knowledge of such methods has to be formalized in terms of reusable method chunks. A method chunk describes the method process (i.e., the guidelines) and its related products (i.e., the concepts and artefacts used/transformed/created by applying the guidelines). It also specifies the situation in which it can be applied (i.e., the required input artefacts) and the intention (i.e., the engineering goal) to be reached. The method chunks are used as building blocks for constructing a situation-specific method, which can be a project-specific method or even a configurable method family including several method chunk variants for each method step. In both cases, the approach consists of defining method requirements and then selecting and assembling method chunks satisfying these requirements. Method requirements (also called requirements map) are specified as a desired process model by using the Map process modeling formalism [12], which allows to express methods in terms of intentions and strategies to reach the intentions. The variability and flexibility of a method is reached by defining several strategies for achieving an intention.

The sources for engineering method chunks can be various: existing methods, standards, templates, and best practices. Depending on their formalization and level of detail, the creation of method chunks consist in reengineering the existing method knowledge or defining it from scratch.

2.2 Application

The assembly-based SME approach has been applied in various software and information systems engineering domains. For instance, Ralyté et al. reengineered the RESCUE Requirements Process into a modular method (a collection of method chunks organized into a multi-level process map) allowing to assess the quality of the method, to identify omissions and weaknesses, and to reason about its improvements [13]. This case also demonstrated the effectiveness of the SME approach for modelling large-scale engineering processes. In a different domain, López et al. presented the OSSAP method [14], applying assembly-based SME approach to construct a method for OSS adoption business processes. The OSSAP chunks correspond to the different ways of adopting OSS and the pieces of processes to be adopted by the organization, depending on the way they want to be involved with the OSS community producing the OSS.

3 Software Development Process in Agile Projects

In this section, we present the analysis of the software development process employed in four use cases (UCs) of the Q-Rapids project. The results are based on preliminary findings of case studies conducted to understand the software development processes and QR management practices adopted in selected projects of the Q-Rapids industrial partners. The Q-Rapids industrial partners are representatives of small, medium, and large sized companies from three different countries (Finland, France and Poland), all produce software in different domains (telecommunications, secure solutions, modeling and ad-hoc solutions). Qualitative analysis was done on the 12 semi-structured interviews conducted in the UCs to get an understanding of the development processes.

Our findings reveal that all of the UCs adopt variants of Scrum tailored to their specific context of development. The UCs operate in predefined release cycles that range from two weeks to six months. The sprint cycle varied from one to four weeks. Medium and large companies are characterized by complex backlog structure and multiple teams. The smaller companies utilized a single backlog and consist of a small sized team. Additionally, the ASD maturity level applied in the UCs also varied. We observed both similarities and differences in the practices, roles and tools utilized in the UCs.

During initial stages of the development process, the UCs elicit requirements (both functional requirements and QRs) mainly based on customer needs. At this stage, high level features are elicited together with the customer. Features that bring more value to the customer are prioritized. However, the level of customer involvement, as well as the practices and roles involved in the process, varies among the UCs. For instance, two UCs from small and medium sized companies mainly utilize the customer for eliciting requirements. The other two UCs from medium and large sized companies consider additional factors such as product roadmaps, the status of the market and problems of potential customer segments. Roles involved in higher level requirements elicitation included product owners, product and technical managers, sales team, and usability experts. Product and technical managers made requirements prioritization decision in UCs of medium and large companies. On the other hand, smaller companies relied on the product owners’ decisions for requirements elicitation and prioritization. Elicitation of the higher-level features considered both functional requirements and QRs.

The higher level features are refined and specified into lower level features or user stories and tasks. In medium and large organizations, higher level features were refined in several steps due to the product size. On the other hand, in smaller companies, the number of refinement steps were fewer.

Communication happens throughout the development process in all of the UCs. Face-to-face communication serves as the main source of communication in small sized companies. In such cases, face-to-face communication facilitates the development process, as the developers are close to each other and usually in the same room. Additionally, there was less emphasis on the documentation practices. However, in medium and large sized companies, documentation and shared tools serve as sources of communication. Face-to-face communication was adopted only at lower (local) level.

All UCs employ continuous integration in their development process. Nightly builds, integration tests, and acceptance tests are applied in the verification and validation process. The testing practices also varied with the size of the companies. Figure 1 depicts the generic view of the development process adopted in the UCs.

Fig. 1.
figure 1

Aggregated view of the development processes in the UCs

Full size image

4 QR Management Method Requirements

The analysis of the software development process of the UCs, described in the previous section, uncovered that they do not use a predefined existing method for QR management. The organizations use and combine different methods and techniques in different ways for setting their own agile oriented development process. The aim of this work is setting up a portfolio of best practices organizing and complementing these techniques to improve QR management in the context of ASD processes.

Due to this diversity of methods and techniques, we are developing this portfolio applying SME, concretely creating a new method constructed from scratch [15]. In order to identify the needed guidelines, we applied a process-driven strategy to elicit the method requirements, which is more relevant in the case of a new method construction [16]. In order to specify the requirements for the method, we need to (1) identify the set of intentions related to the QR management in the current processes, and (2) identify the possible strategies for fulfilling these intentions.

During the UCs analysis, we collected the initial set of intentions to be fulfilled by the new method: Elicit, Specify, Communicate, and Verify and Validate QRs. These intentions correspond to the underlying goals for each activity of the generic development process depicted in Fig. 1: meetings discussing market roadmap and customer needs for elicitation, backlogs and whiteboards for specification and communication, and testing for verification and validation. Then, we complemented the set of intentions identifying the different strategies to fulfill them. The intentions are represented as nodes and strategies as edges in the requirements map shown in Fig. 2.

Fig. 2.
figure 2

QR management method requirements map

Full size image

Most of the strategies included in the requirements map are still generic, except for the strategies to fulfill the Specify QR intention. The Q-Rapids UC providers (see Sect. 3), pointed out that we can find different levels of requirements in ASD processes, from high-level requirements (coming from the elicitation activity) to lower-level requirements (defined in later stages), which are the refined requirements that can be translated to user stories, features or tasks to be communicated to the development team. Therefore, refinement is the strategy to specify new lower-level requirements. Prioritization is really important in agile environments, requirements need to be arranged by priority to be fully specified before they are communicated to the development teams.

5 Example: Chunks for QR Prioritization

In this section, we describe the possible strategies for fulfilling the Prioritize QRs intention. From the analysis of the UC processes, we identified the following two situations: the prioritization by urgency (issue-driven) and prioritization based on value (value-driven). The prioritization by urgency occurs when some blocking situation arises during the software development process that affects the expected workflow. For example, if there is a specific problem/issue in the development of a critical feature, the development team should reprioritize the work focusing on fixing this situation. On the other hand, when no critical situations should be handled, the organization can prioritize their requirements with no specific problem to solve.

For the value-driven strategy, we identified an existing method chunk included in [17] for cost-value requirements prioritization. This value-driven prioritization chunk proposes having two criteria for evaluating requirements: relative value and relative cost, which are used for ranking the requirements. Figure 3 reproduces the process map for this chunk.

Fig. 3.
figure 3

Cost-value requirements prioritization approach chunk [17]

Full size image

We did not find any existing method for the Issue-driven prioritization, so we envisage that we are going to create one. It could be based on the idea of identifying the features related to the issue, and then the dependencies for this feature, the features would be ranked depending on the dependency to the critical issue to solve.

According to SME process, we refined the strategy named “by prioritization” into two: Value-driven prioritization and Issue-driven prioritization.

6 Conclusions and Future Work

Organizations do not use a predefined existing method for QR management. In this paper we present the initial findings of our research investigating what industrial practices, from the agile methods, can be used for better management of QRs in agile software development.

In this paper, we present how we are using Situational Method Engineering (SME) to identify, complement and classify a portfolio of best practices for agile QR management. SME is used to construct methods that can be customized to fulfill the organization needs. The first results reported in this paper correspond to the initial set of intentions that are leading our method requirements elicitation. The guidelines should include best practices to fulfill four different intentions: QR elicitation, specification, communication, and verification and validation, and the three strategies for fulfilling the specification intention: by refinement, documentation and prioritization. So far, we identified two concrete strategies for the prioritization: the prioritization by urgency (issue-driven) and prioritization based on value (value-driven), and the paper includes the method chunk corresponding to the value-driven strategy.

We are in the initial stages of identification of different strategies to achieve identified intentions. Our future work is to select current strategies and create new ones to produce a complete set of chunks that will shape our best practices portfolio.