Immer häufiger wird eine agile gegenüber einer klassischen Projektmethodik bevorzugt. Doch welchen Einfluss hat die gewählte Methodik auf das Requirements Engineering und auf welche Besonderheiten sollte während des agilen Anforderungsprozesses geachtet werden?

 

Klassisches Requirements Engineering

Bei klassisch geführten Projekten und dem klassischen Requirements Engineering steht vor der Realisierung der gesamte, vollständig dokumentierte und abgenommene Umfang der Produktanforderungen bereit. Entlang dieser Anforderungen wird das Produkt entwickelt, getestet und eingeführt. Änderungen an der Anforderungsbasis werden dabei nur bei grossen Differenzen vorgenommen und haben oft eine grosse Auswirkung auf die Projektkosten oder die Projektdauer. Kleinere Änderungen oder Optimierungen werden zurückgestellt und in einem Folgeprojekt bearbeitet.

Klassisches Requirements Engineering

Abbildung 1: Requirements Engineering im klassischen Projektmanagement

 

Agiles Requirements Engineering

Bei agil geführten Projekten und dem agilen Requirements Engineering stehen vor der Realisierung noch nicht alle bis ins Detail spezifizierten Anforderungen zur Verfügung. Die für den kommenden Sprint relevanten Anforderungen werden jedoch bis zum Sprintbeginn genau in der für die Realisierung erforderlichen Detailtiefe vorbereitet.

Agiles Requirements Engineering

Abbildung 2: Requirements Engineering im agilen Projektmanagement

 

Agiler Requirements Engineering-Prozess

Um einen möglichst grossen Mehrwert aus dem in Abbildung 3 dargestellten Requirements Engineering-Prozess herauszuholen, sollten die 5 zentralen Erfolgsrezepte für agiles Requirements Engineering beachtet werden.

Agiles Requirements Engineering

Abbildung 3: Agiler Requirements Engineering-Prozess nach IREB

 

Die 5 zentralen Erfolgsrezepte für agiles Requirements Engineering

 

  1. Prüfen Sie für die Abnahme des initial definierten Produkt-Backlogs und noch vor dem Start der ersten Entwicklungsiteration, ob alle kritischen Anforderungen aufgenommen wurden und die Prioritäten stimmen!Anforderungen, welche eine grosse Auswirkung auf die Systemarchitektur, die Beschaffung von Hardware und Infrastruktur oder auf die generelle Realisierbarkeit der Lösung haben, müssen noch vor dem Start genügend klar definiert sein. Anforderungen mit geringeren Auswirkungen können zu einem späteren Zeitpunkt noch verfeinert werden.Stellen Sie sicher, dass der Umfang des Minimum Viable Product festgelegt und die Priorisierung des Backlogs darauf ausgerichtet ist.

 

  1. Legen Sie den Detaillierungsgrad der Backlog-Items gezielt fest!Je detaillierter ein Backlog-Item beschrieben wurde, desto kleiner sind der Entscheidungsspielraum und die mögliche Kreativität des Entwicklungsteams. Besitzt das Team das nötige Know-how um fehlende Details zu ergänzen, so sollte dem Team diese Entscheidungskompetenz auch überlassen werden.

 

  1. Detaillieren und validieren Sie Backlog-Items, bevor diese dem Sprint Backlog zugewiesen werden!Wurden die Backlog-Items bereits vor der Entwicklung von den entsprechenden Stakeholdern validiert, so können unnötige Entwicklungsaufwände vermieden werden. Ansonsten besteht die Gefahr, dass Fehler erst beim Test der bereits entwickelten Software entdeckt werden. Besonders bei Backlog-Items mit hohen Risiken, grossen Abhängigkeiten oder hohen Testkosten kann dies zu spürbaren Mehrkosten führen. Nutzen Sie bekannte Instrumente um beispielsweise Anforderungen an die Benutzeroberfläche mittels Mock-Ups greifbarer zu machen, noch bevor diese auf Basis von textuellen Anforderungen umgesetzt wurden.

 

  1. Schätzen Sie ab, welche Auswirkungen ein Feedback haben könnte, bevor das Backlog aktualisiert wird!Feedbacks der Stakeholder zum entwickelten Produktinkrement bringen häufig auch eine Aktualisierung des Backlogs mit sich. Dies funktioniert für detaillierte Anforderungen mit kleiner oder abschätzbarer Abhängigkeit sehr gut. Es ist jedoch nicht ratsam, dass komplexe Anforderungen mit teilweise unbekannten Abhängigkeiten kurzfristig und ohne zusätzliche Abklärungen geändert werden.

 

  1. Legen Sie die Dauer des Entwicklungszyklus bewusst fest!Die Dauer des Entwicklungszyklus beeinflussen sowohl die Requirements Engineering-Arbeiten, welche mindestens an den für den nächsten Sprint vorgesehenen Backlog-Items vorgesehen sind, als auch die Häufigkeit, in denen Stakeholder mit neuen Arbeitsergebnissen konfrontiert werden und diese beurteilen und prüfen müssen.Es sollte berücksichtigt werden, dass ein kürzerer Entwicklungszyklus zwar die Möglichkeit für Feedback erhöht und damit Fehler und Verbesserungen schneller erkannt werden, dies aber gleichzeitig auch höheren Druck auf das Entwicklungsteam und grössere Aufwände seitens der Stakeholder bedeutet.

 

Experten in Requirements Management und Engineering

Als Experten im Thema Requirements Management und Engineering unterstützen wir Sie bei der Aufnahme, Dokumentation und Verwaltung Ihrer Anforderungen sowohl in einem agilen, wie auch in einem klassischen Projektsetup. Kontaktieren Sie uns vor Ihrem nächsten Projekt.

Auf welche typischen Stolpersteine Sie beim agilen Requirements Engineering besonders achtgeben müssen, erfahren Sie im nächsten Blogbeitrag unserer Serie «Xperts in Requirements Engineering».

 

Jean-Marc Riser

Jean-Marc Riser

Senior Technical Consultant

 jean-marc.riser@valion.ch

David Meier

David Meier

Technical Consultant

 david.meier@valion.ch

Stefanie Schütz

Stefanie Schütz

Senior Consultant

 stefanie.schuetz@valion.ch

David Winkler

David Winkler

Senior Technical Consultant

 david.winkler@valion.ch

Share This