Requirements Engineering. Stakeholder-Management und Anforderungserhebung

Inhalt

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Konzeptionelle Grundlagen des Requirements Engineering
2.1 Was ist Requirements Engineering
2.2 Stakeholderanalyse
2.2.1 Was sind Stakeholder
2.2.2 Ziele der Stakeholder
2.3 Erhebung von Requirements
2.3.1 Durchführung
2.3.2 Die Anforderungsschablone nach Chris Rupp
2.3.3 Kano-Kategorien

3 Fallstudie
3.1 Ausgangssituation
3.2 Stakeholderanalyse
3.3 Anforderungserhebung

4 Fazit

Anhang

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Anforderungsschablone nach Chris Rupp

Abbildung 2: Relevanz-Matrix

Tabellenverzeichnis

Tabelle 1: Zusammenfassung der Stakeholder und ihrer Ziele

Tabelle 2: Zusammenfassung der Anforderungen

1 Einleitung

Eine Kostensteigerung von knapp 170 % und eine Überschreitung des Fertigstellungstermins um fast neun Jahre. Mit diesen Daten bestimmt der Flughafen BER derzeit immer wieder die Schlagzeilen. Mit zwei Milliarden Euro Kosten wurde der Flughafen geplant, im Jahr 2011 sollte er eröffnen. Inzwischen belaufen sich die Kosten auf circa 5,4 Milliarden Euro, die geplante Eröffnung ist auf Ende des Jahres 2020 terminiert.¹ So oder so ähnlich geht es vielen Projekten. Laut des Chaos-Reports der Standish Group aus dem Jahr 2015 wurden lediglich 29% der Projekte erfolgreich abgeschlossen. Erfolgreich bedeutet, dass Budget- und Zeitplan eingehalten wurden. Aber auch die Zufriedenstellung der Beteiligten wurde hier berücksichtigt.² Als häufige Gründe warum Projekte scheitern wird dabei oftmals angegeben, dass Zielvorgaben unklar oder gar nicht vorhanden waren, die Erwartungen von Anspruchsgruppen überhöht waren oder das Projekt nur unzureichend vorbereitet wurde.³ Mit einem exakt durchgeführten Requirement Engineering könnten diese Fehler vermieden und dadurch vermutlich mehr Projekte auch erfolgreich abgeschlossen werden.

Hierzu ist es wichtig zu wissen, was Requirement Engineering überhaupt bedeutet und welche Schritte es beinhaltet. Antworten auf die genannten Fragen sollen in dieser Arbeit dargelegt werden.

Ziel dieser Arbeit ist es, die Grundlagen und Voraussetzungen eines erfolgreichen Requirement Engineerings herauszuarbeiten und diese anhand eines Fallbeispiels eines IT-Projektes bezüglich verschiedener Kriterien zu analysieren und zu konkretisieren. Hierzu werden zunächst die Grundlagen des Requirement Engineerings erläutert. Es wird geklärt, was man unter dem Begriff versteht. Zudem wird auf einzelne Schritte, wie beispielsweise die Stakeholderanalyse und die Erhebung von Requirements näher eingegangen. Anschließend finden die zuvor definierten Grundlagen in einem Fallbeispiel eines IT-Projektes praktische Anwendung.

2 Konzeptionelle Grundlagen des Requirements Engineering

In diesem Kapitel sollen zunächst das Requirement Engineering als Ausgangspunkt aller weiteren Betrachtungen näher erläutert werden. Hierzu wird der Begriff zunächst definiert und es wird beschrieben was unter Stakeholdern verstanden wird. Am Ende wird noch genauer auf den Schritt der Erhebung der Requirements eingegangen.

2.1 Was ist Requirements Engineering

