Keywords

1 Business Agility, Requirements, and Tools

Business agility is a very intuitive concept that guides the vision of modern product management and product development. While a single authoritative definition is lacking, the concept is generally associated with the ability to rapidly and systematically adapt to market, environmental, and technological changes (cf. [1]).

Business agility can be viewed as an extension of Lean Startup [2] into established, non-startup business environments: Like in Lean Startup, agile development is the driving force for finding and maintaining viable business models (cf. [3]). Agile development is guided by the ideas of customer value and business value (cf. [4, 5]).

Requirements practices are an important foundation of business agility. Product management uses requirements for capturing market changes and customer demands, and for communicating these to development. Development transforms requirements into new product versions that shall create future business value (see Fig. 1).

Mature development organizations, regardless of whether plan-based or agile, have the capability to continuously improve their management and development practices. For instance, in Scrum the role of the Scrum Master (core task: remove impediments) and the practices Daily Scrum meeting, and Sprint Retrospective serve the purpose of continuous improvement [4].

Fig. 1.
figure 1

The role of requirements in mediating between customer need and business value.

Full size image

Continuous improvement is also key to maintaining business agility and its requirements practices. However, because requirements practices in larger and more complex environments must be tool-based, specific challenges emerge: Since the traditional generations of requirements tools are firmly rooted in plan-based development approaches, there is little guidance and support for the continuous or even agile evolution and improvement of tool-based requirements practices.

This paper wants to contribute to overcoming this limitation. It is a long-term industrial experience report that proposes a new process for evolutionarily improving tool-based requirements practices in a way that supports business agility. The process can be applied for further optimizing work practices on an existing tool platform as well as for introducing a new requirements tool and suitable associated work practices.

The next sections introduce key characteristics of requirements tools, the requirements tools market, and the state of tool-based requirements practices (Sect. 2), propose the process for continuously evolving tool-based requirements practices (Sect. 3) and provide an experience-based justification (Sect. 4). The final section points out conclusions, discusses empirical evidence, and proposes future work (Sect. 5).

2 Requirements Tools

Requirements practices usually require suitable tool support to be effective and efficient. Modern requirements practices therefore encompass the processes and their associated tool support. Both must be considered as a unit (i.e., tool-based requirements practices). The tools most widely used are desktop office applications, in particular text processors and spreadsheet tables. They have severe limitations, namely limited central availability (single point of truth) and little support for versioning and tracing.

Specialized requirements tools are available since the 1990s, first as client/server solutions, later as web applications and now increasingly often as cloud applications (SaaS, Software as a Service). Initially, they supported specification-based requirements management. Most modern tools also support agile requirements workflows. DeGea et al., Wiegers, and Bühne and Herrmann (IREB) provide overviews of the tool market and tool functionality [6,7,8].

The characteristics of the initial client/server tool generation (e.g., huge expensive products, difficult to install and access) still dominate and bias our today’s perception of requirements tools and how we deal with them. This is particularly true for the selection and introduction of requirements tools and tool-based requirements practices.

Figure 2 shows a typical tool selection and introduction process as it can be found across industry and in the literature (cf. [6,7,8]). It is built on the comparative evaluation of several candidate tools, in a two-step process (longlist and shortlist evaluation), usually involving checklist scoring, vendor demos, open trial-uses, and vendor-driven proofs of concept (PoC). The selection processes can last many months, sometimes up to a few years. The associated requirements work practices are often based on the vendors’ blueprints, with the later users involved very little into process design. As consequences, effective tool-based requirements practices are still rare. Their contributions to business agility fall far short of what would be possible.

Fig. 2.
figure 2

A typical traditional requirements tool selection process.

Full size image

Today’s tool generation allows for new requirements work practices and for more efficient evolutionary improvement approaches: Cloud applications can be accessed very easily for trial-usage. Powerful administration functionality and cloud and virtualization technology allow for easily switching between different candidate solutions. These developments enable new ways for designing and deploying tool-based requirements practices. The following section proposes such a process.

3 Continuously Evolving Tool-Based Requirements Practices

A process for evolving tool-based requirements practices must be iterative, staged, focused, and collaborative: Sufficiently small iterations foster rapid progress and alignment, reduce risk of failure, and fit with Agile. Stages allow for controlled addition of complexity. Focus through objectives and scope gives success criteria and alignment. Collaboration reduces overhead, supports alignment, and, again, fits in well with Agile.

The proposed process has five steps: Prepare, Prototype, Pilot, Introduce/Roll out, and Use/Apply (see Fig. 3). Table 1 describes the activities of each step, their results, and the key actors involved. The actors are:

