Agile requirements engineering
Requirements and requirements engineering are always needed
Those who equate the requirements specification with the requirements commit the same mistake as those who confuse the hiking map with the landscape. In both cases it is an image omitting irrelevant details.
In every project, no matter which one, it is indispensable to know the requirements of the stakeholders. After all, these requirements must be met. Whether and how they are written down is another question. But you have to know them. There is no doubt that you have to communicate for this purpose.
Eisenhower said about plans: “Planning is everything, plans are nothing”. The same applies to requirements engineering. The most important thing is not the specification that comes out at the end, but the fact that people have talked to each other about the requirements.
And the art of achieving correct, complete and consistent requirements can still be called requirements engineering. Even those who advocate the “abolition” of requirements engineering suggest new terms such as “digital design” (Kim Lauenroth) or “digital business analysis” (Ursula Meseberg). The activity as such is not to be omitted, but to make use of other and additional methods.
Agile requirements engineering in pure form
Even in agile projects, the requirements are determined in order to implement them. Requirements Engineering according to the pure teachings of Scrum works in such a way that as little as possible is written down. The knowledge should exist above all in the heads of the team members. Since everyone communicates regularly with each other in a small circle, user stories or general backlog items are sufficient as a short reminder note for the requirements that have been discussed in detail. A minimum number of attributes such as story points and / or estimated benefits are noted for the user stories. That’s it.
The agile requirements engineering in this form is a very nice ideal picture of what you should at least write down. This means that you should not forget that a certain requirement exists at all, and if you have already done any estimation for it, this work should not get lost. That’s the least we can do.
The limits of agile requirements engineering
But the least is often not enough. After all, the agile way of working is ideal for small teams and for technologies whose complexity is low enough for short iterations. However, some projects require a larger team, extensive architecture planning, analysis of security requirements, or longer-term release planning.
For this reason, methods and principles have been newly developed within the agile world, partly familiar requirements engineering methods in a new guise. Story mapping, for example, is the good old business process analysis with simple means. The specification of requirements on several abstraction levels also returns with an agile name. In addition, there are artifacts such as personas, quality requirements, glossaries and the definition of ready as quality criteria for the review of requirements – pardon: the backlog items.
Order into Chaos: CPRE RE@Agile
In response to the confusing variety of new practices in agile requirements engineering, the IREB (International Requirements Engineering Board) has developed two standards with the title CPRE RE@Agile – the RE@Agile Primer and the Advanced Level RE@Agile – to order the confusing variety of new practices in agile requirements engineering and to select suitable conventional techniques that have proven themselves in agile engineering.
The principle is the same as with the other CPRE standards: they represent a toolbox from which you can make appropriate use if required. Artefacts and techniques are presented and their possible applications discussed. In addition, there is the philosophical background of the whole as well as the discussion of concrete practical questions, in particular the scaling of agile work for larger teams.
It depends …
Now the participants in the training course like to ask me how one knows when which technique and which document are needed. That depends … Offering simple formulas or decision trees would not do justice to the complexity of requirements engineering.
But a plain consideration is easy to apply: You simply think from behind. Who will need which information when? But also: What can be configured from a technical point of view? Since you are always smarter afterwards, a lessons learned analysis after the project makes sense.
A typical special case of requirements engineering is, for example, the customising of standard software. If this software already has its own specific interface design, there is no need to talk about colors and font sizes during requirements engineering. Often a ready-made data model is already available, in which data fields are best renamed. Or the standard process of an order is to be used. Then the requirements engineering can be designed accordingly lightweight by using a demo system of the standard software as prototype and documenting only in free text or a picture where one wants to modify. Complete use case scenarios can be avoided at this point, since not much fun is involved if you first perform a sophisticated process analysis with thorough consideration of usability aspects, and in the end everything looks completely different for technical reasons.
But requirements engineering has always known the problem. When I was still raising the requirements, my rule of thumb for lightweight (non-agile) requirements engineering was: I stop specifying when the programmer nods and says he knows how to implement it. And I create another model when we start talking with our hands and feet or when the whiteboard on the wall is overwhelmed with the complexity of our discussions. Then there was obviously a need for specification, and then I chose the notation that best suited the subject.
Even before agile development was limited to keyword notes, there was a need for lightweight specifications in projects that only wrote as much as was later needed. Confusing diagrams, useless information, and conflicting text were not only unnecessary, but also damaging.
Bottom line
In many cases, the agile requirement specification, limited to the bare essentials, is too simple. As a first attempt, however, these approaches are not wrong at all. Since agility is used to iteratively evaluate and improve one’s working methods anyway, one can notice in the Sprint Review if information, diagrams or activities have been missing. In order to competently select the right practices to solve the observed problem, it is necessary to be familiar with the variety of agile and conventional requirements engineering methods.
Notes:
Here in our t2informatik Blog you can find more articles from her, including
The biggest obstacles in requirements engineering
What prevents creativity in requirements analysis?
7 IT use cases with ChatGPT
Dr Andrea Herrmann
Dr Andrea Herrmann has been a freelance trainer and consultant for software engineering since 2012. She has more than 28 years of professional experience in practice and research.
Dr Herrmann was most recently a deputy professor at Dortmund University of Applied Sciences and Arts, she has published more than 100 specialist publications and regularly gives conference presentations. She is an official supporter of the IREB Board and co-author of the IREB syllabus and handbook for the CPRE Advanced Level Certification in Requirements Management.