Entwickeln einer Anforderungsanalysemethodik anhand eines Projektportfoliomanagementsystems

Inhaltsverzeichnis

1 Einleitung
1.1 Ausgangssituation
1.2 Aufgabenstellung
1.3 Zielsetzung der Arbeit
1.4 Vorgehen und Methodik
1.5 Aufbau der Arbeit

2 Theoretische Grundlagen
2.1 Business Systems Engineering und Vorgehensmodelle
2.2 Requirements Engineering
2.2.1 Definition
2.2.2 Zahlen und Fakten
2.2.3 Der Analytiker und seine Probleme
2.2.4 Der Weg zum Anforderungsdokument
2.3 Projektportfoliomanagement
2.3.1 Definition
2.3.2 Voraussetzungen
2.3.3 Maturity Levels

3 Anforderungsanalyse für ein PPM-System

4 Schlussfolgerungen

Abbildungsverzeichnis

Tabellenverzeichnis

Literaturverzeichnis

Index

1 Einleitung

„Aus kleinem Anfang entspringen alle Dinge.”

— Marcus Tullius Cicero

Dieses Kapitel führt in die Problemstellung dieser Arbeit ein. Die Anforderungsana-lyse und das weiter gefasste Requirements Engineering ist der erste und auf keinen Fall zu vernachlässigende Schritt in einem Projekt. Ohne genaue Informationen darüber was geschehen soll, kann man den Verlauf der Produktherstellung nicht verwalten. Im dieser ersten Phase kommt auch Projektportfoliomanagement (PPM) ins Spiel. Das Maturity Level 1^[1] des PPM dient vorwiegend der Projektidentifikation. Ist ein genaues Missionstatement definiert lassen sich hier Redundanzen aufdecken.

1.1 Ausgangssituation

In kleinen Softwarebetrieben kommt es immer wieder vor, dass neue Mitarbeiter (auch ohne Berufserfahrung), auf Grund des Ressourcenmangels, kurz nach ihrem Eintritt, eigene Projekte mehr oder minder alleine bearbeiten müssen. Die ersten Pro-jekte können die Mitarbeiter dabei jedoch zermürben da noch keine Einsicht in diese Materie vorhanden ist. Aus diesem Grund sollte in jeder Firma ein einfach anzuwen-dendes Vorgehen dokumentiert sein, welches angewendet werden kann um grö!ere Schwierigkeiten zu vermeiden. Dies kann jedoch nur funktionieren wenn der Pro-zess durchgehend dokumentiert ist und dabei unterstützend aus einem Pool von be-reits abgeschlossenen und aktiven Projekten Synergien gezogen werden können. Die Herausforderung ist, dass dies in KMU wegen des geringen Mitarbeiterstandes oft vernachlässigt wird und in gro!en Unternehmen wegen zu hoher Komplexität kei-nen Anklang findet. Zusätzlich kommt der Zeitdruck, welcher schnelle Resultate er-zwingt und die Dokumentation oft Au!en vorlässt (diese wird dann kaum mehr bzw. nicht mehr in der gewünschten Qualität nachgeholt). Durch schlechte Ziel- und An-forderungsformulierungen wird wegen Fehlentscheidungen dieser Zeitdruck noch verstärkt.

1.2 Aufgabenstellung

Die primäre Aufgabenstellung dieser Arbeit besteht im bestimmen des Nutzens von Requirements Engineering am Beginn eines Projektes. Dafür soll ein korrekt durchge-führter Analyseprozess beschrieben werden. Zusätzlich soll der Analyseprozess an einem verbunden Thema, dem Projektportfoliomanagement, angewandt werden. Dazu muss eine Einführung in das Projektportfoliomanagement behandelt werden.

1.3 Zielsetzung der Arbeit

Diese Arbeit behandelt die nötigsten Schritte im Bezug auf die Erhebung von Anfor-derungen. Dabei werden keine Fragetechniken oder Ratschläge für Workshops erläu-tert, sondern Hinweise für die Notwendigkeit eines Glossars und der Verifizierung durch den Kunden. Dabei wird Grundlagenforschung für Requierements Engineering und Projektportfoliomanagement betrieben.

Nicht behandelt wird die Erstellung eines neuen Anforderungsanalysemodells, statt-dessen wird sich der Prozess an bestehende Systeme anlehnen.

Die Thematik der Geschäftsprozessdokumentationen wird in dieser Arbeit nur ange-schnitten und kann daher auch nicht als Unterlage für die Einführung einer solchen dienen.

