Requirements Engineering in IT-Projekten. Eignen sich klassische oder agile Methoden besser für das Anforderungsmanagement?

Inhalt

Abstract

Vorwort

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Hinführung zum Thema
1.2 Problemstellung
1.3 Forschungsfrage
1.4 Methode
1.5 Aufbau der Arbeit

2 Definition und Eigenschaften
2.1 Definition der Anforderung
2.2 Anforderungsarten nach Pohl
2.3 Anforderungsarten nach Young
2.4 Definition des Anforderungsmanagements

3 Klassische Methoden
3.1 ISO/IEC 12207
3.2 RE in verschiedenen klassischen Vorgehensmodellen

4 Agile Methoden
4.1 Scrum.
4.2 Weitere agile Methoden des Requirements Engineering
4.3 Zusammenfassung klassische und agile Methoden im RE

5 Hybride Methoden
5.1 Agil und Wasserfall
5.2 Agil und RUP

6 Leitfadengestütztes Experteninterview
6.1 Zielsetzung
6.2 Auswahl Interviewpartner
6.3 Durchführung der Interviews
6.4 Interview Leitfaden
6.5 Aufbereitung und Auswertung des Interviewmaterials
6.6 Ergebnispräsentation

7 Reflexion und Fazit
7.1 Zusammenfassung
7.2 Fazit und Beantwortung der Forschungsfrage

Literaturverzeichnis

Anhang

Bibliografische Information der Deutschen Nationalbibliothek:

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Impressum:

Copyright © Studylab 2020

Ein Imprint der GRIN Publishing GmbH, München

Druck und Bindung: Books on Demand GmbH, Norderstedt, Germany

Coverbild: GRIN Publishing GmbH | Freepik.com | Flaticon.com | ei8htz

Abstract

Requirements Engineering ist ein immer wichtigerer Bestandteil erfolgreicher IT-Projekte geworden und gewinnt zunehmend an Bedeutung. So ist es unbedingt notwendig Anforderungen zu definieren, jedoch gibt es dafür verschiedenste Herangehensweisen, die von klassisch über agil hin zu hybriden Methoden reichen.

Für die vorliegende Arbeit wurden in einem ersten Schritt an Hand der Literaturrecherche traditionelle Methoden wie das Wasserfall oder V-Modell in Hinblick auf das Requirements Engineering sowie agile Methoden wie Scrum beschrieben, gegenübergestellt und Vor- und Nachteile herausgearbeitet. In einem zweiten Schritt wurden leitfadengestützte Experteninterviews durchgeführt. Ziel dieser Befragungen war die Exploration von Pro und Contra Argumenten hinsichtlich der unterschiedlichen Praktiken sowie eine Darstellung der Praxisrelevanz an Hand von aktuellen Projekten der Interviewpartner. Auch die derzeitige Positionierung von agilen Methoden wie Scrum auf dem Hype Cycle nach Gartner und der Stellenwert in der Zukunft wurden behandelt.

Zwischen den verschiedensten Zugängen wie man Requirements Engineering in einem IT-Projekt umsetzt gibt es ein immenses Spannungsfeld. Es konnte aber aufgezeigt werden, dass es die effizienteste Methode im Requirements Engineering global gesehen nicht gibt. Als kritischer Punkt hat sich die Umgebung in der man sich befindet herauskristallisiert. So haben die Untersuchungen gezeigt, dass es in einer komplexen Umgebung sinnvoller ist agil zu arbeiten wohingegen man in einer komplizierten Umgebung mit klassischen Ansätzen besser zurechtkommt. Hybride Methoden wurden generell als sehr positiv beurteilt.

Stichwörter: Requirements Engineering, Agilität, klassische Methoden, hybride Ansätze, leitfadengestütztes Experteninterview

Vorwort

„Es ist nicht genug zu wissen, man muss es auch anwenden.

Es ist nicht genug zu wollen, man muss es auch tun.“

Johann Wolfgang von Goethe

An dieser Stelle möchte ich mich bei all denjenigen bedanken, die mich während der Anfertigung dieser Masterarbeit unterstützt und motiviert haben.

Zuerst gebührt mein Dank Hr. Mag. Dr. David Rückel, der meine Masterarbeit betreut und begutachtet hat. Für die hilfreichen Anregungen und die konstruktive Kritik bei der Erstellung dieser Arbeit möchte ich mich bedanken.

Ein besonderer Dank gilt allen Teilnehmern und Teilnehmerinnen meiner Befragung, ohne die diese Arbeit nicht hätte entstehen können. Mein Dank gilt ihrer Informationsbereitschaft und den interessanten Beiträgen und Antworten auf meine Fragen.

Außerdem möchte ich mich bei meinem Mann Thomas und meinen Kindern Leonie und Sophie bedanken, die während der Zeit des Studiums immer hinter mir gestanden und mir den Rücken gestärkt haben.

