Requirements management or requirements engineering describes “the engineering definition of the requirements for a system; in system analysis related to computer-aided (computer system) business information systems, in software engineering to software products. ” (Gabler Wirtschaftslexikon)

A management discipline that, as agile requirements engineering, is always in demand wherever complex systems are developed in processes that are strongly based on division of labor.

agiles requirements engineering
The main criteria of requirements engineering (own presentation based on the idea of Chris Rupp and the SOPHISTs)

One of the main tasks of requirements engineering is first of all to use the representation to determine the respective requirements profile – also known as requirements analysis. These determined requirements are also documented. In this context, agile requirements engineering requires that knowledge be actively imparted to the team. When checking and coordinating the requirements, the RE must plausibly and conclusively prove the correctness of the requirements. As the last core activity, Chris Rupp and the SOPHISTs (2014, p. 14) describe the administration of requirements. Parts of the risk management are therefore also assigned to this aspect.

More complex requirements require agile RE practices that lead to a variety of challenges. Chart: Ramesh et al. (2010, p. 456)

Ramesh et al. (2010, p. 456) state that in times when technologies change quickly and develop further, requirements are becoming more and more complex and clear time problems prevail, agile RE practices are in demand. More frequent tests and reviews, constant personal communication with the developers, and extreme prioritization result in complex challenges to which no answers can currently be found.

agile anforderungsanalyse scrum
Integration of RE in Scrum (own presentation but inspired by Chris Rupp and the SOPHIST )
The representation inspired by Chris Rupp and the SOPHIST (2014, p. 62) illustrates the approach of integrating RE in Scrum.

These provide an alternative to an initial approach for integrating RE in Scrum. The principle can be integrated before, during or after the sprint. In this way, the problem of uncertainty can be closely observed during development and a more precise, more up-to-date statement can be made about the feasibility of the objective. This provides the possibility of prompt, targeted adaptation of the requirements. A precise application is currently not yet to be found in the literature and is currently being evaluated in case studies.

The history of requirements engineering

Own illustration based on some Google research.

Requirements engineering is still a very young discipline and was first seriously mentioned in 1993 at the ICRE conference. With the emergence of UML, it was used for the first time in feature-driven development and later in IBM’s Rational Unified Process. The IREB has been working on the professionalization of requirements engineering since 2006 and since 2013 there have been many publications on the subject of agile requirements engineering.

Requirements engineering in the Scrum process

agile requirementsengineering
Scrum idea: a process over everything (own representation based on the idea of Tree gardener )

But what exactly does modern and agile RE look like? As we already know, united Scrum and Agility all in one process. The question therefore arises as to whether one can still speak of RE in the classic sense in this case. If we look at what Scrum actually looks like – Baumgärnter et al (2013, p. 3) provide a nice illustration of this – we quickly notice that from the Position of the “Requirements Engineer” now the Role of the requirements engineer becomes. So this is still an elementary part of the process.

The role of the RE

However, the understanding of the role of RE is changing. The requirements engineer is now also a manager within the process. In addition to his usual tasks, he now plans more than before and constantly switches back and forth between the two roles. Like every role, the RE now has more responsibility and thus more opportunities and opportunities to contribute.

agile re
Tasks of the requirements engineer (content own presentation and idea from Baumgartner et al 2013, p. 101)

Let’s look up one level and ask ourselves where the requirements engineer can be found in the process. In modern processes, he is often replaced by the product owner, but he still exists in larger projects and organizations. The RE can then be found as a specialist department or individual person parallel to the Product Owner.

Agile requirements engineering in the course of the project

How does it all work in practice? If we look at the course of a project, we see that a large number of requirements engineers are usually needed at the beginning, and that their need decreases significantly over the course of the project. In the first interviews, however, we noticed that the aim should be to distribute the requirements engineers equally over the course of the project and that the normal procedure is not optimal. The requirements engineers now also appreciate the specification effort, plan larger features at the beginning than epics and therefore ensure the possibility of flexible changes to them. The REs also evaluate the software with the customer right from the start and stay true to this process through to the end. In the course of the observation, I experienced an equal distribution of the discipline of requirements engineering.

agile re anforderung
The necessity in the course of the project, as it should not be (own illustration but inspired by Baumgartner et al. 2013, p. 78)

Tips for the product owner

Many RE’lers are happy to be made product owners. But this is different to the Product Owner. But what does he do? I have this in Boris Gloger’s blog found a definition:

The role of product owner is perhaps the simplest, and yet one that is completely misunderstood by many. The product owner is Part of the scrum team. He works with the scrum team. This means: He is not a requester who lets the team build something, but an integral part. He has a special view of working together. He wants the Scrum team to only deliver what is valuable – that is, what the customer will buy. For more information, please refer to the Book by Boris Gloger on Scrum watch.
But what can a good product owner do? I have gathered a few examples of the character on various websites and list them here:

  • represents the product vision
  • makes decisions
  • knows business models
  • shares experiences
  • Strong in communication
  • exemplifies agility
  • understands the product
  • is there for the team
  • can say no
  • is an entrepreneur


Verwendete Quellen anzeigen

Baumgartner, M., Klonk, M., Pichler, H., Seidl, R., & Tanczos, S. (2013). Agile testing . Munich: Hanser Verlag.

Ramesh, B., Cao, L., & Baskerville, R. (2010). Agile Requirements Engineering Practices and Challenges: an Empirical Study. Information Systems Journal, 20 (5), 449-480.

Rupp, C. (2014). Requirements engineering and management: From practice from classic to agile . Munich: Hanser Verlag.


I blog about the influence of digitalization on our working world. For this purpose, I provide content from science in a practical way and show helpful tips from my everyday professional life. I am an executive in an SME and I wrote my doctoral thesis at the University of Erlangen-Nuremberg at the Chair of IT Management.

By continuing to use the site, you agree to the use of cookies. more

The cookie settings on this website are set to "Allow Cookies" to provide the best browsing experience. If you use this website without changing the cookie settings or click "Accept", you agree to this.