1.4 Vorgehen und Methodik

Zu Beginn wird geeignete Literatur über praxisbezogenes Requirements Engineering sowie theoretische Grundlagen des Business Systems Engineering und Projektportfolio-management gesichtet, bewertet und kategorisiert.

Dies Grundlagen werden zu einem durchgängigen Theorieteil verbunden, welcher danach an einem kleinen Beispiel bis zu einem gewissen Grad erprobt werden. Aus der Anwendung werden folgend Schlüsse für die Anforderungsanalyse gezo-gen.

1.5 Aufbau der Arbeit

Diese Arbeit beginnt mit der abstrakten Ebene des Business Prozess Engineerings, wendet sich dann spezifischern Informationen und der Umsetzung dieser zu und wird dann wieder auf einen höheren Abstraktionslevel gehoben.

Dies geschieht, indem in den theoretischen Grundlagen des Kapitels 2, zuerst die höhere Sicht auf Arbeiten beschrieben wird. Das Stichwort hier ist Buiness Systems Engineering. Danach folgt ein Einblick in das Requirements Engineering. Hierzu wird das Wissen um Business Systems Engineering angewandt, um einen Anforderungs-analyseprozess zu beschreiben. Da Prozesse abstrakt sind, wird er an der Anforde-rungsanalyse an ein Projektportfoliomanagementsystem angewandt. Dies geschieht aufgrund des Umfanges, in diesem Fall nur bis zum Grobkonzept.^[2] Damit die Anfor-derungen klarer verständlich sind, bildet den Abschluss von Kapitel 2, eine Einfüh-rung in das Projektportfoliomanagement.

In Kapitel 3 wird der, in den theoretischen Grundlagen festgehaltene Prozess, am Bei-spiel Projektportfoliomanagementsystem angewandt.

Im schließenden Kapitel 4 werden die Probleme der Anforderungsanalyse beschrie-ben und Fragen für die weitere Vorgehensweise aufgetan.

2 Theoretische Grundlagen

„Es ist alles sehr kompliziert.”

— Fred Sinowatz

Dieses Kapitel dient der Übersicht und dem grundlegenden Verständnis der The-menbereiche dieser Arbeit. Den Anfang bildet ein kurzer Einblick in das Business Systems Engineering (BSE) und Vorgehensmodelle um zu verstehen, warum Prozes-se überhaupt definiert werden. Danach folgen die Grundlagen des Requirements En­gineering (RE, Anforderungsanalyse). Der wirtschaftliche Nutzen sowie ein grober Überblick über die einzelnen Schritte sind die Hauptthemen dieses Abschnittes. Den Schluss dieses Kapitels stellen die Basiselemente des Projekt Portfolio Management (PPM) und dessen Zweck dar.

2.1 Business Systems Engineering und Vorgehensmodelle

„Am Anfang war der Prozess”. So, oder so ähnlich hätte Johannes 1,1ff in der Bibel auch lauten können. Ein Prozesse war laut Duden ein „sich über eine gewisse Zeit er-streckender Vorgang, bei dem etwas (allmählich) entsteht, sich herausbildet”^[3]. Heute nutzt man Definitionen wie jene des Institute for Total Quality Management deren Prozesse ”[eine] Folge von Tätigkeiten, die Wertschöpfung erbringt, indem sie aus einer Input- Vielfalt den verlangten Output erzeugt”^[4] sind.

Somit kann man sagen, dass jede Abfolge von Tätigkeiten einen Prozess darstellt ob man sich dessen bewusst ist oder nicht bzw. ob der Output so und in diesem Ausmaß gewünscht war oder nicht sei dahingestellt.

Business Systems Engineering befasst sich mit den Wechselwirkungen zwischen Stra-tegie und IT. Diese werden als Prozess erfasst und dokumentiert.

In diesem Kontext fällt auch der Begriff Business Process Reengineering. BPR ist ein Konzept das seit Anfang der 90er stark im Kommen ist. Geprägt wurde es von Michael Hammer und James Champy. Das Ziel ist die radikale und rasche Veränderung der Geschäftsprozesse. Dabei wird das gesamte Unternehmen betrachtet um nicht Gefahr zu laufen, unnötige Abläufe zu optimieren. Alle Prozesse werden von Grund auf neu gestaltet um eine hohe Kostenreduktion (ca 70%) zu erzielen. Das gro!e Risiko dabei ist eine starke Einbu!e im Ergebnis.^[5]