Abschließend bei meiner Mutter, die immer ein offenes Ohr hatte, wenn Motivation nötig war.

Simone Weidenfelder

Gratwein-Straßengel am 28.02.2020

Abbildungsverzeichnis

Abbildung 1: Vorgehen auf Basis wissenschaftlicher Methodik (eigene Darstellung)

Abbildung 2: Definitionen des Anforderungsbegriffs (eigene Darstellung)

Abbildung 3:Gliederung der Anforderungsarten (eigene Darstellung)

Abbildung 4: Haupttätigkeiten des RE (nach Rupp et al, 2014, S.14)

Abbildung 5: Vergessenskurve nach Ebbinghaus (nach Rupp et al, 2014, S.20)

Abbildung 6: Projektdurchführungsstrategie (V-Modell XT, Version 1.4., S. 21)

Abbildung 7: Vorgehensbaustein Anforderungsfestlegung (Friedrich et al, 2009, S. 6)

Abbildung 8: Scrum Prozess (Kullmann et al, 2013, S. 15)

Abbildung 9: Verständnis über die Ziele (Benefield G., 2008, S. 2)

Abbildung 10: Sechsstufiges Auswertungsverfahren nach Mühlfeld et. al. (nach Mayer, 2013, S. 48ff)

Tabellenverzeichnis

Tabelle 1: Vergleich klassisches vs. agiles RE (eigene Darstellung)

Tabelle 2: Klassifizierung von Interviews nach ihrer Standardisierung (nach Gläser & Laudel, 2010, S.41)

Tabelle 3: Interviewpartner (eigene Darstellung)

Tabelle 4: Ausrichtung der Firmen (eigene Darstellung)

Tabelle 5: Interviewleitfaden mit Reflexion (eigene Darstellung)

Tabelle 6: Statistik der Datenerhebung (eigene Darstellung)

Tabelle 7: Abkürzungen der Interviewpartner (eigene Darstellung)

1 Einleitung

1.1 Hinführung zum Thema

Die Bedeutung der Informationstechnologie hat sich in den letzten Jahren stark gewandelt und ihr Stellenwert als Wettbewerbsfaktor rückt immer mehr in den Vordergrund. (Tiemeyer 2013, S. 8) Diese Erkenntnis resultiert vor allem daraus, dass der Einsatz von Informationstechnologie in nahezu allen Unternehmen ein wesentlicher und wichtiger Bestandteil geworden ist. (Spath et al, 2004, S. 182)

Um die Bedürfnisse der Kunden in Bezug auf die Implementierung von Systemen so gut wie möglich erfüllen zu können, ist gerade im Bereich der Softwareentwicklung Requirements Engineering einer der entscheidenden drei Faktoren für erfolgreiche Projekte wie die Standish Group in ihrem CHAOS Report festgestellt hat. (The Standish Group, 2002)

Anforderungsmanagement ist unbedingt notwendig, wenn es darum geht Systeme zu entwickeln die den Kundenwünschen entsprechen und dabei Budget- und Zeitpläne einzuhalten. Ziel ist es, Kundenanforderungen in guter Qualität mit einem möglichst hohen Reifegrad zu erfassen und dabei Fehler in einer frühen Phase zu erkennen. (Pohl & Rupp, 2015, S.11)

Der Fokus dieser Arbeit liegt auf dem Vergleich zwischen klassischen und agilen Methoden im Requirements Engineering, sowie dem Spannungsfeld zwischen den beiden Ansätzen.

So sagt Ernst Tiemeyer in seinem Handbuch IT Management. Konzepte, Methoden, Lösungen und Arbeitshilfen für die Praxis (2017, S. 391):

„Soll ein Anforderungsmanagement im klassischen stringenten Sinn im Rahmen eines generischen Projektmanagements erfolgen, dann sollen so die vorherrschende Auffassung, die meisten und wichtigsten Anforderungen schon zum Start des IT Projektes bekannt sein.“

Im Gegensatz dazu wird die regelmäßige Ergänzung und Veränderung der Requirements im agilen Ansatz begrüßt, wie man im agilen Manifest von Beck et al. (2009) sehen kann:

„Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. “

Fakt ist, dass die wichtige Rolle des Requirements Engineering in Bezug auf den Projekterfolg in den letzten Jahren stark in das Bewusstsein von Forschung und Industrie gerückt ist. (Elshandidy & Mazen, 2013, S. 473)

1.2 Problemstellung

Hauptaufgabe des Anforderungsmanagements ist es, bei allen Beteiligten eines IT-Projekts ein gemeinsames Verständnis über das zu entwickelnde Produkt zu schaffen. Aus einer Studie des PMI von 2016 geht hervor, dass bei 37 % der gescheiterten IT-Projekte eine Hauptursache das unzureichende Anforderungsmanagement war. (PMI’s Pulse of the Profession, 2016)

