Autor: Stan Bühne
Auch in einer immer agiler werdenden Welt sind die Grundprinzipien für gutes Requirements Engineering (RE) nach wie vor relevant, da am Ende eines jeden Entwicklungsprozesses das Ziel steht, ein gutes Produkt zu entwickeln. Dies führt immer über ein gemeinsames Verständnis. Requirements Engineering wird oft synonym zu einem planbasierten Vorgehen verstanden. Das ist aber nicht der Fall: Denn selbst in planbasierten Vorgehensmodellen wie dem Wasserfall- oder V-Modell ist der RE-Prozess meist agil und iterativ, da sich Anforderungen an komplexe Systeme verändern oder sich neue Prioritäten ergeben – vor allem dann, wenn das Problem mit der Zeit besser verstanden wird. In diesem Artikel sollen neun grundsätzliche Prinzipien für gutes Requirements Engineering vorgestellt werden, die prozessagnostisch sind und sowohl im agilen als auch im planbasierten Umfeld ihre Bedeutung haben.
Prinzip 1: Gutes Requirements Engineering ist wertorientiert und kein Selbstzweck
Zu Beginn einer Requirements Engineering-Aktivität sollte man sich Gedanken zu Kosten und Nutzen machen, sowohl im agilen als auch im planbasierten Umfeld. Der Wert einer Anforderung ist gleich ihrem Nutzen abzüglich der Kosten für das Ermitteln, Dokumentieren, Validieren und Verwalten der Anforderung. Doch was versteht man unter Nutzen? Der Nutzen einer Anforderung stellt den Grad dar, in dem die Anforderung dazu beiträgt:
- … ein System zu bauen, das die Wünsche und Bedürfnisse der Stakeholder erfüllt.
- … das Risiko von Fehlschlägen und kostspieligen Nacharbeiten zu verringern
Für jedes System, Teilsystem und jede Anforderung sollte man sich die Frage stellen: Wie klar, offensichtlich und allgemein verständlich ist die Anforderung und welches Risiko gehe ich ein, wenn ich diese nicht in allen Details spezifiziere und damit gewisse Freiheitsgrade in der Umsetzung gebe?
Prinzip 2: Gutes Requirements Engineering befriedigt die Wünsche und Bedürfnisse der Stakeholder
Beim Requirements Engineering geht es darum, die Wünsche und Bedürfnisse aller relevanten Stakeholder zu verstehen. Deshalb ist der richtige Umgang mit den Stakeholdern eine Kernaufgabe des REs. Im Kontext des zu errichtenden Systems hat jeder Stakeholder eine Rolle. Dies kann z.B. die Rolle des/der BenutzerIn, KundIn, AuftraggeberIn, BetreiberIn oder der Regulierungsbehörde sein. Auch kann ein Stakeholder mehrere Rollen gleichzeitig ausüben.
Die Einbeziehung der richtigen Personen in die entsprechenden Stakeholder-Rollen ist für ein erfolgreiches RE von entscheidender Bedeutung. Werden wesentliche Stakeholder-Rollen vernachlässigt oder übersehen, kann dies den kompletten Stopp eines Produktes bedeuten. Werden bspw. die Logistiker in einem Onlineshop-Projekt nicht ausreichend miteinbezogen und der aktuelle Lagerbestand sowie Lieferprozess nicht hinreichend berücksichtigt, kann dies starke Auswirkungen auf die Customer Experience haben.
Eine weitere zentrale Aufgabe des Requirements Engineers ist es, regelmäßig mit den unterschiedlichen Bedürfnissen und Standpunkten sowie konträren Anforderungen der Stakeholder umzugehen. Was unter Umständen zu Konflikten führen kann. Um also die Bedürfnisse aller relevanten Stakeholder zu erfüllen, ist es die Aufgabe des Requirements Engineers, diese Konflikte zu identifizieren und zu lösen.
Prinzip 3: Gutes Requirements Engineering sorgt dafür, ein gemeinsames Verständnis zu erreichen
Gutes RE fördert und sichert ein gemeinsames Verständnis zwischen allen beteiligten Parteien: Stakeholdern, Requirements Engineers, ArchitektInnen, UX-DesignerInnen, EntwicklerInnen und TesterInnen. Doch was bedeutet es, ein gemeinsames Verständnis zu erlangen? Wir unterscheiden zwei Arten von gemeinsamem Verständnis:
- Explizites gemeinsames Verständnis: Dieses wird beispielsweise durch exakt dokumentierte und vereinbarte Anforderungen erreicht.
- Implizites gemeinsames Verständnis: Dieses basiert auf einem gemeinsamen Wissen über Bedürfnisse, Visionen, Kontext usw.
Erfolgsfaktoren für ein gemeinsames Verständnis können ein gemeinsames Domänenwissen, eine frühere erfolgreiche Zusammenarbeit, eine gemeinsame Kultur und Werte sowie gegenseitiges Vertrauen sein. Geografische Distanz, Outsourcing und große Teams mit hoher Fluktuation stellen hingegen oftmals Hindernisse für ein gemeinsames Verständnis dar. Übrigens fällt der Umfang der Anforderungsdokumentation in agilen Umgebungen häufig geringer aus als in planbasierten Umgebungen, da agile Teams räumlich zusammensitzen und im Rahmen von Refinement-Sessions Anforderungen diskutieren und so ein explizites gemeinsames Verständnis aufbauen.
Praktiken zur Erzielung eines gemeinsamen Verständnisses
Bewährte Praktiken zur Erzielung eines gemeinsamen Verständnisses sind insbesondere eine intensive Kommunikation, aber auch die Erstellung von Glossaren, Prototypen oder die Verwendung eines bestehenden Systems als Bezugspunkt. Um objektiv bewerten zu können, ob ein gemeinsames Verständnis vorliegt, hilft es, konkrete Beispiele heranzuziehen, welche als Vorlage für die erwarteten Ergebnisse, Untersuchung von Prototypen oder Schätzung der Kosten für die Umsetzung einer Anforderung dienen. Im agilen Umfeld wird dies im Rahmen von Planning Sessions durchgeführt. Unabhängig vom Vorgehensmodell sollten regelmäßig kurze Rückkopplungsschleifen stattfinden, um die Auswirkungen von Missverständnissen zu verringern.
Prinzip 4: Gutes Requirements Engineering berücksichtigt den Kontext, in dem ein System existiert
Da Systeme immer in einen größeren Kontext eingebettet sind, ist es ohne Verständnis über diesen Kontext nahezu unmöglich, ein System richtig zu spezifizieren. Beim Requirements Engineering ist der Kontext eines Systems der Teil der Systemumgebung, der für das Verständnis des Systems und seiner Anforderungen relevant ist.
Abb. 1: Grafische Darstellung von System, Systemkontext und Systemumgebung, Quelle: IREB®
Systemgrenzen definieren
Die Systemgrenze ist die Grenze zwischen dem gewünschten System und seinem umgebenden Kontext. Anfangs ist diese Systemgrenze oft unklar und wird oft von einer Art “Grauzone” umgeben, die sich im Laufe der Zeit auflöst und das System immer klarer von seinem Kontext abgrenzt.
Die Klärung der Systemgrenze und die damit verbundene Definition der externen Schnittstellen zwischen dem System und dem Systemkontext sind Kernaufgaben des Requirements Engineers. Zu den wichtigsten Zielen gehört es, herauszufinden und zu definieren, welche anderen Systeme aus dem Kontext mit dem gewünschten System interagieren sowie welche Systembenutzer mit dem gewünschten System direkt und indirekt interagieren.
Mit der Festlegung der Systemgrenze wird gleichzeitig der Umfang des Systems bestimmt. Um nicht die gesamte Welt als Kontext zu betrachten, ist es wichtig, den relevanten Kontext so früh wie möglich abzugrenzen (Kontextgrenze). In klassischen Anforderungsdokumenten kann dafür ein eigenes Kapitel in der Spezifikation genutzt werden, um sowohl das System als auch den Kontext über eindeutige Einschränkungen und Annahmen abzugrenzen. Auch in agilen Umgebungen ist es nützlich, die System- und Kontextgrenzen zu kennen, um sich auf dieser Basis bewusst für oder gegen eine neue Anforderung aus den Product Backlog entscheiden zu können. Innerhalb des Requirements Engineering Prozesses sollten sich alle Beteiligten im Klaren darüber sein, dass sich Änderungen im Kontext des Systems auf das System selbst auswirken und damit Änderungen an bereits abgestimmten Anforderungen nach sich ziehen können.
Prinzip 5: Gutes Requirements Engineering bringt Problem, Anforderung und Lösung in einen Einklang
Probleme, ihre Lösungen und Anforderungen sind eng und unausweichlich miteinander verflochten: Immer dann, wenn Menschen mit der Art und Weise, wie sie Dinge tun, nicht zufrieden sind, können wir im weitesten Sinne über ein Problem sprechen, das nach einer neuen Lösung sucht. Um diese Lösung zu gestalten, sollten sowohl das Problem als auch die Anforderungen analysiert und durchdrungen werden. Hierbei ist es wichtig zu verstehen, dass Probleme, Anforderungen und Lösungen nicht zwingend in dieser zeitlichen Abfolge entstehen. Der Entwurf eines innovativen Systems kann durch Lösungsideen angetrieben werden, die am Ende das bekannte Problem lösen. Mit dem Problem- und Lösungsverständnis werden wiederum Anforderungen ausgearbeitet, die Benutzerbedürfnisse befriedigen und in einer konkreten Lösung umgesetzt werden.
Prototypen oder MVPs (Minimal Viable Products) können bei innovativen Lösungen eine Hilfe sein, um schrittweise ein besseres Verständnis darüber zu erlangen, ob bekannte Probleme mit einer (Teil-)Lösung angegangen werden können oder ob weitere Anforderungen notwendig sind, um die Benutzerbedürfnisse zu befriedigen. Wichtig ist allerdings zu verstehen, dass es nutzlos ist, Anforderungen zu spezifizieren, wenn es kein Problem zu lösen gibt oder keine neue Lösung entwickelt wird. Genauso ist es sinnlos, eine Lösung zu entwickeln, die nach einem zu lösenden Problem oder nach zu erfüllenden Anforderungen sucht.
Trotz der Verflechtung von Problemen, Anforderungen und Lösungen sind Requirements Engineers bestrebt, beim Denken, Kommunizieren und Dokumentieren Anforderungen und Lösungen voneinander zu trennen, um den Fokus auf die Anforderungen zu legen und so wenig wie möglich technische Vorgaben zu machen.
Prinzip 6: Gutes Requirements Engineering setzt auf eine frühzeitige Validierung von Anforderungen
Das Ziel einer jeden Entwicklung ist eine funktionsfähige, benutzerfreundliche und qualitativ hochwertige Lösung. Der Weg von der Idee bis zur finalen Umsetzung kann jedoch mehrere Fallstricke bergen (sicherlich kennen Sie die unterschiedlichen Varianten des Schaukelbeispiels). Wichtig ist zu verstehen, dass die Qualitätssicherung nicht erst am Ende der Entwicklung geschehen kann, sondern bereits frühzeitig im RE erfolgen muss. Agile Vorgehensweisen haben aufgrund kürzerer Iterationen und schnellerer Feedbacks deutliche Vorteile gegenüber planbasierten Vorgehensweisen, die nicht selten Monate oder gar Jahre dauern. Unabhängig vom Vorgehen ist es aber ratsam, frühzeitig mit der Validierung der Anforderungen (oder User Storys), zu beginnen. Denn die Validierung von Anforderungen ist ein Mittel, welches frühzeitig eingesetzt werden kann, um zu prüfen, ob:
- die Wünsche und Bedürfnisse der Stakeholder durch die Anforderungen ausreichend abgedeckt werden (siehe Prinzip 2)
- ein gemeinsames Verständnis über die Anforderungen zwischen den Stakeholdern erreicht wurde (siehe Prinzip 3)
- die Annahmen und Abgrenzungen zum Systemkontext vernünftig sind und standhalten können (siehe Prinzip 4)
Validierungstechniken im RE sind beispielsweise klassische Reviews, Inspektionen, Walkthroughs, Prototypen und A/B Tests. Wichtig ist es, im Rahmen eines Reviews herauszufinden, ob das durch den Requirements Engineer Verstandene korrekt ist und ob alle Stakeholder die gleiche Sichtweise darauf haben. Im agilen Umfeld kann die Validierung von Anforderungen beispielsweise im Rahmen von Product Backlog Refinement-Sessions stattfinden, die im gesamten Team sicherstellen, dass die Bedürfnisse der Stakeholder durch die Dokumentation abgedeckt und für die Entwicklung ausreichend verständlich sind.
Prinzip 7: Gutes Requirements Engineering berücksichtigt die Evolution von Anforderungen
Wer glaubt, dass Anforderungen einmal ermittelt sind und dann genau so umgesetzt werden können, hat noch keine realen Entwicklungsvorhaben erlebt. Systeme und ihre Anforderungen unterliegen einer Evolution und ständigen Veränderung. Änderung von Anforderungen können beispielsweise durch folgende Ursachen notwendig werden:
- geänderte Geschäftsprozesse
- WettbewerberInnen, die neue Produkte oder Dienstleistungen einführen
- KundInnen, die ihre Prioritäten oder Meinung ändern
- SystembenutzerInnen, die nach einer neuen oder geänderten Funktion fragen
- Veränderungen in der Technologie
- Änderungen von Gesetzen oder Vorschriften
Darüber hinaus können sich die Anforderungen aufgrund von Rückmeldungen der Stakeholder, geänderten Bedürfnissen oder durch die Entdeckung von Fehlern in zuvor erhobenen Anforderungen ändern. Aus diesem Grund müssen Requirements Engineers zwei – auf dem ersten Blick widersprüchliche – Ziele verfolgen:
- Sie müssen Änderungen an Anforderungen zulassen und unterstützen
- Sie müssen aber auch Anforderungen stabil halten
Für Requirements Engineers ist es deshalb wichtig, Anforderungen möglichst so zu dokumentieren, dass Änderungen einfach möglich sind, z. B. durch wenig Redundanzen und gute Strukturen. Es ist aber auch wichtig, dass Abhängigkeiten zu anderen Anforderungen einfach identifiziert werden können, z. B. durch Traceability (zu Deutsch: Rückverfolgbarkeit).
Änderungen im agilen Umfeld vs. bei planbasierten Vorgehen
Im agilen Umfeld sind Änderungen willkommen – solange sie einen Sprint nicht stören. Neue oder geänderte Anforderungen werden ins Backlog aufgenommen und dann genauso bewertet und geschätzt wie alle anderen Anforderungen im Backlog. Im planbasierten Vorgehen sind Änderungen genauso willkommen, erfordern jedoch in aller Regel einen etwas formaleren Prozess über einen formalen Änderungsantrag, der dann in einem Gremium diskutiert, bewertet und eingeplant wird.
Das Ziel “das Entwicklungsteam nicht ad-hoc mit jeder Änderung zu belästigen” ist im Grunde gleich – auch wenn die Iterationen und der Prozess unterschiedlich sind.
Prinzip 8: Gutes Requirements Engineering gestaltet Systeme, die begeistern
Wenn man Stakeholdern nur genau das gibt, was sie wirklich äußern, verpasst man die Gelegenheit, Lösungen zu erstellen, die ihre Bedürfnisse noch besser erfüllen als erwartet. Mit klassischen Anforderungserhebungstechniken wie Interviews, Workshops, Feldbeobachtungen oder Dokumentenanalysen, kann man im Sinne von KANO[1] Basisfaktoren und Leistungsfaktoren ermitteln. Diese helfen aber nicht dabei, innovative Lösungen zu erstellen, die BenutzerInnen begeistern:
Um Begeisterungsfaktoren zu ermitteln, sind daher Ermittlungstechniken notwendig, die explorativ zur Ausarbeitung von Ideen eingesetzt werden oder die Kreativität steigern. Hier kann der Einsatz von Prototyping oder die Verwendung von Storyboards weiterhelfen, um exemplarische und iterative Lösungen zu finden, die BenutzerInnen begeistern und einen deutlichen Mehrwert bieten.
Gutes RE – egal ob im planbasierten oder agilen Kontext – strebt also nicht nur an, Stakeholder zufriedenzustellen, sondern auch sie am Ende glücklich und begeistert zu sehen und ihnen eine Lösung zu präsentieren, mit der sie sich sicher fühlen.
Abb. 2: Grafische Darstellung des KANO-Modells, Quelle: IREB®
Prinzip 9: Gutes Requirements Engineering bedeutet systematische und disziplinierte Arbeit
Requirements Engineering ist keine Kunst sondern eine Disziplin, die eine systematische und kontinuierliche Durchführung erfordert. Sie benötigt geeignete Prozesse und Praktiken zur systematischen Ermittlung, Dokumentation, Validierung und Verwaltung von Anforderungen. Agilität und Flexibilität können dabei nicht als Entschuldigung für einen unsystematischen und chaotischen Stil im Requirements Engineering gelten. Auch im agilen Vorgehen verbessert ein systematischer und disziplinierter Requirements Engineering-Ansatz die Qualität des daraus resultierenden Systems.
Fazit: Requirements Engineering kann und muss nicht überall gleich aussehen – ganz im Gegenteil!
Requirements Engineering ist ein hochdynamischer Prozess, der von vielen Aspekten abhängig ist. Der Entwicklungsprozess ist dabei nur ein Aspekt von vielen: Es gibt nicht den einen Prozess oder das eine Verfahren im RE, welches in jeder gegebenen Situation funktioniert. Systematisches und diszipliniertes Arbeiten bedeutet vielmehr:
- angewandte Prozesse und Praktiken an das jeweilige Problem, den Kontext und die Arbeitsumgebung anzupassen
- nicht immer das gleiche Verfahren und die gleichen Praktiken zu verwenden, nur weil man diese gut beherrscht
- Prozesse und Praktiken aus früheren erfolgreichen RE-Tätigkeiten nicht unreflektiert wiederzuverwenden
Für jedes Vorhaben müssen Prozesse, Praktiken und Arbeitsprodukte gewählt werden, die der jeweiligen Situation am besten entsprechen. Hierbei sollte man das erste dieser neun Prinzipien “Gutes Requirements Engineering ist wertorientiert und kein Selbstzweck” nicht aus den Augen verlieren.
Eine entscheidende Voraussetzung für den Erfolg ist, zu wissen was man will – dies gilt auch für jede Softwareentwicklung. Selbstverständlich kennt man zu Beginn eines Entwicklungsvorhabens nicht alle Anforderungen. Dieser lange ignorierten Tatsache trägt eine agile Vorgehensweise hervorragend Rechnung. Dennoch – ohne gezielte Kommunikation, Abstimmung und Dokumentation von Anforderungen wird der Produkterfolg am Ende zum Spielball von Zufall und Glück.
Die hier vorgestellten neun Prinzipien sollen als Leitfaden dienen und ein Bewusstsein für die entscheidenden Aspekte im Requirements Engineering geben – völlig unabhängig von der Art der späteren Lösungsumsetzung.