In dieser Arbeit wird der Prozess der Anforderungsanalyse als Teil des Softwareent-wicklungsprozesses neu definiert. Das Vorgehensmodell des Softwareentwicklungs-prozesses ist für diese Arbeit nicht weiter von Bedeutung, da in jedem gängigen Mo­dell die Anforderungsanalyse den Grundstein der Entwicklung liefert, obwohl die Modelle an sich natürlich stark differieren. Dies gilt auch für die immer stärker ver-tretenen agilen Prozessen wie deren Vorreiter das XP-Modell.^[6] (siehe Abbildung 2.1)

Natürliche Sprache ist die einfachste Art der Beschreibung von Prozessen. In dieser Arbeit wird zusätzlich die Business Process Modelling Notation verwendet.^[7] Mehr dazu später unter Abschnitt 2.2.4 und Kapitel 4.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Extreme programming business process (BPMN)

Quelle: vgl. WELLS: XP Flow chart ; 2000 [21]

Vor allem in KMUs kommt es vor, dass kein Vorgehensmodel bewusst gelebt wird. Erfahrene Softwareentwickler wenden jedoch immer ein Modell an. Dieses entsteht meistens durch Rückschläge bei vorausgegangen Projekten. Das Problem dabei ist, dass individuell ausgelegte Prozesse erhöhte Prozesskosten nach sich ziehen. Das liegt an den Reibungs- und Wissensverlusten bei Zu- oder Abgängen. Kurzzeitig ist man der Meinung, einen Wettbewerbsvorteil zu erzielen wenn man kein Vorgehens-modell nutzt, jedoch sprechen Studien wie The CHAOS Report 1994 von The Standish Group International, Inc. gegen eine solche Entscheidung.^{[8] [9]} Dies nahmen sich auch zahlreiche Unternehmen zu herzen, da sich die Anzahl der gescheiterten Projekte in den letzen Jahren verringert hat.^[10]

2.2 Requirements Engineering

Fortwährend werden Anforderungen an unterschiedliche Systeme gestellt. Ein Sys-tem muss aber nicht zwingend ein Softwareprodukt sein. Bei dem einfachen Bei-spiel einer Einkaufsliste lässt sich das Problem von Anforderungen gut verdeutli-chen: Wird man gebeten Streichkäse einzukaufen merkt man spätestens im Geschäft wenn man vor dem Regal steht, dass diese Anforderung nicht genau genug spezifi-ziert wurde.^[11]

An diesem Beispiel erkennt man die größten Probleme des Requirements Enginee­ring, nämlich die fehlende Erfahrung mit dem Themengebiet, schlechte Kommuni-kation und die daraus resultierenden Anforderungsänderungen.

Aus Zeit- und Kostengründen bestehen die meisten Anforderungsanalysen aus ei-nem kleinen Interview mit einem Kunden. Dass dabei vergangenheitsorientiert und punktuell vorgegangen wird ist weder dem Kunden noch dem Analytiker bewusst.^[12] Dabei werden meist eine der zwei folgenden Praktiken angewandt:^[13]

Romantische Prosa Abstrakt beschriebene, vage Formulierungen stellen mit vielen Worten keine oder sehr weit interpretierbare Anforderungen dar.

Technischer Exzess Anforderungen werden sofort, ohne die Möglichkeit von Fehl-interpretationen, mit Hilfe von Tabellen und Modellen, von Technikern, für Techniker niedergeschrieben und können vom Fachanwender nicht mehr nach-vollzogen werden (siehe Tabelle 2.1).

2.2.1 Definition

Rupp (2007) liefert folgende Definitionen für Anforderungen und Requirements En-gineering:^[14]

Requirements Engineering befasst sich mit dem systematischen Erheben, Doku-mentieren, Prüfen und Verwalten von Anforderungen Anforderung „Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung ei-nes Produktes, eines Prozesses oder der am Prozess beteiligten Personen”

Folgende Begriffe werden im nachfolgenden Text öfter auftreten und werden hier daher beschrieben:

Stakeholder Sind alle am Erfolg des Projekts interessierten Projektteilnehmer. Dies inkludiert zwar auch die Entwickler, jedoch wird darunter eher ein Fachanwen-der oder ein Entscheidungsträger auf Kundenseite verstanden^[15]

System Besteht aus mehreren in Beziehung stehenden Teilen und bezeichnet die Problemstellung oder auch dessen Lösung

