Requirements Engineering und Risikomanagement: Zwei Seiten der gleichen Medaille

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

1. Standish Group. CHAOS: A Recipe for Success. 1999
2. PMI. A Guide to the Projekt Management Body of Knowledge. PMBOK (5.Edition). PMI 2013
3. Pohl, K., Rupp, C. Requirements Engineering Fundamentals. Rocky Nook Inc. 2011

• Über
• Letzte Artikel

Christoph Oemig

studierte Medieninformatik mit dem Schwerpunkt Mensch-Computer Interaktion und Betriebswirtschaft in Wedel und Furtwangen. Seine Promotion zum Dr. rer. nat. erlangte er im Bereich Computer-gestützte Gruppenarbeit am Lehrstuhl für Human-Computer-Interaction an der Otto-Friedrich-Universität Bamberg. Er ist IREB Certified Professional for Requirements Engineering (CPRE), IIBA Certfied Business Analysis Professional (CBAP), UXQB Certified Professional for Usability and User Experience (CPUX) und gestaltet als Lead Business Analyst bei der Deutschen Bank die anforderungstechnischen Belange im Bereich Cash und Selbstbedienung. Er ist Mitglied der Fachgruppe Requirements Engineering der Gesellschaft für Informatik (GI) sowie des Berufsverbandes der Deutschen Usability und User Experience Professionals (German UPA) und regelmäßig Referent auf Tagungen und Konferenzen zu Themen des Requirements Engineerings, der Business Analyse sowie dem Usability Engineering.

Letzte Artikel von Christoph Oemig (Alle anzeigen)

• 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