Software Engineering:
Requirements Engineering für agile Teams
So viel RE wie nötig, so wenig RE wie möglich – Leichtgewichtigkeit in jeder Iteration.
Kontaktiere das Team
Folge uns
Was passiert im Zuge einer agilen Transformation mit dem Requirements Engineering (RE)?
Wird die Rolle des Requirements Engineers noch gebraucht und in welcher Beziehung steht sie zur Rolle des Product Owners? Bedeutet agiles RE, Anforderungen nur noch in Form von User Stories zu verwalten? Wie wird eine ausreichende Dokumentation sichergestellt? Wie findet man gute Akzeptanzkriterien? Und wie passen Artefakte, Methoden und Dokumente des “klassischen” RE ins Bild? Bei uns findest du Antworten!
- Wir schaffen Verständnis über die Bedürfnisse und die Arbeitsweise der späteren Nutzer.
- Das leichtgwichtig und „just in time“.
- Mit der Testbarkeit der identifizierten Stories und Requirements im Blick.
Fachartikel
10 Praxistipps für Product Owner
Du bist Product Owner? Oder hast vor, einer zu werden? Dann kennst du vielleicht folgende Situation: Deine Firma hat – aus welchen Gründen auch immer – beschlossen, künftig “agil” zu arbeiten. Die EntwicklerInnen jubeln mehrheitlich, die TesterInnen nicken sich wissend zu, nur die Requirements Engineers verhalten sich ungewöhnlich still.
Kein Wunder, denn ein Kulturschock steht ins Haus: Eben noch wurden Anforderungen in umfassenden Analyse-Prozessen erhoben und in umfangreichen Dokumenten versammelt, und auf einmal soll das alles der Vergangenheit angehören – stattdessen gibt es nur noch “Boards”, auf denen “Storys” angepinnt werden. Dokumentieren gilt künftig als Teufelszeug, und das einzige, was vom Anforderungsmanagement in die neue Welt mitgenommen wird, sind – ausgerechnet, denn die waren schon in der vor-agilen Welt unangenehm – Akzeptanzkriterien! Willkommen in der agilen RE-Transition!
Agiles Requirements Engineering: die Schwerpunkte
Unsere Expertise im Requirements Engineering (RE) besteht darin, deinem oder deiner Product Owner:in (PO) und deinen Requirements Engineers dabei zu helfen, in deinem Team Verständnis über die Bedürfnisse und die Arbeitsweise der späteren Nutzer zu schaffen.
Stakeholder-Analysen
Entwicklung von Nutzerszenarien und User Stories
Validieren von Anforderungsdokumenten
Etablierung von Feedback-Schleifen
Workshops und Schulungen
Ein effektives Requirements Engineering erfordert ein klares Verständnis des Problemraums, einschließlich des „Was“ und „Warum“. Dies bedeutet, dass wir gemeinsam mit deinem Team die tatsächlichen Bedürfnisse und Herausforderungen der Nutzer identifizieren und strukturieren. Unsere Methode setzt dabei auf Leichtgewichtigkeit und Agilität: Anforderungen werden „just in time“ erfasst und dokumentiert, also so wenig wie möglich und so viel wie nötig.
Durch gezielte Methodik und kontinuierliche Feedbackschleifen stellen wir sicher, dass das Team stets auf dem neuesten Stand ist und flexibel auf Veränderungen reagieren kann. Dies schafft nicht nur Klarheit und Transparenz, sondern ermöglicht auch eine schnellere Anpassung an neue Anforderungen und Entwicklungen. Unser Ziel ist es, das Team zu befähigen, die besten Lösungen für die Nutzer zu entwickeln und dabei stets das große Ganze im Blick zu behalten.
Verstehen des Problemraums für bessere Lösungen
Worauf es ankommt
Testbarkeit der User Stories
Dabei haben wir von Anfang an die – viel zu oft vernachlässigte – Testbarkeit der identifizierten Stories und Requirements im Blick. Dieses Vorgehen ist ein Alleinstellungsmerkmal von QualityMinds.
Wenn du also wissen möchtest, ob, wie viel und welches RE dich bei deiner agilen Arbeitsweise am besten unterstützt, dann bist du bei uns genau richtig.
Workshop Beispiel
Requirements Engineering
Improvement
Wie Requirements Engineering und agiles Vorgehen nutzbringend zusammenarbeiten
In einem agilen Team ist das Ziel von Requirements Engineering das Erzeugen eines gemeinsamen Verständnisses über das zu entwickelnde Produkt und dessen Nutzer:innen. Das Team muss zunächst die Produktvision verstehen. Dafür kann es beispielsweise ein Produkt-Poster mit den wichtigsten Funktionen, Usern, Partnersystemen, Zielen und Risiken entwerfen oder die Methode Product Canvas nutzen. Anschließend muss das Team verstehen, was die User Stories der jeweils nächsten Iteration konkret umfassen. Eine einzelne User Story beschreibt dabei nicht alle Details, die für Entwicklung bzw. Test nötig sind, und muss um testbare Akzeptanzkriterien ergänzt werden.
Die 3 wichtigsten Fragen zur Dokumentation einer User Story:
Gibt es Dokumente, die – etwa aus regulatorische Gründen – für diese Story zwingend erstellt werden müssen? Diese Dokumente sollten Teil der „Definition of Done“ werden. Während des Plannings sollten entsprechende Tasks erstellt werden.
Gibt es Artefakte – zum Beispiel eine Entscheidungstabelle oder ein Prozessdiagramm – die dem Team bei der Realisierung helfen würden? Wenn ja, sollten diese Artefakte im Refinement erstellt werden. Eine Hilfe beim Finden hilfreicher Artefakte kann ein Artefakt-Poster sein, auf dem mögliche Formate, Einsatzszenarien und zugehörige Testmethoden abgebildet sind.
Wenn zusätzliche Artefakte oder Dokumente weder hilfreich noch notwendig sind, genügt direkte Kommunikation zwischen dem Team und dem oder der Product Owner. So entsteht nur Dokumentation, die einen Mehrwert bietet; gleichzeitig liegt im Sprint alles vor, was das Team benötigt.
Consulting
Als Consultants unterstützen wir dich und dein Projekt vor Ort in folgenden Rollen:
→ Product Owner
→ Requirements Engineer
→ Business Analyst
Wir übernehmen die Rolle verantwortlich, integrieren uns bestmöglich in dein Team und liefern „in time & in budget & in quality“ die von dir benötigten Arbeitsergebnisse.
Coaching
Alternativ dazu unterstützen wir deine Mitarbeiter:innen, die eine dieser Rollen bereits ausüben, und stellen einen Coach für:
→ Product Owner
→ Requirements Engineers
→ Business Analysts
Als Sparringpartner, Erfahrungs- und Wissensträger stehen unsere Coaches dir zur Seite. Insbesondere zu allen Themen rund um agile Werte und Vorgehensweisen können wir dein Team wirksam unterstützen.
podcast
Wie passen nicht-funktionale Requirements und technische Stories in ein agiles Backlog?
QualityHeroes Podcast Folge 14: Christian und Ralph diskutieren dieses Mal 2 Themen, die vermutlich in jedem Scrum-Projekt auftauchen, und präsentieren Lösungen und konkrete Hilfsmittel zur Beantwortung der Frage aus dem Podcast-Titel. Viel Spaß dabei!
Referenzen Requirements Engineering
Einige unserer zufriedenen Kunden
LETSSWAP24 – Let’s Change Logistics
Die Anforderungen waren eine Plattform zu schaffen, die einerseits für die Nutzer:in leicht und intuitiv zu bedienen ist und die andererseits eine komplexe Funktionsbandbreite aufweist, wie Mehrsprachigkeit, Schnelligkeit und Stabilität.
DATEV KI-Werkstatt – Zukunft gestalten. Gemeinsam.
Die Anforderung war, in sehr kurzer Zeit responsiv gestaltete Prototypen für die KI-Werkstatt zu entwickeln. Dabei sollte eine funktionierende Plattform in der DATEV-Cloud realisiert werden, auf der die Anwendungen in einem frühen Entwicklungsstadium getestet und weiterentwickelt werden können.
Wir freuen uns auf deine Anfrage!
Hochzufriedene Kund:innen sind unser Kapital und Anliegen zugleich. Du brauchst Unterstützung im agilen Requirements Engineering? Dann lass uns in einem unverbindlichen Erstgespräch klären, wie wir dir helfen können!