Anforderungen werden erhoben um ein System erstellen zu können. Es soll den Men-schen bei der Informationsverarbeitung unterstützen. Damit dies geschehen kann, muss der Verarbeitungsprozess möglichst genau und der Realität entsprechend be-schrieben werden.^[16]

Anforderung ist aber nicht gleich Anforderung. Die erste Gruppe stellen funktionel-le Anforderungen dar. Sie beschreiben, was das System leisten soll. Daneben gibt es die Gruppe der nicht funktionalen Anforderungen, die beschreiben welche Eigenschaf-ten die funktionalen Anforderungen aufweisen müssen. Eine Liste von diesen Eigen-schaften liefert unter anderem das Volere Template:^[17]

- Look and Feel
- Benutzbarkeitsanforderungen
- Performance / Durchsatz / Kapazität / Sicherheit
- Operationale Anforderungen
- Wartungs- und Portierungsanforderungen
- Zugriffsschutzanforderungen
- Kulturelle und politische Anforderungen
- Rechtliche Anforderungen

Jede einzelne Anforderung muss dabei folgenden Qualitätskriterien entsprechen^[18]:

- Vollständig
- Korrekt
- Klassifizierbar
- Konsistent
- Prüfbar
- Eindeutig
- Verstehbar
- Gültig und aktuell
- Realisierbar
- Notwendig
- Verfolgbar
- Bewertet

Ein Beispiel für korrekte, vollständige und prüfbare Anforderungen ringt Scharbert:^[19] Ein Rabattsystem beschreibt das Entgelt abhängig von der Stückanzahl x. Bei x < 10#, entspricht das Entgelt 10 €/#. X < 25 kosten 8 €/# und x>25 kosten 6€/#. Dies ist die Aussage des Fachanwenders.

Rein aus dieser Angabe würde hervorgehen, dass -1# +/-10€ kosten würde und dass für 25# kein Endgeld verlangt wird.

Das sind Extreme, die der Hausverstand nicht durchgehen lässt. Jedoch ist die Frage, ob nun 10# wirklich mehr kosten dürfen als 12# oder ob Intervalle herangezogen wer-den ist nicht definiert. Diese Anforderung entspricht also nicht den Qualitätskriterien einer Anforderung.

2.2.2 Zahlen und Fakten

Es gibt sehr viele Studien, welche die Notwendigkeit von Requirements Engineering bestätigen. Die bekannteste ist wohl The CHAOS Report 1994 von The Standish Group International, Inc.:^[20]

- 16,2% Erfolg
- 52,7% Misserfolg
- 31,1% Abbruch
- 53% Budgetüberschreitung um mehr als 50%
- 4,4% Budgetüberschreitung um mehr als 400%

Ein Projekt gilt hier als erfolgreich wenn es in der geforderten Zeit, mit dem gegebe-nen Budget in der gewünschten Qualität erstellt wurde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Fehlerbehebungskosten

Quelle: vgl. BERGSMANN : „Requirements-Engineering“; 2003 [2]

In diesem Zusammenhang kann auf den Begriff Frontloading verwiesen werden. Meist scheitern diese Projekte weil zu wenig Arbeit in die Anforderungsanalyse zu Beginn des Projekt (oder Projektabschnittes) gesteckt wird und sich der Gesamtauf-wand dann vergrößert. Dabei sollten folgende Punkte beachtet werden, wenn das Budget und die Terminpläne bereits gesetzt wurden ohne die Anforderungen zu ken-nen: ^[21]

- Sind 20% des Gesamtaufwandes für die Analyse verbraucht wird die Analyse gestoppt
- Da man nicht einfach halbfertige Anforderungen niederschreiben kann, werden weitere 10% für die Fertigstellung benutzt
- Hier werden keine weiteren Anforderungen aufgenommen

Wird Requirements Engineering betrieben, werden Fehler weitestgehend vermieden (diese Entstehen zu 60% während der Analysephase), was wiederum zu Kostenmini-mierung beiträgt (siehe Abbildung 2.2).

Requirements Engineering ist, wie bei der Definition (siehe 2.2.1) erwähnt, mehr als nur das Erheben von Anforderungen. Viel mehr ist es das Verwalten und Verifizieren dieser. Dabei kann man sich die Abbildung 2.3 vor Augen halten, da diese die Ele-mente und deren Basis, von den Anforderungen bis hin zum Projekterfolg darstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Erfolgsbasis

Quelle: vgl. SCHARBERT: Requirements Analysis realisieren ; 2005, S. 47 [18]

