Die 9 Prinzipien des Requirements Engineering. Laut IREB®
Welche Prinzipien sollten für das Requirements Engineering heute gelten? Und wie setzt man diese in der Praxis um?
Laut offiziellem Glossar des International Requirements Engineering Board (IREB) von 2020 ist das Requirements Engineering ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit folgenden Zielen:
- die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen nach vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu verwalten,
- die Wünsche und Bedürfnisse der Stakeholder zu verstehen und zu dokumentieren,
- die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das zu liefernde System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.
In der Neuauflage des Lehrplans für die Ausbildung zum Certified Professional for Requirements Engineering (CPRE) mit der Versionsnummer 3.0.1 von 2020 hat IREB auch erstmals grundlegende Prinzipien für das Requirements Engineering definiert. Solche Prinzipien, wie man sie zum Beispiel auch aus dem agilen Manifest kennt, helfen dabei, die Zielsetzung des Requirements Engineerings im Allgemeinen besser zu verinnerlichen. Es wurden 9 Prinzipien aufgestellt, die für alle Aufgaben, Aktivitäten und Praktiken im Requirements Engineering gelten sollen.
Prinzip 1: Wertorientierung
Anforderungen sind Mittel zum Zweck, kein Selbstzweck
Der Wert einer Anforderung wird bestimmt durch den Nutzen minus aller Kosten für die Ermittlung, Dokumentation, Validierung und Verwaltung derselben. Der Nutzen wir bestimmt durch ihren Beitrag
- zu einem System, das die Wünsche und Bedürfnisse der Stakeholder erfüllt.
- zur Verringerung des Risikos von Fehlentwicklungen und deren Folgekosten in der Systementwicklung.
Damit legt das Requirements Engineering eine starken Fokus auf die Wertschöpfung einer Entwicklung. Dieses Prinzip ist auch bei agilen Methoden (wie z.B. Scrum) von großer Bedeutung. Anstatt eine Liste von feststehenden Anforderungen linear abzuarbeiten, soll in kurzen Zyklen immer wieder der Wert der Entwicklung überprüft und Anforderungen entsprechend angepasst werden.
Prinzip 2: Stakeholder
Im Requirements Engineering geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen
Die Stakeholderidentifikation, Stakeholderanalyse und das Stakeholdermanagement sind Kernaufgaben des Requirements Engineering. Stakeholder können unterschiedliche Rollen haben in einem zu entwicklenden System. Oder auch mehrere gleichzeitig. Es können auch Prototypen für Stakeholder erschaffen werden, sogenannte Personas. Personas repräsentieren Anwendergruppen, die noch unbekannt sind, wie z.B. zukünftige Nutzer eines Systems. Wichtig ist, dass bei der Anforderungsermittlung keine Stakeholder übersehen werden, Konflikte unter Stakeholdern erkannt und möglichst gelöst werden und im Verlauf der Entwicklung regelmäßig Feedback von den Stakeholdern eingeholt wird. Nur so können Fehlentwicklungen frühzeitig identifiziert und behoben werden.
Prinzip 3: Gemeinsames Verständnis
Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich
Das Requirements Engineering soll ein gemeinsames Verständnis von Stakeholdern, Requirements Engineers und Entwicklern schaffen, fördern und sichern. IREB differenziert hier zwei Formen von gemeinsamem Verständnis:
- explizites (durch dokumentierte und vereinbarte Anforderungen)
- implizites (basierend auf gemeinsamem Wissen)
Natürlich hängt das gemeinsame Verständnis auch von Faktoren wie Teamgröße, Teamverteilung, Fluktuation, Kultur und Werten ab. Das gemeinsame Verständnis kann verbessert werden durch Glossare, Prototypen oder bestehende Referenzsysteme. Um das gemeinsame Verständnis immer wieder zu überprüfen, sollten kurze Feedbackzyklen etabliert werden.
Prinzip 4: Kontext
Systeme können nicht isoliert verstanden werden
Um Systeme richtig spezifizieren zu können, muss man zunächst den Systemkontext bestimmen. Der Systemkontext ist für die Definition und das Verständnis der Anforderungen relevant. Denn Systeme sind in der Regel durch Interaktion mit ihrer Umgebung (z.B. über Schnittstellen) verbunden. Die Grenze zwischen dem zu entwickelnden System und dem umgebenden Kontext kann sich außerdem verschieben, was wiederum Auswirkungen auf die Anforderungen hat. Die Systemgrenze legt zudem den Scope (Umfang) des zu entwickelnden Systems fest. Ist der Scope nicht abgegrenzt, kann es leicht zu einer schleichenden Zunahme von Anforderungen, einem sogenannten Scope Creep kommen. Innerhalb der Scope-Grenze gibt es Gestaltungsspielraum. Kernaufgabe des Requirements Engineering ist es, Verschiebungen der Systemgrenze festzustellen und sich daraus ergebende Veränderungen an den Anforderungen vorzunehmen.
Prinzip 5: Problem – Anforderung – Lösung
Ein unausweichlich ineinandergreifendes Tripel
Probleme, Anforderungen und Lösungen sind eng miteinander verflochten. Sie können nicht isoliert angegangen werden. Oft ist der Ablauf so: Stakeholder haben ein Problem – dann werden Anforderungen erfasst, deren Erfüllung das Problem lösen oder vereinfachen soll – schließlich wird eine Lösung geliefert in Form eines Systems, das diesen Anforderungen gerecht wird. Bei Innovationen stimmt diese Chronologie allerdings nicht immer, weil sie meist nicht aus konkreten Stakeholder-Anforderungen entstehen, sondern Lösungen eher experimentell entstehen.
Requirements Engineers sollten trotzdem bestrebt sein, Probleme, Anforderungen und Lösungen beim Denken, Kommunizieren und Dokumentieren möglichst voneinander zu trennen. Das erleichtert die Abwicklung der Requirements Engineering Aufgaben: Anforderungsermittlung, Anforderungsdokumentation, Anforderungsvalidierung und Anforderungsverwaltung.
Prinzip 6: Validierung
Nicht validierte Anforderungen sind nutzlos
Das zu erstellende System muss die Wünsche und Bedürfnisse der Stakeholder erfüllen. Deshalb sind nicht validierte Anforderungen nutzlos. Die Validierung muss bereits im Requirements Engineering beginnen. Geprüft werden muss, ob
- unter den Stakeholdern Einigkeit über die Anforderungen erreicht wurde
- die Wünsche und Bedürfnisse der Stakeholder durch die Anforderungen ausreichend abgedeckt werden
- die Kontextannahmen richtig und vernünftig sind
Validierungstechniken sind z. B. Reviews wie Walkthroughs oder Inspektionen und Explorationen wie Prototyping, A/B Tests, Minimum Viable Products (MVP) oder Probeentwicklungen.
Prinzip 7: Evolution
Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall
Systeme und ihre Anforderungen ändern sich ständig, sie unterliegen einer Entwicklung. Änderungen an Anforderungen werden ausgelöst durch:
- geänderte Geschäftsprozesse
- Wettbewerber mit neuen Produkten/Dienstleistungen
- Geänderte Wünsche und Prioritäten von Stakeholdern
- technologischen Fortschritt
- Änderung von Gesetzen und Vorschriften
- Feedbackschleifen
Requirements Engineers müssen deshalb zwischen zwei widersprüchlichen Zielen abwägen: sinnvolle Änderungen zuzulassen und Anforderungen stabil zu halten. Ausschlaggeben für diese Entscheidung dürfte sein, ob eine Änderung wertstiftend ist oder nicht.
Prinzip 8: Innovation
Mehr vom Gleichen ist nicht genug
Gutes Requirements Engineering hat zum Ziel, Stakeholder nicht zur zufrieden zu stellen, sondern zu begeistern. Das “Über-Erfüllen” von Anforderungen gelingt oft nur mit Innovation. Das Kano-Modell verdeutlicht diesen Zusammenhang zwischen Anforderungen und Kundenzufriedenheit sehr gut.
Requirements Engineering gestaltet innovative Systeme
- im Kleinen durch das Streben nach aufregenden neuen Funktionen und sehr gute Usability
- im Großen durch das Streben nach verändernden (disruptiven) neuen Ideen.
Mit Kreativitätstechniken und Methoden aus dem Design Thinking können Anforderungen ermittelt werden, die innovative Lösungen hervorbringen helfen.
Prinzip 9: Systematische und disziplinierte Arbeit
Wir können im Requirements Engineering nicht darauf verzichten
Systematik und Disziplin im Requirements Engineering verbessern die Qualität des zu erstellenden Systems. Das bedeutet nicht, dass es nur einen einzigen richtigen Prozess gibt, der für alle Vorhaben eingesetzt werden sollte.
Requirements Engineers sollten daher
- die von Ihnen angewendeten Vorgehensweisen, Praktiken und Arbeitsergebnisse an des jeweilige Problem, den Kontext und die Arbeitsumgebung anpassen.
- nicht immer das gleiche Verfahren und die gleichen Praktiken verwenden
- Prozesse und Praktiken aus früheren erfolgreichen Requirements Engineering Tätigkeiten nicht unreflektiert wiederverwenden.
