One week ago today, 10 October 2019, we were represented with a presentation at the ModernRE in Berlin.
In our presentation entitled “Tools in (agile) Requirements Management – The Agony of Choice” we wanted to show which types of tools can be used in (agile) Requirements Management and which different added values they enable.
We started the presentation by showing why people basically need tools at all. On the one hand tools can enable us to do something we cannot do by nature (e.g. a helicopter or airplane helps us to fly), on the other hand tools allow us to do something better / easier / faster than would be possible without tools. So by nature we can move on earth without any problems, but a car allows us to get to distant destinations much faster and more comfortable.
Typical improvements in requirements management
We then quickly directed the presentation towards the purpose of tools in the requirements management environment. In order to be able to classify and evaluate different tools, we first created a matrix that shows 12 typical improvements with regard to requirements management. The rows of the matrix represent the four main activities of requirements management, i.e. determination, documentation, review and administration, while the columns represent the improvement areas result & quality, time & costs as well as simplicity & controllability.
In sum, we have derived the following improvement (without claiming completeness)
- Fewer important requirements are overlooked and fewer “wrong” requirements are raised
- Fewer working hours are required to determine an appropriate set of requirements
- Participants find it easier to identify requirements in a targeted manner
- More requirements are formulated precisely and completely
- Fewer hours of work are required to create a usable requirements document
- Participants find it easier to adequately write down requirements
- Fewer errors in the requirements are overlooked
- Fewer working hours are required to reliably check requirements
- Participants find it easier to find errors in the requirements
- More requirements are up to date and their dependencies are clear
- Fewer working hours are required to maintain the current status of requirements and their dependencies
- Participants find it easier to keep track of requirements even in large and possibly distributed projects
“Wrong” tools are widespread
Based on this list, we then formed our impression that when selecting a tool for (agile) requirements management, these objectives are often neglected. For years now, a Gartner study has shown that 40-50% of all companies use wrong (i.e. inadequate) tools for requirements management and over 30% of product managers are not even aware of the existence of specialized RE/RM tools.
From our own (sales) experience, we have added typical answers from people we often hear when responding to a or our RM tool:
- “We already have XYZ in house” (Note: which is usually not a RE/RM tool)
- “People don’t want to learn a new tool.”
- “Area A or Company B is also working with XYZ.”
- “It works the same way.”
Consequently, we get the impression that when selecting a tool for one’s own requirements management, the basic problem of requirements management, which one actually tries to avoid by requirements management, often comes into play. Namely: One knows what one wants, but not what one actually needs (and usually also not, what is possible).
Too often companies seem to be trapped in how they want to work or what is there or given. As known from best practices of requirements management, however, it would be much more important to break away from it in order to question what one actually wants to achieve.
The WHY decides, not the HOW
In the lecture we then referred to the Golden Circle by Simon Sinnek. In his well-known book “Start with why”, Sinnek had shown that successful companies focus on the “why” in their actions and align their actions with it (and not on how or what).
Applied to tooling in the area of requirements management, in our opinion companies should rather focus on the question “which tool they need to achieve what they actually want” instead of looking at “which tool they need to be able to work in such a way”.
After this longer basic motivation we then went into the different types of tools that are used within the framework of requirements management. Our goal was not to present the individual tools in detail, but rather to work out their differences and to show which of the above mentioned improvement goals in requirements management they can contribute to (please refer to our blog entry “What makes ReqSuite® so special” for a discussion of the individual tools).
We were able to show that the tool types popular in (agile) requirements management, such as wikis and issue tracking systems, do not in fact make a significant contribution to the actual improvement goals that many companies have, and today only advanced RM tools (i.e. those with AI-based assistance) are actually able to achieve significant added value here. (Note: This of course does not mean that the other tools have no benefit, but they have little benefit for the improvements mentioned above.)
It helps to question tooling
However, since it cannot be ruled out that other tool types are also appropriate in the given company context, we as “Take Away” have given the listeners the opportunity to question their tooling by means of simple guiding questions, which we will illustrate below with a small example.
- What are their real improvement goals in terms of requirements management or development in general?
- Example: “We want to be able to deliver a new version every 3 months”.
- What are the circumstances with regard to the requirements that make it difficult for you to achieve these goals?
- Example: “We lose a lot of time because requirements are unclear and have to be clarified first”.
- What concrete improvements do you consider necessary?
- Example: “We want to increase the quality of the requirements directly when they are recorded”.
- Which tool offers active support for this?
- Example: “We need an advanced tool such as ReqSuite® RM, which includes an automatic audit”.
Of course, and we emphasized this several times in our presentation, there is another way, i.e. you can try to compensate missing features in tools by (good) people. The question, however, is whether this is efficient and scalable or not, or whether it torpedoes the objectives that were actually set with agility.
AI vs. Agile – When does this contradiction resolve?
On this conference day there were two more presentations on “AI in Requirements Management”, which underlines that we are no longer alone with our idea of “advanced RM tools”. Rather, such tools seem to be on the rise for a good reason, which, however, still sounds like a glaring contradiction due to the widespread use of informal tools.
It therefore remains exciting to observe whether agile requirements management will continue to be automatically equated with tools such as JIRA and Confluence, or whether there will be a rethink that can demonstrably lead to significant improvements.