2.2.3 Der Analytiker und seine Probleme

In KMU wird der Analytikerberuf meist nicht besetzt und der Softwareentwickler übernimmt diese Aufgaben. Dabei sind diese beiden Aufgaben von unterschiedli-cher Natur. Beide benötigen zwar als ihr Hauptwerkzeug ihren Kopf, arbeiten jedoch an unterschiedlichen Zielen und den damit verbunden Vokabularien. Der Software-entwickler arbeitet auf einer technisch abstrakten Schicht, wobei sich der Analytiker auf der Ebene der Geschäftsprozesse bewegt und dabei sprachlich immer auf der Sei-te der Fachanwender bleibt. Hauptarbeit des Analytikers ist Zuhören, Hinterfragen, Verstehen, Strukturieren sowie das Dokumentieren. Dabei stellt er das Bindeglied zwischen den Entwicklern und den restlichen Stakeholdern dar.

Stakeholder sind alle am Projekt beteiligten Personen wie zum Beispiel der Vertrieb, Controlling, Gesetzgeber und am Wichtigsten der Endanwender.^[22]

Im Zuge seiner Tätigkeit erstellt der Analytiker zuerst eine grobe Sicht auf das zu ent-wickelnde System. Diese Top-Down Methode spiegelt auch das Konzept des Systems Engineering^[23] wieder. Wenn Prozessdetails ausgearbeitet werden, werden auch de-ren Schnittstellen definiert. Ändert man nun den Prozess, kann es vorkommen, dass diese Schnittstellen mitgeändert werden müssen und die damit verbunden Prozesse ebenfalls neu definiert werden müssen.^[24] Dies passiert natürlich immer im Laufe des Projektes, da sich ein kleiner, aber nicht vernachlässigbarer Teil der Anforderungen immer ändern wird. Daher beinhalten gängige Vorgehensmodelle auch einen Mecha-nismus um diese Änderungen einzuarbeiten^[25]. Jedoch kann man diesen Anteil der Änderungen mit einer groben Sicht früher ausfindig machen und daher minimieren.

Die Hauptprobleme bei Softwareprojekten und der Anforderungsanalyse sind nach Rupp folgende:^[26]

- Unklare Zielvorstellungen
- Hohe Komplexität
- Sprachbarrieren
- Veränderliche Anforderungen
- Schlechte Qualität
- Unnötige Merkmale
- Ungenaue Planung

Diese Arbeit fokussiert sich vorwiegend auf die ersten drei Probleme. Daraus lässt sich ableiten, dass der Analytiker ein Sprachtalent ist. Der Analytiker muss sich mit dem Fachanwender verständigen und diese Informationen für die Designer und Ent-wickler leicht verständlich Aufbereiten können. Dabei muss der Analytiker auf die speziellen Eigenschaften dieser beiden Gruppen Rücksicht nehmen (siehe Tabelle 2.1). Daher ist es von Vorteil wenn der Analytiker Software entwickeln kann.

Die korrekte Formulierung von Anforderungen spielt eine gro!e Rolle für das Ver-ständnis und die richtige Auslegung der geforderten Funktionalität. Trotzdem sollte man nicht die wesentlichen Aspekte der Analyse au!er Acht lassen und das ist kor-rekte Anforderungen zu erstellen (siehe Qualitätskriterien unter 2.2.1). Ein Beispiel hierfür wäre die richtige Formulierung der Aussage: „sieben und fünf sind oder ist dreizehn”. ^{[27] [28]}

The Sophist Group liefert für diese sprachlichen Probleme das SOPHIST-REgelwerk^[29]. Es befasst sich mit den Sprachverwirrungen die durch unterschiedliche Erfahrungen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Eigenschaften von Facharbeiter und Software Entwicklern

Quelle: vgl. SCHARBERT: Requirements Analysis realisieren ; 2005, S. 58 [18] und Umfelder der Stakeholder entstehen und liefert eine Schablone (siehe Abbildung 2.4) mit der eine Anforderung niedergeschrieben werden soll.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Anforderungsschablone

Quelle: RUPP: Requirements-Engineering und -Management ; 2007, S. 234 [17]

Diese Schablone ist natürlich nicht für jeden Fall einsetzbar, lenkt den Stakeholder aber in die richtige Denkrichtung um möglichst alle benötigten Informationen bereit-zustellen.