Klassisches Anforderungsmanagement ist selbst noch ein relativ junges Fach unter den erfahrenen Disziplinen wie dem Projekt- oder Qualitätsmanagement und wird positiv bewertet, häufig aber noch nicht auf demselben Level anerkannt. Die Aufnahme aller Anforderungen, möglichst bis zum letzten Detailgrad, stellt in vielen klassischen Projektmethoden die Grundvoraussetzung dar. Oft ist es aber immer häufiger so, dass kein exaktes Bild beziehungsweise ausreichende Informationen über das zu erstellende Projekt existieren. Somit fehlt in weiterer Folge auch eine belastbare Basis für die Aufwandschätzung im Gesamtkontext. (Meuten & Fritsch, 2009)

Im agilen Umfeld wird viel Wert auf Flexibilität und die Einbeziehung aller Stakeholder gelegt. Agil arbeitende Teams sind es gewohnt, selbstständig zu arbeiten und Eigenverantwortung für ihre Handlungen zu übernehmen. (Tiemeyer, E. et al, 2014)

Diese Einstellung zeigt sich gerade auch im Umgang mit Anforderungen. Anforderungen stehen in der Regel nicht komplett fest, bevor mit der Umsetzung begonnen wird. Anwender haben die Möglichkeit, sehr früh im Prozess und regelmäßig Produktversionen zu testen und ihre Anforderungen zu überdenken. So können Anforderungen angepasst und erweitert werden. Details werden möglichst erst direkt vor der Umsetzung zwischen Anwendern und Entwicklern diskutiert und festgelegt. Die Reihenfolge der Umsetzung von Anforderungen ist dynamisch und richtet sich nach einer vom Kunden vorzugebenden Priorität gemäß seiner Bedürfnisse. (Wolf H. & Bleek W.G., 2011)

Die zunehmende Verbreitung der agilen Softwareentwicklung in den letzten Jahren hat dazu geführt, dass viele Unternehmen von einem planbasierten Ansatz mit Wasserfallmodellen abgewichen sind. (Cao, Mohan, Xu & Ramesh, 2019)

Agile Methoden beziehen sich auf ein Konglomerat von iterativen Systementwicklungsmethoden, bei welchen Teamzusammenarbeit, minimale Vorausplanung und die Flexibilität bei der Anpassung an sich ändernde Anforderungen im Vordergrund stehen (Beck et al., 2001).

Die Entscheidung einer jeden Organisation, agile Systeme einzusetzen, hängt von verschiedenen Faktoren ab, darunter dem Wunsch die Effizienz zu verbessern, negativen Erfahrungen mit anderen Entwicklungsansätzen und dem Druck der Beteiligten innovative Entwicklungsansätze anzuwenden (Mangalaraj et al., 2009).

Es gibt natürlich auch Organisationen, die den Wert des agilen Ansatzes schätzen sich jedoch nicht vollständig von den traditionellen Wasserfalltechniken lösen können oder sich an vorgeschriebene Richtlinien halten müssen. Untersuchungen zeigen, dass die anfängliche Einführung von agilen Methoden von Überlegungen wie Projektgröße, Anwendungskritikalität, Komplexität, Qualifikation der Mitarbeiter und Unternehmenskultur abhängt (Boehm & Turner, 2003; Nerur et al., 2005; Vinekar et al., 2006).

Unternehmen können ihre Entwicklungsmethoden auch individuell anpassen, indem sie einen Notfallansatz wählen, beispielsweise wird je nach Projektkontext eine aus einer Reihe möglicher Methoden ausgewählt. Auch ein methodentechnischer Ansatz ist möglich, hier werden Methoden aus einer Reihe vordefinierter Methodenkomponenten erstellt sowie ein a-la-carte-Ansatz bei dem fragmentierte Elemente einer Methode oder Gruppe von Methoden zur gemeinsamen Verwendung ausgewählt werden (Fitzgerald et al., 2006).

1.3 Forschungsfrage

Es existieren unterschiedliche Ansätze wie Requirements Engineering methodisch eingesetzt werden kann. Auf der einen Seite die klassischen Methoden und auf der anderen Seite agile Ansätze. Die vorliegende Arbeit fokussiert sich auf den Vergleich und somit die Vor- und Nachteile der beiden Methoden um so die effizientesten Ansätze zu extrahieren.

Die zentrale Fragestellung ist demnach:

- Welche Methoden und somit Vorgehensweisen, sowohl agile als auch klassische zur Ermittlung von Anforderungen, sind am effizientesten um eine hohe Qualität bzw. Reifegrad der Requirements zu gewährleisten?

Im Zuge der Beantwortung dieser zentralen Fragestellung sollen auch weiterführende Fragen adressiert werden um die Arbeit zu konkretisieren:

