Abstract. Die Phase der Anforderungserhebung gilt im Allgemeinen als sehr risikobehaftet. Obwohl das Minimieren von Risiken im Kern der Definition des Requirements Engineering (RE) steht, wird das Risikomanagement eher dem Projektleiter überlassen. Dieser Beitrag grenzt das Risikomanagement des Requirements Engineering von dem des Projektmanagement auf Basis von Kausalketten ab. Darauf aufbauend stellt er ein Werkzeug aus der Praxis vor, mit dem ein explizites Risikomanagement im RE durchgeführt werden kann. Hierdurch wird nicht nur die Notwendigkeit des RE unterstrichen, sondern auch seine Skalierbarkeit deutlich erhöht.
Einleitung
Die Phase der Anforderungserhebung gilt im Allgemeinen als sehr risikobehaftet. Die hier gemachten Fehler sind bekanntermaßen nicht nur am teuersten, sondern meist auch am schwersten zu korrigieren [1]. Die Ursachen sind in der Regel eingetretene Risiken. Letztere sind allerdings per Definition nicht auf das Projektmanagement (PM) beschränkt:
“A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on the projects objectives” [2].
Risiken sind vielmehr sogar expliziter Bestandteil der Definition des Requirements Engineering (RE) mit dem Wortlaut:
„specify and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders‘ desires and needs“ [3].
Jede Aktion des Requirements Engineer ist demnach eine Art Risk Response, also eine Maßnahme, um bestimmten Risiken entgegen zu wirken.
Umso mehr überrascht es, dass das Thema Risikomanagement kein Bestandteil des Curriculums für das RE ist. In die täglichen Abläufe oder Prozeduren des RE ist das Risikomanagement nicht explizit integriert. Vielmehr wird es meist in der Verantwortung des Projektleiters gesehen [4]. Eher zum Zweck eines Methodenüberblicks wurden Risiken und RE Methoden in sogenannten Contingency Frameworks verknüpft [5]. In der RE Praxis sind diese jedoch kaum von Relevanz.
Dieser Beitrag zeigt, inwiefern und warum das Risikomanagement eine wichtige Bedeutung für das RE hat. Er stellt einen praktischen Ansatz vor, mit dem ein explizites Risikomanagement im RE durchgeführt werden kann. Gleichzeitig wird dadurch die Notwendigkeit des RE nicht nur unterstrichen, sondern seine Skalierbarkeit deutlich erhöht. Hierzu wird sich dem Thema aus der Perspektive von Kausalketten genähert und auf dieser Basis eine Abgrenzung von PM Risiken und Risiken des RE vorgenommen. Abschließend wird dieser Ansatz kurz diskutiert.
Von der Kausalkette zum Risiko
In einer Kausalkette bewirkt ein Ereignis (Ursache) ein anderes (Wirkung), welches selbst wiederum ein weiteres Ereignis bewirken kann. D.h. eine Wirkung kann gleichzeitig wiederum eine Ursache mit einer weiteren Wirkung sein usw. (siehe Abbildung 1).
Den reproduzierbaren Zusammenhang zwischen Ursache und Wirkung nennt man auch Kausalität. Wie eingangs beschrieben, sind Risiken nichts anderes als eine bestimmte Art von Ereignis. Dementsprechend lassen sich Risiken sowohl Ursachen als auch Wirkungen entlang einer Kausalkette zuordnen. Bei letzterer wird dann deutlich, dass sie verschiedene Verantwortungsbereiche (RE, Entwicklung, etc.) in einer Projektorganisation durchlaufen, bevor sie zu zentralen Projektrisiken werden. Ein Beispiel: Da die Mitglieder einer Fachabteilung wenig Zeit haben, entsenden sie einen Vertreter für die Anforderungserhebung, der „entbehrlich“ ist (U1). Da dieser Vertreter nicht ganz im Tagesgeschäft steckt und aufgrund persönlicher Merkmale, beantwortet er viele Fragen mit der eigenen Meinung (W1/U2). Hierdurch entstehen falsche Anforderungen (W2/U3).
In Folge dessen wird das Projekt nie den Umfang erreichen, den es haben müsste (W3). Während U1 und W1 typischerweise durch Maßnahmen im RE adressiert werden, ist der Rest der Kette das Risiko des Projektleiters. Hierdurch wird vor allem eines deutlich: Jeder Projektbereich zeichnet sich durch zentrale Wirkungen aus (siehe Abbildung 1). Während im PM die zentralen Wirkungen längere, teurere und nicht dem geforderten Umfang entsprechende Projekte sind, lassen sich im RE die folgenden zentralen Wirkungen identifizieren: unvollständige, fehlerhafte und fehlende Anforderungen. Alle Ursachen, die dazu führen, sind im RE relevante Risiken.
Das RE Risiko Register
Dem erfahrenen Requirements Engineer sind viele Risiken (zumindest implizit) vertraut. Er/sie hat seine/ihre Methoden dahingehend ausgewählt bzw. entwickelt oder angepasst, um diesen erfolgreich zu begegnen. Genau dieses implizite Risikomanagement gilt es aus dem eher intuitiven und schwer reproduzierbaren Bereich hervor zu holen, um es weiter zu entwickeln und zu strukturieren mit dem Ziel, es z.B. unerfahreneren Kollegen an die Hand geben zu können (so gesehen sind letztere sonst selbst eines der Risiken der Anforderungserhebung). Zur Anwendung kommen in diesem Fall sogenannte Risiko Register [1] (siehe Abbildung 2). Ein Risk Register (PMI)/Risk Log (PRINCE2) ist vom Prinzip her eine Tabelle mit je einer Zeile für ein Risiko. Es gibt hierfür aber durchaus unterschiedliche Formate. Standard Spaltenattribute sind meist eine generelle Beschreibung, die Auswirkungen, die Eintritts-wahrscheinlichkeit und Indikatoren sowie Maßnahmen (Risk Responses) zur Abschwächung der Effekte bei Risikoeintritt bzw. zu deren generellen Vermeidung. Bei den Maßnahmen finden sich dann hauptsächlich Methoden des RE wieder. Bei nahezu identischer Struktur ist der Hauptunterschied eines Risiko Registers im RE zum PM vor allem der Inhalt.
Die Herleitung über Kausalketten verdeutlicht auch einen weiteren Aspekt: jede Maßnahme (Risk Response) birgt ein sekundäres Risiko, d.h., dass die Anwendung einer RE Methode als Reaktion auf ein Risiko, mitunter neue Risiken entstehen lässt [1]. Ein Beispiel: durch einen Anforderungsworkshop besteht die Gefahr, nur Kano Leistungsfaktoren zu erheben, was wiederum zu unvollständigen Anforderungen führen kann, da die Basisfaktoren fehlen.
Initial lässt sich ein Risk Register über eine einmalige Expertensitzung füllen. Sie können durchaus firmen- oder domänenspezifisch sein, denn sie sind vor allem aus der bisherigen Erfahrung bzw. aus der Praxis getrieben. Danach ist es sinnvoll, einen Prozess der RE Risiko Analyse und ein abschließendes Lessons-Learned in die allgemeinen Abläufe zu integrieren, beispielsweise im agilen Umfeld in das Sprint Planning bzw. in die Sprint Retrospective.
Diskussion
Mit dem RE Risiko Register erhält man nicht nur wie bei Contingency Frameworks einen Methodenüberblick, sondern darüber hinaus einen solchen, der für den jeweiligen Kontext ein abgestimmtes Methodenbündel (approved subset) bereitstellt. Im Gegensatz zu Contigency Frameworks sind sekundäre Risiken integraler Bestandteil. Die verwendete Sprache (des PM) erleichtert die Kommunikation gerade mit Projektleitern sehr. Dies ist auch dann von Vorteil, wenn RE unerfahrene bzw. fachfremde Personen (z.B. aus dem PM) das RE übernehmen. Das RE Risiko Register liefert nicht nur die Methoden, sondern gleichzeitig auch die Gründe für deren Anwendung: die Risiken. Das hilft auch in der Lehre/Schulung und fördert allgemein das Verständnis der Notwendigkeit eines guten RE Ansatzes. Darüber hinaus lässt es sich zur Beurteilung der Zweckmäßigkeit neuer RE Methoden verwenden: adressiert die neue Methode ein nicht vorhandenes Risiko, fehlt entweder das Risiko im Register oder die Methode ist für den vorliegenden Kontext überflüssig. Nicht zuletzt unterstreichen die Risiken die Notwendigkeit des RE. Ein explizites Risikomanagement macht es darüber hinaus noch skalierbar innerhalb der Organisation.
Referenzen
- Standish Group (1999). CHAOS: A Recipe for Success.
- PMI (2013). A Guide to the Project Management Body of Knowledge: PMBOK (5. Ed), PMI 2013
- Pohl, K., Rupp, C. (2011). Requirements Engineering Fundamentals. Rocky Nook Inc.
- Herrmann, A., Knauss, E., Weißbach, R. (2013). Requirements Engineering und Projektmanagement. Springer Vieweg
- Mathiassen, L., Saarinen, T., Tuuanen, T., Rossi, M. (2004). Managing Requirements Engineering Risks: An Analysis and Synthesis of Literature.
- UX Designer by Default - 13. März 2023
- Zur Lage des Requirements Engineering: Der RE-Kompass - 1. Februar 2023
- Die Fahrradschlosskalkulation: Eine Analogie zur Operationalisierung des Wertes des Requirements Engineering - 28. Januar 2023