Requirements Engineering meets agility

Agile methods, which are based on iterative development cycles and close collaboration between the team and stakeholders, typically define requirements in less detail than traditional projects. Instead of creating comprehensive requirements specifications, Requirements Engineering focuses on the collection and prioritization of user stories. Accordingly, the RE activity in agile projects isn’t an upstream phase, but a continuous activity that runs parallel to the development process.

1. Don't lose sight of the big picture: a key challenge in agile Requirements Engineering is the lack of a detailed, long-term requirements document. In a traditional project, a detailed requirements specification would serve as a reference, whereas in an agile environment requirements are "alive" and can change regularly. It’s a challenge not to lose sight of the big picture when specifying complex requirements. Helpful techniques here include defining a product vision and structuring the requirements into EPICs, stories and visualizing dependencies and relationships between requirements.

2. Stakeholder engagement: the agile project requires continuous communication with stakeholders. This means regular meetings such as sprint reviews in which the team receives feedback on the developed functions and the requirements can be adapted based on the latest findings.

3. Prioritization and iteration: requirements are collected in the form of user stories and prioritized according to their importance or value. Methods such as the MoSCoW principle (Must have, Should have, Could have, Won't have) help to develop the most needed functions first, which is crucial in agile iterations.

4. User stories and acceptance criteria: the use of user stories with clearly defined acceptance criteria is a proven method for formulating requirements in such a way that they meet both the needs of the stakeholders and the practical implementation requirements. The challenge is to prepare requirements in an appropriate level of detail at the required time in an understandable way.

5. Backlog refinement: a regular "backlog refinement" ensures that the product backlog always contains up-to-date, clear and well-prioritized requirements that are ready for the next sprints. This continuous adjustment process prevents the project from encountering outdated requirements. However, only those requirements that offer the highest added value and therefore have a high priority are worked out in detail. As the specification of requirements is also an integrative process, less value-creating requirements are deliberately left in outline form until their implementation is closer and more details are useful.

6. Reacting flexibly to changes: continuous requirements management in agile projects means that reacting flexibly to changes is also an important component. Instead of going through a change process, as in traditional projects, agile projects can react flexibly and quickly to a change. In some cases, the scope is also changed in an active sprint and the sprint is rescheduled to integrate the change as quickly as possible.

In classic RE, we speak of the following four activities: requirements elicitation, documentation, validation and management. These form the basis for the successful handling of complex requirements. In agile projects, however, the characteristics of these activities differ from classic approaches, as they also need to be adapted to an iterative and flexible way of working.

• Requirements elicitation

In agile projects, requirements are identified continuously and iteratively. Instead of comprehensive workshops or interviews at the beginning of the project, requirements are typically identified during regular meetings such as sprint planning, backlog refinements or through direct exchange with stakeholders. Product increments and sprint reviews also enable quick feedback and can provide new ideas for the product backlog. This activity focuses on the collection of user stories, which can be flexibly supplemented or adapted to take account of new findings.

• Requirements documentation

Instead of a detailed requirements specification, agile projects rely on minimalist and easily adaptable forms of documentation. User stories, EPICs and acceptance criteria serve as the main means of describing requirements. Tools such as Jira help to keep the documentation up to date and accessible to everyone involved. The focus is on keeping the documentation as lean as possible and at the same time sufficiently precise. By working in sprints, it’s also important to cut the requirements in such a way that a user story doesn’t contain more than can be implemented in one sprint - it must be further broken down into smaller stories, if necessary.

• Requirements validation

The validation of requirements in agile projects is iterative and closely interlinked with development. Sprint reviews and automated tests (e.g. acceptance tests) play a central role in ensuring that the requirements are implemented correctly and completely. Stakeholder feedback is essential here to make adjustments at an early stage if necessary and to ensure that the functions developed meet actual needs.

• Requirements management

In agile projects, the management of requirements mainly relates to backlog management. This is an ongoing activity in which the product backlog is maintained and regularly updated. The same applies to the sprint backlog, as it should reflect the actual status of work in the current sprint. In contrast to the product backlog, for which the product owner is responsible, the responsibility for the sprint backlog lies with the team itself. Another component of requirements management, both in traditional and agile projects, is attribute management. This involves enriching requirements with additional information such as status, estimates, priorities and responsibilities. Links to conflicting or dependent requirements are also documented in order to identify conflicts at an early stage and resolve them efficiently. In agile projects, attribute management also supports traceability and facilitates the dynamic adaptation of requirements in the development process.

Requirements Engineering in an agile context requires a more flexible, iterative approach than in traditional projects. By focusing on documentation based on user stories, regular feedback and close collaboration with stakeholders, requirements can be efficiently captured, prioritized and continuously adapted. Despite the challenges posed by the lack of detailed documentation, well-implemented Requirements Engineering can help to implement projects successfully and in a timely manner. It’s crucial that all team members and stakeholders are involved in the agile process to ensure that the requirements always meet the actual needs.

However, it’s also important to note that there are also good reasons for practicing Requirements Engineering as an upstream activity with a comprehensive catalog of requirements. This makes it easier to estimate scope and budget. It’s not possible to make a blanket statement as to which approach is preferable in Requirements Engineering. Rather, the RE techniques and working methods used should always be adapted to the specific circumstances of the project and evaluated individually.