- Welche Vor- und Nachteile bieten das klassische und agile Anforderungsmanagement?
- Was kann ein hybrider Einsatz beider Methoden leisten?

Da der Umgang mit Anforderungen ein wesentlicher Erfolgsfaktor in Projekten ist, soll im Rahmen dieser Arbeit auf die Vor- und Nachteile der genannten Methoden eingegangen werden. Identifizierte Vor- und Nachteile sollen aufgezeigt und beschrieben werden. Außerdem soll ein Auszug an Methoden welche im klassischen als auch im agilen Kontext zur Verfügung stehen untersucht werden.

Die Arbeit geht außerdem auf einen möglichen Einsatz einer hybriden Methode im Requirements Engineering und deren Vor- und Nachteile ein.

Es ist aber nicht Ziel dieser Arbeit, auf die verschiedenen toolunterstützten Möglichkeiten im Anforderungsmanagement einzugehen.

1.4 Methode

Um die zuvor definierten Forschungsfragen zu beantworten wird in einem ersten Schritt die relevante Literatur analysiert. Aus wissenschaftlichen Artikeln bzw. Literaturbeiträgen sollen Potenziale der verschiedenen Methoden aber auch Nachteile erhoben werden. Zu diesem Zweck wird die Literaturrecherche sowohl im Print- als auch im Onlinebereich durchgeführt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Vorgehen auf Basis wissenschaftlicher Methodik (eigene Darstellung)

Neben der Literaturanalyse und Definition der Begrifflichkeiten sowie Vergleich der Methoden wird in einem nächsten Schritt ein Leitfaden für ein Experteninterview entwickelt um darauf basierend das leitfadengestützte Experteninterview mit fünf Personen durchzuführen. Die Interviewpartner wurden nach zuvor festgelegten Kriterien ausgewählt und stammen aus verschiedenen Unternehmen mit Positionen im IT-Umfeld und Bezug zu klassischem oder agilem Requirements Engineering.

Ziel der Experteninterviews ist es einerseits die zuvor analysierten Aussagen mit den Erkenntnissen aus den Interviews gegenüberzustellen und mögliche Abweichungen zu erläutern aber auch neue Erkenntnisse zu gewinnen.

Die Auswertung der leitfadengestützen Experteninterviews erfolgt anhand der qualitativen Inhaltsanalyse nach Mühlfeld. Es erfolgt eine Darstellung der wesentlichen Kernaussagen sowie eine Auswertung der für die Untersuchung relevanten Themenblöcke. Eine zusammenfassende Darstellung führt die theoretischen Ergebnisse mit den Daten der qualitativen Erhebung zusammen und prüft mit einer kritischen Reflexion die Übereinstimmung der gewonnenen Erkenntnisse.

1.5 Aufbau der Arbeit

Die vorliegende Arbeit gliedert sich in insgesamt neun Kapitel. In Kapitel eins wird die Problemstellung sowie die Forschungsfrage und die verwendete Methodik dargestellt.

Als Heranführung an das Thema, wird in Kapitel zwei der Anforderungsbegriff, die Anforderungsarten und das Anforderungsmanagement definiert um den Leser mit den Grundlagen vertraut zu machen und um ein einheitliches Begriffsverständnis zu gewährleisten.

Kapitel drei und vier gehen sowohl auf die klassischen als auch agilen Methoden im Requirements Engineering ein. Es werden einerseits das Wasserfall und V-Modell beschrieben, aber auch die Details von Scrum herausgearbeitet und weitere agile Methoden vorgestellt. So werden auch Potenziale und Herausforderungen von agilen Modellen wie Scrum beschrieben. Darüber hinaus beinhaltet es eine Zusammenfassung beziehungsweise Gegenüberstellung von traditionellen und agilen Praktiken.

Im Anschluss daran widmet sich das fünfte Kapitel den hybriden Methoden und geht besonders auf die Kombinationen aus agilen Methoden und Wasserfall sowie agilen Methoden und RUP ein.

Der praktische Teil beginnt ab Kapitel sechs, wo sich die Arbeit mit der Vorgehensweise und der Beschreibung der empirischen Erhebung beschäftigt. In diesem Teil werden die Methoden des leitfadengestützten Experteninterviews beschrieben, sowie die Auswahl der Interviewpartner und die Aufbereitung und Auswertung der Interviews im Detail dargestellt. Außerdem erfolgt in diesem Kapitel die Ergebnispräsentation der Befragungen.

Die Schlussbetrachtung in Kapitel sieben fasst die wesentlichen Ergebnisse der Arbeit zusammen und beinhaltet ein abschließendes Fazit.

Kapitel acht und neun umfassen sowohl das Literaturverzeichnis als auch den Anhang in dem sich einerseits der Leitfaden für das Interview mit einer Beschreibung des Hype Cycles nach Gartner, sowie die transkribierten Interviews finden.