Wie aus der Einleitung bereits hervorgegangen ist, scheitern immer noch viele (Software-) Projekte aufgrund von mangelndem Requirements Engineering. Grundlegende Probleme die sich bei der Umsetzung von Projekten abzeichnen sind dabei vor allem unklare Zielvorgaben, inhärente Komplexität sowie Kommunikationsprobleme.⁴ Hier setzt das Requirements Engineering an. Nach dem International Requirements Engineering Board handelt es sich um einen "systematischen und disziplinierten Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

1. die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen
2. die Wünsche und Bedürfnisse der Stakeholder zu verstehen und zu dokumentieren
3. die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, ein System auszuliefern, das nicht den Wünschen und Bedürfnissen der Stakeholder entspricht."⁵

Die Haupttätigkeiten im Requirements Engineering sind dabei das Ermitteln, das Dokumentieren, das Prüfen und Abstimmen sowie das Verwalten von Anforderungen.⁶

2.2 Stakeholderanalyse

2.2.1 Was sind Stakeholder

Es soll nun zunächst geklärt werden, was unter einem Stakeholder zu verstehen ist. Im deutschen kann das Wort "stake" als "Anteil" übersetzt werden. Genauer betrachtet ist hier ein Interessensanteil gemeint.⁷ Edward Freeman prägte 1984 die Stakeholder-Theorie. Er definiert Stakeholder wie folgt:

"Stakeholder sind alle Gruppen und Individuen, die die Erreichung der Ziele einer Organisation oder eines Projekts beeinflussen können oder von der Organisation bzw. vom Projekt beeinflusst werden."⁸

Aus dieser weitreichenden Definition wird bereits ersichtlich, dass Stakeholder nicht nur im eigenen Unternehmen zu finden sind, sondern auch außerhalb des Unternehmens existieren können. Man unterscheidet daher auch zwischen internen Stakeholdern wie beispielsweise sämtlichen Mitarbeitern des Unternehmens und externen Stakeholdern wie Kunden, Lieferanten, Behörden und ähnlichen.⁹

2.2.2 Ziele der Stakeholder

Bei der Analyse von Stakeholdern und ihren Interessen stellt sich oftmals heraus, dass die Einzelinteressen der Stakeholder widersprüchlich oder gar unvereinbar sind. Hierdurch kann es zu Konflikten kommen, die den erfolgreichen Abschluss eines Projektes verhindern können.¹⁰ Es ist daher wichtig bereits am Anfang eines Projektes die unterschiedlichen Ziele der Stakeholder herauszuarbeiten, um sie dann im Projektverlauf bestmöglich erfüllen zu können. Dafür ist es notwendig die Ziele auch nach bestimmten Kriterien zu formulieren damit später beispielsweise eine Erfolgskontrolle erfolgen kann. Dies ist nur der Fall, wenn die Ziele auch messbar formuliert wurden.¹¹ Hierzu können einige Modelle helfen, die Vorgaben für die Eigenschaften von "gut formulierten" Zielen anführen. Hier soll nun beispielhaft der SMART-Ansatz kurz vorgestellt werden.

Der Ausdruck "SMART" dient als Eselsbrücke und setzt sich zusammen aus den Anfangsbuchstaben der folgenden Kriterien:

S pezifisch - Ziele müssen immer konkret formuliert werden
M essbar - das Erreichen der Ziele muss über Kennzahlen o.ä. nachweisbar sein
A kzeptiert - Ziele müssen für alle verständlich, nachvollziehbar und motivierend sein
R ealistisch - Ziele müssen unter gewissen Rahmenbedingungen erreichbar sein
T erminiert - Ziele müssen den Zeitpunkt der Zielerreichung ausweisen¹²

Zu diesen Anforderungen sollte die Zielformulierung auch lösungsneutral und positiv formuliert werden. Ebenso sind einschränkende Rahmenbedingungen in die Formulierung aufzunehmen. Im Fallbeispiel später werden die Ziele der Stakeholder auch mit Hilfe der genannten Kriterien erfasst. Auf die Terminierung jedes einzelnen Ziels wird hierbei verzichtet, da die Terminierung des Projekts übergeordnet festgelegt wurde und in jedem Ziel als Terminierungszeitpunkt zu berücksichtigen ist.

