Requirements management or requirements engineering describes “the engineering of the requirements for a system; in system analysis related to computer-aided (computer system) operational information systems, in software engineering to software products.” (Gabler Economic Dictionary)
This is a management discipline that is always in demand as agile requirements engineering where complex systems are developed in highly work-sharing processes.
One of the main tasks of requirements engineering is to determine the respective requirement profile – also called requirements analysis – based on the presentation. These identified requirements are further documented. In this context, Agile requirements engineering requires that the team be actively conveyed knowledge. When checking and coordinating the requirements, the RE must demonstrate the correctness of the requirements plausibly and conclusively. Chris Rupp and the SOPHISTen (2014, p. 14) describe the management of requirements as their last core activity. Thus, parts of risk management are also taken into account in this aspect.
Ramesh et al. (2010, p. 456) note that agile RE practices are needed at a time when technologies are changing and evolving rapidly, requirements are becoming more complex and clear time problems predominate. More frequent testing and reviews, constant personal communication with the developers, extreme prioritization result in complex challenges to which no answers are currently found.
- Inspired by Chris Rupp and the SOPHISTen (2014, p. 62), the presentation illustrates the approach of integrating RE into Scrum.
Thus, they provide an alternative to a first approach to integrating RE into Scrum. The principle can be integrated before, during or after the sprint. Thus, during development, the problem of uncertainty can be closely monitored and a more precise, more up-to-date statement can be made about the feasibility of the objective. This makes it possible to adapt the requirements in a timely, targeted manner. An exact application is not yet available in the literature and is currently being evaluated in case studies.
The History of Requirements Engineering
Requirements Engineering is a very young discipline and was first mentioned in earnest at the ICRE conference in 1993. With the emergence of UML, it was first used in IBM’s feature-driven development and later in IBM’s Rational Unified Process. Since 2006, IREB has been working on the professionalization of requirements engineering and since 2013 there have been many publications on the topic of agile requirements engineering.
Requirements Engineering in the Scrum Process
But what exactly does modern and agile RE look like? As we already know, Scrum and agility combine everything in one process. The question therefore arises as to whether, in this case, one can still speak of RE in the classical sense. If we look at what Scrum actually looks like – Baumgärnter et al (2013, p. 3) provide a nice illustration for this – we quickly notice that the position of the “Requirements Engineer” now becomes the role of the Requirements Engineer. This is therefore still an elementary part of the process.
The role of the RE
However, the re’s understanding of roles 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 any role, the RE now has more responsibility and thus more opportunities and opportunities to get involved.
Let’s look up a level and ask ourselves where the Requirements Engineer can be found in the process. In modern processes, it is often replaced by the product owner, but in larger projects and organizations it still exists. The RE can then be found as a specialist department or individual in parallel with the product owner.
Agile Requirements Engineering in the course of the project
How does it work in practice? If we look at the course of a project, we see that usually many requirements engineers are needed at the very beginning, the need for which decreases significantly over the course of the project. In the first interviews, however, we notice that an equal distribution of the requirements engineers over the course of the project should be sought and the normal procedure is not optimal. In the meantime, the Requirements Engineers also estimate the specification effort, plan larger features at the beginning than epics, and therefore provide the possibility of flexible changes to the same. The REs also evaluate the software with the customer at the beginning and remain true to this process until the end. Thus, in the course of observation, I experienced an equal distribution of the discipline of requirements engineering.
Tips for the product owner
Many RE’lers are often made a product owner. But this is a difference from the product owner. But what does he do? I found a definition of this in Boris Gloger’s blog:
The role of product owner is perhaps the simplest role, but so is the role that many people completely misunderstand. The product owner is part of the scrum team. He works with the scrum team. In other words, he is not a demander who lets the team build something, but an integral part. He has a special view of the joint work. He wants the scrum team to deliver only what is valuable – that is, to be bought by the customer. For more information you can look at Boris Gloger’s book on Scrum.
But what can a good product owner do? I have collected a few examples of the character on different websites and list them here:
- represents the product vision
- makes decisions
- knows business models
- shares experiences
- Strong communication
- lives agility
- understands the product
- is there for the team
- can say no
- is an entrepreneur
Genderhinweis: Ich habe zur leichteren Lesbarkeit die männliche Form verwendet. Sofern keine explizite Unterscheidung getroffen wird, sind daher stets sowohl Frauen, Diverse als auch Männer sowie Menschen jeder Herkunft und Nation gemeint. Lesen Sie mehr dazu.
Falls es noch Fragen gibt, können Sie mich gerne anrufen. Hierzu einfach im Buchungssystem nach einen freien Termin schauen. Ich nehme mir jeden Monat einige Stunden Zeit um mit Lesern zu interagieren.
Helfen Sie meinem Blog, vernetzen Sie sich oder arbeiten Sie mit mirSie haben eigene, interessante Gedanken rund um die Themenwelt des Blogs und möchten diese in einem Gastartikel auf meinem Blog teilen? – Aber gerne! Sie können dadurch Kunden und Fachkräfte ansprechen.
Ich suche aktuell außerdem Werbepartner für Bannerwerbung für meinen Blog. Sollte es für Sie spannend sein Fachkräfte oder Kunden auf Ihre Seite zu leiten, dann bekommen Sie mehr Informationen hier.
Vernetzen Sie sich in jedem Fall auf Xing oder LinkedIn oder kontaktieren Sie mich direkt für einen Austausch, wenn Sie gleich mit mir ins Gespräch kommen wollen. Werfen Sie auch einen Blick in meine Buchvorschläge zur Digitalisierung, vielleicht wollen Sie mir auch ein Buch empfehlen?
Ich arbeite gerne mit Unternehmen zusammen. Sie können mich ebenfalls gerne bezüglich folgender Punkte anfragen:
- Halten von Vorträgen zu Arbeit, Führung und Agilität
- Unterstützung Ihres Marketings (z.B Blogartikel)
Verwendete Quellen anzeigen
Baumgartner, M., Klonk, M., Pichler, H., Seidl, R., & Tanczos, S. (2013).
. 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. http://doi.org/10.1111/j.1365-2575.2007.00259.x
Rupp, C. (2014). Requirements engineering and management: From the practice of classic to agile. Munich: Hanser Verlag.