Agile Requirements Engineering (RE)

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.

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.

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.

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

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

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.

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.

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

[werbung]

Verwendete Quellen anzeigen

[fotolia]