2 Definition und Eigenschaften

Der Fokus dieses Kapitels ist es die Begrifflichkeiten der Anforderung und des Anforderungsmanagements, welche im weiteren Verlauf der Arbeit verwendet werden zu erklären und einen Überblick über die Eigenschaften bzw. Arten des Requirements Engineering zu geben. Ziel ist es ein einheitliches Verständnis des Begriffes zu erlangen.

2.1 Definition der Anforderung

Requirements Engineering ist eine Disziplin, in der es um Anforderungen geht.

So stellen bereits Gause und Weinberg (1989), die Urväter des Requirements Engineering fest, dass „Teams exakt das erstellen, was von ihnen verlangt wird“ und vice versa nichts von dem, was ihnen im Vorfeld nicht bekannt war. Fehlerhafte Produkte werden also erstellt, wenn die Vorgaben und somit Anforderungen fehlerhaft oder nicht vorhanden sind.

Anforderungen entsprechen folglich gewünschten Funktionalitäten oder Eigenschaften, die das resultierende Produkt besitzen soll. Sie formulieren, wie Robertson und Robertson (2013) es ausdrücken, einen „Business Need, den das Produkt befriedigen soll.“

So gibt es in der Fachliteratur zahlreiche Definitionen des Anforderungsbegriffs.

Der Standard ISO/IEC/IEEE 24765 (2017, S.377) definiert den Begriff „Anforderung“ folgendermaßen:

- Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
- Eine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen.
- Eine dokumentierte Repräsentation einer Bedingung oder Fähigkeit aus den ersten beiden Punkten
- Eine Anforderung inkludiert die quantifizierten und dokumentierten Bedürfnisse, Wünsche, Sehnsüchte des Sponsors, Kunden oder anderer Stakeholder.

In ähnlicher Weise wird der Begriff im Referenzmodell CMMI (2011, S.442) definiert:

- Eigenschaft oder Fähigkeit, die von einem Anwender zur Lösung eines Problems oder zum Erreichen eines Ziels benötigt wird.
- Eigenschaft oder Fähigkeit, die ein Produkt, eine Dienstleistung, ein Produkt- oder Dienstleistungsbestandteil besitzen muss, um eine Lieferantenvereinbarung, eine Norm, eine Spezifikation oder andere formell vorgegebene Dokumente zu erfüllen.
- Dokumentierte Darstellung einer Eigenschaft oder Fähigkeit, wie sie in den beiden oberen Punkten beschrieben werden.

Diese beiden Definitionen unterscheiden sich demnach nur in minimaler Art und Weise. Chemuturi (2013, S.3) spricht aber davon, dass diese Definitionen Einschränkungen besitzen, welcher sich folgendermaßen darstellen:

- ISO IEC/IEEE 24765 und CMMI sprechen nur von sogenannten „needs“ (Bedürfnissen), berücksichtigen aber nicht die Erwartungshaltung der Anwender, dass dich das Team mit seinem Fachwissen in die Entwicklung des Softwareproduktes miteinbringt.
- Sie betrachten die Einschränkungen der Benutzer nicht, welche im Zuge ihrer täglichen operativen Arbeit mit dem System auftreten können
- Es werden keine Schnittstellen zu anderen Systemen betrachtet wie sie z.B. bei ERP oder CRM Software der Fall sind.
- Die Verantwortlichen und Stakeholder von Anforderungen werden nicht betrachtet. Dadurch ist es möglich wichtige Stakeholder als Quelle von Anforderungen zu übersehen.
- Unausgesprochene Bedürfnisse werden nicht berücksichtigt, da nur dokumentierte Anforderungen an das System umgesetzt werden.

Ergo definiert Chemuturi (2013, S.3) seine Definition von „Anforderung“ zusammenfassend wie folgt:

„A requirement is a need, expectation, constraint or interface of any stakeholders that must be fulfilled by the proposed software product during its development “.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Definitionen des Anforderungsbegriffs (eigene Darstellung)

2.2 Anforderungsarten nach Pohl

Pohl (2008, S.14) beschreibt die folgenden drei Anforderungsarten, welche wie in Abbildung 2.2. gegliedert sind.

- Funktionale Anforderungen
- Qualitätsanforderungen
- Rahmenbedingungen

Die nichtfunktionalen Anforderungen werden von Pohl bewusst nicht dargestellt, da er diese als unterspezifizierte funktionale Anforderungen oder Qualitätsanforderungen sieht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3:Gliederung der Anforderungsarten (eigene Darstellung)

2.2.1 Funktionale Anforderungen

