Professionelles Requirements Engineering ist auch bei agilen Vorgehensweisen wie Scrum eine wesentliche Voraussetzung für den Projekterfolg. Doch wie fügt sich, vor allem bei komplexen Entwicklungsprojekten in größeren Unternehmen, die Erhebung, Dokumentation und Verwaltung von Anforderungen in das agile Vorgehensmodell ein? Wie kann das gemeinsam erarbeitete Fach- und Technologiewissen konserviert werden? Die meisten RE-Aktivitäten lassen sich in Scrum wiederfinden oder zwanglos ergänzen. Die Rolle des Requirements Engineers kommt dabei dem Product Owner zu.

Professionelles Requirements Engineering ist (nicht nur) in komplexen Entwicklungsprojekten ein Schlüsselfaktor für den Projekterfolg, unzählige Studien und Erfahrungsberichte wie z. B. der regelmäßige CHAOS-Report belegen das. Die wesentlichen Gründe hierfür liegen in der Vielzahl von Stakeholdern, die unterschiedliche Interessen haben, sowie in komplexen Sachverhalten, die für Einzelne kaum überschaubar sind.

In Scrum, auf das wir uns im Folgenden wegen seiner Verbreitung fokussieren wollen, verwaltet der Product Owner die Anforderungen z. B. in Form von User Stories im Product Backlog. Scrum sagt jedoch nichts dazu aus, wie Anforderungen erarbeitet und qualitätsgesichert werden. Der Scrum Guide [1] sowie einschlägige Literatur [z. B. 2] hält sich zu diesem Thema eher bedeckt. Standardisierungen z. B. vom International Requirements Engineering Board IREB [3] und andere Modelle beschreiben, wie Anforderungen erarbeitet und verwaltet werden, äußern sich aber nicht zur Einbettung des Requirements Engineering in die verschiedenen Vorgehensmodelle zur Softwareentwicklung.

Aber auch ein mit RE-Methoden systematisch erarbeitetes Product Backlog reicht nicht aus, wenn wir den gesamten Lebenszyklus eines Softwareprodukts betrachten. So fällt ein Großteil des Gesamtaufwands in der Wartungsphase – im Sinne der Produktpflege oder Produktweiterentwicklung – an. Manche Anwendungen, z. B. Bestandsführungs- oder Schadensysteme bei Versicherungen, sind zwanzig oder dreißig Jahre in Betrieb, sie stellen einen bedeutenden Vermögenswert des Unternehmens dar. Die ursprünglichen Entwicklungsteams sind dann wahrscheinlich nicht mehr greifbar, das Wissen über die Anwendung und die zugrunde liegenden Anforderungen muss daher dokumentiert und gepflegt werden.

Dieser Artikel beschreibt, wie professionelles Re­quire­ments Engineering in einem Scrum-Projekt erfolgt. Dabei steht die Entwicklung kundenspezifischer Individualsoftware im Vordergrund, nicht Standardsoftware für eine anonyme Nutzergruppe. In diesem Kontext muss der Product Owner häufig eine Vielzahl von Anforderungsgebern aus einem nicht agilen Umfeld mit unterschiedlichen, möglicherweise widersprüchlichen Auffassungen koordinieren.

Der Artikel soll keine Einführung in das Requirements Engineering oder in Scrum sein, stellt jedoch die in diesem Kontext relevanten Aspekte der beiden Vorgehensweisen kurz vor. Unsere Projekterfahrungen zeigen, dass professionelles Requirements Engineering in Scrum-Projekten notwendig und möglich ist [4]. Es erfolgt durch den Product Owner in enger Zusammenarbeit mit dem Entwicklungsteam.

Requirements Engineering nach IREB

Das Requirements Engineering beschreibt die Erhebung, Dokumentation, Abstimmung und Verwaltung von Anforderungen und ihren Änderungen [5]. Der Requirements Engineer

• beschreibt in der Produktvision die Idee und das Ziel der Software sowie ihren Nutzen aus Sicht des Auftraggebers.

• erstellt eine Liste aller relevanten Stakeholder und ihrer Interessen.

• grenzt im Systemkontext das zu erstellende System von seiner Umwelt ab.

• erstellt die Liste der Anforderungen auf einer High-Level-Ebene (d. h. ohne allzu sehr ins Detail zu gehen).