Core Team: The persons running the improvement project. The group should be small and include all relevant perspectives, usually: Requirements experts (i.e., methods, processes), tool experts (i.e., how to best support practices by the given tool), and stakeholder experts familiar with the application contexts of the practices and tools (e.g., product managers, business analysts, or IT operations managers).

Fig. 3.
figure 3

Evolutionary improvement of tool-based requirements practices: Process overview.

Full size image

Sponsor: The persons who have a key interest that the improved solution becomes available, and who provide the needed budget and organizational support.

Key Stakeholders: A focus group of persons from the target group that shall later apply the improved tool-based requirements practice, and who actively support the development of the solution.

Pilot Stakeholders: A focus group of persons from the later application stakeholders who are willing in trial-using the new solution. Pilot stakeholders should not be key stakeholders in order to be unbiased.

Figure 3 shows the main feedback and iteration relations. Usually, the steps are conducted in sequence, with as many small internal iteration cycles as needed. Feedback occurs mainly from the Prototype and Pilot steps, if the solution turns out not sufficiently mature or ineffective. Then even the entire project may be stopped.

Once the pilot has been successful, the solution will eventually be made available for common application. Additional adjustments can mostly be made without larger intervention. In larger endeavors, like the introduction of a new tool platform, the entire process may be iterated multiple times with increasing scopes.

Table 1. Evolutionary improvement of tool-based requirements practices: process details.
Full size table

4 Experiences and Justification of the Approach

The process has been developed gradually over many projects in various organizations. It shall make this experience available for future improvement projects. Also many additional observations and experience reports from third parties were included. A detailed systematic substantiation of the process cannot be given in this short experience report. However, the following two example cases illustrate how the process was derived and justified, and how it can be conducted in practice.

The first example is a smaller-scale improvement of a tool-based requirements practice. It took place within the established tool-based requirements workflow for the development of large software-controlled high-tech machinery. Sometimes engineers tended to overlook requirements status updates (e.g., from Defined to Approved for Implementation). It was decided that requirements status transitions should be marked in the tool-internal comments thread of each requirement. Initial research (Prepare phase) showed that a ready-to-use solution did not exist (e.g., neither a tool configuration option nor a third-party plug-in). However, a custom workflow script could be implemented easily. It was developed in a sandbox project and tested successfully (Prototype phase). Pilot application happened in the productive tool environment under special supervision by the core team. The change was soon released for general use. The entire improvement project was conducted within two weeks.

The second example is a large-scale substitution of an established tool-based requirements process by a new tool from the latest tool generation and with advanced work practices. It happened at a large global product division in the semiconductor industry, with several hundred development staff, over a period of about 1.5 years. The core team included persons from the established requirements management team and the requirements tool’s product owner from IT operations.

Each step from the improvement process above could be identified, involving several sub-steps and taking several months. For instance, the Prepare step included a systematic study of future tool performance. Prototyping involved the design of new tool-based practices across various workshops with key stakeholders like marketing, requirements, and architecture. Pilot projects tested the new practices and tried the highly critical migration approach. Roll out included comprehensive training activities.

The entire improvement project progressed in a well-controlled manner. The new tool and the new tool-based requirements practices received high acceptance.

5 Conclusions, Evidence, and Future Work

The main conclusions from developing and using the proposed process are: Tool-based requirements practices can be evolved and improved continuously in ways that align well with the iterations and improvement practices of agile methods. Product organizations can strengthen their capabilities to react to market trends and customer demands by continuously advancing tool-based requirements practices. This potentially increases the business value of the organization’s products and fosters its business agility.

The process has been presented here as a long-term industrial experience report. Basic substantiation has been provided by two example application cases. Many similar projects influenced the design of the process since the early 2000s until mid 2023. They took place in a wide variety of contexts: Product organizations and internal IT, from small teams to divisions of large corporations, hardware/software products as well as marketed software applications. The author of this experience report was mostly involved in the role of a consultant (i.e., a typical position to provide tool-based guidance and support). So, method development has been performed as a kind of action research. Author bias may have been mitigated, because projects were conducted in teams, and various stakeholders strongly influenced the projects’ processes. Experience reports from other sources were considered, too. For instance, the incremental, staged approach by Rathod, Cebulla and Kugele [9] using which they developed advanced requirements traceability support can be mapped fully on the proposed process.

Future work shall be conducted for systematically substantiating the proposed process. It should also investigate in more detail how the evolutionary improvement of tool-based requirements practices advances agile development effectiveness and business agility. Derived experiences shall be integrated into future versions of the process, in order to provide additional and more detailed methodological support and guidance.