Eine funktionale Anforderung definiert eine vom System bzw. von einer Systemkomponente bereitzustellende Funktion oder einen Service. Als Benutzeranforderung kann eine funktionale Anforderung sehr allgemein beschrieben sein. Als Bestandteil einer Spezifikation beschreibt eine funktionale Anforderung detailliert die Eingaben und Ausgaben sowie bekannte Ausnahmen. (Sommerville, 2018, S. 124-125)

2.2.2 Qualitätsanforderungen

Qualitätsanforderungen definieren eine qualitative Eigenschaft des gesamten Systems, einer Systemkomponente oder einer Funktion und somit gewisse Qualitätsmerkmale wie beispielsweise die Performanz eines Systems, seine Zuverlässigkeit oder die geforderte Ausfallssicherheit. (Pohl, 2008, S.15-16)

2.2.3 Rahmenbedingungen

Rahmenbedingungen oder „Projektbeschränkungen“ wie sie Robertson & Robertson (2013, S. 28) nennen sind organisatorische oder technologische Anforderungen, welche die Art und Weise einschränken wie ein System entwickelt wird.

2.3 Anforderungsarten nach Young

Young (2004, S.49) unterscheidet differenzierte Typen von Anforderungen und stellt sie in einen prozessualen Zusammenhang. Anforderungen werden als abstraktes Konstrukt aus verschiedenen Quellen im Rahmen eines Anforderungsmanagementprozesses sortiert und münden in spezifischen Beschreibungen für Systeme.

Kundenwünsche und -erwartungen:

- Fachliche Anforderunge
- Anforderungen der Anwender
- Anforderungen an das Produkt
- Umweltanforderungen
- Unbekannte Anforderungen

Diese werden analysiert und entsprechend beschrieben:

- „High-Level“ Anforderungen
- Funktionale Anforderungen
- Nichtfunktionale Anforderungen
- Systemeigenschaften (z.B. Sicherheit)
- Spezielle Anforderungen an die Entwicklung
- Abgeleitete Anforderungen und Designbeschränkungen
- Leistungsanforderungen
- Schnittstellenanforderungen

Getrennt werden die Systemanforderungen in:

- Subsysteme
- Systemkomponenten (Hardware, Software, Schulung, Dokumentation)

2.4 Definition des Anforderungsmanagements

Unter der Begrifflichkeit des Anforderungsmanagements werden verschiedene Passagen, die grundlegend die fundierte und strukturierte Sammlung, Dokumentation, Klassifikation und Pflege der Anforderungen an ein zu entwickelndes System zum Thema haben, verstanden. (Robertson & Robertson, 2013)

Laut IREB (Pohl & Rupp, 2015) wird die Disziplin des Anforderungsmanagements folgendermaßen beschrieben:

Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

- 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.
- 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, ein System auszuliefern, das nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Haupttätigkeiten des RE (nach Rupp et al, 2014, S.14)

So ist ein Teil des Anforderungsmanagements, nämlich die Dokumentation in den letzten Jahren eines der meistdiskutierten Themen in diesem Zusammenhang. Die Dokumentationserstellung und -pflege wird als unerwünschte Aufgabe wahrgenommen, was auch durch die Fehlinterpretation der agilen Werte unterstützt wird. Aussagen wie: „Das Wissen befindet sich doch in den Köpfen der Projektbeteiligten“ werden oft benutzt um das Thema Dokumentation umgehen zu können. Doch Wissen verfällt bzw. diffundiert im Laufe der Zeit wie die Vergessenskurve nach Ebbinghaus zeigt. (Rupp et al, 2014, S.19)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Vergessenskurve nach Ebbinghaus (nach Rupp et al, 2014, S.20)

3 Klassische Methoden

Das Anforderungsmanagement im klassischen Sinne gehört zu den elementarsten Bereichen der Softwareentwicklung, dementsprechend ist es auch stark standardisiert und in den ISO Normen ISO/IEC 12207 und ISO/IEC 15504 wiederzufinden. Außerdem in der Anwendung formalisierter Methoden zur Spezifikation wie beispielsweise Lasten- und Pflichtenhefte. Diese Methoden werden meist in einem wasserfallartigen Modell implementiert, welches vorschreibt, dass Auftraggeber und Auftragnehmer die Anforderungen an das System „Up-Front“, also bereits vor Projektbeginn im Detail definieren. Im Verlauf des Projektes werden diese Anforderungen dann Schritt für Schritt abgearbeitet. Diese Vorgehensweise erscheint aus Business-Sicht immer noch sehr attraktiv, da es die Allokation von Ressourcen vereinfacht und Eventualitäten ausschließt. In der Vergangenheit des Wasserfall-Modells war es noch möglich, modellhafte Anforderungen zu Beginn präzise vorzuschreiben, die durch das ganze Projekt hinweg rigoros durchexerziert wurden. Ob diese Annahmen tatsächlich zutreffend waren, wurde erst in einer sehr späten Phase oder gar erst am Ende des Projekts deutlich. (Möller L., 2019, S. 47 - 48)

