Software Engineering:
Requirements engineering for agile teams
As much RE as necessary, as little RE as possible – lightweight in every iteration.
Contact the team
Follow us
What happens to requirements engineering (RE) in the course of an agile transformation?
Is the role of the requirements engineer still needed and how does it relate to the role of the product owner? Does agile RE mean only managing requirements in the form of user stories? How can sufficient documentation be ensured? How do you find good acceptance criteria? And how do artifacts, methods and documents of “classic” RE fit into the picture? You’ll find the answers here!
- We create an understanding of the needs and working methods of future users.
- Lightweight and “just in time”.
- With an eye on the testability of the identified stories and requirements.
Technical article
10 practical tips for product owners
Are you a Product Owner? Or are you planning to become one? Then you may be familiar with the following situation: your company has decided – for whatever reason – to work “agile” in future. Most of the developers are cheering, the testers are nodding knowingly to each other, only the requirements engineers are unusually quiet.
No wonder, because a culture shock is on the horizon: just a moment ago, requirements were collected in comprehensive analysis processes and compiled in extensive documents, and suddenly all that is supposed to be a thing of the past – instead, there are only “boards” on which “stories” are pinned. In future, documentation will be considered the devil’s work, and the only thing that requirements management will take with it into the new world are – of all things, because they were already unpleasant in the pre-agile world – acceptance criteria! Welcome to the agile RE transition!
Agile requirements engineering: the focal points
Our expertise in Requirements Engineering (RE) consists of helping your Product Owner (PO) and your Requirements Engineers to create an understanding in your team of the needs and working methods of the future users.
Stakeholder analyses
Development of user scenarios and user stories
Validation of requirements documents
Establishment of feedback loops
Workshops and training courses
Effective requirements engineering requires a clear understanding of the problem space, including the “what” and “why”. This means that we work with your team to identify and structure the actual needs and challenges of the users. Our method focuses on lightness and agility: requirements are captured and documented “just in time”, i.e. as little as possible and as much as necessary.
Through targeted methodology and continuous feedback loops, we ensure that the team is always up to date and can react flexibly to changes. This not only creates clarity and transparency, but also enables faster adaptation to new requirements and developments. Our aim is to enable the team to develop the best solutions for users while always keeping the big picture in mind.
Understanding the problem space for better solutions
What matters
Testability of the user stories
Right from the start, we focus on the – all too often neglected – testability of the identified stories and requirements. This approach is a unique selling point of QualityMinds.
So if you want to know whether, how much and which RE best supports you in your agile way of working, then you’ve come to the right place.
Workshop example
Requirements Engineering
Improvement
How requirements engineering and an agile approach work together beneficially
In an agile team, the aim of requirements engineering is to create a shared understanding of the product to be developed and its users. The team must first understand the product vision. For example, it can create a product poster with the most important functions, users, partner systems, goals and risks or use the Product Canvas method. The team then needs to understand what the user stories of the next iteration actually comprise. A single user story does not describe all the details that are necessary for development or testing and must be supplemented with testable acceptance criteria.
The 3 most important questions for documenting a user story:
Are there any documents that must be created for this story – for regulatory reasons, for example?
These documents should be part of the “Definition of Done”.
Corresponding tasks should be created during planning.
Are there artifacts – for example a decision table or a process diagram – that would help the team with the implementation?
If so, these artifacts should be created in the refinement.
An artifact poster can be helpful in finding helpful artifacts, on which possible formats, application scenarios and associated test methods are depicted.
If additional artifacts or documents are neither helpful nor necessary, direct communication between the team and the product owner(s) is sufficient.
In this way, only documentation that offers added value is created; at the same time, everything the team needs is available in the sprint.
Consulting
As consultants, we support you and your project on site in the following roles:
→ Product Owner
→ Requirements Engineer
→ Business Analyst
We take on the role responsibly, integrate ourselves into your team in the best possible way and deliver the work results you require “on time & in budget & in quality”.
Coaching
Alternatively, we support your employees who already perform one of these roles and provide a coach for them:
→ Product Owner
→ Requirements Engineers
→ Business Analysts
Our coaches are at your side as sparring partners, experience and knowledge carriers. We can provide your team with effective support, particularly on all topics relating to agile values and procedures.
podcast
How do non-functional requirements and technical stories fit into an agile backlog?
QualityHeroes Podcast Episode 14: This time Christian and Ralph discuss 2 topics that probably come up in every Scrum project and present solutions and concrete tools to answer the question from the podcast title. Have fun with it!
References Requirements Engineering
Some of our satisfied customers
Let’s Swap 24 – Let’s Change Logistics
The requirements were to create a platform that is easy and intuitive for users to use on the one hand, and that offers a complex range of functions such as multilingualism, speed and stability on the other.
DATEV KI-Werkstatt – Shaping the future.Together.
The requirement was to develop responsively designed prototypes for the AI workshop in a very short space of time. The aim was to create a functioning platform in the DATEV cloud on which the applications could be tested and further developed at an early stage of development.
We look forward to your inquiry!
Highly satisfied customers are both our capital and our concern. Do you need support with agile requirements engineering? Then let us clarify how we can help you in a non-binding initial consultation!