• dokumentiert und spezifiziert alle Anforderungen im Detail.

• lässt jede Anforderung von den betroffenen Stakeholdern prüfen und abstimmen.

• beschreibt und etabliert einen Änderungsprozess für Anforderungen.

Anforderungen beschreiben gewünschte Fähigkeiten oder Leistungen eines Produkts oder Prozesses [6]. Weiterhin empfiehlt IEEE Vorgehensweisen für die Dokumentation und Kriterien für Anforderungen [7]. Die Dokumentation kann natürlichsprachlich und/oder modellbasiert erfolgen. Für die natürlichsprachliche Dokumentation werden häufig Lasthefte oder so genannte Fachkonzepte erstellt, wobei es jedoch schwierig sein kann, aus Prosatext einzelne Anforderungen zu identifizieren. Daher schlagen z. B. Rupp und Pohl eine Satzschablone vor („Das System muss/soll dem <Benutzer> die Möglichkeit bieten, …“). Diese muss in der Regel durch weitere detaillierte Beschreibungen ergänzt werden.

RE-Modelle legen jedoch keinen Entwicklungsprozess fest. Klassisch definieren z. B. Wasserfall- oder ­V-Mo­dell, wann welche RE-Aktivitäten stattfinden. Wie aber sieht das agile Vorgehen aus?

Agile Softwareentwicklung

Die agile Softwareentwicklung basiert auf dem Agilen Manifest [8]. Insbesondere stellt es die direkte Kommunikation über eine umfassende Dokumentation (jedoch ohne eine Dokumentation als solche grundsätzlich abzulehnen).

Die Erfahrung hat uns gezeigt, dass sich durch die Trennung von Analyse und Implementierung komplexe Sachverhalte häufig nicht ausreichend vollständig und mit akzeptablem Aufwand in einer Spezifikation erfassen lassen. Aus Sicht des Requirements Engineering ermöglichen uns agile Vorgehensweisen durch intensive Kommunikation zwischen Anforderungsgeber und Entwickler unklare, unvollständige oder unverstandene Anforderungen an das Produkt zu handhaben, ohne in einer oft langwierigen Analysephase zu versuchen, alle Anforderungen vollständig zu durchdringen (was häufig trotzdem nicht gelingt). Das schnelle Feedback durch frühzeitige und häufige Auslieferungen erlaubt die ständige Anpassung und Optimierung der Anforderungen und schnelle Reaktionen auf geänderte Bedingungen. Aus der direkten Kommunikation am entstehenden Produkt erwächst so das gemeinsame Verständnis der Anforderungen.

Anforderungen und das Backlog in Scrum

In Scrum verwaltet der Product Owner (PO) im Product Backlog Anforderungen aus Nutzersicht, z. B. als User Story: „Als <Nutzer> möchte ich <Tätigkeit>, damit <Nutzen>“ mit Akzeptanzkriterien. Diese werden nach dem INVEST-Prinzip [9] entworfen:

• Independent (unabhängig)

• Negotiable (verhandelbar)

• Valueable (wertorientiert)

• Estimatable (schätzbar)

• Small (klein)

• Testable (testbar)

Auch wenn sich allgemein User Stories durchgesetzt haben, macht Scrum keine Vorgaben zur Beschreibungsform. Falls erforderlich, können z. B. auch fachliche Klassenmodelle, Architekturmodelle, Prozessbeschreibungen oder Mockups dazu gehören. Neben funktionalen Anforderungen lassen sich aber auch Qualitätsanforderungen in Form von User Stories beschreiben („Als Benutzer möchte ich auch bei n parallel arbeitenden Benutzern nach x Sekunden eine Reaktion des Systems erhalten, damit die Kosten des Geschäftsvorfalls …“, „Als Produktentwickler möchte ich, dass neue Produkte mit maximal n Tagen Aufwand in die Software integriert werden können, damit wir Marktführer bleiben.“).

Die Akzeptanzkriterien sind ein wesentlicher Bestandteil der Anforderung: Sie beschreiben die Erwartungen des Anforderungsgebers an die Lösung, die über die kurze User Story hinausgehen. Sie können auch auf weitere Dokumente und Artefakte verweisen.

Probleme im nicht agilen Umfeld

Selten wird Individualsoftware „auf der grünen Wiese“ und für einen einzelnen Stakeholder als PO entwickelt...