3.1 ISO/IEC 12207

Wie bereits in Kapitel 3 erwähnt ist das klassische Requirements Engineering fest in den ISO Normen verankert, der Umfang der ISO 12207:2017 wird in diesem Kapitel näher beschrieben.

3.1.1 ISO/IEC 12207:2017

Dieser internationale Standard legt einen gemeinsamen Rahmen für Software-Lebenszyklusprozesse mit einer klar definierten Terminologie fest, auf den die Softwareindustrie Bezug nehmen kann. Er enthält Prozesse, Aktivitäten und Aufgaben, die bei der Anschaffung eines Softwaresystems, eines Produkts oder einer Dienstleistung sowie bei der Bereitstellung, Entwicklung, dem Betrieb, der Wartung und der Entsorgung von Softwareprodukten anzuwenden sind. Dies geschieht durch die Einbeziehung von Stakeholdern mit dem Ziel, die Kundenzufriedenheit zu erreichen. Dieser internationale Standard gilt für den Erwerb von Softwaresystemen, Produkten und Dienstleistungen, für die Lieferung, Entwicklung, den Betrieb, die Wartung und die Entsorgung von Softwareprodukten und den Softwareteil eines jeden Systems, unabhängig davon, ob er intern oder extern für eine Organisation durchgeführt wird. Software umfasst den Softwareanteil der Firmware. Diejenigen Aspekte der Systemdefinition, die erforderlich sind, um den Kontext für Softwareprodukte und -dienstleistungen bereitzustellen, sind eingeschlossen. Dieser internationale Standard stellt auch Prozesse zur Verfügung, die zur Definition, Steuerung und Verbesserung von Software-Lebenszyklus­prozessen innerhalb einer Organisation oder eines Projekts eingesetzt werden können. (ISO/IEC/IEEE 12207, 2017, S.1)

3.2 RE in verschiedenen klassischen Vorgehensmodellen

Das Requirements Engineering ist in Frameworks verschiedener klassischer Vorgehensmodelle eingebunden, welche im Zuge der vorliegenden Arbeit näher beleuchtet werden sollen.

3.2.1 Wasserfall Modell

Beim Wasserfallmodell handelt es sich um ein lineares Vorgehensmodell in der Softwareentwicklung, welches sich in die folgenden sechs Phasen gliedert und auch jeweils ein Dokumentationsergebnis enthält:

- Machbarkeitsstudie
- Anforderungsanalyse
- Entwurf
- Codierung und Modultest
- Integration und Systemtest
- Installation und Wartung

Ein wichtiges Merkmal an diesem Modell ist, dass die Phasen konsequent nacheinander ausgeführt werden. Das bedeutet in einem weiteren Schritt auch, dass neue Anforderungen beziehungsweise Erweiterungen und Anpassungen nur mit einem Rücksprung von einer in die nächstliegende Vorphase möglich sind. (Gabler Wirtschaftslexikon, 2019)

3.2.2 V-Modell XT

Rupp et. al (2014, S. 53–54) beschreiben das V-Modell XT als ein flexibles Vorgehensmodell, welches zum Planen und Durchführen von Systementwicklungsprojekten entworfen wurde und sich aus modular aufeinander aufbauenden Bausteinen zusammensetzt die projektspezifisch angepasst werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Projektdurchführungsstrategie (V-Modell XT, Version 1.4., S. 21)

So schreiben Friedrich et al (2009, S. 3) in ihrem Buch:

„Herausragende Kennzeichen des V-Modell XT sind seine Anpassbarkeit und Flexibilität. Das V-Modell XT wurde so konzipiert, dass es für unterschiedliche Projektsituationen und Projektgrößen angewendet werden kann. Das Ziel ist es, soviel Dokumentation wie nötig, aber so wenig wie möglich zu erzeugen.“

Auch im V-Modell XT müssen Anforderungen erfasst und strukturiert werden, hier spricht man vom Produkt „Anforderungen“ welches im Vorgehensbaustein „Anforderungsfestlegung“ enthalten ist und auch bereits die Verantwortlichkeiten und Aktivitäten enthält wie in Abbildung 3.3. ersichtlich ist. (Friedrich et al, 2009, S. 5-6)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Vorgehensbaustein Anforderungsfestlegung (Friedrich et al, 2009, S. 6)

4 Agile Methoden