Für diese Arbeit wird davon ausgegangen, dass die Stakeholder nicht bewusst Infor-mationen zurückhalten und dem Entwicklungsprozess offen gegenüberstehen, ob-wohl dies leider kein ungewöhnliches Problem darstellt. In solchen Fällen sind die Analytiker leider machtlos und müssen sich das Wissen um den zu unterstützenden Prozess meist selbst aneignen.

Ist die Zusammenarbeit mit dem Fachanwender nicht fruchtend, kann dies folgende Ursachen haben:^[30]

Fehlende Festlegung Vage Aussagen müssen dem Fachanwender klar gemacht werden und durch konkrete Aussagen ersetzt werden

[...]

---

^[1] Siehe dazu Abschnitt 2.3

^[2] Näheres dazu in Abschnitt 2.2.4

^[3] DUDEN: DUDEN: Deutsches Universalwörterbuch; 1989, S. 1190f [9]

^[4] ITQM: ITQM-Glossar; 2007 [12]

^[5] vgl. BALANCED SCORECARD INSTITUTE: Definitions of Terms; 2007 [1]

^[6] Im XP-Modell greift man gerne auf einen On-Site-Customer zurück. User Stories entsprechen hier den Interviewprotokollen bzw. Use Cases in anderen Vorgehensmodellen — vgl. RUPP: Requirements- Engineering und -Management; 2007, S. 55 [17] ; vgl. RUMPE: Extreme Programming-Back to Basics?; 2001 [16]

^[7] vgl. OBJECT MANAGEMENT GROUP: Business Process Modeling Notation Specification; 2006 [13]

^[8] vgl. THE STANDISH GROUP INTERNATIONAL, INC.: The CHAOS Report 1994; 1994 [19]

^[9] vgl. BERGSMANN: „Vorgehensmodelle“; 2003 [3]

^[10] vgl. THE STANDISH GROUP INTERNATIONAL, INC.: The CHAOS Report 2006; unpublished [20] ;

Zitiert in: vgl. RUBINSTEIN: „Standish Group Report: There’s Less Development Chaos Today“; [2007][15]

^[11] vgl. RUPP: Requirements-Engineering und -Management; 2007, S. 12 [17]

^[12] vgl. BERGSMANN: „Requirements-Engineering“; 2003 [2]

^[13] vgl. RUPP: Requirements-Engineering und -Management; 2007, S. 15 [17]

^[14] RUPP: Requirements-Engineering und -Management; 2007, S. 13f [17]

^[15] vgl. RUPP: Requirements-Engineering und -Management; 2007, S. 544 [17]

^[16] vgl. SCHARBERT: Requirements Analysis realisieren; 2005, S. 34 [18]

^[17] vgl. ROBERTSON UND ROBERTSON: Volere Requirements Specification Template; 2006, S. 4 [14]

^[18] vgl. IEEE: IEEE 830; 1998 [11] ; Zitiert in: vgl. RUPP: Requirements-Engineering und -Management; 2007, S. 27 [17]

^[19] vgl. SCHARBERT: Requirements Analysis realisieren; 2005, S. 53 [18]

^[20] vgl. THE STANDISH GROUP INTERNATIONAL, INC.: The CHAOS Report 1994; 1994 [19] ; Zitiert in: vgl. BERGSMANN: Requirements Engineering: Die Wiege des Projekt-(Miss)-Erfolges; 2003 [4]

^[21] vgl. SCHARBERT: Requirements Analysis realisieren; 2005, S 26 [18]

^[22] vgl. RUPP: Requirements-Engineering und -Management; 2007, S. 93 [17]

^[23] vgl. HABERFELLNER U. A.: Systems Engineering: Methodik und Praxis; 1992 [10]

^[24] vgl. SCHARBERT: Requirements Analysis realisieren; 2005, S 59f [18]

^[252] % der Anforderungen ändern sich jedes Monat (vgl. RUPP: Requirements-Engineering und -

Management; 2007, S. 47 [17] )

^[26] RUPP: Requirements-Engineering und -Management; 2007, S. 25 [17]

^[27] SCHARBERT: Requirements Analysis realisieren; 2005, S. 202 [18]

^[28] Bei mathematischen Ausdrücken heisst es laut DUDEN immer ist. Jedoch ist sieben und fünf zwölf und nicht dreizehn.

^[29] vgl. RUPP: Requirements-Engineering und -Management; 2007, S. 140ff [17]

^[30] vgl. SCHARBERT: Requirements Analysis realisieren; 2005, S 60ff [18]