2.3 Erhebung von Requirements

2.3.1 Durchführung

Nachdem die Stakeholder und deren Ziele bekannt sind, kann mit der Erhebung der Anforderungen begonnen werden. Requirements müssen erhoben werden, um Ziele zu konkretisieren. Sie dienen dabei als Basis, auf der eine Lösung zum Nutzen des Kunden entwickelt wird.¹³

Wie aus dem Kapitel der Stakeholderanalyse bereits hervorging, sind die Anforderungen, die von Stakeholdern genannt werden, nicht immer eindeutig oder präzise formuliert. Im Gegenteil, oftmals sind es schwammige, unvollständige oder gar widersprüchliche Anforderungen.¹⁴

Requirements können allerdings nicht nur aus den Wünschen und Zielen von Stakeholdern entstehen. Auch Dokumente können beispielsweise wichtige Informationen enthalten, aus denen Anforderungen abgeleitet werden können. Zudem können Anforderungen auch aus bereits betriebenen Systemen gewonnen werden.¹⁵ Zur genauen Ermittlung der Requirements steht eine Vielzahl an Ermittlungstechniken zur Verfügung, die abhängig von der zeitlichen und räumlichen Verfügbarkeit der Stakeholder, dem zur Verfügung stehenden Budget sowie der Bewusstseinsstufe der Stakeholder angewandt werden können. Kreativitätstechniken wie beispielsweise Brainstorming oder De Bonos Denkhüte eignen sich vor allem für neue Produkte gut, bei denen noch keine Erfahrungen vorliegen. Bei Requirements, die für Stakeholder selbstverständlich oder unbewusst sind und damit schwer zu artikulieren, eignen sich beispielsweise Beobachtungstechniken wie die Feldbeobachtung. Außerdem können die Stakeholder auch nach ihren Requirements per Interview oder Fragebogen befragt werden oder es kann die Systemarchäologie untersucht werden. Dies ist an dieser Stelle nur ein kleiner Ausschnitt der Ermittlungstechniken. Eine umfangreichere Ausführung würde den Umfang der Arbeit an dieser Stelle übersteigen.¹⁶

2.3.2 Die Anforderungsschablone nach Chris Rupp

Chris Rupp entwickelte mit seiner Anforderungsschablone bzw. Sprachschablone ein Hilfsmittel, mit dem Anforderungen immer in hoher Qualität und mit geringem Zeit- und Kostenaufwand verfasst werden können. Die Anforderungsschablone ist damit also ein Bauplan, der die Struktur eines jeden Requirementsatzes festlegt. Wichtig bei der Formulierung von Anforderungen ist es, dass diese unmissverständlich und prägnant formuliert werden, damit nachher alle Stakeholder ein gleiches Verständnis darüber haben. Rupp verwendet dabei für die verschiedenen Arten von Requirements jeweils eigene Schablonen. In dieser Arbeit beschränken wir uns auf die Anforderungsschablone für funktionale Requirements.

Im ersten Schritt muss dabei festgelegt werden, wie wichtig einem die Anforderung ist. Dann muss die geforderte Funktionalität identifiziert werden. Es folgt die Festlegung der Art der geforderten Funktionalität, z.B. kann es sich um eine selbständige Systemaktivität oder eine Benutzerinteraktion handeln.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Anforderungsschablone nach Chris Rupp¹⁷

Im vierten Schritt wird das Objekt identifiziert, für das die Funktionalität gefordert wird und im letzten Schritt werden noch die Bedingungen festgelegt, unter denen die Funktionalität durchgeführt werden soll.¹⁸ Auf ein Beispiel der Anwendung der Anforderungsschablone soll an dieser Stelle verzichtet werden, da dies später im Fallbeispiel nochmals aufgegriffen wird.

