Einführung
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 oft eingetretene Risiken. Man kennt sie häufig aus dem Projektmanagement. Allerdings sind sie per Definition nicht auf letzteres 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 entgegenzuwirken–sozusagen ein implizites Risiko Management.
Im RE Curriculum (z.B. IREB CPRE) taucht das Risikomanagement derzeit überhaupt nicht auf, weder implizit noch explizit. Etwas ungewöhnlich: Obwohl Requirement Engineers ständig damit beschäftigt sind, an anderen Stellen Explizites aus Implizitem zu machen, klappt es im eigenen Bereich nicht. Dabei sind die Nachteile offensichtlich: Implizites ist schwer übertragbar und skaliert schlecht. Der beste Requirement Engineer ist der beste Risikomanager, obwohl er davon nichts weiß.
Dieser Artikel beschreibt und sammelt Wissenswertes rund um ein explizites Risiko Management im Requirements Engineering.Thematisiert werden insbesondere folgende Aspekte:
- Herleitung und Abgrenzung zum Risikomanagement im Projektmanagement.
- Methodik
- Anwendung: Planung und Durchführung
Vorträge
- Von Kausalketten zum Risiko Register: Praktisches Risiko Management für das Requirements Engineering. (Posterbeitrag beim Fachgruppentreffen Requirements Engineering der GI 2014 in Dortmund)
- Risiko Management?! Das ist doch der Job vom… (Vortrag bei der REConf 2015)
- Risiko Management?! Aber ich bin doch der für die Anforderungen… (Vortrag bei der User Group Requirements Engineering, Software Foren Leipzig 2015)
Referenzen
- Standish Group. CHAOS: A Recipe for Success. 1999
- PMI. A Guide to the Projekt Management Body of Knowledge. PMBOK (5.Edition). PMI 2013
- Pohl, K., Rupp, C. Requirements Engineering Fundamentals. Rocky Nook Inc. 2011
- UX Designer bei 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