Im agilen Umfeld haben das Ergebnis und der Wert für den Kunden höchste Priorität, aus diesem Grund gibt es anstelle einer einmaligen umfassenden Vorausplanung wie einem Lasten-/Pflichtenheft, eine ständig rollierende Planung in Verbindung mit zügigen Feedbackschleifen durch kurze Iterationen. Diese Vorgehensweise hat den Vorteil, dass der Kunde sehr schnell erste Ergebnisse sehen und den Prototypen bestenfalls auch sofort verwenden bzw. testen kann. Ein starker Fokus liegt im agilen Umfeld auf den Themen Transparenz, Kommunikation und einem Team, welches sich selbst steuert. Dennoch gibt es neben den Werten welche sich im Agilen Manifest oder auch daraus abgeleiteten Methoden wie Scrum oder Extreme Programming finden, auch weitere Aspekte wie z.B. Requirements Engineering die kritisch für den Erfolg von Softwareprojekten sind. Für die erfolgreiche Einführung und den Einsatz agiler Vorgehensweisen ist es daher essentiell, dass einerseits eine Fokussierung des Teams bzw. der Organisation auf die agilen Werten und einer disziplinierten Anwendung der Regeln der von der Organisation gewählten agilen Vorgehensweise erfolgt, und andererseits auch alle anderen für den Erfolg wesentlichen Themen berücksichtigt werden, sodass diese in einer sinnvollen Art und Weise zu einem effektiven Framework für die Softwareentwicklung integriert werden können. (Bergsmann, 2014, S.3)

Bergsmann (2014, S.2) beschreibt weiter, dass das Agile Manifest als ein Meilenstein in der Geschichte der Softwareentwicklung gilt. Die zwölf folgenden Prinzipien hatten eine so große Auswirkung auf die Softwareentwicklung, dass sich darauf basierend alle agilen Methoden etablieren und entwickeln konnten.

Die zwölf Prinzipien hinter dem Agilen Manifest nach Beck et. al (2009):

(1) Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
(2) Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
(3) Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
(4) Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.
(5) Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
(6) Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
(7) Funktionierende Software ist das wichtigste Fortschrittsmaß.
(8) Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
(9) Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
(10) Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
(11) Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
(12) In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Ziel agiler Methoden ist es, Softwareentwicklungsunternehmen bei der schnellen Entwicklung und Veränderung ihrer Produkte und Dienstleistungen zu unterstützen und so die Fähigkeit zu schaffen, sich an dynamische Marktbedingungen anzupassen. (Highsmith & Cockburn, 2001, S.120-127)

Obwohl agile Methoden nur in kleinen bis mittelgroßen Projekten als geeignet angesehen werden (Highsmith & Cockburn, 2001, S.120-127; Boehm, 2002 S. 64-69; Turk & Rumpe, 2005, S.62-87), erkennen Softwareentwicklungsunternehmen zunehmend die Notwendigkeit der Agilität in fast jedem durchgeführten Projekt (Lyytinen & Rose, 2006, S.183–199; Mathiassen & Pries-Heje, 2006, S.116–119) aufgrund von Herausforderungen, die sich aus einer sich ändernden Umgebung, hochkomplexen Benutzeranforderungen und Termindruck ergeben (Boehm, 2002, S. 64-69; Maurer & Melnik, 2006, S.1057–1058; Abrahamsson & Still, 2007, S.410-411). Der Einsatz agiler Methoden stellt jedoch auch Herausforderungen dar, wie z.B. das Fehlen einer ausreichenden Architekturplanung, die Überbetonung früher Ergebnisse und eine geringe Testabdeckung (Highsmith & Cockburn, 2001, S.120-127; Boehm, 2002, S. 64-69).

Es wurden Anstrengungen unternommen, agile Methoden in großen, komplexen Projekten anzuwenden, um schnellere Entwicklungszyklen zu erreichen, jedoch mit gemischten Ergebnissen (Elshamy und Elssamadisy, 2006, S.164–168; Reifer, 2003, S.14–15). Einige Kritiker argumentieren jedoch, dass agile Methoden in großen, komplexen Projekten nicht eingesetzt werden können (Rasmussen, 2003, S.21–28)

4.1 Scrum

Scrum ist ein aus dem Rugby entlehnter Begriff, der auf Deutsch soviel wie „Gedränge“ bedeutet und auf Scrum übertragen für Zusammenhalt im Team und das rigide befolgenden von wenigen Regeln steht. (Gloger B., 2016, S. 6)

Ken Schwaber veröffentlichte auf der OOPSLA ‘95 den ersten Konferenzbeitrag über Scrum. Die Grundthese dieses Beitrags war, dass Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software, welche entsteht, wenn man die Faktoren: Kosten, Funktionalität, Zeit und Qualität entsprechend berücksichtigt. (Gloger B., 2016, S. 21)

Es basiert auf den Prinzipien und Werten aus dem agilen Manifest von Beck et. al. und stellt sich in Hinblick auf den Prozess wie in Abbildung 4.1. ersichtlich dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Scrum Prozess (Kullmann et al, 2013, S. 15)

Gloger (2016, S. 56) erwähnt außerdem, dass durch Scrum der Teamgeist und die Motivation gestärkt werden.

[...]