2.3.3 Kano-Kategorien

Nachdem die Anforderungen nach der zuvor vorgestellten Sprachschablone formuliert wurden ist es weiterhin von Bedeutung zu wissen, welchen Einfluss die einzelnen Anforderungen auf die Zufriedenheit der Stakeholder haben. Um dies herauszufinden kann auf das Modell von Dr. Noriaki Kano zurückgegriffen werden, der die Anforderungen in drei Kategorien unterteilt.¹⁹ Die erste Kategorie sind Basisanforderungen. Sie bilden die Musskriterien für ein Produkt. Das bedeutet, dass ihre Nicht-Erfüllung zu extremer Unzufriedenheit bei den Kunden führen würde. Andererseits führt eine Erfüllung dieser Anforderungen nicht zu mehr Zufriedenheit. Sie sind oftmals schwer zu ermitteln, da sie der Kunde voraussetzt und nicht zwingend immer deutlich artikuliert. Die nächste Kategorie sind die Leistungsanforderungen. Hier stehen Erfüllungsgrad und Zufriedenheit in einem proportionalen Verhältnis zueinander. Je höher der Erfüllungsgrad, desto zufriedener sind auch die Kunden und umgekehrt. Diese Anforderungen werden vom Kunden meist ausdrücklich verlangt und sind daher einfacher zu ermitteln als die Basisfaktoren.²⁰ Die letzte Kategorie die Kano unterscheidet sind die Begeisterungsfaktoren. Hierunter fallen Merkmale die der Kunde noch nicht kennt, sondern erst während der Nutzung des Produkts als angenehme Überraschung entdeckt.²¹ Diese Anforderungen entscheiden oftmals darüber, ob ein Produkt einen wesentlichen Vorsprung zur Konkurrenz erhält oder nicht und sind damit entscheidend um sich auf dem Markt von der Konkurrenz abzuheben. Da es sich hier meist um neue Ideen handelt, ist auch die Ermittlung der Begeisterungsfaktoren nicht einfach, da hier oftmals kreative Techniken zur Ermittlung eingesetzt werden müssen.²² Auch in diesem Kapitel wird auf konkrete Beispiele verzichtet, da diese im Fallbeispiel dargelegt sind.

[...]

¹ Vgl. Wagner, A. (2019 ), www.welt.de (Stand: 24.03.2020).

² Vgl. O.V., (2015 ), www.standishgroup.com (Stand: 24.03.2020).

³ Vgl. Schmitt, D. M. (o.J. ), www.haufe.de (Stand: 25.03.2020).

⁴ Vgl. Partsch, H. (2010), S. 5f.

⁵ Glinz, M. (2017 ), www.ireb.org (Stand: 23.03.2020)., S. 18

⁶ Rupp, C. (2014), S. 14

⁷ Vgl. Krips, D. (2017), S. 1f.

⁸ Vgl. Freeman, E. (2010), S. 54

⁹ Vgl. Altenburger, R. (2016), S. 163

¹⁰ Vgl. Krips, D. (2017), S. 3ff.

¹¹ Vgl. Niebisch, T. (2013), S. 56f.

¹² Vgl. Schmelzer, H.; Sesselmann, W. (2013), S. 272

¹³ Vgl. Ebert, C. (2019), S. 51

¹⁴ Vgl. Balzert, H. (2009), S. 507

¹⁵ Vgl. Rupp, C. (2014), S. 77

¹⁶ Vgl. Rupp, C. (2014), S. 98ff.

¹⁷ eigene Darstellung, Vgl. Rupp, C. (2014), S. 219

¹⁸ Vgl. Rupp, C. (2014), S. 217ff.

¹⁹ Vgl. Rupp, C. (2013), S. 40

²⁰ Vgl. Sauerwein, E. (2000), S. 28

²¹ Vgl. Rupp, C. (2013), S. 40

²² Vgl. Rupp, C. (2014), S. 97