Herleitung und Validierung eines Modells zur Planung von Requirements Engineering Aktivitäten

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Herleitung und Validierung eines Modells zur Planung von Requirements Engineering Aktivitäten Diplomarbeit im Studiengang Mathematik mit Studienrichtung Informatik von Elizaveta Sarkisyan Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Christoph Walker Betreuer: M. Sc. Eric Knauss Hannover, 30. April 2009

2 Erklärung Hiermit versichere ich, die vorliegende Diplomarbeit selbstständig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet zu haben. Die Arbeit hat in gleicher oder ähnlicher Form noch keinem anderen Prüfungsamt vorgelegen. Hannover, den 30. April 2009 Elizaveta Sarkisyan

3 Danksagung Ich möchte mich an dieser Stelle bei allen herzlich bedanken, die mich in den letzten sechs Monaten unterstützt haben. Für die hervorragende Betreuung meiner Diplomarbeit, die hilfreichen und kompetenten Ratschläge, danke ich Herrn M. Sc. Eric Knauss. Besonderer Dank geht an Uschi Beck und Leif Singer, die mir bei der Korrektur hinsichtlich der Grammatik und der Rechtschreibung halfen und mich emotional unterstützt haben. Uschi, Leif, ich danke euch von ganzem Herzen.

4 Zusammenfassung Requirements Engineering (RE) ist eine sehr wichtige und kritische Phase jedes Software Projektes und doch wird diese oft vernachlässigt. Der Nutzen des RE ist dem Top- Management und Projektleitern nicht bewusst: oft fehlt die notwendige Unterstützung des Top-Managements für RE-Aktivitäten, Projektleiter verwenden die Praktiken des RE nicht. Dies hat zur Folge, dass es oft an notwendigen Ressourcen in dieser Phase fehlt. Für den Requirements Prozess wird ein zu kleiner Anteil der Gesamtprojektkosten investiert, für die Anforderungserhebung ist nicht genügend Zeit vorhanden, die Weiterbildung der Requirements Engineers wird nicht gefördert und die Nacharbeitungskosten auf Grund von Anforderungsdefekten sind sehr hoch. Durch die Sensibilisierung des Top-Managements und der Projektleiter für das Requirements Engineering kann die Wahrscheinlichkeit des Projekterfolgs erhöht werden. In dieser Arbeit wird ein Modell zur Planung von RE-Aktivitäten im Rahmen des Risikomanagements erstellt. Dies geschieht mit dem Ziel, so den Nutzen des Requirements Engineerings zu zeigen. Dafür werden in dieser Arbeit a) typische Risiken in IT- Projekten und b) RE-Aktivitäten als Maßnahmen zu deren Senkung auf Basis einer Literaturrecherche identifiziert. Es wird gezeigt, dass 49% der identifizierten, typischen Projektrisiken auf die Vernachlässigung von RE-Aktivitäten zurückgeführt werden können und die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß von 70% der Risiken durch RE-Aktivitäten gesenkt werden kann. Damit ist der Nutzen des RE projektübergreifend gezeigt. Schließlich wird ein einfaches Werkzeug erstellt, das eine Anwendung des ausgearbeiteten Modells zulässt und bei der Planung von RE-Aktivitäten sowie dem projektspezifischen Aufzeigen des Nutzens von Requirements Engineering in einem konkreten Projekt hilft.

5 Inhaltsverzeichnis 1. EINLEITUNG Motivation Zielsetzung Struktur der Arbeit GRUNDLAGEN Requirements Engineering Projektmanagement Risikomanagement Projekterfolg Requirements-Engineering-Guides CMMI-DEV Automotive SPICE Volere IEEE CobiT Zusammenfassung MODELLIERUNG DES RE-NUTZENS MIT HILFE VON RISIKEN Warum den RE-Nutzen mit Hilfe von Risiken modellieren? Modellierungskonzept zur Demonstration des RE-Nutzens Klassifikationsmodell für Risiken Zusammenfassung STRATEGIE DER LITERATURRECHERCHE RE-ABHÄNGIGE RISIKEN Identifikation der typischen Risiken in IT-Projekten Ergebnis der Klassifizierung Zusammenfassung RISIKEN, DIE MIT RE-AKTIVITÄTEN GESENKT WERDEN KÖNNEN Identifikation der Maßnahmen Analyse der Quellen bei der Ableitung der Maßnahmen Interpretation bei der Ableitung der Maßnahmen Ergänzung der Maßnahmen in RE-Guides Ableitung von RE-Maßnahmen Ergebnis der Identifikation der Maßnahmen Zusammenfassung PLANUNG VON RE-AKTIVITÄTEN IM RAHMEN DES RISIKOMANAGEMENTS Modell zur Planung Projektübergreifende Risikopriorisierung Zielsetzung und Durchführung der empirischen Erhebung Auswertung der empirischen Erhebung Verwendung der Ergebnisse der empirischen Erhebung Validierung des Modells zur Planung von RE-Aktivitäten Zusammenfassung EIN ANWENDUNGSBEISPIEL VERGLEICH VON RE-GUIDES ALS ANWENDUNGSBEISPIEL DER ERGEBNISSE ZUSAMMENFASSUNG UND AUSBLICK Zusammenfassung Ausblick... 65

6 LITERATURVERZEICHNIS ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS ANHANG A: RISIKOFAKTOREN IN IT-PROJEKTEN ANHANG B: KLASSIFIZIERUNG DER TYPISCHEN PROJEKTRISIKEN ANHANG C: IDENTIFIZIERTE MAßNAHMEN ANHANG D: FRAGEBOGEN UND AUSWERTUNG

7 Einleitung 1 1. Einleitung Die Einleitung stellt die Motivation und die Ziele dieser Arbeit vor. Diese werden von einer Beschreibung der Struktur dieser Diplomarbeit gefolgt. 1.1 Motivation Software-Projekte weisen eine hohe Misserfolgs-Quote auf. Es gibt eine Vielzahl von Studien, die die Ausmaße und die Ursachen dieser Situation untersuchen. Die am meisten zitierte Quelle ist der Chaos Report der Standish Group. Der Report wird seit 1994 im 2-Jahres-Rhythmus herausgegeben. Die Untersuchungen der Standish Group von 1994 [Gro1994] zeigen, dass 31,1% der IT-Projekte scheitern. 52,7% werden zwar abgeschlossen, jedoch werden dabei Zeit und Kosten teilweise erheblich überschritten. Lediglich 16,2% der Software-Projekte werden uneingeschränkt erfolgreich abgeschlossen. Im Jahr 2004 verbesserte sich die Erfolgsquote, allerdings scheiterten immer noch rund 18% der IT-Projekte, während hingegen immerhin rund 29% zum Erfolg führten [Gro2005]. Weiterhin litt mit 53% der größte Teil der IT-Projekte unter Kosten- oder Terminüberschreitungen. In dem Chaos Report werden nicht nur ermittelte Ausmaße der fehlgeschlagenen Software-Projekte veröffentlicht sondern auch Erfolgs- und Misserfolgs-Faktoren der Software-Projekte. Die Unterstützung des Top-Managements (Executive Support) wird dabei immer wieder als einer der wichtigsten Erfolgsfaktoren (1994 und 2004: 2. Platz; 2000: 1. Platz) [Gro1994], [Gro2001], [Gro2005]. genannt. Die Tatsache, dass die Anzahl der erfolgreichen Projekte sich zwar seit 1994 positiv verändert hat, aber immer noch sehr gering ist, lässt vermuten, dass die Unterstützung durch das Top-Management weitgehend als notwendig erkannt wird, jedoch in vielen Software-Projekten noch nicht ausreichend vorhanden ist. Die Anforderungen und somit auch das Requirements Engineering, das sich mit Anforderungsanalyse und der Verwaltung von Anforderungen beschäftigt, bilden das Fundament eines jeden Projektes. Die Erfüllung der Anforderungen ist ein wichtiger Erfolgsfaktor der Entwicklung von Soft- und Hardware. Einer ordnungsgemäßen Durchführung der Aktivitäten aus dem Requirements Engineering wird eine Steigerung der Qualität, die Vermeidung von Fehlern und eine Reduzierung der Risiken in Projekten nachgesagt [Bro1987], [Pro2002]. Requirements Engineering wird oft als eine der wichtigsten, aber auch schwierigsten Phasen der Software-Entwicklung bezeichnet [Bro1987], [You2001]. Möglicherweise 80 Prozent der Fehlerbehebung in einem Entwicklungsprojekt können auf Anforderungsdefekte zurückverfolgt werden [Wie2001]. Es existieren genügend Erfahrungen zu effektiven Anforderungspraktiken (z.b. [Jon2007], [Rup2007], [Rob1999]), jedoch werden diese von den meisten Projektmanagern nicht praktiziert [You2001].

8 Einleitung Zielsetzung Das Aufzeigen eines direkten Zusammenhangs zwischen Requirements-Engineering- Aktivitäten und Risiken kann dabei helfen, die Unterstützung durch das Top- Management für Requirements Engineering zu gewinnen sowie die Projektmanager für Requirements-Engineering-Aktivitäten zu sensibilisieren. Eine Demonstration dieses Zusammenhangs ist der Mittelpunkt dieser Diplomarbeit. Das Ziel ist, den Nutzen von Requirements Engineering zu zeigen. Unter dieser Zielsetzung soll ein Modell zur Planung von Requirements-Engineering-Aktivitäten hergeleitet werden. Dafür sollen mittels einer Literaturrecherche typische Risiken und Requirements-Engineering-Aktivitäten als Maßnahmen zur Senkung dieser Risiken identifiziert werden. Abschließend soll ein Werkzeug entwickelt werden, mit dem es möglich ist, das ausgearbeitete Modell zur Planung von RE-Aktivitäten anzuwenden. 1.3 Struktur der Arbeit Die vorliegende Arbeit ist nach diesem Einleitungskapitel wie folgt aufgebaut: In Kapitel 2 werden Grundlagen zum Verständnis dieser Arbeit gelegt. Es wird zunächst eine kurze Einführung in die Aktivitäten des Requirements Engineering sowie die des Projektmanagements gegeben. Gesondert wird der Risikomanagementprozess erläutert. Es wird die in dieser Arbeit verwendete Definition des Begriffes Projekterfolg vorgestellt und diskutiert. Anschließend werden die Reifegradmodelle CMMI-DEV und Automotive SPICE, sowie das Volere Requirements-Prozessmodell und der IEEE830-Standard, die in dieser Arbeit mit dem Begriff Requirements-Engineering-Guide bezeichnet werden, kurz beschrieben. Außerdem wird das CobiT-Referenzmodell betrachtet. Kapitel 3 beginnt mit der Motivation zur Modellierung des Nutzens von Requirements Engineering mit Hilfe von Risiken. Anschließend wird das Konzept zur Modellierung vorgestellt. Das Modellierungskonzept zur Demonstration des RE- Nutzens basiert auf zwei Fragestellungen: a) Wie viele RE-abhängige Risiken treten in Projekten ein? b) Wie viele Risiken können mit Requirements- Engineering-Aktivitäten gesenkt werden, also die Wahrscheinlichkeit des Eintretens von Risikoereignissen verringern bzw. das Schadensausmaß des Risikoereignisses begrenzen? Diese Fragestellungen werden im Laufe dieser Arbeit beantwortet. Ein Teil des Konzeptes ist ein Klassifikationsmodell für Risiken. Dieses Modell wird auch in Kapitel 3 vorgestellt. Für die Realisierung des Konzeptes werden die typischen Risiken sowie Requirements-Engineering- Aktivitäten als Maßnahmen zur Senkung dieser Risiken mittels Literaturrecherche identifiziert. In Kapitel 4 wird die Strategie der Literaturrecherche beschrieben.

9 Einleitung 3 In Kapitel 5 wird auf die identifizierte Literatur speziell für die Identifikation der Risiken eingegangen. Das Ergebnis der Klassifizierung der Risiken wird vorgestellt und die erste Fragestellung des Modellierungskonzeptes beantwortet. In Kapitel 6 wird das Vorgehen bei der Identifikation der Requirements- Engineering-Aktivitäten als Maßnahmen zur Risikosenkung erläutert. Anschließens werden die Ergebnisse dargestellt und die zweite Fragestellung beantwortet. In Kapitel 7 wird das Modell zur Planung von Requirements-Engineering- Aktivitäten vorgestellt. In Kapitel 8 wird die Anwendung eines Werkzeugs demonstriert. Es wird gezeigt, dass die Anwendung des ausgearbeiteten Modells mit diesem Werkzeug möglich ist und bei der Planung von RE-Aktivitäten sowie dem Aufzeigen von RE-Nutzen hilft. In Kapitel 9 wird ein Anwendungsbeispiel der Ergebnisse dieser Arbeit vorgestellt. Die Auswahl eines geeigneten RE-Guides ist eine wichtige planerische Aktivität im Rahmen des Requirements Engineering. Eine Gegenüberstellung der identifizierten Risiken sowie der Maßnahmen, die ein RE-Guide zur Risikosenkung enthält, wird für einen Vergleich der RE-Guides verwendet. In Kapitel 10 werden die wichtigsten Punkte dieser Arbeit zusammengefasst und ein Ausblick auf mögliche zukünftige Arbeiten gegeben.

10 Grundlagen 4 2. Grundlagen In diesem Kapitel werden theoretische Grundlagen zum Verständnis dieser Arbeit geschaffen. Zunächst wird der Begriff Requirements Engineering eingeführt und ein Überblick über die Aktivitäten gegeben, die im Requirements Engineering vorkommen. Anschließend werden die Aktivitäten im Projektmanagement kurz anhand der Wissensbereiche aus dem PMBOK Guide [PMI2004] vorgestellt. Dabei wird erläutert, was der PMBOK Guide ist. In dem hierauf folgenden Abschnitt wird der Risikomanagementprozess beschrieben und eine Definition für den Begriff Risiko gegeben. Für die Identifikation von Risiken ist es ferner wichtig zu wissen, was unter Projekterfolg zu verstehen ist. Deswegen wird diskutiert, wie Projekterfolg in dieser Arbeit definiert ist. In den darauf folgenden Abschnitten werden die grundlegenden Eigenschaften und Konzepte der Requirements-Engineering-Guides sowie das CobiT-Referenzmodell [ISA2008] eingeführt, die in dieser Arbeit für die Ableitung der Maßnahmen zur Risikosenkung verwendet werden. 2.1 Requirements Engineering Requirements Engineering ist die erste Aktivität innerhalb jedes systematischen und strukturierten Softwareentwicklungsprozesses. Das in der Abbildung 2-1 dargestellte Referenzmodell Requirements Engineering gibt einen Überblick über die Aktivitäten, die während der Anforderungsanalyse sowie des Anforderungsmanagements ausgeübt werden. Requirements Engineering Req. Analysis Req. Management Erhebung (Elicitation) Interpretation Abstimmung (Negotiation) Validierung / Verfizierung Dokumentation Änderungsmanagement Verfolgbarkeit (Tracing) Identifikation von Stakeholdern und Quellen von Anforderungen (Altsysteme, Geschäftsprozesse etc.) Erfassung von Rohanforderungen Identifikation von Anforderungen im engeren Sinn Strukturierung - Verfeinerung -Verschmelzung - Gruppierung/ Klassifizierung Konkretisierung (bis zu prüfbaren Erfüllungskriterien Identifikation von Abhängigkeiten Identifikation von Inkonsistenzen Auflösung von Inkonsistenzen Priorisierung Fixierung von Anforderungen, Zwischenständen, Annahmen Administrative Attributierung Inhaltliche Prüfung (Korrektheit, Vollständigkeit, Konsistent) Formale Prüfung (Vollständigkeit, Konsistenz Behandlung von Änderungswünschen Verwalten unterschiedlicher Versionen von Anforderungen (Historie) Propagieren der Änderung (-> Tracing) Festhalten der zugrundeliegenden Annahmen, Quellen von Anforderungen (pre-tracing) Festhalten, wie sich Anforderungen im System manifestieren (post-tracing) Abbildung 2-1: Referenzmodell Requirements Engineering nach [Sch2007a]

11 Grundlagen 5 Die Requirements-Engineering-Aktivitäten werden im Rahmen dieser Arbeit für die Klassifizierung der Risiken benötigt. Die Anforderungsanalyse (Requirements Analysis) umfasst Aktivitäten, um Anforderungen zu ermitteln, abzustimmen, zu formulieren, zu dokumentieren und zu validieren. Das Anforderungsmanagement (Requirements Management) beinhaltet die Verwaltung von Anforderungen und zugehöriger Informationen, um Anforderungsänderungen zu verwalten und die Verfolgbarkeit von Anforderungen zu gewährleisten [Sch2007a]. Die einzelnen Aktivitäten sind in Abbildung 2-1 durch die jeweils enthaltenen Tätigkeiten kurz beschrieben und werden hier nicht weiter erläutert. 2.2 Projektmanagement Projektmanagement ist ein wesentlicher Teil des Software Engineerings, der maßgeblich zum Projekterfolg beiträgt. Hierbei erledigen Softwareprojektmanager dieselben Aufgaben wie Projektmanager in anderen Entwicklungsbereichen [Som2007]. In dieser Arbeit wird folgende Definition verwendet: Definition 2-1 (Projektmanagement) [PMI2004] Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Das Project Management Institute (PMI) ist der US-amerikanische Projektmanagementverband und Herausgeber des meistverbreiteten und international anerkannten Standardwerkes für das Projektmanagement, des Guide to the Project Management Body of Knowledge (PMBOK) [Wik2009], [Jae2009]. Der PMBOK Guide ist die Basis für die Zertifizierungsprüfung zum Project Management Professional (PMP) [PMI2004a]. Er definiert neun Wissensbereiche des Projektmanagements, die in Abbildung 2-2 dargestellt sind. Diese Wissensbereiche geben einen guten Überblick über die Projektmanagementaktivitäten, die im Rahmen dieser Arbeit für die Klassifizierung der Risiken benötigt werden. Jeder Wissensbereich wird durch einzelne Prozesse beschrieben, für die jeweils der notwendige Input, Werkzeuge, Techniken und der Output definiert sind.

12 Grundlagen 6 PROJECT MANAGEMENT 4. Project Integration Management 4.1 Develop Project Charter 4.2 Develop Preliminary Project Scope Statement 4.3 Develop Project Management Plan 4.4 Direct and Manage Project Execution 4.5 Monitor and Control Project Work 4.6 Integrated Change Control 4.7 Close Project 7. Project Cost Management 7.1 Cost Estimation 7.2 Cost Budgeting 7.3 Cost Control 10. Project Communications Management 10.1 Communications Planning 10.2 Information Distribution 10.3 Performance Reporting 10.4 Manage Stakeholders 5. Project Scope Management 5.1 Scope Planning 5.2 Scope Definition 5.3 Create WBS 5.4 Scope Verification 5.5 Scope Control 8. Project Quality Management 8.1 Quality Planning 8.2 Perform Quality Assurance 8.3 Perform Quality Control 11. Project Risk Management 11.1 Risk Management Planning 11.2 Risk Identification 11.3 Qualitative Risk Analysis 11.4 Quantitative Risk Analysis 11.5 Risk Response Planning 11.6 Risk Monitoring and Control 6. Project Time Management 6.1 Activity Definition 6.2 Activity Sequencing 6.3 Activity Resource Estimation 6.4 Activity Duration Estimation 6.5 Schedule Development 6.6 Schedule Control 9. Project Human ResourceManagement 9.1 Human Resource Planning 9.2 Acquire Project Team 9.3 Develop Project Team 9.4 Manage Project Team 12. Project Procurement Management 12.1 Plan Purchase and Acquisitions 12.2 Plan Contracting 12.3 Request Seller Responses 12.4 Select Sellers 12.5 Contract Administration 12.6 Contract Closure Abbildung 2-2: Übersicht der Wissensbereiche des Projektmanagements nach [PMI2004] 2.3 Risikomanagement Risikomanagement wird zunehmend als eine der wichtigsten Aufgaben des Projektmanagements angesehen [Som2007] und wird im Rahmen dieser Arbeit entsprechend der folgenden Definition verwendet. Definition 2-2 (Risikomanagement) [Sch2009] Risikomanagement ist eine systematische Vorgehensweise, um Projektrisiken (aller Art) frühzeitig zu erkennen und während der Projektlaufzeit fortlaufend zu überwachen, um mögliche Nachteile und Verluste zu verringern. Im Folgenden wird einer der ersten formal definierten Risikomanagementprozesse in der Softwareentwicklung vorgestellt, der durch Barry Boehm beschrieben wurde [Boe1989]. Dieser Prozess bildet die Grundlage für das Modell zur Planung von Requirements-Engineering-Aktivitäten im Rahmen des Risikomanagements. Bevor der Prozess erläutert wird, wird kurz auf den Risiko-Begriff eingegangen.

13 Grundlagen 7 Es gibt keine generell akzeptierte Definition für den Begriff Risiko. Die unterschiedlichen Definitionen haben jedoch alle zwei Aspekte gemeinsam: die Unsicherheit über das Eintreten eines Ereignisses und die negativen, unerwünschten Konsequenzen dieses Ereignisses [Wal2004]. Folgende Beispiele belegen dies: Ein Risiko ist ein unerwünschtes Ereignis, das das Erreichen eines bestimmten Ziels gefährdet [Som2007]. Ein Risiko ist die Möglichkeit eines körperlichen oder materiellen Schadens oder Verlustes durch eine Aktivität [Bal2008]. Ein Risiko ist ein potenzielles Problem, das noch nicht eingetreten ist, und von der Verzögerung bis im schlimmsten Fall zum Scheitern des Projektes führen kann [Wal2004]. An uncertain event or condition that, if it occurs, has positive or negative effect on a project s objectives [PMI2004]. Ein Risiko ist ein potenzielles Problem (verbunden mit einem Verlust), das eintreten kann, aber nicht sicher eintritt [Sch2009]. In dieser Arbeit wird folgende Definition verwendet: Definition 2-3 (Risiko) Ein Risiko ist ein potenzielles Problem (verbunden mit Reduzierung der Chance auf Projekterfolg), das eintreten kann, aber nicht sicher eintritt. Definition 2-4 (RE-abhängiges Risiko) Als RE-abhängiges Risiko wird in dieser Arbeit ein Risiko bezeichnet, bei dem das Vernachlässigen von Requirements-Engineering-Aktivitäten die Hauptursache dafür ist, dass dieses Risiko eintritt oder die saubere Durchführung des Requirements Engineering eine Voraussetzung für die erfolgreiche Durchführung einer anderen Aktivität ist, deren Vernachlässigen den meisten Einfluss darauf hat, dass das Risiko eintritt. Barry Boehm gilt als Vater des Software-Risikomanagements. Er hat das Spiralmodell [Boe1988] definiert, ein iteratives, risikogetriebenes Vorgehensmodell für die Softwareentwicklung. In [Boe1989] beschreibt er zudem den ersten Risikomanagementprozess. Viele seither definierten Prozesse gehen auf seinen Grundprozess zurück [Wal2004]. Dies gilt auch für den Risikomanagementprozess des PMI [PMI2004]. Der Risikomanagementprozess von Boehm besteht aus den Teilprozessen Risk assessment (Risikobewertung) und Risk control (Risikosteuerung), wie in Abbildung 2-3 zu sehen ist. Der erste Teilprozess, die Risikobewertung, beinhaltet drei Schritte: Risikoidentifikation: Erstellen einer Liste der projektspezifischen Risiken. Dabei kann z.b. eine Risikocheckliste benutzt werden. Risikoanalyse: Bewertung der identifizierten Risiken. Dazu werden die Eintrittswahrscheinlichkeit, das Ausmaß des möglichen Schadens und die Abhängigkeiten zwischen den Risiken abgeschätzt.

14 Grundlagen 8 Risikopriorisierung: Festlegung der Reihenfolge, in welcher die Risiken bearbeitet werden sollen. Eine mögliche Priorisierung der Risiken ist die quantitative Bewertung und Berechnung des Risikofaktors (risk exposure). Der Risikofaktor lässt sich folgendermaßen berechnen [Boe1991]: Risikofaktor = Eintrittswahrscheinlichkeit * Ausmaß des möglichen Schadens Risk identification Checklists Decision-driver analysis Assumption analysis Decomposition Risk assessment Risk analysis Performance models Cost models Network analysis Decision analysis Risk management Risk priorization Risk exposure Risk leverage Risk management Compound-risk reduction Buying information Risk-management planning Risk avoidance Network analysis Risk control Risk resolution Risk trasfer Risk reduction Risk-element planning Risk-plan integration Prototypes Simulations Benchmarks Analyses Staffing Risk monitoring Milestone tracking Top 10 tracking Risk reassessment Corrective action Abbildung 2-3: Software-Risikomanagement-Prozessschritte nach Boehm [Boe1991] Der zweite Teilprozess, die Risikosteuerung, besteht aus weiteren drei Schritten: Risikomanagementplanung: Festlegen der Maßnahmen zur Risikosenkung, die - die Eintrittswahrscheinlichkeit eines Risikoereignisses vermindern

15 Grundlagen 9 - die negativen Auswirkungen nach Eintreten eines Risikoereignisses verringern. Risikoauflösung: Ausführen der in der Risikomanagementplanung definierten Maßnahmen. Risikoüberwachung: regelmäßige Beurteilung der Wirksamkeit der eingeleiteten Maßnahmen. 2.4 Projekterfolg Um den Nutzen von Requirements Engineering im Zusammenhang mit Risiken zu zeigen, werden in dieser Arbeit zunächst typische Risiken identifiziert. Dafür ist es wichtig zu verstehen, wann ein Projekt als erfolgreich bezeichnet wird und wann nicht. Es gibt keine allgemein gültige Definition für Projekterfolg [Hyv2006]. Die Standish Group [Gro2001] charakterisiert Projekte anhand von drei Ergebnistypen: Successful sind Projekte, die abgeschlossen sind und die Ziele Termintreue, Budgettreue sowie vereinbarte Qualität und Funktionalität erreicht haben. Challenged sind Projekte, die abgeschlossen und in Betrieb sind, jedoch die vereinbarte Qualität und Funktionalität nicht vollständig realisieren und/oder Projektbudget und Projektzeitplan nicht eingehalten haben. Failed sind Projekte, die abgebrochen oder nie implementiert worden sind [Gro2001]. Projektmisserfolg bezieht sich auf die beiden letzteren Ergebnistypen [Lin1999], [Pro2002], [Joh2007]. Die Definition der Standish Group für Projekterfolg ist die am häufigsten verwendete Definition [SUC2006], [Wöl2002], [Hoc2008]. [Lin1999], [Ber2006], [Jon2007], [Tar2008], [Hyv2006], [Kam2007]. Versteegen [Ver2005] erweitert die messbaren Kriterien (Projektbudget, Termintreue) der Beurteilung des Projekterfolgs um die Zufriedenheit des Auftraggebers und die Bezahlung der Abschlussrechnung. Hamidovic und Krajnovic schlagen vor, die Definition der Standish Group um zwei weitere Faktoren zu erweitern: Zufriedenheit des Kunden und Bedeutung des Projektergebnisses für die Organisation [Ham2005]. Jó und Barry, die ihre Forschung nur auf Regierungsprojekte in Entwicklungsländern beschränken, argumentieren, dass die Definition der Standish Group für Projekterfolg um das Kriterium Zufriedenheit der Stakeholder ergänzt werden sollte [Jó2008]. In [Ber2006] wird außerdem die Definition von Baccarani zitiert: Projekterfolg = Projektmanagementerfolg + Produkterfolg. Diese Definition wird dadurch begründet, dass einerseits das Endprodukt erfolgreich sein kann trotz einer Überschreitung von vereinbartem Termin und Budget. Andererseits kann das terminund budgettreue Projekt als erfolgreich bezeichnet werden, obwohl das Endprodukt im Abschluss z.b. auf Grund geänderter Marktgegebenheiten nie benutzt wird und somit in dieser Hinsicht keinen Erfolg hat. Die Studie von Linberg [Lin1999] zeigt, dass sich Projekterfolg aus der Sicht der Entwickler und der des Managements unterscheidet.

16 Grundlagen 10 Dies spricht für die Verwendung der Definition von Baccarani. In dieser Arbeit wird aus folgenden Gründen auf die Definition der Standish Group zurückgegriffen: Alle hier vorgestellten Definitionen haben drei Aspekte gemeinsam: Erfolgreiche Projekte wurden innerhalb des vereinbarten Budgets und der vereinbarten Zeit beendet und entsprachen der Spezifikation. Bei der Angabe der Erfolgs- bzw. Misserfolgsfaktoren unterscheiden die meisten Studien nicht zwischen Produkt- bzw. Projektmanagementerfolg. Ein Ergebnis von Berntsson-Svensson und der Aurum-Studie [Ber2006] ist, dass die Industrie meist die Definition der Standish Group benutzt. Definition 2-5 (Projekterfolg) [Gro2001] Ein Projekt gilt als erfolgreich, wenn es abgeschlossen ist und die Ziele Termintreue, Budgettreue sowie die vereinbarte Qualität und Funktionalität erreicht oder übertroffen wurden. Risiken sind also potenzielle Probleme, die zur Nichterreichung der Ziele Termintreue, Budgettreue sowie vereinbarte Qualität und Funktionalität führen können und im schlimmsten Fall zum Scheitern des Projektes führen. 2.5 Requirements-Engineering-Guides In diesem Abschnitt werden Requirements-Engineering-Guides vorgestellt. Diese werden im Rahmen dieser Arbeit analysiert und miteinander verglichen. Die Analyse dient dazu, die Maßnahmen zu ermitteln, die die Eintrittswahrscheinlichkeit eines Risikoereignisses vermindern bzw. die negative Auswirkung nach Eintreten eines Risikoereignisses verringern. Requirements-Engineering-Guides (RE-Guides) helfen bei vielen Requirements- Engineering-Fragestellungen, von der Gestaltung eines einzelnen Spezifikationsdokumentes bis zur organisationsweiten Prozessverbesserung [Bir2008]. Der Requirements- Engineering-Arbeitskreis der Gesellschaft für Informatik (GI e.v.) verwendet synonym den Begriff RE-Framework [Bir2007]. Definition 2-6 (RE-Guide) Ein RE-Guide ist ein Dokument oder Buch bzw. Abschnitt(e) eines Dokumentes oder Buches, das grundlegende Informationen oder Instruktionen für Requirements Engineering anbietet. Dabei deckt er einen oder mehrere der folgenden Aspekte ab: Rollen und notwendige Qualifikationen für das Requirements Engineering Strukturierung und Dokumentation von Anforderungen Konkrete Techniken, Methoden und Arbeitsanweisungen (das wie ) Tätigkeiten und Aufgaben (das was ) Vorgehen (das wer, wann und was ) Im Rahmen dieser Arbeit werden folgende RE-Guides verwendet:

17 Grundlagen 11 CMMI-DEV, ein Reifegrad- und Referenzmodell für die Systementwicklung [CMM2006] Automotive SPICE, ein Reifegrad- und Referenzmodell für die Entwicklung von softwarebestimmten Systemen [VDA2007] Das Volere Requirements-Prozessmodell und das damit verbundene Volere Spezifikations-Template [Rob1999] IEEE 830, ein Standard zur Gestaltung einer Anforderungsspezifikation für Software [IEE1998] Tabelle 1 zeigt, welche Aspekte der oben eingeführten Definition (markiert durch X) durch die in dieser Arbeit verwendeten RE-Guides abgedeckt sind. Der Aspekt Vorgehen wird von keinem in dieser Arbeit verwendeten RE-Guides abgedeckt. Es existieren jedoch RE-Guides, wie z.b. das V-Modell, die diesen Aspekt abdecken. RE-Guide Rollen und notwendige Qualifikation Strukturierung und Dokumentation von Anforderungen Konkreten Techniken, Methoden und Arbeitsanweisungen Tätigkeiten und Aufgaben Vorgehen CMMI-DEV X X SPICE X X Volere X X X X IEEE 830 X X Tabelle 1: Abdeckung der Aspekte von RE-Guides Im Folgenden werden die genannten RE-Guides vorgestellt CMMI-DEV Das Capability Maturity Model Integration (CMMI) wird vom Software Engineering Institute (SEI) der Carnegie Mellon University herausgegeben. CMMI ist ISO/IEC kompatibel und ist das Nachfolgemodell des CMM [Wal2004]. CMMI ist eine Familie von Referenzmodellen für unterschiedliche Anwendungsgebiete. CMMI for Development (CMMI-DEV) [CMM2006] als Reifegradmodell für die Systementwicklung enthält Leitlinien für die Verwaltung, das Messen und die Überwachung des Entwicklungsprozesses. Das Ziel des CMMI-DEV ist, den Organisationen, die Software, Systeme oder Hardware entwickeln, zu ermöglichen, ihre Entwicklungs- und Wartungsprozesse sowohl für Produkte als auch für Dienstleistungen zu bewerten und damit verbessern zu können. Alle CMMI Modelle sind gleich strukturiert, wie in Abbildung 2-4 dargestellt. Die Inhalte des CMMI-DEV sind in 22 Prozessbereiche (process areas) gegliedert. Ein Prozessbereich (synonym: Prozessgebiet) ist durch zwei Arten von Zielen definiert: Spezifische Ziele sind inhaltliche Ziele und gelten für den jeweiligen Bereich.

18 Grundlagen 12 Generische Ziele gelten übergreifend für verschiedene Prozessbereiche zur Etablierung von Arbeitsweisen in der täglichen Arbeit. Zu jedem Ziel gibt es eine oder mehrere Praktiken, mit denen es erreicht werden kann. CMMI definiert keine konkreten Schritte und Strukturen, sondern nur die Anforderungen an eine gute Produktentwicklung, d.h.: das was, aber kein wie [Foe2007]. Die Prozessbereiche sind vier Kategorien zugeordnet: Process Management, Project Management, Engineering und Support. Kontinuierliche Sicht Sachliche zusammenhängende Ordnung der Prozessgebiete Stufenförmige Sicht Ordnung der Prozessgebiete in sinnvolle Schritte um Software-Organisation zu verbessern Kategorien (Prozessmanagement, Projektmanagement, technische Umsetzung, Unterstützung) Reifegrad (CMMI Stufen 1 bis 5) * 1 * Prozessgebiet (z.b. Projektverfolgung und steuerung oder Anforderungsmanagement ) 1 1 * Spezifisches Ziel (was soll erreicht werden) 1 * Spezifische Praktik (wie Ziel erreicht werden kann) Generische Ziele gelten für mehrere Prozessgebiete (im Gegensatz zu den spezifischen, die für genau ein Prozessgebiete gelten) 1 * Generisches Ziel (was soll erreicht werden) * Generische Praktik (wie Ziel erreicht werden kann) 5 1 Jedes Prozessgebiet hat fünf generische Ziele, die im Prinzip die Qualität der Durchführung des Prozessgebiets (Fähigkeitsgrade) beschreiben. In der stufenförmigen Sicht werden für jede Stufe nicht nur die Prozessgebiete, sondern auch die Stufe der Durchführungsqualität des Prozessgebiets (Fähigkeitsgrad) vorgegeben. 1 Fähigkeitsgrade (0 5) Abbildung 2-4: Aufbau und Struktur von CMMI nach [Foe2003] CMMI unterscheidet fünf Reifegradstufen (Maturity levels), die der Entwicklungsprozess von Software in einem Unternehmen aufweisen kann: Initial, Managed, Defined,

19 Grundlagen 13 Quantitatively Managed und Optimizing. Mit der Erreichung einer höheren Stufe ist eine Verbesserung des Entwicklungsprozesses und der Qualität der erstellten Produkte verbunden. Die Reifegradstufen dienen außerdem der vergleichbaren Bewertung der Prozessqualität von verschiedenen Organisationen. CMMI definiert nach ISO/IEC neben dem Reifegradstufen-Modell auch ein kontinuierliches Fähigkeitsgrade-Modell. Der Fähigkeitsgrad (Capability level) bezieht sich auf jeweils ein Prozessgebiet und dient zur Bewertung der einzelnen Prozessbereiche. Folgende Fähigkeitsgrade werden unterschieden: Incomplete, Performed, Managed, Defined, Qualititatively Managed und Optimizing. Der Fähigkeitsgrad n ist durch einen Prozess erreicht, wenn das generische Ziel n erfühlt ist. CMMI ist für viele internationale Unternehmen und insbesondere für diejenigen, die am nordamerikanischen Markt agieren, zum internen Standard geworden [Hör2006] Automotive SPICE Die ISO/IEC (genannt SPICE ) hat besonders in Europa durch die Entscheidung der meisten Automobilhersteller, ihre Lieferanten nach ISO/IEC zu bewerten, weite Verbreitung gefunden [Hör2006]. SPICE steht für Software Prozess Improvement and Capability Determination. Im Mittelpunkt von SPICE stehen Prozessbewertungen (process assessments), die sowohl zur Reifegradbestimmung der Prozesse als auch zum Aufzeigen von Möglichkeiten zur Prozessverbesserung dienen [Bal2008]. SPICE definiert folgende sechs Reifegradstufen für einzelne Prozesse: Incomplete, Performed, Managed, Established, Predictable und Optimizing. Diese entsprechen den CMMI- Fähigkeitsgraden. Die Prozessreife wird anhand von Prozessattributen beurteilt. Die Prozessattribute sind durch die Indikatoren Generische Produkte, Generische Praktiken und Generische Ressourcen beschrieben. Die ISO/IEC erlaubt die Verwendung verschiedener Prozessreferenzmodelle sowie Prozessassessmentmodelle, um die domänenspezifische Anpassung der Modelle [Hör2006] zu ermöglichen. Automotive SPICE ist eine domänenspezifische Variante des internationalen Standards, die an die spezifischen Bedürfnisse der Automobilbranche angepasst und erweitert wurde. Automotive SPICE, wie in Abbildung 2-5 dargestellt, enthält 31 Prozesse, die sieben Prozessgruppen zugeordnet sind. Diese Prozessgruppen sind wiederum in drei Kategorien zusammengefasst (Primary Life Cycle Processes, Organizational Life Cycle Processes, Supporting Life Cycle Processes). Die Beschreibung jedes Prozesses ist gleich strukturiert und enthält Prozess-ID, Prozessbezeichnung, Zweck des Prozesses, Ergebnisse einer erfolgreichen Umsetzung sowie Base Practices, um diese Ergebnisse zu erreichen.

20 Grundlagen 14 Primary Life Cycle Processes Acquisition (ACQ) ACQ.03 Contract agreement ACQ.04 Supplier monitoring ACQ.11 Technical requirements ACQ.12 Legal and administrative requirements ACQ.13 Project requirements ACQ.14 Request for proposals ACQ.15 Supplier qualification Supply (SPL) SPL.1 Supplier tendering SPL.2 Product release Engineering (ENG) ENG.01 Requirements elicitation ENG.02 System requirements analysis ENG.03 System architecture design ENG.04 Software requirements analysis ENG.05 Software design ENG.06 Software construction ENG.07 Software integration test ENG.08 Software testing ENG.09 System integration test ENG.10 System testing Organizational Life Cycle Processes Support (SUP) SUP.01 Quality assurance SUP.02 Verification SUP.04 Joint Review SUP.07 Documentation management SUP.08 Configuration management SUP.09 Problem resolutionmanagement SUP.10 Change request management Organizational Life Cycle Processes Management (MAN) MAN.3 Project management MAN.5 Risk management MAN.6 Measurement Prozessverbesseung (PIM) PIM.3 Process improvement Reuse (REU) REU.2 Reuse program management Abbildung 2-5: Überblick über die Prozesse in Automotive SPICE Volere Der Volere RE-Guide beinhaltet das Volere Requirements-Prozessmodell und ein damit verbundenes Spezifikations-Template. Dieser Guide ist ein Leitfaden, um Anforderungen zu erheben und testbar zu dokumentieren. Er konzentriert sich auf die Ergebnisse (deliverables), die benötigt werden, um eine prüffähige und nachvollziehbare Anforderungsspezifikation zu produzieren [Rob1999]. Die Inhalte des Volere Requirements- Prozessmodells sind in neun Prozessbereiche gegliedert: Project Blastoff, Trawl For Knowledge, Write The Requirements, Quality Gateway, Prototype The Requirements, Do Requirements Post Mortem, Taking Stock of the Specification, Domain Analysis und Reusing Requirements. Die Prozessbereiche sind durch ihre Ergebnisse miteinander verknüpft und durch Prozesse beschrieben IEEE 830 IEEE 830 ist der vom Institute of Electrical and Electronic Engineers (IEEE) veröffentlichte Standard zur Gestaltung einer Anforderungsspezifikation von Software. Das IEEE hat den erstmals unter ANSI/IEEE Std herausgegebenen Standard mehrmals überarbeitet. Die zurzeit aktuellste Version ist Std : IEEE Recommended Practice for Software Requirements Specifications [IEE1998]. Der Standard beschreibt den Inhalt und die Eigenschaften einer guten Anforderungsspezifikation (Software Requirements Specification).

21 Grundlagen CobiT CobiT (Control Objectives for Information and related Technology) ist ein Referenzmodell, das dabei helfen soll, IT-Risiken zu steuern [Wal2004]. W. Johannsen und M. Goeken [Joh2007] bewerten CobiT als ein wichtiges Instrument zur Reduzierung von Risiken. Deswegen wird CobiT neben der bereits vorgestellten Requirements- Engineering-Guides für die Ableitung der Maßnahmen zur Risikosteuerung verwendet und in diesem Kapitel kurz vorgestellt. CobiT wird vom unabhängigen internationalen Berufsverband Information Systems Audit and Control Association (ISACA) und dem IT Governance Institute (ITGI) herausgegeben. Die Inhalte des CobiT-Prozessmodells sind in 34 Prozesse gegliedert, mit Hilfe derer IT-Ressourcen (Personal, Information, Anwendungen und Infrastruktur) gemanagt werden. In der Prozessbeschreibung werden Geschäftsziele, IT-Ziele, Steuerungs- und Kontrollelemente sowie Metriken genannt. Die Prozesse sind vier Kategorien (auch Kontrollbereiche genannt) zugeordnet: Planung, Entwicklung, Betrieb und Monitoring. Die Kontrollbereiche bilden die Phasen des üblichen IT-Lebenszyklus ab [Joh2007]. Für jeden der 34 CobiT IT-Prozesse wurde ein vom Maturity Model des CMMI abgeleitetes Reifegradmodell festgelegt, das eine inkrementelle Beurteilungsskala von (0) nicht existent bis (5) optimiert enthält [ISA2008]. Monitoring ME1: Überwache und evaluiere IT-Performance ME2: Überwache und evaluiere Internal Controls ME3: Stelle Compliance mit Vorgaben sicher ME4: Sorge für IT-Governance Monitoring Geschäftsziele IT-Ressourcen Anwendungen Information Infrastruktur Personal Planung Planung PO1: Definiere einen strategischen IT-Plan PO2: Definiere die Informationsarchitektur PO3: Bestimme die technologische Richtung PO4: Definiere die IT-Prozesse, Organisation und Beziehungen PO5: Manage IT-Investitionen PO6: Kommuniziere Ziele und Richtung des Managements PO7: Manage die IT-Human-Ressourcen PO8: Manage Qualität PO9: Beurteile und Manage IT-Risiken PO10: Manage Projekte Betrieb DS1: Definiere und manage Service Levels DS2: Manage Leistungen von Dritten DS3: Manage Performance und Kapazität DS4: Stelle den kontinuierlichen Betrieb sicher DS5: Stelle Security von Systemen sicher DS6: Identifiziere und verrechne Kosten DS7: Schule und trainiere User DS8: Manage den Service Desk und Incidents DS9: Manage die Konfiguration DS10: Manage Probleme DS11: Manage Daten DS12: Manage die physische Umgebung DS13: Manage den Betrieb Betrieb Entwicklung Entwicklung AI1: Identifiziere automatisierte Lösungen AI2: Beschaffe und warte Anwendungssoftware AI3: Beschaffe und warte technologische Infrastruktur AI4: Ermögliche Betrieb und Verwendung AI5: Beschaffe IT-Ressourcen AI6: Manage Changes AI7: Installiere und akkreditiere Solutions und Changes Abbildung 2-6: Das CobiT-Referenzmodell

22 Grundlagen Zusammenfassung In diesem Kapitel wurden zunächst kurz die Aktivitäten des Requirements Engineerings sowie des Projektmanagements, die im Rahmen dieser Arbeit für die Klassifizierung der Risiken benötigt werden, vorgestellt. In dem darauf folgenden Abschnitt wurde der Risikomanagementprozess von Boehm betrachtet. Es wurden die Begriffe Risiko und RE-abhängiges Risiko definiert. Anschließend wurde der Begriff Projekterfolg diskutiert und motiviert, weshalb in dieser Arbeit auf die Definition der Standish Group zurückgegriffen wird. Im nächsten Abschnitt wurde der Begriff des Requirements-Engineering-Guides definiert. Die konkreten RE-Guides, die im Rahmen dieser Arbeit für die Ableitung der Maßnahmen verwendet werden, wurden erläutert. Auf Basis dieser Grundlagen kann im folgenden Kapitel nun das Konzept zur Modellierung des Nutzens von Requirements Engineering mit Hilfe von Risiken betrachtet werden.

23 Modellierung des RE-Nutzens mit Hilfe von Risiken Modellierung des RE-Nutzens mit Hilfe von Risiken In diesem Kapitel wird das Konzept zur Modellierung des Nutzens von Requirements Engineering (RE) mit Hilfe von Risiken vorgestellt. Dabei wird begründet, warum der Nutzen von Requirements Engineering im Zusammenhang mit Risiken modelliert wird. 3.1 Warum den RE-Nutzen mit Hilfe von Risiken modellieren? Leute wie Barry Boehm, Grady Booch und Karl Wiegers predigen seit Jahren, auf die Architektur und den Anforderungskatalog also die Vorbereitungsphase zu achten. Man sollte meinen, die Manager hätten inzwischen begriffen, dass Softwareentwicklung nicht ausschließlich aus dem Schreiben vom Quelltext besteht. [McC2004] Einer der wichtigsten kritischen Erfolgsfaktoren in Software-Projekten ist die Unterstützung durch Entscheidungsträger (Top-Management-Unterstützung oder auch Executive Support) [Gro2001], [SUC2006], [Jon2007], [Hoc2008], [Eng2006], [Eng2007]. Eine der Folgen des unzureichenden Executive Supports ist ungenügende Unterstützung des Projektleiters bei Entscheidungen, bei Ressourceneinteilungen und bei Konfliktlösungen [SUC2006]. Vor allem in der Vorbereitungsphase leidet das Requirements Engineering darunter. Dies hat zur Folge, dass es oft an notwendigen Ressourcen in dieser Phase fehlt. Für den Requirements Prozess werden ein zu geringes Budget investiert, für die Anforderungserhebung ist nicht genügend Zeit vorhanden und die Weiterbildung der Requirements Engineers wird nicht gefördert. Die Hauptursache der entstehenden Fehler in der Software Entwicklung sind Anforderungsdefekte [Bas1984], [Wei1993], [Gro1994], [McC2004], [Ver2005], [SUC2006]. Investiert man wenig Zeit in RE, so ist die Gefahr groß, dass das Projekt nicht zum Erfolg wird, da das Endprodukt nicht den Kundenwünschen entspricht und Nacharbeit erfordern wird [Dav2005]. Steve McConnell berichtet in [McC2004] über seine Erfahrung mit dem so genannten PDNH ( Programmiert denn niemand hier? )- oder auch WIESOFA ( Wieso ist Egon so faul? )- Syndrom. Darin beschreibt er die Nicht-Akzeptanz eines Entscheidungsträgers in Bezug auf die Zeitinvestition für Anforderungserhebung und damit verbundene Kunden- sowie interne Gespräche. Folgende zentrale Aussagen aus [You2001a] sind bei einigen Entscheidungsträgern entweder nicht angekommen oder haben nicht genügend Überzeugungskraft: 80% von allen Produktdefekten sind auf Anforderungsdefekte zurückzuführen. Die Nacharbeitungskosten betragen 45% der Gesamtkosten. Die Investition von weniger als 5% der Gesamtkosten des Projektes in den Requirements Engineering Prozess führt erfahrungsgemäß zu % Budgetüberschreitung. Die Investition von 8 14% Gesamtkosten des Projektes dagegen zu weniger als 60%. Deshalb ist es notwendig, einen anderen Weg zu finden, um insbesondere die Entscheidungsträger (Top-Manager) davon zu überzeugen, dass mehr Ressourcen in Require-

24 Modellierung des RE-Nutzens mit Hilfe von Risiken 18 ments Engineering investiert werden müssen, um ein Projekt erfolgreich zu gestalten. In dieser Arbeit wird der Weg über die Risiken verfolgt. Ein funktionierendes und effizientes Risiko-Management sowie eine gelebte Risikound Kontrollkultur ist als Erfolgsfaktor für Unternehmen nicht wegzudenken. Nur jene Unternehmen, die ihre Risiken effizient steuern und kontrollieren sowie ihre Chancen erkennen und nutzen, werden langfristig erfolgreich sein und den Unternehmenswert steigern [Rom2002]. Die Entwicklung des allgemeinen Verständnisses sowie zunehmende Auseinandersetzung mit Risikomanagementfragen ist derzeit in der Wirtschaft festzustellen [KPM2007]. Somit sind Risiken auch für das Top-Management ein Begriff. Wenn sich also zeigen lässt, dass die typischen Risiken sich durch RE-Aktivitäten reduzieren lassen, dann kann über Risiken der Nutzen von Requirements Engineering gezeigt werden. Mit einem vollständigen Risikomanagementplan kann die Unterstützung von Managern leichter gewonnen werden und die Projektprioritäten und damit das Bereitstellen von Ressourcen verbessert werden [Wal2004]. Das Management lässt sich am besten mit konkreten Zahlen im konkreten Fall überzeugen. Es ist also wichtig, den Nutzen von RE über die Risiken auch projektspezifisch zeigen zu können. Außerdem wird durch die Akzentuierung bestimmter Tätigkeiten des Requirements Engineering, die in Bezug zu relevanten Risiken im aktuellen Projekt stehen, Rücksicht auf das Management-Prinzip Konzentration auf Weniges [Bal2008] genommen. Durch das Aufzeigen des Nutzens von Requirements Engineering im allgemeinen Fall (also für alle typischen Risiken) kann die Aufmerksamkeit der Entscheidungsträger auf diese Problematik gerichtet werden. Die konkreten Zahlen im konkreten Projekt (also der projektspezifische Nutzen von Requirements Engineering) dienen dann schließlich der Überzeugung des Top-Managements. 3.2 Modellierungskonzept zur Demonstration des RE-Nutzens Um den RE-Nutzen mit Hilfe von Risiken zu zeigen, werden in dieser Arbeit folgende Fragestellungen beantwortet: Wie viele RE-abhängige Risiken (gemäß Definition 2-4) treten in Projekten ein? Wie viele Risiken können mit Requirements-Engineering-Aktivitäten gesenkt werden, also die Wahrscheinlichkeit des Eintretens von Risikoereignissen verringern bzw. das Schadensausmaß des Risikoereignisses begrenzen? Mit der Beantwortung der Fragen werden folgende Aussagen getroffen: 1. Vernachlässigen der Requirements-Engineering-Aktivitäten führt zur Entstehung von X% derjenigen Probleme, die die Chance auf Projekterfolg reduzieren. 2. RE-Aktivitäten können die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß von Y % der Risiken senken.

25 Modellierung des RE-Nutzens mit Hilfe von Risiken 19 Je höher X bzw. Y sind, desto größer ist der Nutzen von Requirements Engineering. Zunächst werden die Kennzahlen X und Y projektübergreifend (also für alle typischen Risiken bestimmt. In Abbildung 3-1 sind die Schritte des Vorgehens zur Bestimmung der X und Y als UML-Aktivitätsdiagramm dargestellt. Risiken identifizieren Liste typischer Risiken Risiken klassifizieren Liste klassifizierter, typischer Risiken X bestimmen Maßnahmen identifizieren RE-Aktivitäten als Maßnahmenvorschläge Y bestimmen Abbildung 3-1: Übersicht des Vorgehens, um RE-Nutzen über Risiken zu zeigen Mittels einer Literaturrecherche werden in dieser Arbeit typische Risiken identifiziert. Um die Unbekannte X durch eine konkrete Zahl zu ersetzen, werden die Risiken klassifiziert. Dafür wird ein Klassifikationsmodell verwendet, das in Abschnitt 3.3 beschrieben wird. X ist dabei die Prozentzahl der RE-abhängigen Risiken im Verhältnis zur Gesamtanzahl der identifizierten Risiken. X = Anzahl RE-abhängigen Risiken Anzahl identifizierten Risiken * 100% Y ist die Prozentzahl der Risiken, deren Eintrittswahrscheinlichkeit bzw. deren Schadensausmaß durch RE-Aktivitäten gesenkt werden kann. Y = Anzahl der Risiken, die mit RE-Aktivitäten gesenkt werden können Anzahl identifizierten Risiken * 100% Um Y zu bestimmen werden RE-Aktivitäten als Maßnahmen zur Risikosenkung mittels Literaturrecherche identifiziert. Diese Maßnahmen dienen dazu, die Wahrscheinlichkeit für das Eintreten von Risikoereignissen zu verringern (Risikoverminderung) bzw. das Schadensausmaß des Risikoereignisses zu begrenzen (Risikobegrenzung). Treten die Risiken ein, so wird die Chance auf Projekterfolg reduziert. Dieser Zusammenhang ist in Abbildung 3-2 als UML-Klassendiagramm veranschaulicht. Die zweite Aussage besagt, dass es RE-Aktivitäten gibt, die Risiken senken. Das gilt in jedem Fall für die RE-abhängigen Risiken (Kennzahl X). Hinter der Fragestellung steckt aber auch die Annahme, dass Risiken anderer Handlungsfelder, z.b. dem des Projektmanagements, durch RE-Aktivitäten gesenkt werden können. Die Kennzahl Y ist also mindestens so groß wie die Kennzahl X (Y>=X). Nicht alle typischen Risiken sind für jedes Projekt relevant. Risikomanagement ist die Aufgabe jedes Projektmanagers und immer projektspezifisch. Der erste Schritt dabei ist,

26 Modellierung des RE-Nutzens mit Hilfe von Risiken 20 wie in Kapitel 2.3 beschrieben, das Erstellen einer Liste der projektspezifischen Risiken. Die Liste der in dieser Arbeit identifizierten typischen Risiken kann dabei als Checkliste benutzt werden. Die identifizierten Risiken mit den Angaben zur Klassifizierung sowie die Maßnahmen zur Risikosenkung werden im Rahmen dieser Arbeit in ein Modell zur Planung von RE-Aktivitäten integriert. Dadurch wird ermöglicht, die Kennzahlen X und Y projektspezifisch (also im konkreten Projekt) zu bestimmen. Das Modell zur Planung von RE-Aktivitäten wird in Kapitel 7.1 beschrieben. Problem 0..1 tritt ein reduziert Chance auf Projekterfolg Risiko Wahrscheinlichkeit Schadenausmaß 0..* 0..* verringert 0..* 0..* begrenzt Maßnahme Abbildung 3-2: Zusammenhang Maßnahmen und Risiken 3.3 Klassifikationsmodell für Risiken Um die Kennzahl X aus der Aussage Vernachlässigen der Requirements-Engineering- Tätigkeiten führt zur Entstehung von X % der Risiken zu bestimmen, werden die identifizierten Risiken klassifiziert. Das Klassifikationsmodell ist in Abbildung 3-3 dargestellt. Bei der Einordnung jedes Risikos wird die Frage gestellt: Vernachlässigen welcher Aktivität hat den meisten Einfluss darauf, dass dieses Risiko eintritt? Bei der Analyse der identifizierten Risiken wurde festgestellt, dass relevante Risiken im Wesentlichen in drei Bereichen entstehen: im Requirements Engineering, im Projektmanagement und im Entwicklungsprozess. Deswegen wurden für die Klassifizierung vier Klassen gewählt: je eine Klasse für die oben aufgeführten Bereiche sowie eine Klasse für alle anderen Risiken, die keinem dieser Bereiche zugeordnet werden können. Um den Projektmanagern bei der Risikomanagementplanung eine Hilfestellung zu geben, welche Aktivitäten als Maßnahme zur Risikosenkung durchgeführt werden sollten, werden die Klassen in Kategorien und diese weiter in Aktivitäten unterteilt. Die Risiken werden in die jeweilige Klasse nach dem Bottom-up-Prinzip (von Unten-nach-Oben) eingeordnet. Zunächst wird versucht, die Risiken einer Aktivität zuzuordnen. Lässt sich das Risiko mehreren Aktivitäten zuordnen, so wird das Risiko einer Kategorie zugeord-

27 Modellierung des RE-Nutzens mit Hilfe von Risiken 21 net. Ist diese Kategorie nicht eindeutig, so wird das Risiko in die zugehörige Klasse eingeordnet. Die Risiken, bei denen das Vernachlässigen der RE-Aktivitäten den meisten Einfluss hat, werden entsprechend der Klasse Requirements Engineering zugeordnet. Für die Klassifizierung wird dabei das RE-Referenzmodell (siehe Kapitel 2.1) verwendet. Die Aktivitäten Validierung und Verifizierung werden dabei allerdings als zwei eigenständige Unterkategorien betrachtet. Validierung ist die Prüfung inhaltlicher Aspekte, bei der geprüft wird, ob die dokumentierten Anforderungen auch tatsächlich den Kundenanforderungen entsprechen. Die Verifikation ist die Prüfung formaler Aspekte, bei der sichergestellt wird, ob ein neues Dokument konsistent zu vorangegangenen Dokumenten oder einer Referenz ist. Diese zwei Arten von Prüfungen unterscheiden sich nicht nur in den zu prüfenden Aspekten, sonder auch vom Personenkreis, der an der Prüfung beteiligt werden soll. Bei der Validierung ist bspw. die Kundenbeteiligung unerlässlich. Risiken Klassifikation Requirements Engineering Projekt Management Entwicklungsprozess Andere Requirements Analysis Requirements Management Mit Requirements Engineering als Eingabe Ohne RE als Eingabe Produkterstellungs prozess Projektmanagement prozess Requirements Engineering abhängige Risiken Elicitation Interpretation Negociation Dokumentation Validierung Verfizierung Änderungs Management Verfolgbarkeit Integration Mngmt. Scope Mngmt Time Mngmt. Cost Mngmt Quality Mngmt Human Mngmt Communication Mngmt Risk Mngmt Procurement Mngmt Integration Mngmt. Scope Mngmt Time Mngmt. Cost Mngmt Quality Mngmt Human Mngmt Communication Mngmt Risk Mngmt Procurement Mngmt Abbildung 3-3: Klassifikationsmodell Die Risiken, auf die das Vernachlässigen von Projektmanagement-Aktivitäten den meisten Einfluss hat, werden in die Klasse Projektmanagement eingeordnet. Für die Klassifizierung wird dabei der PMBOK Guide (siehe Kapitel 2.2) verwendet. Bei einer genaueren Analyse der Wissensbereiche wurde festgestellt, dass einige Prozesse eng mit dem Requirements Engineering verbunden sind, da diese bspw. product scope und damit Produkt-Anforderungen als Input (Eingabe) haben. Die professionelle Durchführung des Requirements Engineering ist demnach die Voraussetzung für den erfolgrei-

28 Modellierung des RE-Nutzens mit Hilfe von Risiken 22 chen Ablauf dieser Prozesse. Wird Requirements Engineering vernachlässigt, so werden die Risiken, bei denen diese Projektmanagement-Aktivitäten den meisten Einfluss darauf haben, dass die Risiken eintreten, trotz bester Bemühungen im Projektmanagement zu Problemen. Deswegen wird die Klasse Projektmanagement in zwei Kategorien unterteilt: Projektmanagement-Aktivitäten mit RE als Eingabe für diejenigen Aktivitäten, die eng mit Requirements Engineering verbunden sind, und eine Kategorie für diejenigen ohne Requirements Engineering als Eingabe. Jede Kategorie enthält alle Wissensbereiche, weil jeder Wissensbereich Prozesse und somit auch Aktivitäten beider Art enthalten kann. Die Risiken aus der Klasse Requirements Engineering sowie die Risiken aus der Kategorie Projektmanagement mit Requirements Engineering als Eingabe sind Risiken, bei denen Vernachlässigen der Requirements-Engineering-Aktivitäten zur Entstehung von X % der Probleme führt, die die Chance auf Projekterfolg reduzieren. Je größer die Prozentzahl dieser Risiken im Verhältnis zu Gesamtanzahl der Risiken ist, desto höher ist der Nutzen des Requirements Engineering. Die Klasse Entwicklungsprozess wird in zwei Kategorien unterteilt: Produkterstellungsprozess und Projektmanagementprozess. Der Grund für diese Unterteilung ist die Unterscheidung im PMBOK zwischen dem Projektmanagementprozess und dem produktorientierten Prozess. 3.4 Zusammenfassung Viele Software-Projekte und insbesondere die Requirements-Engineering-Aktivitäten leiden unter fehlender Unterstützung des Top-Managements. Es ist notwendig, die Entscheidungsträger vom Nutzen des Requirements Engineerings zu überzeugen. Risikomanagement gewinnt zurzeit an Popularität [KPM2007]. Die Modellierung des RE-Nutzens über die Risiken ist daher erfolgsversprechend, um das Top-Management zu erreichen. Dieser Nutzen wird gezeigt, indem zwei Kennzahlen bestimmt werden: die Prozentzahl X der von Requirements Engineering abhängigen Risiken im Verhältnis zur Gesamtanzahl der identifizierten Risiken, sowie die Prozentzahl Y derjenigen Risiken, deren Eintrittswahrscheinlichkeit bzw. deren Schadensausmaß mit RE-Aktivitäten als Maßnahmen reduziert werden kann. Durch das Aufzeigen des allgemeinen Nutzens von Requirements Engineering zur Vermeidung der typischen Risiken kann die Aufmerksamkeit der Entscheidungsträger auf diese Problematik gelenkt werden. Darüber hinaus dienen die daraus abgeleiteten Kennzahlen X und Y im konkreten Projekt der Überzeugung des Top-Managements. In den folgenden Kapiteln wird die Realisierung des in diesem Kapitel erläuterten Konzeptes beschrieben. Zunächst werden die typischen Risiken und die Maßnahmen zur Risikosenkung mittels Literaturrecherche identifiziert. Die identifizierten Risiken werden anhand des beschriebenen Klassifikationsmodells klassifiziert. Anschließend werden X und Y projektübergreifend bestimmt.

29 Modellierung des RE-Nutzens mit Hilfe von Risiken 23 Die identifizierten Risiken und RE-Aktivitäten als Maßnahmen dienen nicht nur dazu, den Nutzen von Requirements Engineering zu zeigen, sondern sind auch die Eingangsparameter des Modells zur Planung von RE-Aktivitäten im Rahmen der Risikomanagementplanung. Das Modell erlaubt eine projektspezifische Demonstration des RE- Nutzens und wird in Kapitel 7 beschrieben.

30 Strategie der Literaturrecherche Strategie der Literaturrecherche In diesem Kapitel wird die Strategie der Literaturrecherche beschrieben, mit der in dieser Arbeit typische Risiken und die entsprechenden Maßnahmen zur Risikosenkung identifiziert werden. Anschließend werden die identifizierten Quellen als Ergebnis der Durchführung dieser Strategie kurz vorgestellt. Für die Literaturauswahl in dieser Arbeit sind zwei zentrale Fragestellung von Bedeutung: Identifikation der Risiken: Was sind typische Risiken in der IT und insbesondere in der Softwareentwicklung? Identifikation der Maßnahmen: Welche RE-Aktivitäten können als Maßnahmen zur Senkung dieser Risiken eingesetzt werden? Ausgehend von einer Quelle [Dam2006] wird die Literaturrecherche nach dem Schneeballprinzip durchgeführt. Diese Quelle ist aus folgenden Gründen ein geeigneter Ausgangspunkt: Laut Cheng und Atlee [Che2007] ist die Studie von Damian und Chisan eine der wenigen Evaluierungen, wie gut RE-Forschungsergebnisse reale Industrieprobleme adressieren. Sie ist eine der wenigen empirischen Studien über den Einfluss des Requirements Engineerings auf den Projekterfolg. Die Studie enthält einen Vorher-/Nachher-Vergleich und ist somit nachvollziehbar und glaubwürdig. Die Studie ist relativ aktuell (2006). Die Studie wurde in den IEEE Transactions on Software Engineering veröffentlicht, einem wissenschaftlich renommierten Journal, wie es in [Dei2002] bezeichnet wird. Die aus dem Schneeball der ersten Literaturquelle aufgefundene Literatur ist in Abbildung 4-1 als gerichteter Graph mit dem Schneeball als Wurzel dargestellt. Die für die Arbeit relevante, zitierte Literatur aus einer Quelle ist durch eine gerichtete Kante (dargestellt als durchgezogener Pfeil) mit dem Nachfolgeknoten verbunden. Die Studie SUCCESS [SUC2006], eine im Auftrag des Bundesministeriums für Bildung und Forschung (BMBF) durchgeführte Umfrage, wurde bei der Suche nach dem Chaos Report [Gro1994] entdeckt. Diese ist das deutsche Pendant zum Chaos Report und ist daher sehr bedeutsam. Da die Quelle nicht zitiert wurde, sondern bei der Literatursuche im Zusammenhang mit dem Chaos Report entdeckt wurde, ist die Verbindung zwischen den Knoten [Gro1994] und [SUC2006] als gestrichelter Pfeil dargestellt. Die SUCCESS -Studie ist im Gegensatz zum Chaos Report öffentlich zugänglich. Dadurch kann die Literaturrecherche hier nach dem Schneeballprinzip fortgeführt werden.

31 Strategie der Literaturrecherche 25 Die so aufgefundene relevante Literatur mit Bezug zu den o.g. Fragestellungen ist in Tabelle 2 dargestellt. [Wie2001] [Wei1993] [Rob1999] [Dam2005] [Pro2002] [Lev2000] [Kau2004] [Lin1999] [Jon1996] [Dam2006] [Ber2006] [Gro1994] [SUC2006] [Eng2006] [KPM1994] [VDA2007] [Eng2007] [Wal2004] [Ver2005] [McC2004] [Boe1991] [ISA2008] [IEE1998] [Wöl2002] [CMM2006] [Jon2007] Abbildung 4-1: Literaturrecherche nach Schneeballprinzip Der Nachteil der Literaturrecherche nach dem Schneeballprinzip ist, dass die zitierte Literatur immer älter als die zitierende Quelle ist. Um möglichst aktuelle Informationen zu erhalten wurde versucht, bei Studien möglichst die aktuellste Version der zitierten Literatur zu verwenden. Das Schneeballprinzip wird stark von der Qualität des Ausgangspunkts beeinflusst und ist daher relativ selektiv. Daher wird diese Strategie durch

32 Strategie der Literaturrecherche 26 eine Schlagwortsuche ergänzt. Dabei wird eine Schlagwortsuche in den folgenden digitalen Bibliotheken durchgeführt: IEEE Computer Society Digital Library ( ACM (Association for Computing Machinery) Digital Library ( Relevant für die Identifikation der Risiken [Gro1994], [SUC2006], [Eng2007], [Eng2006], [Ver2005], [Wal2004], [KPM1994], [Boe1991], [Ber2006], [Kau2004], [Pro2002], [Lin1999], [Jon2007], [Wöl2002] Tabelle 2: Ergebnisse der Literaturrecherche nach Schneeballprinzip Relevant für die Identifikation der Maßnahmen [Dam2006], [Dam2005], [Rob1999], [Lev2000], [Eng2007], [Eng2006], [Jon1996], [Ver2005], [Wal2004], [ISA2008], [VDA2007], [CMM2006], [McC2004], [IEE1998], [Boe1991], [Wei1993], [Jon2007] Laut Prof. Dr. Christian Wolff [Wol2006] decken diese beiden Bibliotheken wichtige und einschlägige Informatik-Fachzeitschriften und eine Vielzahl von aktuellen Tagungsbänden ab. Folgende Suchbegriffe werden bei der Schlagwortsuche eingegeben: 1. requirements quality and project success 2. project success and success factors Die erste Schlagwortsuche in IEEE Digital Library ergibt vier Ergebnisse. Diese werden vollständig analysiert. Die dabei aufgefundene relevante Literatur mit dem Bezug zu den beiden Fragestellungen ist in der ersten Zeile der Tabelle 3 dargestellt. Die erste Schlagwortsuche in der ACM Digital Library ergibt 5066 Ergebnisse. Diejenigen Ergebnisse, die hiervon in den letzten 10 Jahren erschienen sind, werden selektiert und dadurch auf eine Anzahl von 4671 reduziert. Die Suchergebnisse werden nach Relevanz sortiert und die ersten 10 analysiert. Zunächst werden Einleitung und Schlussfolgerung jedes dieser 10 Papiere gelesen. Wird eindeutig klar, dass die Quelle nicht relevant ist, so wird diese nicht weiter betrachtet. Sonst wird das Papier vollständig analysiert. Dabei wird nur die [Boo2006]-Quelle als relevant eingestuft. Die Suche wird weiter verfeinert, in dem nur die Papiere, der International Conference on Software Engineering (ICSE) selektiert werden. Die Anzahl der Suchergebnisse wird dadurch auf 356 reduziert. Diese werden zunächst nach Veröffentlichungsdatum sortiert. Es werden die Einleitung und Schlussfolgerung der ersten 10 Ergebnisse gelesen, sowie der Titel der nächsten 10 Ergebnisse studiert. Anschließend werden die 356 Ergebnisse nach Relevanz sortiert und die Einleitung und Schlussfolgerung der ersten 10 Ergebnisse gelesen. Zwei dieser Quellen werden vollständig analysiert. Eine der Quellen [Gan2003] wird als relevant eingestuft und kann für die Ableitung einer Maßnahme verwendet werden. Die Titel der nächsten 10 Ergebnisse werden zusätzlich studiert. Abschließend werden die 356 Ergebnisse nach Anzahl der Verwendung als Quelle in anderen Papieren sortiert und nach gleichem Vorgehen analysiert. Es wird hierbei keine weitere Quel-

33 Strategie der Literaturrecherche 27 le als relevant eingestuft. Durch die drei Arten der Sortierung werden immer verschieden Quellen analysiert. Die Recherche wird nicht weiter verfolgt. Schlag wortsuche In IEEE Digital Library Relevant für die Identifikation der Risiken Relevant für die Identifikation der Maßnahmen 1. [Kuj2005] [Kam2007], [Ras2007], [Kuj2005] 2. [Din2008], [Jó2008], [Bed2008], [Ham2005], [Tar2008], [Nel2001], [Thi1999], [Gem1997], [War1996] [Tar2008] Tabelle 3: Ergebnisse der Schlagwortsuche In ACM Digital Library Relevant für die Identifikation der Risiken [Boo2006] Relevant für die Identifikation der Maßnahmen [Boo2006], [Gan2003] Die zweite Schlagwortsuche in der IEEE Digital Library ergibt 22 Ergebnisse. Diese werden nach folgendem Vorgehen analysiert: Zunächst wird die Einleitung und Schlussfolgerung jedes Dokumentes gelesen. Wird eindeutig klar, dass die betreffende Quelle nicht relevant ist, so wird diese nicht weiter betrachtet. Anderenfalls werden die Quellen vollständig studiert. Die dabei aufgefundene relevante Literatur mit dem Bezug zur Fragestellung ist in der zweiten Zeile der Tabelle 3 dargestellt. Die zweite Schlagwortsuche in der ACM Digital Library ergibt 362 eher unspezifische und zu bereits identifizierten Ergebnisse redundante Treffer. Daher wird an dieser Stelle die Schlagwortsuche nicht weiter verfolgt. Zusätzlich zu den recherchierten Quellen werden auch andere bekannte relevante Quellen verwendet. Diese Quellen sind in der Tabelle 4 mit dem Bezug auf die Fragestellung aufgelistet. Relevant für die Identifikation der Risiken [Hoc2008], [Fir2007], [Kna2007], [Dav2005] Tabelle 4: Einordnung der bekannten Quellen Relevant für die Identifikation der Maßnahmen [Fir2007], [Kna2007], [Sch2007], [Dav2005], [Kir1997] Die Literaturrecherche zu der Fragestellung, was typische Risiken in IT-Projekten sind, zeigt, dass diese Fragestellung seit Jahren aktuell ist. Die Standish Group ( und auch das Software Quality Lab ( führen dazu regelmäßige Umfragen durch. Es existieren viele Studien, die sich dieser Fragestellung annehmen. In dieser Arbeit fließen insgesamt 29 relevante Quellen zur Identifikation von Risiken ein, die in der zweiten Spalte der Tabelle 5 aufgelistet sind. Es werden 12 Quellen verwendet, um die Risiken zu identifizieren. 17 weitere Quellen, die sich mehr oder weni-

34 Strategie der Literaturrecherche 28 ger mit dieser Thematik beschäftigen, enthalten keine neuen Risiken. Daraus kann gefolgert werden, dass die typischen Risiken weitgehend identifiziert werden. Im folgenden Abschnitt wird näher auf die verwendete Literatur eingegangen. Die Literaturrecherche zur Fragestellung welche RE-Aktivitäten als Maßnahmen zur Senkung dieser Risiken eingesetzt werden können, erweist sich als komplizierter als diejenige zur Identifikation der Risiken. Seit dem ersten Chaos Report 1994 wird die Fragestellung, was typische Risiken in IT-Projekten sind, oft diskutiert. Die Maßnahmen zur Risikosenkung als eine Lösung dagegen werden meistens nicht weiter analysiert. Unter den analysierten Quellen finden sich nur wenige, die die Risiken und Maßnahmen zu deren Senkung explizit adressieren. Dadurch wird die Interpretation der Quellen unumgänglich. Einige Maßnahmen werden auf Grund der impliziten Beschreibung erhoben und andere geschlussfolgert. Das Vorgehen bei der Identifikation der Maßnahmen und die dabei verwendete Quellen werden im Kapitel 6.1 erläutert. In dieser Arbeit fließen insgesamt 28 relevanten Quellen für die Identifikation der Maßnahmen zur Risikosenkung ein, die in der dritten Spalte der Tabelle 5 aufgelistet sind. Aus diesen Quellen wird nicht nur zu jedem RE-abhängigen Risiko mindestens eine RE-Maßnahme identifiziert, sondern auch für die Risiken aus anderen Handlungsfeldern. Dadurch ist die Literaturrecherche zu der Fragestellung, welche RE-Aktivitäten als Maßnahmen zur Senkung dieser Risiken eingesetzt werden können zwar nicht vollständig, jedoch ausreichend, um die Annahme Y>X zu bestätigen und den Nutzen von Requirements Engineering mit Hilfe von Risiken zu zeigen. Auf die Ergebnisse der Identifikation der Maßnahmen wird im Kapitel 6.2 detaillierte eingegangen. Art der Literaturrecherche Schneeballprinzip Schlagwortsuche Analyse der bekannten Quellen Relevant für die Identifikation der Risiken [Gro1994], [SUC2006], [Eng2007], [Eng2006], [Ver2005], [Wal2004], [KPM1994], [Boe1991], [Ber2006], [Kau2004], [Pro2002], [Lin1999], [Jon2007], [Wöl2002] [Kuj2005], [Boo2006], [Din2008], [Jó2008], [Bed2008], [Ham2005], [Tar2008], [Nel2001], [Thi1999], [Gem1997], [War1996] [Hoc2008], [Fir2007], [Kna2007], [Dav2005] Relevant für die Identifikation der Maßnahmen [Dam2006], [Dam2005], [Rob1999], [Lev2000], [Eng2007], [Eng2006], [Jon1996], [Ver2005], [Wal2004], [ISA2008], [VDA2007], [CMM2006], [McC2004], [IEE1998], [Boe1991], [Wei1993], [Jon2007] [Kam2007], [Ras2007], [Kuj2005], [Boo2006], [Gan2003], [Tar2008] [Fir2007], [Kna2007], [Sch2007], [Dav2005], [Kir1997] Tabelle 5: Ergebnis der Literaturrecherche Um den Nutzen von RE zu zeigen, gibt es im Rahmen dieser Arbeit zwei Fragestellungen. Die erste Fragestellung ( Wie viele RE-abhängige Risiken treten in Projekten

35 Strategie der Literaturrecherche 29 ein? ) wird im nächsten Kapitel auf Basis der in diesem Kapitel vorgestellten Strategie zur Literaturrecherche beantwortet. In dem darauf folgendem Kapitel 6 werden die mittels dieser Strategie identifizierten Quellen analysiert, die für die Identifikation der Maßnahmen relevant sind. Anschließend wird die zweite Fragestellung beantwortet.

36 RE-abhängige Risiken RE-abhängige Risiken In diesem Kapitel wird kurz auf die identifizierte Literatur speziell für die Identifikation der typischen Risiken eingegangen. Anschließend werden die Ergebnisse der Klassifizierung der identifizierten Risiken vorgestellt. Die Fragestellung wie viele REabhängige Risiken (gemäß Definition 2-4) in Projekten eintreten wird beantwortet und damit die projektübergreifende Kennzahl X spezifiziert. 5.1 Identifikation der typischen Risiken in IT-Projekten Aus der Literaturrecherche nach dem Schneeballprinzip und der Verwendung bekannter Quellen werden typische Risiken identifiziert. Die aufgefundenen Studien, die dabei verwendet sind sowie deren Eckdaten sind in Tabelle 6 zusammengefasst. Quelle Land Jahr Umfang Methode Teilnehmer Untersuchungsfrage [Hoc2008] DE 2008 keine Angabe Umfrage IT- Verantwortliche Umfrage [Eng2007] DE Unternehmen Projektmanager unterschiedlicher Branchen Die größten Risikofaktoren in Ihren IT- Projekten Ursachen für das Scheitern von Projekten [Eng2006] DE und DK [SUC2006] DE Unternehmen aus DE 150 Unternehmen aus DK Umfrage 378 Befragte Interviews und Onlinebefragungen [Gro1994] USA Befragte Umfrage und Interviews [KPM1994] UK Befragte Telefonische Umfrage [Jon2007] NA Projekte Assessements und Benchmarks Projektmanager unterschiedlicher Branchen Projektleiter und Entwickler IT Executive Managers IT Manager keine Angabe Gründe für den Misserfolg bei Projekten Ermittlung von Erfolgs- und Misserfolgsfaktoren Ermittlung von Erfolgs- und Misserfolgsfaktoren Gründe für das Projektversagen Ermittlung von Erfolgs- und Misserfolgsfaktoren Tabelle 6: Eckdaten der verwendeten Studien zur Risikoidentifikation Die Originalangaben zu den Risikofaktoren in IT-Projekten dieser Studien befinden sich in Anhang A.

37 RE-abhängige Risiken 31 Zur Ermittlung der Risiken werden nicht nur Gründe für den Misserfolg bei Projekten, sondern auch Erfolgsfaktoren herangezogen. Der Grund dafür ist meine persönliche Überzeugung, dass es in der menschlicher Natur liegt, das Positive lediglich dann bewusst zu erkennen, wenn es einmal gefehlt hat. Die Teilnehmer der Studien sind überwiegend Manager. Diese Tatsache zeigt, dass die Identifikation der Risiken in dieser Arbeit sich nicht speziell auf RE-abhängige Risiken konzentriert und der Anteil der RE-abhängigen Risiken nicht beabsichtigt beeinflusst wird. Zusätzlich zu den oben genannten Studien wird zunächst die Literatur verwendet, die in Tabelle 7 mit den Angaben zu Risiken dargestellt ist. Boehm [Boe1991] und Versteegen [Ver2005] nennen dabei explizit Risikofaktoren. Firesmith [Fir2007] beschreibt 12 übliche Anforderungsprobleme und deren Konsequenzen. Diejenigen Anforderungsprobleme, die als negative Konsequenzen den Projekterfolg gemäß Definition 2-5 gefährden, werden als Risiko erkannt. Auch [Kna2007] und [Dav2005] nennen die Risiken implizit, indem sie die Anforderungsprobleme im Kontext von Projekterfolg beschreiben. Im Gegensatz zu den oben genannten Studien, die die Ergebnisse der systematischen Ermittlung von Risikofaktoren wiedergeben, berichten die Autoren über ihre eigenen Erfahrungen. Quelle [Fir2007] [Kna2007] [Dav2005] [Ver2005] [Boe1991] Risiken Schlechte Qualität der Anforderungen; Übergewichtung der Use Cases; Dokumentierte Anforderungen sind nicht verfolgbar; Fehlende Anforderungen; Ineffektive Änderungskontrolle der Anforderungen; Inadäquate Verifikation der Anforderungen (Anforderungsdefekte werden nicht rechtzeitig identifiziert und mit dokumentiert); Inadäquate Anforderungsvalidierung (Anforderungen werden nicht immer von den Stakeholdern validiert); Unzureichendes Anforderungsmanagement Übergewichtung der Use Cases; Nicht-Funktionale Anforderungen werden vernachlässigt; Anforderungen sind nicht testbar dokumentiert; Mangel an qualifizierten Mitarbeitern (technische, fachliche, psychologische Kompetenzen); Mangelhafte Anforderungsspezifikation Anforderungen sind nicht bekannt; Mangel an Ressourcen; Mangelhafte Anforderungsspezifikation Zu hohe Erwartungen an Projekte; unklare Anforderungen; wechselnde Technologien; mangelnde Kommunikation; zu späte Integration und fehlende Werkzeugunterstützung; zu hohe Dokumentenorientierung; fehlende Prozessmodelle; mangelnde Ausbildung; fehlende Ressourcen; fehlende Qualitätssicherung; nachlassende Produktivität bei mehrjährigen Projekten Personelle Defizite; Unrealistische Zeit- und Kostenplanung; Entwicklung falscher Funktionen und Eigenschaften; Entwicklung falscher Benutzerschnittstellen; Gold Plating (unnötige, überflüssige Eigenschaften); Ständige Änderung der Anforderungen; Defizite in externen Komponenten; Defizite in extern ausgeführten Aufgaben; Unzureichende Performance; Überschätzung der eigenen Informatikfähigkeiten Tabelle 7: Auszug der Risiken aus der Literatur

38 RE-abhängige Risiken 32 Die Analyse weiterer identifizierter Quellen ergibt keine, zusätzlich zu bereits identifizierten, neuen Risiken. Die betriebswirtschaftliche Studie der Schweizer Informatikabteilungen [Wöl2002] zu den Gründen für gefährdete oder gescheiterte Projekte sowie folgende weitere Literaturquellen berichten über bereits identifizierte Risiken [Wal2004], [Kau2004], [Lin1999], [Pro2002], [Jó2008], [Bed2008], [Ham2005], [Tar2008], [Nel2001], [Thi1999], [Gem1997], [War1996], [Kuj2005] und [Boo2006]. Auch die Autoren der Studien [Ber2006] und [Din2008], die eine ähnliche Literaturrecherche durchgeführt haben, bestätigen die schon aufgenommenen Risiken. Daraus lässt sich schließen, dass die typischen Risiken in IT-Projekten weitgehend identifiziert worden sind. 5.2 Ergebnis der Klassifizierung Es werden insgesamt 70 typische Risiken identifiziert. Diese werden unter Verwendung des Klassifikationsmodells für Risiken klassifiziert. Das Ergebnis der Klassifizierung ist in Abbildung 5-1 dargestellt. 22 Risiken (also 31,43% aller Risiken) sind aus dem Bereich des Requirements Engineerings. 27 Risiken (also 38,57% aller Risiken) kommen aus dem Projektmanagement-Bereich, davon haben 12 Risiken (also 17,14% aller Risiken) Ergebnisse des Requirements Engineerings als Eingabe. Außerdem sind 7 Risiken aus dem Bereich des Entwicklungsprozesses und 14 andere Risiken vorhanden. In Anhang B sind alle identifizierten Risiken mit ihrer jeweiligen Klassifizierung aufgelistet. Andere 20,00% Entwicklungsprozess 10,00% Requirements Engineering 31,43% Projekt Management ohne RE als Eingabe 21,43% Projekt Management mit RE als Eingabe 17,14% Abbildung 5-1: Ergebnis der Klassifikation aller typischen Risiken in IT-Projekten

39 RE-abhängige Risiken 33 Die erste Fragestellung, die in Kapitel 3.2 aufgestellt wurde, um den RE-Nutzen mit Hilfe der Risiken zu zeigen, kann somit projektübergreifend beantwortet werden: Vernachlässigen der Requirements-Engineering-Aktivitäten führt zur Entstehung von 49% derjenigen Probleme, die die Chance auf Projekterfolg reduzieren. Das heißt auch, dass mindestens 49% der Risiken durch RE-Aktivitäten gesenkt werden können, also die Wahrscheinlichkeit für das Eintreten von Risikoereignissen verringert bzw. das Schadensausmaß des Risikoereignisses begrenzt werden kann. 5.3 Zusammenfassung Mittels Literaturrecherche wurden 70 typische Projektrisiken identifiziert. 49% der in dieser Arbeit identifizierten Risiken sind RE-abhängige Risiken. Damit ist die erste Fragestellung, die in Kapitel 3.2 gestellt wurde, um den RE-Nutzen mit Hilfe der Risiken zu zeigen, projektübergreifend beantwortet. Im folgenden Kapitel wird auf die zweite Fragestellung des Modellierungskonzepts zur Demonstration des Nutzens von Requirements-Engineering ( Wie viele Risiken können mit Requirements-Engineering- Aktivitäten gesenkt werden? ) und somit auf die Identifikation geeigneter Maßnahmen eingegangen.

40 Risiken, die mit RE-Aktivitäten gesenkt werden können Risiken, die mit RE-Aktivitäten gesenkt werden können Dieses Kapitel geht auf die zweite zentrale Fragestellung dieser Arbeit ein, wie viele Risiken mit Requirements-Engineering-Aktivitäten gesenkt werden können, um den RE-Nutzen mit Hilfe von Risiken zu zeigen. Um den Anteil dieser Risiken zu bestimmen, werden relevante Maßnahmen mittels einer Literaturrecherche identifiziert. Die Strategie der Literaturrecherche ist in Kapitel 4 erläutert worden. In diesem Kapitel wird detaillierter auf die speziell für die Identifikation der Maßnahmen verwendete Literatur eingegangen. Dazu werden unter anderem die RE-Guides analysiert, die bei der Literaturrecherche identifiziert werden konnten. Anschließend wird die projektübergreifende Kennzahl Y spezifiziert und damit die zugehörige Aussage RE-Aktivitäten können die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß von Y % der Risiken senken. konkretisiert. 6.1 Identifikation der Maßnahmen Die in der Literaturrecherche aufgefundene Literatur wird auf geeignete Maßnahmen zur Risikosenkung analysiert. Das sind Maßnahmen, die entweder die Eintrittswahrscheinlichkeit eines Risikoereignisses vermindern oder die negativen Auswirkungen nach Eintreten eines Risikoereignisses verringern. Zunächst werden die in Kapitel 2.5 beschrieben RE-Guides sowie das CobiT-Referenzmodell studiert. Diese werden auf alle möglichen Maßnahmen ohne Einschränkung auf die RE-Aktivitäten analysiert, um einen möglichst vollständigen Vergleich dieser Quellen zu ermöglichen. Anschließend werden weitere mittels Literaturrecherche identifizierte Quellen analysiert. Die RE- Guides werden miteinander und mit weiteren Literaturquellen verglichen. Die dokumentierten Maßnahmen zur Risikosenkung in den RE-Guides werden durch weitere Maßnahmen ergänzt. Abschließend werden die RE-Aktivitäten aus den abgeleiteten Maßnahmen extrahiert und dokumentiert. Zusammengefasst besteht die Identifikation der Maßnahmen aus folgenden Schritten: Maßnahmen ableiten - Analyse der Quellen - Interpretation des Textes - Dokumentation der Maßnahmen - Vergleich der Quellen und Ergänzung der Maßnahmen in RE-Guides RE-Maßnahmen ableiten - Analyse aller Maßnahmen und Extrahieren von RE- Aktivitäten - Dokumentation der RE-Maßnahmen Im Folgenden wird zunächst der Schritt Maßnahmen ableiten beschrieben.

41 Risiken, die mit RE-Aktivitäten gesenkt werden können Analyse der Quellen bei der Ableitung der Maßnahmen Requirements-Engineering-Guides (RE-Guides) helfen bei vielen Requirements- Engineering-Fragestellungen [Bir2008]. Die SEI-Untersuchung in 35 Organisationen zeigt, dass die Verwendung des CMMI zur Verbesserungen der Kosten, Termineinhaltung, Produktivität, Qualität und Kundenzufriedenheit führt [Gib2006]. Laut Erfahrungsberichten hat auch die Verwendung des Volere-Guides einen positiven Einfluss auf den Projekterfolg [Vol2009]. CMMI, SPICE und IEEE 830 entstanden jeweils aus der Zusammenarbeit vieler Experten und wurden auf Grund der Praxiserfahrung überarbeitet. Die im Rahmen der Literaturrecherche (siehe Kapitel 4) identifizierten RE- Guides sind somit jeweils qualitativ hochwertige Quellen für die Identifikation von Maßnahmen. Im Folgenden wird zunächst auf die Analyse der RE-Guides eingegangen. Für jeden RE-Guide wird zuerst das Vorgehen beschrieben und anschließend ein oder mehrere Beispiele in tabellarischer Form angegeben. Die Tabellen sind dabei wie folgt organisiert: Die erste Spalte enthält die Risikobezeichnung. Die zweite Spalte enthält die Maßnahme zur Senkung dieses Risiko. - Die Maßnahmen sind in Form eines Verweises auf den Abschnitt, aus dem die Maßnahme abgeleitet wird, dokumentiert. Dabei werden die Abbreviaturen des Abschnittes der Originalquelle und keine Seitenzahlen benutzt, um die Verwendung anderer Versionen der Guides zu vereinfachen. - Die Maßnahmen, die die Wahrscheinlichkeit für das Eintreten von Risikoereignissen verringern, sind bei der Dokumentation mit (E) gekennzeichnet. - Die Maßnahmen, die das Schadensausmaß des Risikoereignisses begrenzen, sind bei der Dokumentation mit (S) gekennzeichnet. Die dritte Spalte enthält einen Ausschnitt des Originaltextes, der ausschlaggebend für das Erkennen einer Maßnahme ist. Außerdem wird ein Verweis auf die Textstelle des Abschnittes angegeben, der die Maßnahme entnommen wurde. Diese Spalte dient der Nachvollziehbarkeit der Maßnahmenableitung und wird als Begründung für Ableitung der Maßnahme verwendet. CMMI-DEV-Guide Bei der Ableitung der Maßnahmen wird die aktuelle Originalquelle CMMI for Development Version 1.2 [CMM2006] (im Folgenden CMMI-DEV-Guide genannt) verwendet. Im CMMI-DEV-Guide wird der Zweck (Purpose), die Einleitung (Introductory Notes) und insbesondere die spezifischen Ziele (SG) und Praktiken (SP) (Specific Goal and

42 Risiken, die mit RE-Aktivitäten gesenkt werden können 36 Practice) jedes Prozessbereiches studiert. Zusätzlich werden generische Ziele (GG) und Praktiken (GP) analysiert. Ein Ziel bzw. eine Praktik wird hierbei als Maßnahme erkannt, wenn die Beschreibung dieses Zieles bzw. dieser Praktik die Tätigkeit oder das Ergebnis enthält, die das Risiko senkt. Einige Maßnahmen werden auch aus der einleitenden Beschreibung (Intoductory Notes) der Prozessbereiche abgeleitet. In der Tabelle 8 ist ein Beispiel angegeben. Die Abbreviatur in den Klammern bei der Dokumentation der Maßnahmen verweist auf den zugehörigen Prozessbereich, hier Requirements Development (RD). SG 2 verweist auf das zweite spezifische Ziel des Prozessbereichs. Wird das Ziel erreicht, so wird die Eintrittswahrscheinlichkeit des Risikos Dokumentierte Anforderungen sind nicht verfolgbar reduziert. Risiko Dokumentierte Anforderungen sind nicht verfolgbar CMMI-DEV Maßnahme zur Risikosteuerung (RD) SG 2 Develop Product Requirements (E) Tabelle 8: Beispiele zur Erhebung der Maßnahmen aus CMMI-DEV Automotive SPICE -Guide Begründung Beschreibung des Zieles: The traceability of requirements to functions, objects, tests, issues, or other entities is documented. Bei der Erfassung der Maßnahmen wird die aktuelle Originalquelle Automotive SPICE Prozessassessment Version 2.3 [VDA2007] verwendet. Im Automotive SPICE -Guide wird die Beschreibung jedes Prozesses analysiert. Wie schon in Kapitel beschrieben, ist die Beschreibung jedes Prozesses gleich strukturiert und enthält Prozess-ID, Prozessbezeichnung, Zweck des Prozesses, Ergebnisse einer erfolgreichen Umsetzung sowie Base Practices, um diese Ergebnisse zu erreichen Eine Base Practice wird als eine Maßnahme erkannt, wenn durch ihre Umsetzung ein Ergebnis erreicht wird oder sie eine Tätigkeit beschreibt, so dass mit dem Ergebnis bzw. der Tätigkeit das Risiko gesenkt wird. Der gesamte Prozess wurde als Maßnahme erfasst, wenn die Erfüllung des Prozesszwecks zur Risikosenkung führt. In Tabelle 9 sind zwei Beispiele dargestellt. Die Notation der Maßnahmen enthält die Prozess-ID, also die Abbreviatur der Prozessgruppe (hier Engineering (ENG) sowie Support (SUP)) mit der Nummer des Prozesses. Eine Base Practice (BP), die als Maßnahme erfasst wird, enthält die Identifikation und Bezeichnung der Base Practice in der

43 Risiken, die mit RE-Aktivitäten gesenkt werden können 37 oben eingeführten Notation. Wird der Prozess als Maßnahme erfasst, so wird die Prozess-Bezeichnung neben der Prozess-ID notiert. Risiko Automotive SPICE Unzureichende Kundeneinbindung Entwicklung falscher Funktionen und Eigenschaften Maßnahmen zur Risikosteuerung ENG.1.BP2: Kundenerwartungen verstehen. (E) Begründung Beschreibung der Base Practice: Gemeinsame Überprüfung der Kundenanforderungen und -anfragen mit den Kunden, um deren Bedürfnisse und Erwartungen besser verstehen zu können. SUP.4: Gemeinsames Review. (E/S) Der Zweck des Prozesses bezüglich Gemeinsamer Reviews besteht darin, ein gemeinsames Verständnis mit den Stakeholdern bezüglich der Fortschritte im Vergleich zu den vereinbarten Zielsetzungen zu wahren, und abzustimmen, was getan werden sollte, um sicherzustellen, dass ein Produkt entwickelt wird, das zur Zufriedenheit der Stakeholder ist. Tabelle 9: Beispiele zur Erhebung der Maßnahmen aus Automotive SPICE -Guide Volere-Guide Bei der Erfassung der Maßnahmen aus dem Volere-Guide werden die Anhänge A und B der Originalquelle [Rob1999] verwendet. In dem Volere-Guide sind die Prozesse (Anhang A), die von den Autoren als Process Notes bezeichnet werden, und das Spezifikations-Template (Anhang B) analysiert. In Tabelle 10 sind zwei Beispiele aufgeführt. Bei der Dokumentation der Maßnahmen wird die in der Quelle verwendete Abbreviatur PN für Process Notes verwendet. In Anhang B wird in der Quelle keine Abbreviatur verwendet. Deswegen wird eine Abbreviatur T eingeführt, um auf den Spezifikations-Template-Abschnitt des Guides zu verweisen. Risiko VOLERE Begründung Maßnahmen zur Risikosteuerung Kun- Unzureichende deneinbindung PN 3.9 Define Customer Value (E) Beschreibung der Process Notes: Define the customer value by asking the customer to look at the requirement from two points of view Entwicklung falscher Benutzerschnittstelle T3: User of the Product (E) Motivation aus der Beschreibung des Template-Punktes: The more you know about the user the more likely you will deliver a product that fits in with user's way of working, and conforms to the user's metaphors and preferences Tabelle 10: Beispiele zur Erhebung der Maßnahmen aus dem Volere-Guide

44 Risiken, die mit RE-Aktivitäten gesenkt werden können 38 Die als Template-Abschnitt dokumentierten Maßnahmen sind folgendermaßen zu verstehen: Die Dokumentation des Abschnittes in der Anforderungsspezifikation senkt das jeweilige Risiko. IEEE 830-Guide Für die Erfassung der Maßnahmen aus dem IEEE 830-Guide wird das gesamte Dokument [IEE1998] studiert. In Tabelle 11 ist ein Beispiel für die Ableitung angegeben. Die Notation der Maßnahme enthält die Abschnitts-Identifikation. Risiko IEEE 830 Ständige Änderung der Anforderungen Maßnahmen zur Risikosteuerung Begründung 4.6 Prototyping (E) Beschreibung des Abschnittes 4.6 c) An SRS [Software Requirements Specification] based on a prototype tends to undergo less change during development, thus shortening development time. Tabelle 11: Beispiel zur Erhebung der Maßnahmen aus dem IEEE830-Guide CobiT Nach E. Wallmüller sowie W. Johannsen und M. Goeken [Wal2004], [Joh2007] hilft das CobiT-Referenzmodell, IT-Risiken zu reduzieren. Auch CobiT entstand aus Zusammenarbeit vieler Experten und wurde auf Grund von Praxiserfahrungen überarbeitet. Deswegen wird CobiT für die Ableitung der Maßnahmen zur Risikosteuerung verwendet. Bei der Erfassung der Maßnahmen wird die aktuelle deutsche Ausgabe CobiT Version 4.0 [ISA2008] verwendet. Im CobiT-Referenzmodell wird die Beschreibung jedes Prozesses analysiert. Ein Prozess wird als eine Maßnahme erkannt, wenn mit der Umsetzung des Prozesses ein Ergebnis erreicht wird, das die Wahrscheinlichkeit für das Eintreten von Risikoereignissen verringert oder das Schadensausmaß des Risikoereignisses begrenzt. In Tabelle 12 ist ein Beispiel angegeben. Die Notation der Maßnahme enthält zusätzlich zur Prozessbezeichnung die Identifikation des Prozesses. Risiko Wenig Endbenutzer- Einbeziehung CobiT Maßnahmen zur Risikosteuerung PO10 Manage Projects (Manage Projekte) (E) Begründung Beschreibung des Prozesses: Dieser Ansatz verbessert die Einbindung des Business und der Endbenutzer, Tabelle 12: Beispiel zur Erhebung der Maßnahmen aus CobiT

45 Risiken, die mit RE-Aktivitäten gesenkt werden können 39 Nach der detaillierten Analyse der Prozesse ist festzustellen, dass das CobiT- Referenzmodell zwar Maßnahmen zur Risikosenkung enthält, es sich dabei jedoch nicht um Requirements-Engineering-Aktivitäten handelt. Diese Quelle ist deswegen ungeeignet für die zweite Fragestellung der Literaturrecherche, welche RE-Aktivitäten als Maßnahmen zur Senkung dieser Risiken eingesetzt werden können. Weitere Literaturquellen Neben den RE-Guides werden weitere unterschiedliche Arten von Literatur analysiert, wie in Tabelle 13 dargestellt. Typ der Quelle Lehrbuch Zeitschriftenartikel Beitrag im Tagungsband Andere Quellen [Sch2007], [Ver2005], [Dav2005], [McC2004], [Wal2004], [Wei1993] [Fir2007], [Dam2006], [Lev2000], [Jon1996], [Boe1991] [Tar2008], [Kam2007], [Kna2007], [Ras2007], [Boo2006], [Dam2005], [Kuj2005], [Gan2003] [Jon2007], [Eng2007], [Eng2006] Tabelle 13: Arten der Literatur Eine Maßnahme wird erkannt, wenn die Beschreibung einer RE-Aktivität einen Hinweis zu dem Nutzen dieser Aktivität enthält und mit diesem Nutzen Senkung einer der Risiken erreicht werden kann. Folgendes Beispiel: Graphische Elemente (GUI, Use- Case-Diagramm (UML), Mockups) als Unterstützung zur textuellen Beschreibung in der Anforderungsspezifikation und in der Kommunikation (anstatt nur ) erleichtern die Endbenutzer-Einbindung [Ras2007]. Die Eintrittswahrscheinlichkeit des Risikos Unzureichende Endbenutzer-Einbeziehung kann also mit der Einbindung von graphischen Elementen in die textuelle Beschreibung der Anforderungsspezifikation und in der Kommunikation, reduziert werden Interpretation bei der Ableitung der Maßnahmen Die Ableitung der Maßnahmen ist mit der Interpretation der jeweiligen Quelle verbunden. Nur einige Maßnahmen können als explizite Beschreibung einer Quelle entnommen werden, wie das Beispiel in Tabelle 11 zeigt. Gemeint sind also explizite Angaben wie: Der Einsatz von Prototypen in der Anforderungsanalyse reduziert die Anzahl der Änderungen während der Entwicklung. Einige Maßnahmen werden auf Grund einer impliziten Beschreibung abgeleitet, wie das erste Beispiel in Tabelle 10 verdeutlicht. Process Notes 3.9 im Volere-Guide beschreibt die Priorisierung der Kundenanforderungen, in der die Kundeneinbindung zwingend ist, um den Prozess durchführen zu können. Andere Maßnahmen werden schlussgefolgert, wie in Tabelle 14 anhand von drei Beispielen dargestellt. Die Maßnahmen, die auf Grund einer Schlussfolgerung abgeleitet werden, enthalten den größten Interpretationsspielraum.

46 Risiken, die mit RE-Aktivitäten gesenkt werden können 40 Risiko Maßnahmen zur Risikosteuerung Begründung Unzureichende Kundeneinbindung Mangel an Zeit Schlechte Qualität der Anforderungen [Dam2006]:Verbesserte Schätzung der Ressourcen und sorgfältige Kontrolle fördert die Kundenbereitschaft zu Anforderungserhebung (E). CMMI-DEV:(REQM) SP 1.1 Obtain an Understanding of Requirements (E) Volere: PN 4. Quality Gateway (E): Review Requirement Fit Criteria, Requirements Relevance, Requirement Viability, Identify Gold-Plated Requirements, Requirement Completeness Tabelle 14: Beispiele zur Interpretation bei der Erhebung von Maßnahmen Ergänzung der Maßnahmen in RE-Guides Interpretation: Die Kundenbereitschaft erleichtert wird und dadurch die Kundeneinbindung in die Anforderungserhebung verbessert. Somit ist Eine verbesserte Schätzung der Ressourcen und sorgfältige Kontrolle eine Maßnahme zu Reduzierung des Risikos Unzureichende Kundeneinbindung Beschreibung der Praktik: Subpractice 2 Establish objective criteria for the evaluation and acceptance of requirements. Lack of evaluation and acceptance criteria often results in inadequate verification, costly rework, or customer rejection Interpretation: Daraus folgt, dass das angemessene Festlegen von Abnahmekriterien die Nacharbeit und damit die Eintrittswahrscheinlichkeit des Risikos Mangel an Zeit senkt. Interpretation: In [Rup2007] werden die Merkmale guter (dokumentierter) Anforderungen beschrieben. In dem Prozessbereich PN 4. werden diese geprüft und dadurch wird die Eintrittswahrscheinlichkeit des Risikos reduziert. Nach dem Ableiten der Maßnahmen aus verschiedenen Quellen werden die dokumentierten Maßnahmen dieser Quellen verglichen. Dabei wird für jeden einzelnen RE- Guide analysiert, ob die Maßnahmen, die aus den anderen RE-Guides oder weiteren Literaturquellen abgeleitet worden sind, auch in diesem Guide enthalten sind. Wird so eine Maßnahme gefunden, werden die im RE-Guide dokumentierten Maßnahmen zur Risikosenkung ergänzt. In Tabelle 15 ist ein Beispiel für die Ableitung einer solchen Maßnahme dargestellt. Die Process Notes 5 Prototype the Requirements im Volere- Guide ist eine Maßnahme zur Senkung des Risikos Ständige Änderung der Anforderungen auf Grund der erfassten Maßnahme aus [Jon2007]. Risiko Maßnahmen zur Risikosteuerung Begründung VOLERE: PN 5 Prototype the Requirements (E). Ständige Änderung der Anforderungen Tabelle 15: Beispiele zur Ableitung von Maßnahmen im Volere Guide "Prototypes are also helpful in reducing the rates of downstream requirements changes." [Jon2007]

47 Risiken, die mit RE-Aktivitäten gesenkt werden können 41 Der Schritt Ergänzung der Maßnahmen nach dem Quellenvergleich ähnelt der Schlussfolgerung der Maßnahmen bei der Interpretation. Der Unterschied dabei ist, dass die Maßnahmen bei der Ergänzung auf Grund einer anderen Quelle abgeleitet werden und somit einen viel kleineren Interpretationsspielraum beinhalten Ableitung von RE-Maßnahmen Letztendlich werden alle abgeleiteten Maßnahmen analysiert und die Maßnahmen, die gleichzeitig auch Requirements-Engineering-Aktivitäten sind, zusammengefasst und dokumentiert. Dabei wird folgendermaßen vorgegangen: Zunächst werden die Maßnahmen von quellenspezifischen Angaben bereinigt, also Guide-spezifische Abbreviaturen und Bezeichnungen entfernt. Die bereinigten Maßnahmen werden dann zusammengefasst, wie in der zweiten Spalte der Tabelle 16 dargestellt. Anschließen werden aus diesen Maßnahmen nur diejenigen Maßnahmen extrahiert, die RE-Aktivitäten enthalten. Diese werden dokumentiert, wie in der dritten Spalte von Tabelle 16 dargestellt. Risiko Mangelhaftes Stakeholder Management Allgemeine Maßnahmen zur Risikosteuerung [Rob1999], [CMM2006], [VDA2007] Identifiziere alle Stakeholder ( E) [Rob1999] Für jeden Typ der Stakeholder identifiziere und dokumentiere in der Anforderungsspezifikation: Stakeholder Identification (some combination of role/job title, person name, organisation name), Knowledge needed by the project, Necessary degree of involvement for that stakeholder/knowledge combination, Degree of influence for that stakeholder/knowledge combination, Agreement on how to address conflict between stakeholders who have an interest in the same knowledge. [CMM2006], [VDA2007] Überwache die Einbeziehung der Stakeholder (E) [CMM2006] Führe die Koordination und Zusammenarbeit des Projektes mit den relevanten Betroffenen durch ( E) Tabelle 16: Beispiel zur Ableitung der RE-Aktivitäten RE-Maßnahmen zur Risikosteuerung [Rob1999], [CMM2006], [VDA2007] Identifiziere alle Stakeholder ( E) [Rob1999] Für jeden Typ der Stakeholder identifiziere und dokumentiere in der Anforderungsspezifikation: Stakeholder Identification (some combination of role/job title, person name, organisation name), Knowledge needed by the project, Necessary degree of involvement for that stakeholder/knowledge combination, Degree of influence for that stakeholder/knowledge combination, Agreement on how to address conflict between stakeholders who have an interest in the same knowledge. Nachdem nun die Maßnahmen abgeleitet sind, kann die Anzahl der Risiken, die mit Requirements-Engineering-Aktivitäten gesenkt werden können, bestimmt werden. 6.2 Ergebnis der Identifikation der Maßnahmen Es sind insgesamt zu 49 Risiken RE-Maßnahmen zur Risikosenkung identifiziert worden, also Requirements-Engineering-Aktivitäten, die die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß des Risikoereignisses reduzieren. Wie in Abbildung 6-1 dargestellt sind nicht nur zu jedem der 34 RE-abhängigen Risiken mindestens eine RE- Maßnahme identifiziert, sondern auch für 15 Risiken aus anderen Klassen.

48 Risiken, die mit RE-Aktivitäten gesenkt werden können 42 Die zweite Fragestellung, die in Kapitel 3.2 aufgestellt wurde, um den RE-Nutzen mit Hilfe der Risiken zu zeigen, kann somit projektübergreifend beantwortet werden: RE-Aktivitäten können die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß von 70 % der Risiken senken. Die Annahme, dass Risiken anderer Handlungsfelder, z.b. dem des Projektmanagements, durch RE-Aktivitäten gesenkt werden können, wird damit bestätigt. Die Kennzahl Y ist echt größer als die Kennzahl X. 70% der Risiken, die mit RE-Aktivitäten gesenkt werden können > 49% REabhängige Risiken Alle identifizierten RE-Maßnahmen sind in Anhang C aufgelistet Requirements Engineering Projekt Management mit RE als Eingabe Projekt Entwicklungsprozess Andere Insgesamt Management ohne RE als Eingabe 5 14 Anzahl der Risiken, die mit den RE-Aktivitäten gesenkt werden können Anzahl der identifizierten Risiken Abbildung 6-1: Ergebnis der Identifikation der Maßnahmen 6.3 Zusammenfassung Zunächst wurden allgemein die Maßnahmen zur Risikosenkung aus RE-Guides, dem CobiT-Referenzmodell und weiteren, mittels Literaturrecherche aufgefunden Quellen erfasst. Tabelle 17 gibt eine Übersicht, zu wie vielen Risiken Maßnahmen in welchen Quellen erfasst wurden. Nach der Erhebung und der Interpretation der Maßnahmen aus verschiedenen Quellen wurden die erfassten Maßnahmen analysiert und daraus RE- Maßnahmen abgeleitet, also Requirements-Engineering-Aktivitäten, die die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß des Risikoereignisses reduzieren. Die letzte Zeile von Tabelle 17 zeigt, für wie viele und welche Klassen von Risiken RE- Maßnahmen identifiziert werden konnten. Dabei sind beide Kategorien der Projektmanagement-Klasse dargestellt.

49 Requirements Engineering Projekt Management mit RE als Eingabe Projekt Management ohne RE als Eingabe Andere Etwicklungsrozess Gesamtergebnis Risiken, die mit RE-Aktivitäten gesenkt werden können 43 Es wurden insgesamt zu 49 Risiken RE-Maßnahmen zur Risikosenkung identifiziert. Damit wurde die Annahme bestätigt, dass auch Risiken anderer Handlungsfelder, z.b. dem des Projektmanagements, durch RE-Aktivitäten gesenkt werden können. Außerdem wurde die zweite Fragestellung, die in Kapitel 3.2 aufgestellt wurde, um den RE- Nutzen mit Hilfe der Risiken zu zeigen, projektübergreifend beantwortet: RE- Aktivitäten können die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß von 70 % der Risiken senken. Anzahl der Risiken, die mit den Maßnahmen aus CMMI-DEV-Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus Automotive SPICE - Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus Volere-Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus IEEE 830-Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus CobiT Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus Literatur gesenkt werden können Anzahl der Risiken, die mit den RE- Maßnahmen gesenkt werden können Tabelle 17: Identifizierte Maßnahmen Übersicht Nachdem beide Fragestellungen projektübergreifend beantwortet sind und der Nutzen von Requirements Engineering allgemein gezeigt wurde, wird nun das Modell zur Planung von RE-Aktivitäten im Rahmen des Risikomanagements beschrieben.

50 Planung von RE-Aktivitäten im Rahmen des Risikomanagements Planung von RE-Aktivitäten im Rahmen des Risikomanagements In diesem Kapitel wird das Modell zur Planung von Requirements-Engineering- Aktivitäten vorgestellt. Um die mittels Literaturrecherche identifizierten Risiken so zu ordnen, dass eine Benutzung der Liste, die diese Risiken enthält, sich möglichst angenehm gestaltet, wurde eine empirische Erhebung durchgeführt. Deswegen wird nach der Vorstellung des Modells die empirische Erhebung beschrieben. Die ermittelten Daten werden zur Bestimmung der Rangordnung der Risiken durch Berechnung des Risikofaktors verwendet. Anschließend wird auf die Validierung des Modells eingegangen. 7.1 Modell zur Planung Es wird ein Modell zur Planung von RE-Aktivitäten im Rahmen des Risikomanagements erstellt, mit dem Ziel, so den Nutzen von Requirements Engineering projektspezifisch zu zeigen. Alle Ergebnisse aus der Modellierung des RE-Nutzens mit Hilfe von Risiken werden in dieses Modell integriert. Die Planung findet im Rahmen der Risikomanagementplanung statt, wie in der Abbildung 7-1 als UML-Aktivitätsdiagramm dargestellt. Dabei werden alle Schritte des ersten Teilprozessen Risk assessment und der erste Schritt des zweiten Teilprozesses Risk control des Risikomanagementprozesses, wie im Kapitel 2.3 erläutert durchgeführt. Die folgende Schritte, die in der Abbildung 7-1 als Aktivitäten Definierte Maßnahmen ausführen und Risiken überwachen dargestellt sind, sind nur für die Durchführung des Risikomanagements relevant. Requirements-Engineering-Aktivitäten im Rahmen des Risikomanagements planen Liste klassifizierter, typischer Risiken Risiken projektspezifisch identifizieren Risiken analysieren Bewertete Risiken Risiken priorisieren [Projektende] [Kein Projektende] Anteil Risiken, die mit RE-Aktivitäten gesenkt werden können bestimmen Anteil REabhängigen Risiken bestimmen Risiken überwachen Definierte Maßnahmen ausführen Maßnahmen zur Risikomanagementplanung festlegen RE-Aktivitäten als Maßnahmenvorschläge Abbildung 7-1: Modell zur Planung von RE-Aktivitäten im Rahmen des Risikomanagements Die Eingangsparameter Liste klassifizierter, typischer Risiken und RE-Aktivitäten als Maßnahmenvorschläge stammen aus der Modellierung des RE-Nutzens mit Hilfe der Risiken (siehe Kapitel 3.2). Die Aktivitäten Anteil der RE-abhängigen Risiken bestimmen und Anteil der Risiken, die mit RE-Aktivitäten gesenkt werden können

51 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 45 bestimmen sind optional. Sie werden durchgeführt um den RE-Nutzen projektspezifisch zu zeigen und sind für die Planung von RE-Aktivitäten als solches nicht notwendig. Ohne den oben genannten Eingangsparametern und optionalen Aktivitäten ist in der Abbildung 7-1 dargestellter Prozess ein rein typischer Risikomanagementprozess. Die Demonstration des projektspezifischen RE-Nutzens erfolgt anhand gleicher Fragestellungen wie auch projektübergreifend (siehe Kapitel 3.2). Dabei werden die Kennzahlen X und Y wie folgt bestimmt: X = Anzahl RE-abhängigen Risiken Anzahl identifizierten projektspezifischen Risiken * 100% Y = Anzahl der Risiken, die mit RE-Aktivitäten gesenkt werden können Anzahl identifizierten projektspezifischen Risiken * 100% Durch Vorschläge der Requirements-Engineering-Aktivitäten als Maßnahmen zur Risikosenkung, sollen Aktivitäten weiterer Handlungsfelder, z.b. dem des Projektmanagements, nicht ausgeschlossen, sondern ergänzt werden. Vielmehr soll durch die Risikobasierte Planung von RE-Aktivitäten erreicht werden, dass das Requirements Engineering nicht vernachlässigt wird und in das Risikomanagement als Teil des üblichen Projektmanagement ungezwungen einfließt. Nicht alle typischen Risiken sind für jedes Projekt relevant. Daher muss jeder Projektmanager für jedes konkrete Projekt ein spezifisches Risikomanagement betreiben. Der erste Schritt dabei ist die Risikoidentifikation. Bei der Risikoidentifikation wird eine Liste aller möglichen Risiken erstellt, die im speziellen Projekt eintreten können. Dieser Schritt ist in der Abbildung 7-2 als UML-Aktivitätsdiagramm dargestellt. Für die Identifikation der Risiken werden in der Regel Brainstorming-Techniken und Risiko- Checklisten angewendet [Wal2004]. Risiken projektspezifisch identifizieren Experten befragen Liste klassifizierter, typischer Risiken Typische Projektrisiken analysieren Brainstorming durchführen Identifizierte Risiken Abbildung 7-2: Projektspezifische Risiken identifizieren Der Prozess zur Planung von Requirements-Engineering-Aktivitäten im Rahmen des Risikomanagements unterscheidet sich vom typischen Risikomanagementprozess durch Vorschläge von RE-Maßnahmen zur Senkung identifizierter Risiken. Deswegen soll die

52 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 46 im Rahmen dieser Arbeit erstellte Liste mit klassifizierten, typischen Risiken als Checkliste für die Identifikation projektspezifischer Risiken benutzt werden. Diese Checkliste kann unter anderem bei der Expertenbefragung in Gruppen- oder Einzelgesprächen verwendet werden. Der zweite Schritt des ersten Teilprozesses Risk assessment ist die Risikoanalyse. Wie in der Abbildung 7-3 als UML-Aktivitätsdiagramm dargestellt werden die identifizierte projektspezifische Risiken bewertet, indem die Abhängigkeiten zwischen den Risiken sowie die Eintrittswahrscheinlichkeit und Schadenshöhe des Risikoereignisses abgeschätzt werden. Die Schätzung der Risiko-Abhängigkeiten ist optional, kann jedoch dabei helfen, die Risiken zu bewerten und weitere Risiken zu identifizieren. Die abgeschätzten Abhängigkeiten zwischen den Risiken können unter anderem in Form einer Matrix dargestellt werden. Eine solche Matrix kann erweitert und auch in anderen Projekten verwendet werden. Wird die Wahrscheinlichkeit des Eintretens und die Schadenshöhe jedes Risikos quantitativ bewertet, so kann der Risikofaktor (also das Produkt der beiden Größen) berechnet werden. Dieser Wert wird häufig verwendet, um die Risiken zu priorisieren. Risiken analysieren Identifizierte Risiken Abhängigkeiten zwischen Risiken schätzen Eintrittswahrscheinlichkeit des Risikoereignisses schätzen Schadensausmaß des Risikoereignisses schätzen Bewertete Risiken Abbildung 7-3: Projektspezifische Risiken analysieren Die Checkliste der identifizierten Risiken enthält 70 Risiken. Um die Benutzung dieser Checkliste zu vereinfachen, wurden die Risiken projektübergreifend priorisiert. Zu diesem Zweck wurde eine empirische Erhebung (Expertenbefragung) durchgeführt. Auf die Durchführung und Auswertung der Erhebung wird im folgenden Kapitel eingegangen. 7.2 Projektübergreifende Risikopriorisierung In diesem Abschnitt wird zunächst die Zielsetzung und Durchführung sowie Auswertung der empirischen Erhebung beschrieben. Anschließend wird die projektübergreifende Risikopriorisierung, durch Berechnung des Risikofaktors aus den ermittelten Werten, erläutert Zielsetzung und Durchführung der empirischen Erhebung Das Ziel der empirischen Erhebung bestand darin, die mittels Literaturrecherche identifizierte Risiken projektübergreifend zu priorisieren. Die Rangliste der Risiken sollte auf

53 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 47 Basis des Risikofaktors ermittelt werden. Um den Risikofaktor zu bestimmen, sollte im Rahmen einer Umfrage Experten befragt werden, wie sie Schadensausmaß und Eintrittswahrscheinlichkeit der Risiken auf Basis der persönlichen Erfahrung in Softwareprojekten einschätzen würden. Die Datenerhebung wurde durch eine Online-Umfrage realisiert. Die Erhebung fand im Zeitraum vom bis statt. Dazu wurde ein Fragebogen verfasst und an verschiedenen Stellen der XING-Plattform ( veröffentlicht. Darüber hinaus wurden Projektmanager und Softwareentwickler der eigenen Kontakte per angeschrieben. Durch eine gezielte Veröffentlichung des Fragebogens wurde versucht, nicht vertrauenswürdige Probanden möglichst auszuschließen. Trotzdem kann bei einer Online-Umfrage nicht sichergestellt werden, dass tatsächlich Experten die Bewertung abgegeben haben. Der Fragebogen bestand aus drei Fragenblöcken, wie in der Abbildung 7-4 dargestellt. Im rechten Teil sind verkürzt die Frageninhalte der einzelnen, im linken Teil dargestellten, Frageblöcke abgebildet. Die Risiken in dem zweiten Fragenblock wurden alphabetisch sortiert. Dadurch wurde versucht den Einfluss auf die Bewertung der Risiken bestimmter Klassen der Klassifizierung zu vermeiden. Der vollständige Fragebogen befindet sich im Anhang D. Fragenblöcke Branche, Rolle in Projekten, Jahre der Erfahrung, angestrebte Projektergebnis Fragen über den Teilnehmer Geschlossene Fragen Bewertung der Risiken nach Eintrittswahrscheinlichkeit auf der Skala null, gering, mittel, hoch und Schadenshöhe auf der Skala gering, mittel, hoch, sehr hoch Offene Frage mit Möglichkeit zur Ergänzung Ergänzung der Liste der identifizierten Risiken Abbildung 7-4: Struktur des Fragebogens Insgesamt wurde die Umfrage 75-mal aufgerufen, davon wurde von 53 Teilnehmern der erste Fragenblock beantwortet. Vollständig wurde die Umfrage nur von 28 Teilnehmern ausgefüllt. Für den hohen Abbruch der Befragung existieren zwei mögliche Gründe: Der Umfang des zweiten Fragenblocks war zu hoch und wirkte daher abschreckend.

54 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 48 Die Bewertung der Risiken nach Eintrittswahrscheinlichkeit und Schadensausmaß war zu aufwändig. Im Folgenden wird auf die Auswertung der empirischen Erhebung näher eingegangen Auswertung der empirischen Erhebung Die Risiken wurden aus unterschiedlichen Sichten bewerten, wie in der Tabelle 18 dargestellt. Dabei haben über 30% der Teilnehmer mehrere Rollen angegeben. Diese sind im Anhang D in der Tabelle 23 aufgelistet. Rolle, in der die Befragten die meiste Zeit an IT-Projekten beteiligt waren Anzahl der Nennung Mehrfachnennung 10 Entwickler 8 Projektleiter 7 IT Architekt 1 Requirements Engineer 1 Software Engineer 1 Gesamtergebnis 28 Tabelle 18: Rollen der Umfrageteilnehmer 16 Teilnehmer, also 57%, haben aus Erfahrung von mindestens 10 Jahre berichtet, wie in der Tabelle 19 genau aufgelistet. Jahre der Erfahrung >20 Anzahl der Nennungen Tabelle 19: Angaben zu Erfahrung 4 Teilnehmer fanden die Checkliste unvollständig und haben insgesamt zehn Risiken hinzugefügt. Diese sind im Anhang D-Tabelle 24 aufgelistet. Dies zeigt, dass es wichtig ist, dass das Werkzeug zur Planung von RE-Aktivitäten im Rahmen des Risikomanagements sowie zum Zeigen des Nutzens von RE um zusätzliche Risiken erweiterbar ist. Das Ziel der empirischen Erhebung bestand darin, die mittels Literaturrecherche identifizierten Risiken projektübergreifend zu priorisieren. Dafür wurden die Teilnehmer der Erhebung aufgefordert, alle mittels Literaturrecherche identifizierten Risiken zu bewerten. Dabei sollten die Eintrittswahrscheinlichkeit eines Risikoereignisses auf der Ratingskala: null, gering, mittel, hoch sowie das Ausmaß des möglichen Schadens auf der Ratingskala: gering, mittel, hoch, sehr hoch beurteilt werden. Die qualitativen Merkmale wurden bei der Auswertung der Daten, wie in der Tabelle 20 dargestellt, quantifiziert. Bei der Auswertung wurde davon ausgegangen, dass die Stufen der Ratingskala eine Intervallskala bilden. Das Skalenniveau (ob Ordinal- oder Intervallskala) einer Ratingskala ist zwar nicht abschließend geklärt, jedoch wird im Allgemeinen von einer Inter-

55 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 49 vallskalierung ausgegangen [Cle2008]. Diese Annahme ist erlaubt so lange die statistische Datenauswertung zu sinnvollen Interpretationsergebnissen kommt [Bor2006]. qualitativen Merkmale Eintrittswahrscheinlichkeit Schadenshöhe null 0 - gering 0,25 0,25 mittel 0,5 0,5 hoch 0,75 0,75 sehr hoch - 1 Tabelle 20: Interpretation der qualitativen Bewertung Um die Daten der Erhebung für die projektübergreifende Risikopriorisierung verwenden zu können, wurde jeweils der arithmetische Mittelwert der Beobachtungen der Eintrittswahrscheinlichkeit und der Schadenshöhe des Risikofaktors berechnet. In der Abbildung 7-5 sind die Mittelwerte der Eintrittswahrscheinlichkeit von zehn Risiken dargestellt, deren Eintrittswahrscheinlichkeit von den Probanden im Durchschnitt am höchsten eingeschätzt wurde. In der Abbildung 7-6 sind die Mittelwerte der Schadenshöhe der zehn Risiken dargestellt, deren Schadenshöhe von den Probanden im Durchschnitt am höchsten eingeschätzt wurde. Bewertung der Eintrittswahrscheinlichkeit 0,8 Oberes Quantil Unteres Quantil Mittelwert 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 Abbildung 7-5: Mittelwerte der Eintrittswahrscheinlichkeit des Risikoereignisses

56 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 50 In den beiden Abbildungen sind oberes Quantil und unteres Quantil mit abgebildet. In einem geordneten Datensatz legt das p-prozent-quantil den Wert fest, bei dem mindestens p Prozent der Beobachtungen kleinere oder gleiche Werte und mindestens (1-p) Prozent der Beobachtungen größere oder gleich Werte annehmen [Cle2008]. Das obere Quantil ist die verbreitete Bezeichnung für 75%-Quantil und unteres Quantil für 25%- Quantil. Die beiden Quantile begrenzen somit die zentralen 50 % aller Beobachtungen und sind in den Abbildungen durch eine Linie dargestellt. Die ermittelte Mittelwerte sowie die Standardabweichung der Beobachtungen der Eintrittswahrscheinlichkeit und Schadenshöhe aller Risiken sind im Anhang D in der Tabelle 25 aufgelistet. Bewertung der Schadenshöhe 1,2 Oberes Quantil Unteres Quantil Mittelwert 1 0,8 0,6 0,4 0,2 0 Abbildung 7-6: Mittelwerte der Schadenshöhe des Risikoereignisses Die Auswertung der Daten wurde nur auf die Verfahren der deskriptiven Statistik beschränkt, mit denen sich die Beschreibung von Daten einer Grundgesamtheit der Informationen gewinnen lässt [Cle2008]. Es wurde nicht versucht, aus Stichproben Schlüsse auf die Gesamtheit zu ziehen. Damit würde die Annahmen getroffen werden, dass es eine Priorisierung der Risiken allgemeingültig sei und folglich die projektspezifische Risikopriorisierung nicht notwendig wäre. Eine solche Annahme widerspricht dem Risikomanagementprozess.

57 Planung von RE-Aktivitäten im Rahmen des Risikomanagements Verwendung der Ergebnisse der empirischen Erhebung Nachdem die durchschnittlichen Bewertungen der Eintrittswahrscheinlichkeit und Schadenshöhe für jedes Risiko bestimmt sind, kann der Risikofaktor für jedes Risiko berechnet werden, anhand dessen die Risiken priorisiert werden. D.h. die Berechnung des Risikofaktors wird für die Rangordnungen der Risiken verwendet. Der Risikofaktor wird berechnet, in dem das Produkt der durchschnittlicher Eintrittswahrscheinlichkeit und durchschnittlicher Schadenshöhe bestimmt wird. In der Tabelle 21 sind die 10 Risiken mit dem höchsten Risikofaktor priorisiert aufgelistet. Die Abbildung 7-7 gibt eine Übersicht der berechneten Risikofaktoren. Die Risiken sind in der priorisierten Reihenfolge durch IDs dargestellt. Die entsprechende Risikobezeichnung zu einer ID kann der Tabelle 25 in Anhang D entnommen werden. Die dargestellten Werte des Risikofaktors dienen nur der Orientierung. Es ist zu beachten, dass auf Grund des Skalenniveau keine Aussagen zu dem Verhältnis der Werte (z.b. x = 2*y) getroffen werden dürfen. 0,6 Risikofaktor 0,5 0,4 0,3 0,2 0, Abbildung 7-7: Risikofaktor-Übersicht Risiko-ID Risiko Klassifizierung 1 Fehlende Anforderungen Requirements Engineering 2 Anforderungen sind nicht bekannt Requirements Engineering 3 Mangel an Zeit Projektmanagement mit RE als Eingabe 4 Schlechte Kommunikation Projektmanagement ohne RE als Eingabe 5 Tests nicht oder zu wenig durchgeführt Projektmanagement mit RE als Eingabe 6 Mangelhafte Anforderungsspezifikation Requirements Engineering 7 Unklare Anforderungen Requirements Engineering 8 Anforderungen sind nicht testbar dokumentiert Requirements Engineering 9 Politik, Egoismen, Kompetenzstreit Andere 10 Unrealistische Schätzung der Zeit Projektmanagement mit RE als Eingabe Tabelle 21: Top 10 Risiken nach der Rangordnung

58 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 52 Wie in der Abbildung 7-7 zu sehen ist, liegen die Werte der Risikofaktoren paarweise relativ dicht bei einander. Keines der Risiken wurde von allen Probanden als nicht wahrscheinlich bewertet. Somit sind alle identifizierten Risiken relevant. Das Risiko mit ID=70 Projektergebnis wird nicht länger benötigt hebt sich durch seinen relativ niedrigen Risikofaktor von alle anderen Risiken ab. Ausschlaggebend dafür ist die durchschnittliche Bewertung der Eintrittswahrscheinlichkeit dieses Risikoereignisses. Insgesamt wurde dieses Risiko von 22 Probanden bewertet. 9 Probanden haben dieses Risikoereignis mit null bewertet. Die Klassifizierung der Top 10 Risiken (wie in Kapitel 3.3 beschrieben) aus der projektübergreifende Priorisierung zeigt, dass 80% der Risiken RE-abhängige Risiken sind (siehe Abbildung 7-8). Dieses Ergebnis verdeutlicht noch mal die Wichtigkeit des Requirements Engineerings. 0% 10% Requirements Engineering 10% 30% 50% Projekt Management mit RE als Eingabe Projekt Management ohne RE als Eingabe Entwicklungsprozess Andere Abbildung 7-8: Klassifizierung der Top 10 Risiken aus projektübergreifender Priorisierung Nachdem das Modell beschrieben ist, wird nun geprüft, ob sich das Modell für die Planung von RE-Aktivitäten eignet. Im Folgenden wird auf die Validierung des Modells zur Planung von Requirements-Engineering-Aktivitäten eingegangen. 7.3 Validierung des Modells zur Planung von RE-Aktivitäten Um das Modell zur Planung von Requirements-Engineering-Aktivitäten zu validieren, werden die Anforderungsspezifikationen der im Wintersemester 07/08 durchgeführten Software Projekte am Fachgebiet Software Engineering der Leibniz Universität Hannover untersucht. Dabei wird der Abschnitt 5 Probleme und Risiken der Anforderungsspezifikationen analysiert. In diesem Abschnitt sind von den Projektteilnehmer identifizierte Risiken und zum Teil auch die Maßnahmen zur Risikosenkung dokumentiert. Folgende neun Risiken werden in den Anforderungsspezifikationen identifiziert: 1. Zeitmangel 2. Mangel an qualifizierten Mitarbeitern 3. Unklare Anforderungen

59 Planung von RE-Aktivitäten im Rahmen des Risikomanagements Ständige Änderung der Anforderungen 5. Schlechte Qualität der Anforderungen 6. Technologienwandel 7. Unrealistische Schätzung der Zeit 8. Technische Anforderungen zu hoch 9. Politik, Egoismen, Kompetenzstreit Die von Projektteilnehmern geplanten Maßnahmen zur Risikosenkung sind in der zweiten Spalte der Tabelle 22 aufgelistet. Von Projektteilnehmer geplante Maßnahmen 1 Abstriche zur Aufwandsreduktion. Nur essentielle Anforderungen erfüllen. Die Implementierung erfolgt in der Reihenfolge der Prioritäten des Kunden. Ausreichende und großzügige Zeitplanung im Voraus, sodass wenn es zu Verzögerungen kommen sollte, es trotzdem nicht zu Zeitmangel führt 2 Rechtzeitige Einarbeitung, Verteilung der Teilaufgaben nach Kenntnisstand der Gruppenmitglieder Äquivalente Maßnahme [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen. (E) [Rob1999] Dokumentiere Schedule Constraints in die Anforderungsspezifikation. If the deadline is short, then the requirements must be kept to whatever can be built within the time allowed. (E) [Wal2004], [Boe1991] Inkrementelle Auslieferung (S) [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen. [Rob1999] Do we have the people skills we need to build this product? What new skills are needed? ( E) Anhand dieser Analyse können unteranderen folgende Projektmanagement Maßnahmen geplant werden: Planung und Durchführung von Schulungen, Zuweisung der erforderlichen Qualifikation an Einzelpersonen 3 Mehrere Kundengespräche [VDA2007] Führe gemeinsames Review zur Analyse der Kundenanforderungen durch (E/S) 4 Umfassende Anforderungsanalyse [Tar2008],[Dam2005]Die Involvierung der Stakeholdern in der Anforderungsanalyse -Phase senkt die Anzahl der Änderungen in späteren Phasen (E) 5 Frühzeitige Analyse aller Anforderungen, im Konfliktfall eine Anpassung der Anforderungen vornehmen 6 Rechtzeitiges Einholen der entsprechenden Informationen 7 Schätzungen und gegebenenfalls Abstriche zur Aufwandsreduktion machen 8 Verzicht auf entsprechende Funktionen oder gegebenenfalls Ersatz durch alternative Lösungen in jedem Fall ist der Kunde sofort zu benachrichtigen und die weiteren Maßnahmen müssen besprochen werden Tabelle 22: Vergleich der Maßnahmen [CMM2006] Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects (E/S) [VDA2007] Gemeinsame Reviews sollten zur Verifikation verschiedener Aspekte (z. B. der Einführung neuer Technologien; der Technologieänderungen) durchgeführt werden. (E/S) [Rob1999] Dokumentiere Schedule Constraints in die Anforderungsspezifikation.... If the deadline is short, then the requirements must be kept to whatever can be built within the time allowed. (E) [Wal2004], [Boe1991] Inkrementelle Auslieferung (S) [CMM2006], [VDA2007], [Rob1999] (E ) Prüfen Sie jeder dokumentierten Anforderung auf die technische Realisierbarkeit (Haben wir die technologischen Fachkenntnisse, um diese Anforderung zu erfüllen?) ( E)

60 Planung von RE-Aktivitäten im Rahmen des Risikomanagements 54 Durch die Nummerierung in der ersten Spalte ist der Bezug zu oben genannten Risiken dargestellt. Es wird geprüft, ob zu jeder von den Projektbeteiligten dokumentierten Maßnahme eine äquivalente Maßnahme unter den identifizierten Requirements- Engineering-Aktivitäten als Maßnahmen zur Risikosenkung enthalten ist. Somit kann die von den Projektbeteiligten dokumentierte Maßnahme unter der Benutzung des Modells zur Planung von RE-Aktivitäten auch geplant werden. Die äquivalenten Maßnahmen sind in der dritten Spalte der Tabelle 22 aufgelistet. Zu dem Risiko Politik, Egoismen, Kompetenzstreit wurden keine Maßnahmen von den Projektbeteiligten geplant. Auch mittels Literaturrecherche wurden keine RE- Aktivitäten als Maßnahmen zur Risikosenkung identifiziert. Wie in der Tabelle 22 zu sehen ist, wird zu jeder von der Projektbeteiligten dokumentierten Maßnahme eine äquivalente Maßnahme identifiziert. Daraus lässt sich schließen, dass das im Kapitel 7.1 vorgestellte Modell für die Planung von RE-Aktivitäten im Rahmen des Risikomanagements in den Softwareprojekten der Leibniz Universität Hannover geeignet ist, da es nicht schlechtere Ergebnisse produziert, als traditionelles Vorgehen. 7.4 Zusammenfassung In diesem Kapitel wurde das Modell zur Planung von Requirements-Engineering- Aktivitäten im Rahmen des Risikomanagements vorgestellt. Während der Planung werden alle Schritte des ersten Teilprozesses Risk assessment des Risikomanagementprozesses, also Risikoidentifikation, Risikoanalyse und Risikopriorisierung, und der erste Schritt des zweiten Teilprozesses Risk control Risikomanagementplanung durchgeführt. Der Unterschied zu einem typischen Risikomanagementprozess dabei ist, dass a) es möglich ist den Nutzen von Requirements Engineering projektspezifisch zu zeigen und b) speziell RE-Maßnahmen zur Senkung identifizierter Risiken vorgeschlagen werden. Es wurde eine empirischen Erhebung durchgeführt, um die mittels Literaturrecherche identifizierten Risiken projektübergreifend zu priorisieren und dadurch die Benutzung der Liste typischer Risiken zu vereinfachen. Die Rangliste der Risiken wurde auf Basis des Risikofaktors ermittelt. Die Durchführung und Auswertung der empirischen Erhebung wurde in diesem Kapitel präsentiert. Außerdem wurde eine Validierung des Modells zur Planung von Requirements-Engineering-Aktivitäten durchgeführt. Um die Planung von Requirements-Engineering-Aktivitäten im Rahmen des Risikomanagements sowie die Demonstration von RE-Nutzen mit Hilfe von Risiken projektspezifisch zu ermöglichen, wird ein Excel-basiertes Risikomanagementwerkzeug implementiert. Dieses wird im folgenden Kapitel beschrieben.

61 Ein Anwendungsbeispiel Ein Anwendungsbeispiel In diesem Kapitel wird RERuM (Requirements Engineering und Risikomanagement), ein einfaches Excel-basiertes Werkzeug vorgestellt, das die Anwendung des ausgearbeiteten Modells zulässt. RERuM hilft bei der Planung von RE-Aktivitäten sowie dem projektspezifischen Aufzeigen von RE-Nutzen. Die Demonstration des Werkzeuges erfolgt anhand eines Szenarios. Dabei wird eine fiktive Geschichte erzählt. Szenario Früher war Max ein Software-Entwickler und nun ist er seit zwei Jahren ein Projektleiter in einer Beratungsfirma. Bis jetzt hat er zwei mittlere und ein großes Projekt durchgeführt und dabei festgestellt, dass Risikomanagement wichtig, aber doch eher schwierig ist. Nun ist er der Projektleiter in einem neuen externen Projekt EXTA. Für einen regionalen Konzert-Veranstalter soll ein Veranstaltungskalender entwickelt werden. Dabei hat der Kunde den Wunsch nach einer Anbindung an ein bestehendes Ticketsystem geäußert. Außerdem möchte er gern eine Trendanalyse. Max denkt: Alles klar! und plant daher drei Entwickler für acht Monate ein. Er kennt sich jedoch mit den Trendanalysen nicht gut aus und geht deshalb bei Projektbeginn zu Entwickler Tom, um sich zu vergewissern, dass die Schätzung des Aufwandes in Ordnung ist. Er erzählt Tom kurz von dem Projekt. Ohne seine Bedenken bezüglich der Trendanalyse geäußert zu haben, unterbricht ihn Tom: Dann brauchen wir ja einen Online-Shop für die Tickets. Max wundert sich: Wieso?! Und Tom erklärt kurz: Wie soll der Endbenutzer sonst die Tickets kaufen? Oh Hier werden ihm mögliche Missverständnisse klar. Ich dachte, es soll ein Veranstaltungskalender für den Veranstalter entwickelt werden, in dem es möglich ist, die Verkäufe der Tickets zu überwachen. Und außerdem die Trendanalyse, basierend auf der Statistik von bisherigen Verkäufen zu sehen ist. Hmm aber wissen tue ich es nicht. Ein Risiko ist es auf jeden Fall! Er entscheidet sich, die Planung noch mal zu überdenken. Max erinnert sich, dass Jens, sein Bekannter, ihm vor nicht allzu langer Zeit RERuM empfohlen hat. RERuM ist ein Excel-basiertes Werkzeug, mit dem Projektleiter Risiken verwalten können und sich zu diesen Risiken mögliche Maßnahmen vorschlagen lassen können. Das möchte er jetzt mal ausprobieren, um sich beim Risikomanagement unterstützen zu lassen. In den letzen zwei Jahren hat er wirklich oft Excel verwendet und glaubt deshalb, sich recht schnell in ein Excel-basiertes Werkzeug einarbeiten zu können.

62 Ein Anwendungsbeispiel 56 Max schaut sich die aufgelisteten Risiken an (siehe Abb. 8-1). Das erste Risiko in der Liste ist Fehlende Anforderungen. Er ist sich sicher, die Wahrscheinlichkeit hierfür ist hoch in seinem Projekt und trägt deshalb 75 % ein. Dabei benutzt er eine Verhältnisskala. Aber die Schadenshöhe einzuschätzen fällt ihm schwer. Er schaut in die Risikoabhängigkeits-Matrix, die das Werkzeug bereitstellt, und sieht: acht abhängige Risiken, unter anderem Falsche Wahl von Projektressourcen und Unrealistische Schätzung der Zeit sowie Kosten. Das wäre schlimm, denkt er, und bewertet die Schadenshöhe mit 19%. Bei den prozentualen Angaben von Schadenshöhen bezieht sich Max auf die Auswirkung auf den Umsatz des Projektes. Oh, wie praktisch, der Risikofaktor wird ja gleich berechnet, bemerkt er. Abbildung 8-1: Screenshot des Tabellenblattes Risikobewertung Das nächste Risiko, das er relevant findet ist Unklare Anforderungen. Die Eintrittswahrscheinlichkeit bewertet er sofort mit 100% und schaut wieder in die Matrix. Er sieht 12 abhängige Risiken. Alle wie von Fehlende Anforderungen und noch mehr! Ganz klar 25%! denkt er und bewertet die Schadenshöhe dementsprechend. So geht er die Liste durch. Am Ende hat er 19 Risiken identifiziert und bewertet, die er relevant findet (siehe Abbildung 8-2). Neun davon hat er nur auf Grund der Abhängigkeitsmatrix identifiziert.

63 Ein Anwendungsbeispiel 57 Abbildung 8-2: Screenshot der identifizierten Risiken Bevor Max sich die Maßnahmen vorschlagen lässt, schaut er sich die Auswertung des Quellenvergleichs an (siehe Abbildung 8-3). Abbildung 8-3: Screenshot des Tabellenblattes Quellenvergleich_Auswertung Er sieht, dass die meisten seiner Risiken mit den RE-Maßnahmen und Maßnahmen aus dem CMMI-DEV-Guide, deren Anzahl gleich groß ist, gesenkt werden können. Weil er sich mit dem CMMI-DEV-Guide nicht auskennt, entscheidet er sich für die RE- Maßnahmen. Max weißt, dass RE-Maßnahmen, im Rahmen der Diplomarbeit identifizierte Requirements-Engineering-Aktivitäten als Maßnahmen zur Risikosenkung sind.

64 Ein Anwendungsbeispiel 58 Nun will er sich Maßnahmen vorschlagen lassen. Er drückt auf die Schaltfläche Maßnahmen vorschlagen, woraufhin ein kleines Fenster, wie in der Abbildung 8-4 dargestellt, erscheint. Abbildung 8-4: Screenshot des Auswahlfensters Er belässt seine Auswahl bei den Voreinstellungen und drückt nun auf Auswählen. Es wird das Tabellenblatt Maßnahmen_Vorschläge aktiviert (siehe Abbildung 8-5). Abbildung 8-5: Screenshot des Tabellenblattes Maßnahme_Vorschläge Er geht die Vorschläge durch:

65 Ein Anwendungsbeispiel 59 - [Rob1999] Involviere die Stakeholder in die Aufklärung vager, komplizierter und schwieriger Ereignisse. (Z.B. Die Stakeholder interviewen, Apprentice with the user ) - [VDA2007] Führe gemeinsames Review zur Analyse der Kundenanforderungen durch (E/S) - [Rob1999] Eine gute Weise, den echten Zweck des Systems zu verstehen, ist die wesentlichen Anforderungen zu bestimmen - - [Rob1999], [Eng2006], [Kna2007] Vision, Ziele, Zweck des Produktes kommunizieren und in der Anforderungsspezifikation dokumentieren (E) - - [Tar2008], [Dam2005] Die Involvierung der Stakeholdern in der Anforderungsanalyse -Phase senkt die Anzahl der Änderungen in späteren Phasen (E) Er liest eine häufige, auffällige Quelle [Rob1999] an. Es wird ihm einiges klarer. Macht Sinn, verstehe ich! Auf jeden Fall brauche ich einen Requirements Engineer in meinem Projekt. Mit dieser Erkenntnis geht er zu seinem Management. Er zeigt dem Management die vom Werkzeug automatisch erstellten Grafiken (in Abbildung 8-6 dargestellt) und erklärt, dass 85% seiner Risiken RE-abhängig sind. Und sogar 95% der Risiken kann er mit RE-Aktivitäten senken. Abbildung 8-6: Screenshot der Auswertung des projektspezifischen RE-Nutzens Das Management erkennt die Problematik und Max bekommt einen Requirements Engineer für das Requirements Engineering. Sie heißt Anna. Max ist sehr froh, Anna im Projekt zu haben. Im Einzelgespräch mit Anna geht Max die Checkliste der Risiken noch einmal durch. Nun hat er auf Anraten von Anna auch einen Tester im Team. Anna führt verschieden RE-Maßnahmen durch, unter anderem auch einige, die von dem Tool vorgeschlagen wurden. Dadurch werden die Anforderungen klarer. Die Trendanalyse soll für die Planung neuer Veranstaltungen durchgeführt werden. Der Kunde hat sich ein Internetradio vorgestellt, in dem man bspw. nach Genre abstimmen kann. Diese Abstimmungen sollen dann in die Veranstaltungsplanung einfließen. Die Annahmen von Max waren falsch.

66 Ein Anwendungsbeispiel 60 Das Projekt wird erfolgreich. Max freut sich. Nun versteht er, wie wichtig Requirements Engineering ist. Max hat auch ein neues Risiko Scope Creep in das Tool integriert denn Andreas, ein Kollege von Max, hat ihm von der ständig wachsenden Anzahl neuer Anforderungen am Ende seiner Projekte erzählt. Auch entsprechende Maßnahmen hat er basierend auf Andreas Erfahrung eingetragen. Die Excel-Tabelle, die er in früheren Projekten benutzt hat, um die Risiken zu überwachen, hat er in ein neues Tabellenblatt des Tools kopiert. Max und seine Kollegen, die RERuM jetzt auch benutzen, profitieren von der Erweiterbarkeit des Tools. Ende In dem Szenario wurde folgendes gezeigt: das Werkzeug ist eine Argumentationshilfe beim Management Unterstützung beim Risikomanagement Unterstützung bei der Planung von Requirements-Engineering-Aktivitäten Hilfe bei einem Vergleich von RE-Guides. Nach dieser Demonstration des Werkzeuges, wird im nächsten Kapitel auf Vergleich von RE-Guides als ein Beispiel für die Anwendung der Ergebnisse dieser Arbeit eingegangen.

67 Vergleich von RE-Guides als Anwendungsbeispiel der Ergebnisse Vergleich von RE-Guides als Anwendungsbeispiel der Ergebnisse Die Auswahl eines passenden RE-Guides ist eine grundlegende Planungsaktivität von RE-Aktivitäten. Die Landschaft der RE-Guides ist sehr umfangreich [Bir2007]. Wird eine Anleitung für die RE-Prozesse innerhalb eines Unternehmens gesucht und damit ein passender RE-Guide, so ist die Entscheidung nicht einfach. Eine Gegenüberstellung der Risiken und Maßnahmen, die ein RE-Guide zur deren Senkung enthält, bietet eine Vergleichsmöglichkeit der Guides und somit eine Auswahlhilfe für einen geeigneten RE-Guide. Zur Entscheidungsfindung ist es sinnvoll, zunächst einige in einem Unternehmen durchgeführten Projekte auf organisationsspezifische Risiken hin zu analysieren. Abbildung 9-1 stellt die identifizierten Risiken und Maßnahmen dar, die die in dieser Arbeit untersuchten RE-Guides zur Risikosenkung enthalten. Um einen möglichst vollständigen Vergleich zu ermöglichen wurden alle erfassten und abgeleiteten Maßnahmen berücksichtigt Requirements Engineering Projekt Projekt Entwicklungsprozess Andere Gesamtergebnis Management mit RE Management ohne als Eingabe RE als Eingabe Anzahl der Risiken, die mit den Maßnahmen aus CMMI-DEV-Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus Automotive SPICE -Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus Volere-Guide gesenkt werden können Anzahl der Risiken, die mit den Maßnahmen aus IEEE 830-Guide gesenkt werden können Anzahl der identifizierten Risiken Abbildung 9-1: Vergleich der RE-Guides

68 Vergleich von RE-Guides als Anwendungsbeispiel der Ergebnisse 62 Die Anzahl der Risiken insgesamt, die mit den Maßnahmen aus einem Guide gesenkt werden können, kann dem Gesamtergebnis entnommen werden. Außerdem kann die Anzahl der Risiken pro jeweilige Klasse abgelesen werden, wobei beide Kategorien der Klasse Projektmanagement getrennt aufgeführt sind. Die höchste Anzahl der Risiken kann mit den identifizierten Maßnahmen aus dem CMMI-DEV-Guide gesenkt werden. Für die im Rahmen dieser Arbeit identifizierten Risiken ist also der CMMI-DEV-Guide der Passendere. Bei diesem Vergleich sind die Anzahl sowie die Qualität der Maßnahmen zur Senkung des jeweiligen Risikos nicht berücksichtigt. Zur Entscheidungsfindung ist es ratsam, zunächst die organisationsspezifischen Risiken zu analysieren. Anhand dieser Risiken kann dann mit Hilfe der Ergebnisse dieser Arbeit eine Vorauswahl für einen passenden RE-Guide getroffen werden. Sind beispielsweise die meisten organisationsspezifischen Risiken aus der Kategorie Projekt Management ohne Requirements Engineering als Eingabe, so eignet sich sowohl der CMMI-DEVals auch der Automotive SPICE -Guide. Im nächsten Schritt wäre also ein detaillierterer Vergleich dieser beiden Guides sinnvoll. Dazu könnten die Maßnahmen aus beiden Guides genauer analysiert werden und danach die Entscheidung für den passenden Guide getroffen werden. Die Gegenüberstellung der Risiken und Maßnahmen der verschiedenen RE-Guides ist also ein erstes Auswahlkriterium für den passenden RE-Guide. Dieses Kriterium deckt zwar einen wichtigen, aber nicht alle relevanten Aspekte von RE-Guides ab und ist somit nicht ausreichend. Die im Folgenden aufgeführten Überlegungen können die Auswahlentscheidung beeinflussen. Subjektiv betrachtet ist der IEEE 830-Guide auf Grund der Beschreibung, wann eine Anforderungsspezifikation gut ist, zwar wertvoll, jedoch nicht ausreichend. Das Template aus dem IEEE 830-Guide ist in drei große Abschnitte gegliedert, wobei der dritte Abschnitt Angaben aus dem zweiten Abschnitt detaillierter beschreiben soll. Diese Art der Strukturierung könnte die Dokumentation der Anforderungen insbesondere im Bezug auf Konsistenz und Aktualität erschweren. Das Spezifikations-Template aus dem Volere-Guide würde ich persönlich aus diesem Grund dem des IEEE 830-Guide vorziehen. Der maßgebliche Vorteil des Volere-Guides ist die Beschreibung der konkreten Techniken, Methoden und Arbeitsanweisungen. Die Guides CMMI-DEV und Automotive SPICE sind in der ersten Linie Reifegradmodelle und werden für die Bewertung und Optimierung von Prozessen verwendet. Dadurch gehen diese über andere RE-Guides deutlich hinaus. Automotive SPICE enthält zwar mehr Prozessbereiche und Praktiken, dafür hat der CMMI-DEV-Guide mehr Erläuterungen. Beide Guides sind klar strukturiert, können jedoch ohne zusätzliches Expertenwissen nicht verwendet werden, da die konkreten Techniken und Methoden zum Erreichen der Ziele nicht beschrieben werden. Ist dieses Wissen vorhanden, so sind diese Guides meiner Meinung nach dem IEEE 830- und Volere-Guide vorzuziehen, da sie eine größere Vollständigkeit erreichen.

69 Vergleich von RE-Guides als Anwendungsbeispiel der Ergebnisse 63 Der Nachteil von SPICE gegenüber dem CMMI-Reifegradmodell sind die inkonsistenten Bezeichnungen in der Literatur. Nicht nur der ISO/IEC Standard wird als SPICE bezeichnet, sondern auch der Technische Report (TR) ISO/IEC TR 15504, der Vorgänger des ISO/IEC Standards. Dadurch wird die Auseinandersetzung mit SPICE erschwert.

70 Zusammenfassung und Ausblick Zusammenfassung und Ausblick In diesem Kapitel werden die Ergebnisse dieser Arbeit zusammengefasst und ein Ausblick auf mögliche zukünftige Arbeiten gegeben Zusammenfassung Das Ziel dieser Arbeit war durch eine Demonstration eines direkten Zusammenhangs zwischen Requirements-Engineering-Aktivitäten und Risiken den Nutzen von RE zu zeigen. Unter dieser Zielsetzung sollte ein Modell zur Planung von Requirements- Engineering-Aktivitäten hergeleitet werden. Um dies zu erreichen wurde zunächst ein Modell zur Demonstration des RE-Nutzens konzipiert, welches die zwei folgenden Fragestellungen beinhaltet: Wie viele RE-abhängige Risiken (gemäß Definition 2-4) treten in Projekten ein? Wie viele Risiken können mit Requirements-Engineering-Aktivitäten gesenkt werden, also die Wahrscheinlichkeit des Eintretens von Risikoereignissen verringern bzw. das Schadensausmaß des Risikoereignisses begrenzen? Um diese Fragestellungen zu beantworten wurde eine Literaturrecherche durchgeführt. Dabei wurde die Literatur auf typische Risiken in der IT und insbesondere in der Softwareentwicklung und auf RE-Aktivitäten, die als Maßnahmen zur Senkung dieser Risiken eingesetzt werden können, analysiert. Die Recherche wurde mit Hilfe des Schneeballprinzip ausgehend von [Dam2006] durchgeführt. Zusätzlich wurde eine Schlagwortsuche in der IEEE Computer Society Digital Library und der ACM Digital Library durchgeführt. Außerdem wurden bereits bekannte relevante Quellen herangezogen. Bei der Literaturrecherche wurden insgesamt 29 relevante Quellen für Risiken und 28 relevante Quellen für die Maßnahmen identifiziert. Mittels Literaturrecherche wurden 70 typische Risiken und zu 49 Risiken Requirements-Engineering-Aktivitäten als Maßnahmen zur Risikosenkung identifiziert. Die identifizierten Risiken wurden anschließend klassifiziert. Dafür wurde das im Rahmen des Modells zur Demonstration des RE-Nutzens konzipierte Klassifikationsmodell für Risiken verwendet. Es wurde für die identifizierten Risiken Folgendes gezeigt: Vernachlässigen der Requirements-Engineering-Aktivitäten führt zur Entstehung von 49% derjenigen Probleme, die die Chance auf Projekterfolg reduzieren. RE-Aktivitäten können die Eintrittswahrscheinlichkeit bzw. das Schadensausmaß von 70 % der Risiken senken. Damit wurde der Nutzen von Requirements Engineering mit Hilfe von Risiken projektübergreifend demonstriert.

71 Zusammenfassung und Ausblick 65 Das Management lässt sich am besten mit konkreten Zahlen für konkrete Fälle überzeugen. Um die Demonstration des RE-Nutzens projektspezifisch zu ermöglichen, wurde ein Modell zur Planung vor RE-Aktivitäten im Rahmen des Risikomanagements entwickelt. Die klassifizierten Risiken und identifizierten RE-Aktivitäten als Maßnahmen wurden als Eingangsparameter für das Modell verwendet. Das Modell unterscheidet sich von einem typischen Risikomanagementprozess dadurch, dass es zum Einen möglich ist, den Nutzen von Requirements Engineering projektspezifisch zu zeigen und zum Anderen speziell RE-Maßnahmen zur Senkung identifizierter Risiken vorgeschlagen werden. Es wurde eine empirischen Erhebung durchgeführt, um die mittels Literaturrecherche identifizierten Risiken projektübergreifend zu priorisieren und dadurch die Benutzung der Liste klassifizierter, typischer Risiken bei der Identifikation projektspezifischer Risiken zu vereinfachen. Um die Anwendbarkeit der in dieser Arbeit entwickelten Konzepte zur Planung von RE-Aktivitäten im Rahmen des Risikomanagements zu demonstrieren, wurde ein Excel-basiertes Werkzeug erstellt. Außer den identifizierten Risiken und den Maßnahmen ist auch die Klassifizierung der Risiken in das Werkzeug integriert. Um die Demonstration des RE-Nutzens einfacher zu gestalten, wird vom Werkzeug eine grafische Auswertung generiert. Diese Auswertung beinhaltet projektübergreifende sowie projektspezifische Antworten auf die beiden Fragestellungen aus der Modellierung des RE- Nutzens. Das Werkzeug wurde anhand eines Szenarios illustriert. Außerdem wurde ein mögliches Anwendungsbeispiel der Ergebnisse dieser Arbeit vorgestellt, in dem diese für einen Vergleich der RE-Guides verwendet wurden. Die Auswahl eines passenden RE-Guides ist eine grundlegende Planungsaktivität von RE- Aktivitäten. Eine Gegenüberstellung der identifizierten Risiken sowie Maßnahmen, die ein RE-Guide zur Risikosenkung enthält, ist ein mögliches Auswahlkriterium für einen passenden RE-Guide. Damit bietet diese Arbeit ein tragfähiges Konzept, das sich zum Aufzeigen des RE- Nutzens und somit für die nutzenbasierte Planung von RE-Aktivitäten im Rahmen des Risikomanagements einsetzen lässt. Außerdem stellt die Arbeit eine gute Ausgangsbasis für weitere Arbeiten in diesem Bereich dar Ausblick Erfahrungen sind Katalysatoren in der Softwareentwicklung [Sch2007]. Ergebnisse einer Umfrage des Fraunhofer-Instituts zeigen, dass nur 17% der Befragten eine abschließende Projektanalyse durchführen und so Erfahrungswerte systematisch festhalten [Kal2003]. Eine mögliche Erweiterung dieser Arbeit ist daher die Entwicklung einer Experience Base, die die Ergebnisse dieser Arbeit bereitstellt. In einem solchen Wissensspeicher können die identifizierten Risiken und Maßnahmen von verschiedenen Projekten festgehalten, analysiert und die Ergebnisse in Folgeprojekten verwendet werden. Dabei sollte es möglich sein, die Maßnahmen auf Grund von Erfahrungen bewer-

72 Zusammenfassung und Ausblick 66 ten zu können. Jede Maßnahme sollte dazu einheitlich formuliert, eindeutig identifizierbar und mit einem Risiko verknüpft werden. Eine Bewertung der Maßnahmen könnte außerdem nach der Qualität der Quelle, aus der diese stammen, vorgenommen werden. Eine bessere Wiederverwendung der Erfahrung könnte durch sortiertes Vorschlagen der Maßnahmen gewährleistet werden. Dabei könnten die Maßnahmen nach verschiedenen Kriterien, z.b. nach Anzahl der Risiken, die diese senken können, oder nach einer Bewertung, wie oben beschrieben, sortiert werden. Auch eine Kombination oder weitere Kriterien wären denkbar. Durch die systematische Planung von RE-Aktivitäten im Rahmen des Risikomanagements soll eine bessere Unterstützung des Requirements Engineerings erreicht werden. Das Requirements Engineering soll in das Risikomanagement und damit auch in das Projektmanagement integriert werden. Um eine noch bessere Integration in das Projektmanagement zu erreichen, kann der Maßnahmenkatalog um weitere Handlungsfelder (beispielsweise Projektmanagement) ergänzt werden. Eine andere Möglichkeit zur Erweiterung betrifft den Schritt Risiken projektspezifisch identifizieren des konzipierten Modells. Bei der Risikoidentifikation wird eine im Rahmen dieser Arbeit erstellte Liste mit klassifizierten, typischen Risiken als Checkliste für die Identifikation projektspezifischer Risiken benutzt. Es existiert bereits eine Vielzahl verschiedener Risiko-Checklisten. Eine bekannte Checkliste ist Taxonomy-Based Questionnaire [Car1993], welche an der SEI der Carnegie Mellon Universität in Pittsburgh entwickelt wurde und 194 Fragen enthält [Wal2004]. Es wäre interessant, diesen Risikofragebogen zu analysieren und mit den im Rahmen dieser Arbeit identifizierten Risiken zu verbinden. Dadurch könnte die Identifikation projektspezifischer Risiken erleichtert werden. Zusätzlich zu den oben genannten Erweiterungsvorschlägen ist das Konzept, den Nutzen des Requirements Engineerings mit Hilfe von Risiken zu demonstrieren, auf seine Wirksamkeit in realen Projekten zu untersuchen.

73 Literaturverzeichnis [Bal2008] [Bas1984] [Ber2006] [Bed2008] [Bir2008] [Bir2007] [Boe1991] [Boe1989] [Boe1988] Balzert, H., Lehrbuch der Softwaretechnik: Softwaremanagement, Spektrum Akademischer Verlag, 2008, 2. Auflage Basili, V.R. & Perricone, B.T., Software Errors and Complexity: An empirical investigation, Communications of the ACM, 1984, Vol. 27, pp , Berntsson-Svensson, R. & Aurum, A., Successful Software Project and Products: An Empirical Investigation, ISESE '06, 2006, pp , Bedingfield, J.D.a nd Thal, A., Project manager personality as a factor for success, Portland International Conference on Management of Engineering & Technology, pp , 2008, er= Birk, A.; Heller, G.; Janzen, D. & Schmid, K., Orientierung in der Landschaft des Requirements-Engineering: Ein Überblick über RE- Frameworks und ihre Anwendungsgebiete, GI-Arbeitskreis Requirements-Engineering-Frameworks für Produktlinien, 2008, Birk, A., Fricker, S., Geisberger, E., Heller, G., Janzen, D., von der Maßen, T., Penzenstadler, B. & Schmid, K., Requirements-Engineering- Frameworks und Produktlinien. 2007, 9_Status_Report_REFPL.pdf Boehm, B.W., Software Risk Management: Principles and Practices, IEEE Software, 1991, Vol. 8, pp , stamp/stamp.jsp?arnumber=62930&isnumber=2296 Boehm, B. W., Software Risk Management, IEEE Computer Society Press, 1989, pp Boehm, B. W., A Spiral Model of Software Development and Enhancement, Computer, 1988, Vol. 21, Issue 5, pp ,

74 Literaturverzeichnis 68 [Boo2006] [Bor2006] [Bro1987] [Car1993] [Che2007] [Cle2008] [CMM2006] [Dam2006] [Dam2005] [Dav2005] Boonzaaier, J. & Loggerenberg, J. J. V., Implementation of a Project Office to Improve on Project Delivery and Performance: A Case Study, SAICSIT '06: Proceedings of the 2006 annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries, 2006, , D= &CFTOKEN= Bortz, J., Döring, N., Forschungsmethoden und Evaluation für Humanund Sozialwissenschaftler, 4., überarbeitete Auflage, Springer Medizin Verlag Heidelberg, 2006 Brooks, F.P., No Silver Bullet: Essence and Accidents of Software Engineering, Computer,, Vol. 20, no. 4, pp , 1987 Carr, M. J., Konda, S. L., Monarch, I., Ulrich, F.C., Walker, C.F., Taxonomy-Based Risk Identification, Technical Report CMU/SEI-93-TR-6, Pittsburgh, PA, Software Engineering Institute, 1993, Cheng, B. H. & Atlee, J. M., Research Directions in Requirements Engineering, Future of Software Engineering, pp , 2007, er= Cleff, T., Deskriptive Statistik und moderne Datenanalyse: Eine computergestützte Einführung mit Excel, SPSS und STATA, 1. Auflage 2008, Betriebswirtschaftlicher Verlag Dr. Th. Gabler, 2008 CMMI Product Team, CMMI for Development, Version 1.2, Carnegie Mellon University, Pittsburgh, USA., CMU/SEI-2006-TR-008 ESC-TR , 2006, Damian, D. & Chisan, J., An Empirical Study of the Complex Relationships between Requirements Engineering Processes and Other Processes that Lead to Payoffs in Productivity, Quality, and Risk Management, IEEE Transactions on Software Engineering VOL. 32, NO. 7, IEEE Internal Requirements Engineering Conference, Vol. 14, pp , 2006, er=35280 Damian, D.; Chisan, J.; Vaidyanathasamy, L. & Pal, Y., Requirements Engineering and Downstream Software Development: Findings from a Case Study, Empirical Software Engineering, Volume 10, no. 3, pp , 2005, Davis, A., Just enough requirements management: where software meets marketing, Dorset House Publishing, 2005

75 Literaturverzeichnis 69 [Dei2002] Deininger, M.; Lichter, H.; Ludewig, J. & Schneider, K., Studien- Arbeiten ein Leitfaden zur Vorbereitung, Durchführung und Betreuung von Studien-, Diplom- und Doktorarbeiten am Beispiel Informatik, 4., überarbeitete Auflage, vdf Hochschulverlag an der ETH Zürich Rielasingen, 2002 [Din2008] Ding, R. & Wang, Y., An Empirical Study on Critical Success Factors Based on Governance for IT Projects in China, 4th International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM'08), pp. 1-7, 2008, [Dor2006] Dorling, A., SPICE Trials, Project/, 2006 [Eng2007] Engel, C. & Holm, C., Ergebnisse der Projektmanagement Studie Schwerpunkt Kosten und Nutzen von Projektmanagement, 2007, 089c876bf085e249174f7f6fc [Eng2006] Engel, C., Menzer, M. & Nienstedt, D., Ergebnisse der Projektmanagement Studie Konsequente Berücksichtigung weicher Faktoren Gemeinsame Studie von GPM Deutsche Gesellschaft für Projektmanagement e.v. und PA Consulting Group, 2006, ipma.de//docs/showsite.php?menu=011602&gsag=089c876bf085e f7f6fc [Fir2007] Firesmith, D.G., Common Requirements Problems, Their Negative Consequences, and Industry Best Practices to Help Solve Them, Journal of Object Technology, 2007, Vol. 6, pp. pp , [Foe2007] Foegen, M., Battenfeld, J. & Raak, C., CMMI - ein Werkzeug zur Prozessverbesserung, computerwoche, 2007, [Foe2003] Foegen, M. & Raak, C.,CMMI Überblick, wibas IT Maturity Services GmbH, 2003, [Gan2003] Gantner, T. & Barth, T., Experiences on Defining and Evaluating an Adapted Review Process, Proceedings of the 25th International Conference on Software Engineering, 2003, pp , D= &CFTOKEN= [Gem1997] Gemuenden, H. & Lechler, T., Success factors of project management: the critical few-an empirical investigation, Portland International Conference on Management and Technology Innovation in Technology Management - The Key to Global Leadership, pp , 1997, =13450

76 Literaturverzeichnis 70 [Gib2006] Gibson, D. L.; Goldenson, D. R. & Kost, K., Performance Results of CMMI-Based Process Improvement, CMU/SEI-2006-TR-004, Software Engineering Institute (SEI), 2006, [Gro2005] Group, T.S., CHAOS RISING, 2005, [Gro2001] Group, S., EXTREME CHAOS, 2001, eme_chaos.pdf [Gro1994] Group, S., The CHAOS Report [1994], 1994, [Ham2005] Hamidovic, A. & Krajnovic, S., An example of a novel approach to measuring projects success within ICT industry, Proceedings of the 8th International Conference on Telecommunications (ConTEL), Volume 2, pp , 2005, mber= &isnumber=31386 [Hoc2008] Hochrainer, J., Software Quality Lab QM-Studie 2008, , [Hör2006] Hörmann, K.; Dittmann, L.; Hindel, B. & Müller, M., SPICE in der Praxis dpunkt.verlag, 2006 [Hyv2006] Hyväri, I., Success of projects in different organizational conditions, Project Management Journal, vol. 37, no. 4, pp.31-41, 2006, ess%20of%20projects%20in%20different%20organizational%20condi tions.pdf [IEE1998] IEEE, IEEE Recommended Practice for Software Requirements Specifications, The Institute of Electrical and Electronics Engineers, Inc., 1998 [ISA2008] ISACA, CobiT 4.0, IT GOVERNANCE INSTITUTE, 2008 [Jae2009] De Jaeger, J.-M., PMBOK (PMI), 12manage - The Executive Fast Track, V10.3, letzter Zugriff: [Jó2008] Jó, P. A. & Barry, M.-L., The most important success factors for implementation of government projects in developing countries, Proceedings of Portland International Conference on Management of Engineering & Technology, pp , 2008, er= [Joh2007] Johannes, W. & Goeken, M., Referenzmodell für IT-Governance, dpunkt.verlag, 2007 [Jon2007] Jones, C., SOFTWARE ENGINEERING: THE STATE OF THE ART IN 2007, 2007, Vol. 11,

77 Literaturverzeichnis 71 [Jon1996] [Kal2003] [Kam2007] [Kau2004] [Kir1997] [Kna2007] [KPM2007] [KPM1994] [Kuj2005] [Lev2000] [Lin1999] Jones, C., Strategies for Managing Requirements Creep, Computer, 1996, Vol. 29, no. 6, pp Kalthoff, C. & Kunz, D.S., Projektmanagement bei der Entwicklung kritischer Systeme Ergebnisse einer Umfrage des Fraunhofer-Instituts IITB, Karlsruhe in Kooperation mit der Deutschen Gesellschaft für Projektmanagement GPM, Nürnberg, 2003, Kamata, M.I. & Tamai, T., How Does Requirements Quality Relate to Project Success or Failure?, 15th IEEE International Requirements Engineering Conference, 2007, pp , number= Kauppinen, M., Vartiainen, M., Kontio, J., Kujala, S. & Sulonen, R., Implementing Requirements Engineering Processes throughout Organizations: Success Factors and Challenges, Information and Software Technology, Vol. 46, no. 14, pp , 2004, Kirner, T.G. & Abib, J.C., Inspection of Software Requirements Specification Documents: A Pilot Study, ACM Special Interest Group for Design of Communication, 1997, pp Knauss, E., Flohr, T., Beßen, D., Lübke, D., Röpke, A., Schneider, K., Strüber, B., Trütken, J., Trump, C. & Willmann, M., Nicht perfekt, aber richtig Erfahrungen mit Software-Anforderungen, GI Softwaretechnik-Trends, Band 27, Heft 1, 2007 KPMG, The evolution of risk and controls. From score-keeping to strategic partnering, KPMG International 2007, df KPMG, Report on IT runaway systems. Telephone survey for KPMG Management Consulting, 1994 Kujala, S.; Kauppinen, M.; Lehtola, L. & Kojo, T., The Role of User Involvement in Requirements Quality and Project Success, Proceedings of the 13th IEEE International Conference on Requirements Engineering, 2005, pp , Leveson, N.G., Intent Specifications: An Approach to Building Human- Centered Specifications, IEEE Transactions on Software Engineering, 2000, Vol. 26, pp , umber=17880 Linberg, K.R., Software developer perceptions about software project failure: a case study, The Journal of Systems and Software, 1999, Vol. 49, pp

78 Literaturverzeichnis 72 [McC2004] McConell, S., Code Complete Deutsche Ausgabe der Second Edition, Microsoft Press Deutschland, 2004 [Nel2001] Nellore, R. & Balachandra, R., Factors influencing success in integrated product development (IPD) projects, IEEE Transactions on Engineering Management, Volume 48, Issue 2, pp , 2001, =19944 [PMI2004] PMI, A Guide to the Project Management Body of Knowledge, Third Edition, Project Management Institute, 2004 [PMI2004a] PMI Berlin, Project Management Institute Berlin/Brandenburg Chapter e.v., Version: 2004, letzter Zugriff: [Pro2002] Procaccino, J.D., Verner, J.M. & Overmyer, S.P., Case Study: Factors for Early Prediction of Software Success & Failure, Information and Software Technology, 2002, Vol. 44, pp [Ras2007] Rashid, A., OpenProposal: Towards Collaborative End-User Participation in Requirements Management By Usage of Visual Requirement Specifications, Proceedings of the 15th IEEE International Conference on Requirements Engineering, 2007, pp , [Rob1999] Robertson, S. & Robertson, J., Mastering the Requirements Process, ACM Press Books, 1999 [Rom2002] Frank Romeike, Risikomanagement als Grundlage einer wertorientierten Unternehmenssteuerung, RATINGaktuell 02/2002, 2002, ktuell/ratingaktuell08_2002_risikomanagement.pdf [Rup2007] Rupp, C., Requirements-Engineering und Management, Hanser Fachbuch, Auflage: 4, 2007 [Sch2009] Schneider, Kurt, Vorlesung: Grundlagen der Softwaretechnik, 2009, [Sch2007] Schneider, K., Abenteuer Software Qualität, dpunkt.verlag, 2007 [Sch2007a] Schneider, Kurt, Vorlesung: Anforderungen und Entwurf, 2007, [Som2007] Sommerville, I., Software Engineering, 8., aktualisierte Auflage, Pearson Studium, 2007 [SUC2006] Buschermoehle, R., Eekho, H. & Josko, B., SUCCESS Erfolgs- und Misserfolgsfaktoren bei der Durchfuehrung von Hard- und Softwareentwicklungsprojekten in Deutschland, 2006,

79 Literaturverzeichnis 73 [Tar2008] Tarawneh, M. M. I.; AL-Tarawneh, H. & Elsheikh, A., Software Development Projects: An Investigation into the Factors that Affect Software Project Success/ Failure in Jordanian Firms, First International Conference on the Applications of Digital Information and Web Technologies (ICADIWT), pp , 2008, [Thi1999] Thite, M., Leadership: A Critical Success Factor in IT Project Management, Portland International Conference on Management of Engineering and Technology, Technology and Innovation Management., Vol. 1, pp. 207, 1999, =17495 [VDA2007] Verband der Automobilindustrie e.v., Automotive SPICE Prozessassessment, RELEASE v2.3, 05 May 2007, [Ver2005] Versteegen, G., Prozessuebergreifendes Projektmanagement: Grundlagen erfolgreicher Projekte, Springer Verlag, 2005 [Wal2004] Wallmüller, E., Risikomanagement für IT- und Software-Projekte: Ein Leitfaden für die Umsetzung in der Praxis, Carl Hanser Verlag Müchen, 2004 [Vol2009] Volere, Experiences of Volere Users, lezter Zugriff: [War1996] Warne, L. & Hart, D., The impact of organizational politics on information systems project failure-a case study, Proceedings of the Twenty- Ninth Hawaii International Conference on System Sciences, Volume 4, pp , 1996, =10448 [Wei1993] Weinberg, G.M. & Gause, D.C., Software Requirements: Anforderungen erkennen, verstehen und erfüllen, Carl Hanser Verlag München, 1993

80 Literaturverzeichnis 74 [Wie2001] [Wik2009] [Wol2006] [Wöl2002] [You2001] [You2001a] Wiegers, K.E., Inspecting Requirements, StickyMinds.com Weekly Column, 2001, ETAILBROWSE&ObjectType=COL&sqry=%2AZ%28SM%29%2AJ %28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2 AF%28Karl++E%2E++Wiegers%2C++%93Inspecting++Requirements %2C%94++StickyMinds%2Ecom++Weekly++Column%2C+30+July+ 2001%29%2A&sidx=28&sopp=10&sitewide.asp?sid=1&sqry=%2AZ% 28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28s implesite%29%2af%28karl++e%2e++wiegers%2c++%93inspecting++re quirements%2c%94++stickyminds%2ecom++weekly++column%2c+30+ July+2001%29%2A&sidx=28&sopp=10 Wikipedia, Erläuterung des Begriffs Project Management Institute, 2009, letzter Zugriff: Wolff, C., Medieninformatik Universität Regensburg, Hinweise zur Literaturrecherche, &view=article&id=114&itemid=151, letzter Zugriff: Wöll, P., IT-KOSTEN UND IT-PERFORMANCE Betriebswirtschaftliche Studie der Schweizer Informatikabteilungen, 2002, Young, R.R., What If There s No Time for Requirements Engineering?, 2001, _No_Time_for_RE.ppt Young, R. R., Effective Requirements Practice, Addison-Wesley Professional, 2001

81 Abbildungsverzeichnis 75 Abbildungsverzeichnis Abbildung 2-1: Referenzmodell Requirements Engineering nach [Sch2007a]... 4 Abbildung 2-2: Übersicht der Wissensbereiche des Projektmanagements nach [PMI2004]... 6 Abbildung 2-3: Software-Risikomanagement-Prozessschritte nach Boehm [Boe1991]... 8 Abbildung 2-4: Aufbau und Struktur von CMMI nach [Foe2003] Abbildung 2-5: Überblick über die Prozesse in Automotive SPICE Abbildung 2-6: Das CobiT-Referenzmodell Abbildung 3-1: Übersicht des Vorgehens, um RE-Nutzen über Risiken zu zeigen Abbildung 3-2: Zusammenhang Maßnahmen und Risiken Abbildung 3-3: Klassifikationsmodell Abbildung 4-1: Literaturrecherche nach Schneeballprinzip Abbildung 5-1: Ergebnis der Klassifikation aller typischen Risiken in IT-Projekten Abbildung 6-1: Ergebnis der Identifikation der Maßnahmen Abbildung 7-1: Modell zur Planung von RE-Aktivitäten im Rahmen des Risikomanagements Abbildung 7-2: Projektspezifische Risiken identifizieren Abbildung 7-3: Projektspezifische Risiken analysieren Abbildung 7-4: Struktur des Fragebogens Abbildung 7-5: Mittelwerte der Eintrittswahrscheinlichkeit des Risikoereignisses Abbildung 7-6: Mittelwerte der Schadenshöhe des Risikoereignisses Abbildung 7-7: Risikofaktor-Übersicht Abbildung 7-8: Klassifizierung der Top 10 Risiken aus projektübergreifender Priorisierung Abbildung 8-1: Screenshot des Tabellenblattes Risikobewertung Abbildung 8-2: Screenshot der identifizierten Risiken Abbildung 8-3: Screenshot des Tabellenblattes Quellenvergleich_Auswertung Abbildung 8-4: Screenshot des Auswahlfensters Abbildung 8-5: Screenshot des Tabellenblattes Maßnahme_Vorschläge Abbildung 8-6: Screenshot der Auswertung des projektspezifischen RE-Nutzens Abbildung 9-1: Vergleich der RE-Guides... 61

82 Tabellenverzeichnis 76 Tabellenverzeichnis Tabelle 1: Abdeckung der Aspekte von RE-Guides Tabelle 2: Ergebnisse der Literaturrecherche nach Schneeballprinzip Tabelle 3: Ergebnisse der Schlagwortsuche Tabelle 4: Einordnung der bekannten Quellen Tabelle 5: Ergebnis der Literaturrecherche Tabelle 6: Eckdaten der verwendeten Studien zur Risikoidentifikation Tabelle 7: Auszug der Risiken aus der Literatur Tabelle 8: Beispiele zur Erhebung der Maßnahmen aus CMMI-DEV Tabelle 9: Beispiele zur Erhebung der Maßnahmen aus Automotive SPICE -Guide Tabelle 10: Beispiele zur Erhebung der Maßnahmen aus dem Volere-Guide Tabelle 11: Beispiel zur Erhebung der Maßnahmen aus dem IEEE830-Guide Tabelle 12: Beispiel zur Erhebung der Maßnahmen aus CobiT Tabelle 13: Arten der Literatur Tabelle 14: Beispiele zur Interpretation bei der Erhebung von Maßnahmen Tabelle 15: Beispiele zur Ableitung von Maßnahmen im Volere Guide Tabelle 16: Beispiel zur Ableitung der RE-Aktivitäten Tabelle 17: Identifizierte Maßnahmen Übersicht Tabelle 18: Rollen der Umfrageteilnehmer Tabelle 19: Angaben zu Erfahrung Tabelle 20: Interpretation der qualitativen Bewertung Tabelle 21: Top 10 Risiken nach der Rangordnung Tabelle 22: Vergleich der Maßnahmen Tabelle 23: Mehrfachnennung von Rollen der Umfrageteilnehmer Tabelle 24: Von Teilnehmer hinzugefügte Risiken Tabelle 25: Auswertungsangaben zu Risiken

83 Anhang A: Risikofaktoren in IT-Projekten 77 Anhang A: Risikofaktoren in IT-Projekten Quelle [Hoc2008] [Eng2007] [Eng2006] [SUC2006] [Gro1994] [KPM1994] [Jon2007] Risiken Die größten Risikofaktoren in IT-Projekten: Zu knappe oder unrealistische Terminvorgaben, Fehlende Personalressourcen, Mangelhafte Anforderungsspezifikation, Nicht kalkulierte Mehraufwände, Kunde ist zu wenig eingebunden bzw. nimmt sich zu wenig Zeit, Mangelnde Projektleiterkompetenz, Test nicht oder zu wenig durchgeführt, Unzureichendes Change-Management im Projekt, Unzureichendes Risikomanagement im Projekt, Fehlende Unterstützung durch Entscheidungsträger, Mangelndes Wissen der Projektmitarbeiter, Keine Akzeptanz beim Kunden Ursachen für das Scheitern von Projekten: Schlechte Kommunikation, Unklare Anforderungen und Ziele, Politik / Egoismen / Kompetenzstreit, Fehlende Ressourcen bei Projektstart, Mangel an qualifizierten MA, Fehlende PM-Erfahrung auf Leitungsebene, Fehlende Unterstützung durch Top Management, Unzureichende Projektplanung, Mangelhaftes Stakeholder Management, Fehlende PM-Methodik (z.b. kein Risiko-Mgmt), Technische Anforderungen zu hoch Gründe für den Misserfolg bei Projekten: Unklare Anforderungen und Ziele, Fehlende Ressourcen bei Projektstart, Unzureichende Projektplanung, Mangel an qualifizierten MA, Politik / Bereichsegoismen/ Kompetenzstreit, Schlechte Kommunikation, Fehlende PM-Erfahrung auf Leitungsebene, Fehlende PM-Methodik, Mangelhaftes Stakeholder Management, Fehlende Unterstützung durch Top Management, Technische Anforderungen zu hoch Kriterien, die Erfolg beeinflussen: Projektlaufzeit, Managementunterstützung, Motivation des Projektteams, Qualität der Kommunikation im Team, Projektkontrolle, Kundeneinbindung, Komplexitätsgrad der zu entwickelnden Hard-, Software, Einsatz einer Schätzmethode während der Projektplanung, Kompetenz des Projektteams Project Success Factors: User Involvement, Executive Management Support, Clear Statement of Requirements, Proper Planning, Realistic Expectations, Smaller Project Milestones, Competent Staff, Ownership, Clear Vision & Objectives, Hard-Working, Focused Staff Project Challenged Factors: Lack of User Input, Incomplete Requirements & Specifications, Changing Requirements & Specifications, Lack of Executive Support, Technology Incompetence, Lack of Resources, Unrealistic Expectations, Unclear Objectives, Unrealistic Time Frames, New Technology Project Impaired Factors: Incomplete Requirements, Lack of User Involvement, Lack of Resources, Unrealistic Expectations, Lack of Executive Support, Changing Requirements & Specifications, Lack of Planning, Didn't Need It Any Longer, Lack of IT Management, Technology Illiteracy Following factors caused the Runaway problem: Project objectives nit fully specified, Bad planning and estimating, Used technology new to the organization, Inadequate project management methodology, Not enough senior staff on project team, Poor performance by suppliers of software/hardware, Inadequate software development methodology, The project was too ambitious, Wrong staffing on project team, Poor communication between project personnel, Top management were unaware of project problems, Inadequate training of system users, Poorly defined contract with suppliers, Poor performance by project management consultants, Used the wrong hardware/software, Poorly defined contract with project management consultants Successful Projects: Effective project planning, Effective project cost estimating, Effective project measurements, Effective project milestone tracking, Effective project quality control, Effective project change management, Effective development processes, Effective communications, Capable project managers, Capable technical personnel, Capable technical personnel, Significant use of specialists Failing Projects: Inadequate project planning, Inadequate cost estimating, Inadequate measurements, Inadequate milestone tracking, Inadequate quality control, Ineffective change control, Ineffective development processes, Ineffective communications, Ineffective project managers, Inexperienced technical personnel

84 Anhang B: Klassifizierung der typischen Projektrisiken 78 Anhang B: Klassifizierung der typischen Projektrisiken Requirements Analysis Elicitation Anforderungen sind nicht bekannt Fehlende Anforderungen Unzureichende Kundeneinbindung Wenig Endbenutzer-Einbeziehung Validierung Inadäquate Anforderungsvalidierung Dokumentation Mangelhafte Anforderungsspezifikation Schlechte Qualität der Anforderungen Dokumentierte Anforderungen sind nicht verfolgbar Übergewichtung der Use Cases Anforderungen sind nicht testbar dokumentiert Verifizierung Inadäquate Verifikation der Anforderungen Elicitation/ Interpretation/ Negotiation/ Dokumentation/ V&V Unklare Anforderungen Technische Anforderungen zu hoch Verlieren im Details Entwicklung falscher Benutzerschnittstelle Gold Plating (unnötige, überflüssige Eigenschaftenschaften Entwicklung falscher Funktionen und Eigen- Nicht-funktionale Anforderungen werden vernachlässigt Requirements Management RM: Änderungsmanagement Ständige Änderung der Anforderungen Unzureichendes Anforderungsmanagement (Behandlung von Änderungswünschen, Verwalten unterschiedlicher Versionen von Anforderungen, Propagieren der Änderung) RM: Verfolgbarkeit Mangelhaftes Stakeholder Management Ineffektive Änderungskontrolle der Anforderungen (-> requirements creep)

85 Anhang B: Klassifizierung der typischen Projektrisiken 79 Projekt Management mit Requirements Engineering als Eingabe Project Scope Management Unzureichende Projektplanung Unrealistische Erwartungen Unklare Ziele Inadäquate Messungen Project Time Management Unrealistische Schätzung der Zeit Mangel an Zeit Project Quality Management Inadäquate Qualitätssicherung Test nicht oder zu wenig durchgeführt Unzureichende Qualität des Projektergebnisses Project Human Resource Management Mangel an qualifizierten Mitarbeitern Falsche Besetzung des Projektteams Projekt Management ohne RE als Eingabe Project Integration Management Zu späte Integration Fehlende Werkzeugunterstützung Unzureichende Projektkontrolle Unzureichendes Change- Management im Projekt Project Scope Management Falsche Wahl von Projektressourcen Zu ehrgeizige Projektziele Inadäquates Milestone Tracking Nicht ausreichend feine Meilensteine Project Cost Management Unrealistische Schätzung der Kosten Nicht kalkulierte Mehraufwände Mangel an Budget Project Communications Management Schlechte Kommunikation Fehlende Kenntnis von Projektproblemen beim Management Project Procurement Managemen Defizite in externen Komponenten Defizite in extern ausgeführten Aufgaben Project Human Resource Management Fehlende Motivation des Projektteams

86 Anhang B: Klassifizierung der typischen Projektrisiken 80 Prozess Entwicklungsprozess Unzureichende Software-Entwicklungsmethoden Ineffektive Entwicklungsprozess Projektmanagement-Prozess Fehlende Projektmanagement-Methodik (z.b. kein Risikomanagement) Schlechtes Projektmanagement Unzureichende Projektmanagementmethoden Fehlende Prozessmodelle Zu hohe Dokumentenorientierung (formal statt kurze Dienstwege) Andere Fehlende Unterstützung durch Top-Management Fehlende Projektmanagement-Erfahrung auf Leitungsebene Politik, Egoismen, Kompetenzstreit Anwendung neuer Technologien Überschätzung der eigenen IT- Fähigkeiten Zu hoher Komplexitätsgrad der zu entwickelnden Hard-, Software Technologienwandel (Technologiewechselt während Projektlaufzeit stattgefunden, z.b. weil die vorgesehene Technologie sich nicht etabliert hat.) Äußere Einflüsse Nachlassende Produktivität bei mehrjährigen Projekten Unerfahrener Projektleiter Unklare Verantwortlichkeiten Projektergebnis wird nicht länger benötigt Mangelhaftes IT-Management Technologie Analphabetismus (die Unfähigkeit, die Technologie im Alltag so zu gebrauchen, wie es als selbstverständlich angesehen wird)

87 Anhang C: Identifizierte Maßnahmen 81 Anhang C: Identifizierte Maßnahmen Projekt Management mit RE als Eingabe Projekt Management ohne RE als Eingabe Requirements Engineering Prozess Andere Unzureichende Kundeneinbindung [Rob1999] Stelle sicher, dass alle Teilnehmer Platz und Dauer des Kick-Off-Meetings wissen. Sende jedem die Agenda und stelle sicher, dass jeder weiß, was ihn erwartet. Sende die Liste aller Teilnehmer mit jeder Einladung ( E) [Rob1999] Beschreibe jedes Ziel in einem Satz. Frage den Kunden, warum der Kunde das Ziel verfolgt, welche Vorteile es für sein Geschäft hat und wie der Projekterfolg gemessen wird (E) [Rob1999] Bitte den Kunden die Anforderungen (auf der Skala von 1 bis 5) aus zwei Sichtpunkten zu beurteilen: "Wie glücklich werden Sie sein, wenn ich ein Lösung bereitstelle, die angemessene Kriterien der Anforderung erfühlt?" und "Wie unglücklich werden Sie sein, wenn ich keine Lösung bereitstelle?" (E) [CMM2006] "validation issues can be discovered early in the life of the project using work products by involving relevant stakeholders" (E/S) [CMM2006] Beispiele der Akivitäten für Kundeneinbindung sind folgende (E): " Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces Establishing operational concepts and scenarios Assessing the adequacy of requirements Establishing product and product component requirements Assessing product cost, schedule, and risk" [VDA2007] Überprüfen Sie gemeinsam mit den Kunden die Kundenanforderungen und anfragen, um deren Bedürfnisse und Erwartungen besser verstehen zu können ( E) [VDA2007] Führe gemeinsames Review durch, um ein gemeinsames Verständnis mit den Stakeholdern bezüglich der Fortschritte im Vergleich zu den vereinbarten Zielsetzungen zu wahren, und abzustimmen, was getan werden sollte. (E) [Dam2006] Verbesserte Schätzung der Ressourcen und sorgfältige Kontrolle fördert die Kundenbereitschaft zu Anforderungserhebung [IEE1998] "The customer may be more likely to view the prototype and react to it than to read the SRS [Software Requirements Specification] and react to it. Thus, the prototype provides quick feedback."( E) Unzureichende Endbenutzer-Einbeziehung [Rob1999] Stelle sicher, dass alle Teilnehmer Platz und Dauer des Start-Meetings wissen. Sende jedem die Agenda und stelle sicher, dass jeder weiß, was ihn erwartet. Sende die Liste aller Teilnehmer mit jeder Einladung ( E) [Rob1999] "The end-users have to be satisfied that the product will be beneficial to them" (E) [Ras2007] Graphische Elemente (GUI, Use-case-Diagramm (UML), Mockups) als Unterstützung zur textuelle Beschreibung in der Anforderungsspezifikation und in der Kommunikation (anstatt nur ) erleichtern die Endbenutzer-Einbindung. Mockups und Rapid prototyping techniques in den face-to-face- Meeting einsetzten um Feedback der Endbenutzer zu bekommen. (E) [Kna2007] Use Cases können Anwender und andere Stakeholder gut nachvollziehen und beurteilen (E)

88 Anhang C: Identifizierte Maßnahmen 82 [VDA2007] Führe gemeinsames Review durch, um ein gemeinsames Verständnis mit den Stakeholdern bezüglich der Fortschritte im Vergleich zu den vereinbarten Zielsetzungen zu wahren, und abzustimmen, was getan werden sollte, um sicherzustellen, dass ein Produkt entwickelt wird, das zur Zufriedenheit der Stakeholder ist. (E) [CMM2006] Beispiele der Akivitäten für Endbenutzereinbindung sind folgende (E): " Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces Establishing operational concepts and scenarios Assessing the adequacy of requirements Establishing product and product component requirements" Anforderungen sind nicht bekannt [Rob1999] (E): Benutzen Sie folgende Techniken: 1. Review der gegenwärtigen Situation. - Gut, um unbewusste Anforderungen aufzudecken - Hilft, neue Anforderungen hinzufügen oder Wartungsarbeiten am existierenden System durchführen - Ein gute Basis für Geschäftsprozess-Neugestaltung 2. Apprentice with the user ( Meister macht Tätigkeit vor, Beobachter ( Lehrling ) sieht zu. Nachfragen und Erklären bei Bedarf) - Hilft, unbewusste und bewusste Anforderungen aufzudecken - Nützlich, wenn Benutzer zu beschäftigt sind, um zu sprechen 3. Die wesentlichen Anforderungen bestimmen. - Hilft, Anforderungen von Lösungen zu trennen - Eine gute Weise, den echten Zweck des Systems zu verstehen - Hilft im Aufdecken unbewusster Anforderungen und ermöglicht die Einblicke in die Auslöser der ungeahnte Anforderungen 4. Die Stakeholder interviewen. - Eine gute Technik, um bewusste Anforderungen zu entdecken 5. Brainstorming. - Hilft, ungeahnte Anforderungen aufzudecken - Sehr nützlich bei der Entwicklung neuer Produkte mit unbekannten/potenziellen Benutzern 6. Use Case-Workshops. - Involviert die Stakeholder in die Aufklärung vager, komplizierter und schwieriger Ereignisse - Gut, um bewusste und unbewusste Anforderungen aufzudecken 7. Dokumentenarchäologie. (Untersuche die Dokumente und Dateien, die die Organisation verwendet. Soll nicht als einzelne Technik für die Anforderungserhebung verwendet, aber als Ausgangspunkt für intensiveren Interviews an als Basis für die Aufwand-Modellierung) (E) - Verwendet, wenn Ihre Informationsquelle Dokumente ist 8. Build event models. - Wenn die Geschäftsereignis-Grenzen vage sind, dann untersuchen sie diese anhand einer ausführlichen Systemanalyse-Modellierung 9. Anforderungsvideos machen. - Nützlich, wenn die Zeit von Benutzern beschränkt wird - Kann studiert, analysiert, und von einer Gruppe verwendet werden, nachdem das Video gemacht wird - Hilft, wenn der Zusammenhang vage ist 10. Low-Fidelity prototypes: Gut, um ungeahnte Anforderungen zu ermitteln (E) 11. High-Fidelity prototypes: Gut, um usability Anforderungen zu ermitteln (E) [DAV2005], [IEE1998] Prototyping (E) [DAV2005] Inkrementelle Entwicklung (S) [Ras2007] GUI-Elemente ohne Funktionalitä einsetzen, um die Anforderungen herauszufinden. Mockups und Rapid prototyping techniques in den face-to-face-meeting einsetzten um Feedback der Endbenutzer zu bekommen. (E) [Kuj2005] "user visits help in understanding underlying needs and identifying the most essential issues" (E)

89 Anhang C: Identifizierte Maßnahmen 83 [CMM2006] Folgende Techniken können verwendet werden, um die Bedürfnisse der Betroffenen, Erwartungen, Einschränkungen und Schnittstellen für alle Phasen des Produktlebenszyklus zu ermitteln: "Technology demonstrations; Interface control working groups; Technical control working groups; Interim project reviews; Questionnaires, interviews, and operational scenarios obtained from end users; Operational walkthroughs and end-user task analysis; Prototypes and models; Brainstorming; Quality Function Deployment; Market surveys; Beta testing; Extraction from sources such as documents, standards, or specifications; Observation of existing products, environments, and workflow patterns; Use cases; Business case analysis; Reverse engineering (for legacy products); Customer satisfaction surveys" Fehlende Anforderungen [IEE1998]: Sorgfältiges Review der Anforderung in der SRS kann die Versäumnisse, Missverständnisse, und Widersprüchlichkeiten früh im Entwicklungszyklus aufdecken, wenn diese Probleme leichter zu korrigieren sind. (S) [Rob1999] (E): Um das Fehlen der Anforderungen festzustellen tun Sie folgendes für jeden Typ der Anforderungen: -Identifizieren Sie alle Anforderungen dieses in der Anforderungsspezifizierung definierten Typs. -Wenn es keine Anforderungen dieses Typs gibt, und wenn der strategische Plan für das Produkt anzeigt, dass es Anforderungen dieses Typs geben soll, so gibt es fehlende Anforderungen. Vergleichen Sie jeden Ereignis/Use Case in Ihrer Spezifikation mit jedem Typ der nicht-funktionalen Anforderung. Stellen Sie diese Frage, um fehlende Anforderungen zu identifizieren: Ist dieser Typ der nicht-funktionalen Anforderung für diesen Anwendungsfall/Ereignis relevant? Beachten Sie folgende Typen: FUNCTIONAL REQUIREMENTS: The Scope of the Work; The Scope of the Product; Functional and Data Requirements; NON-FUNCTIONAL REQUIREMENTS: Look and Feel; Usability and Humanity; Performance; Operational; Maintainability and Support; Security, Cultural and Political, Legal [Dam2006] Im Voraus definierte Testszenarien, Validierung der Anforderungen sowie peer-review (Prüfung durch Experten) führen zu verbesserte (Feature) Eigenschaftsabdeckung. (E ) [Kuj2005] "user visits help in understanding underlying needs and identifying the most essential issues" (E) [CMM2006] Analysiere und Validiere Anforderungen (E) [Rob1999] Apprentice with the user (benutze dieses Technik, wenn der Endbenutzer keine Zeit hat für die Unterhaltung oder schlecht in der Obstraktion ist) (E) [Rob1999] Prototype the Requirements. (Neue Anforderungen und Änderung der Anforderungen sind die Ergebnisse der Benutzung des Prototyps) (E) Mangelhafte Anforderungsspezifikation [IEE1998]:Charakteristiken einer guten Software Requirements Spezifikation (SRS) Die SRS ist nur dann korrekt, wenn jede Anforderung korrekt und notwendig ist. Also nur jene Leistungen und Eigenschaften wiederspielgelt, die von Stakeholdern tatsächlich gefordert werden und wenn die Anforderung vollständig der Vorstellung des Stakeholders, der sie formuliert hat, entspricht. Die SRS ist nur dann eindeutig, wenn jede Anforderung eindeutig ist. Also die Anforderung von allen Beteiligten auf die gleiche Art und Weise verstanden wird. Im Falle, dass ein Begriff in einem Zusammenhang mehrdeutig sein kann, so muss dieser im Glossar aufgenommen und erläutert werden. Die in natürlicher Sprache verfasste SRS soll von unabhängigen Dritten geprüft werden, um die Mehrdeutigkeiten zu identifizieren und eliminieren. Die SRS ist vollständig, wenn diese folgende Elemente enthält: a) Alle signifikante Anforderungen bezüglich Funktionalität, Leistung, Design, Grenzen, Attribute und externen Schnittstellen. Insbesondere alle aus der System Spezifikation aufgezwungene Anforderungen sollen behandelt werden.

90 Anhang C: Identifizierte Maßnahmen 84 b) Spezifizierung der Ausgaben (Antworten) der Software in allen vorstellbaren / realisierbaren Klassen von Eingaben und Situationen. Dabei ist es wichtig, die Ausgaben sowohl für gültige als auch für ungültige Eingaben zu spezifizieren. c) Die Beschriftung und Referenzen auf allen Abbildungen, Tabellen, und Diagramme in der SRS sind vollständig sowie alle Begriffe und Maßeinheiten sind definiert Die SRS ist konsistent, wenn jede Anforderung in sich und gegenüber allen anderen Anforderungen widerspruchsfrei ist in der SRS selbst und auch, falls vorhanden, zu den Higher-Level-Dokumenten wie z.b. System Spezifikation. Die SRS ist nach Wichtigkeit und/oder Stabilität bewertet, wenn jede Anforderung nach Wichtigkeit und/oder Stabilität bewertet ist. Stabilität kann als Verhältnis der erwarteten Änderungen der Anforderung zu allen Anforderungen angegeben werden. Eine andere Weise, die Anforderungen zu bewerten, ist, die Klassen von Anforderungen als wesentlich, bedingt und optional zu unterscheiden. Die SRS ist nur dann prüfbar, wenn jede Anforderung prüfbar ist. Eine Anforderung ist prüfbar, wenn, und nur wenn, ein endlicher kosteneffektiv Prozess besteht, mit dem eine Person oder Maschine das überprüfen können, das Softwareprodukt der Anforderung entspricht. Im Allgemeinen ist jede zweideutige Anforderung nicht nachprüfbar. Die SRS ist modifizierbar nur wenn die Struktur und der Stil der SRS solcher sind, dass irgendwelche Änderungen zu den Anforderungen leicht, vollständig, und konsistent vorgenommen werden können währen die Struktur und Stil nicht verändert werden müssen. Üblicherweise erfordert die Modifizierbarkeit von SRS: a) Eine zusammenhängende und gebrauchsfreundliche Organisation der SRS mit einer Inhaltsübersicht, einem Index, und expliziten Querverweisen; b) Nicht redundant zu sein (d. h. sollte dieselbe Anforderung sollte nicht in mehr als einem Platz im SRS auftreten); c) Jede Anforderung ist getrennt, aber nicht vermischt mit anderen Anforderungen ausdrücken. Die Redundanz selbst ist kein Fehler, aber es kann leicht zu den Fehlern führen. Die Redundanz kann gelegentlich helfen, eine SRS leserlicher zu gestallten. Bei der Aktualisierung des Dokumentes können jedoch schneller Inkonsistenzen entstehen, wenn die Änderungen nicht überall vorgenommen werden. Dabei sind Querverweise hilfreich. Ein SRS ist verfolgbar, wenn der Ursprung von jeder Anforderung klar ist, und wenn es das Referenzieren jeder Anforderung in der zukünftigen Entwicklung oder Dokumentationsoptimierung unterstützt. Die folgenden zwei Typen von Verfolgung werden empfohlen: a) Backward traceability: Festhalten der zugrundeliegenden Annahmen und Quellen von Anforderungen b) Forward traceability: Festhalten wie sich die Anforderungen im System manifestieren. Diese Art der Verfolgung des SRS ist besonders wichtig, wenn das Softwareprodukt in die Operations- und Wartungsphase eingeht. [Rob1999] (E ): Wenn der Use Case groß und/oder komplex und/oder unbekannt ist, so eignet sich ein Szenario, um die funktionellen Anforderungen zu dokumentieren. Für jedes Szenario Schritt, finden Sie die funktionalen Anforderungen, indem sie den Schritt in fassbare Statements herunterbrechen. Fragen Sie, was das Produkt tun muss, um die Arbeit dieses Schritts zu vollenden. Die folgenden Fragen sind in dieser Beziehung nützlich: What data must be received by the product? What data must be produced by the product? What data must be recorded by the product? What checks must be made by the product? What decisions must be made by the product? What calculations must be made by the product? [Kir1997] Technische Inspektion (S) [Lev2000], [Kna2007] Nur die wichtigsten Aspekte, aber ausführlich, beschreiben [Lev2000] Notation: informelle und formelle kombinieren [Mc2004] Durch Priorisieren der Qualitätsmerkmale des zu entwickelnden Produktes wird die Qualität der Anforderungen in der Spezifikation erhöht, in dem die Widersprüchlichkeit zwischen Anforderungen vermindert wird ( E)

91 Anhang C: Identifizierte Maßnahmen 85 [Dam2006] Structured Requirement Document (Strukturierte Spezifikation. Zu jeder gewünschten Funktionalität detaillierte technische Anforderung und zu jeder Anforderung Beweggründe und Testszenario(en) dokumentieren), Decomposition (Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen), Tracebility(Verfolgbarkeit der Anforderungen durch Verweise auf Gründe, Gestaltung von Dokumenten und Testszenarien in der Spezifikation) [Gan2003] Qualität der Anforderungsspezifikation durch Review prüfen und verbessern (E/S) [IEE1998] "customer and the supplier should work together to produce a well-written and completely understood SRS" (E) [VDA2007] Lege Standards für die Erstellung, Änderung und Archivierung der Dokumentation fest. (E) Lege die Anforderungen an die Dokumentation wie z. B. Titel, Datum, Kennung, Versionshistorie, Verfasser, Prüfer, Freigabebefugter, Zusammenfassung, Zweck und Verteilerliste fest. (E) Stelle sicher, dass Inhalt und Zweck nach Bedarf überprüft und genehmigt werden. (E/S) Prüfung und Genehmigung der Dokumentation vor der Ausgabe bzw. Freigabe. (E)Dokumentation, die für System oder Software- Anwender bestimmt ist, sollte das System und die Software korrekt beschreiben und ihnen die Verwendung klar und verständlich erläutern. Die Dokumentation sollte mit Hilfe des Verifikations- oder Validierungs-Prozesses überprüft werden. Pflege die Dokumentation gemäß der festgeschriebenen Dokumentationsstrategie (E) [CMM2006] "The customer requirements may be expressed in the customer s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions." ( E) Übergewichtung der Use Cases (Use Case- Modellierung wird als einzige Technik zu Identifizierung und Analysierung der Anforderungen benutzt) [Kna2007], [Fir2007] Use Cases nur für funktionale Anforderungen. [Kna2007] Allen bewusst machen, dass die NFA damit nicht abgedeckt sind. [Fir2007] Qualitätsmodelle für nicht funktionale Anforderungen. [Rob199] (E): Benutzen Sie folgende Techniken für die Identifizierung bzw. Analyse der Anforderungen: 1. Review der gegenwärtigen Situation. - Gut, um unbewusste Anforderungen aufzudecken - Hilft, neue Anforderungen hinzufügen oder Wartungsarbeiten am existierenden System durchführen - Benutze als die Basis der Geschäftsprozess-Neugestaltung 2. Apprentice with the user ( Meister macht Tätigkeit vor, Beobachter ( Lehrling ) sieht zu. Nachfragen und Erklären bei Bedarf) - Hilft, unbewusste und bewusste Anforderungen aufzudecken - Nützlich, wenn Benutzer zu beschäftigt sind, um zu sprechen 3. Die wesentlichen Anforderungen bestimmen. - Hilft, Anforderungen von Lösungen zu trennen - Eine gute Weise, den echten Zweck des Systems zu verstehen - Hilft im Aufdecken unbewusster Anforderungen und ermöglicht die Einblicke in die Auslöser der ungeahnte Anforderungen 4. Die Benutzer interviewen. - Eine gute Technik, um bewusste Anforderungen zu entdecken 5. Brainstorming. - Hilft, ungeahnte Anforderungen aufzudecken - Sehr nützlich bei der Entwicklung neuer Produkte mit unbekannten/potenziellen Benutzern 6. Use Case-Workshops. - Involviert die Benutzer in die Aufklärung vager, komplizierter und schwieriger Ereignisse - Gut, um bewusste und unbewusste Anforderungen aufzudecken 7. Dokumentenarchäologie. (Untersuche die Dokumente und Dateien, die die Organisation verwendet. Soll nicht als einzelne Technik für die Anforderungserhebung verwendet, aber als Ausgangspunkt für intensiveren Interviews an als Basis für die Aufwand-Modellierung) (E) - Verwendet, wenn Ihre Informationsquelle Dokumente ist 8. Build event models.

92 Anhang C: Identifizierte Maßnahmen 86 - Wenn die Geschäftsereignis-Grenzen vage sind, dann untersuchen sie diese anhand einer ausführlichen Systemanalyse-Modellierung 9. Anforderungsvideos machen. - Nützlich, wenn die Zeit von Benutzern beschränkt wird - Kann studiert, analysiert, und von einer Gruppe verwendet werden, nachdem das Video gemacht wird - Hilft, wenn der Zusammenhang vage ist 10. Low-Fidelity prototypes: Gut, um ungeahnte Anforderungen zu ermitteln (E) 11. High-Fidelity prototypes: Gut, um usability Anforderungen zu ermitteln (E) Schlechte Qualität der Anforderungen [Kuj2005] Frühzeitige Endbenutzer-Einbeziehung führt zur besseren Qualität der Anforderungen (E) [VDA2007] Priorisiere und Kategorisiere der ermittelten und untersuchten Softwareanforderungen (E). [Kna2007], [McC2004] Nicht-funktionale Anforderungen projektspezifisch priorisieren (E) [CMM2006] Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects (E/S) [Kna2007] Anforderungen testbar dokumentieren. (E) [Kna2007] Testfälle und Abnahmekriterien vorab definieren (E) [CMM2006] Analyze operational concepts and scenarios to refine the customer needs, constraints, and interfaces and to discover new requirements (E) [VDA2007] Bestimme die Schnittstellen zwischen den Softwareanforderungen, den Systemanforderungen und/oder anderen Komponenten der Betriebsumgebung und der Auswirkungen, die die Anforderungen haben werden. (E) [Dam2006] Decomposition: Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen (E) [Dam2006], [Dam2005]Requirements-Analyse-Sitzungen mit Beteiligung verschiedener Departments senkt die Widersprüchlichkeit der Anforderungen (E) [Rob1999], [Fir2007] Binden Sie die Testdesigner in den Review-Prozess ein. (E ) [Fir2007] Stakeholder einbeziehen, Architekten während Anf. Qualität-Verifikation miteinbeziehen (E) [Rob1999] Prüfen Sie die Relevanz der dokumentierten Anforderungen. Steht die Anforderung in Kotext von Produkt? Ist wirklich eine Anforderung und keine Lösung? (E) Prüfen Sie folgende Qualitätsaspekte (aus [Rup2007]) jeder dokumentierten Anforderung (E ): [Rob1999], [CMM2006] Vollständigkeit (beschreibt die geforderte und zu liefernden Funktionalität vollständig) [Rob1999] Korrektheit (entspricht vollständig der Vorstellung des Stakeholders, der sie formuliert hat) [Rob1999] Klassifizierbarkeit (die rechtliche Relevanz einer Anforderung ist festgelegt) [Rob1999] Konsistenz (in sich und gegenüber allen anderen Anforderungen widerspruchsfrei ). [VDA2007] Stelle sicher die Konsistenz zwischen den Systemanforderungen (einschließlich Verifikationskriterien) und den Softwareanforderungen (einschließlich Verifikationskriterien). Konsistenz wird dadurch gefördert, dass eine Traceability in beide Richtungen zwischen den Systemanforderungen (einschließlich Verifikationskriterien) und den Softwareanforderungen (einschließlich Verifikationskriterien) erzeugt und gepflegt wird. (E) [VDA2007] Stelle sicher die Konsistenz zwischen der Systemarchitektur (einschließlich Verifikationskriterien) und den Softwareanforderungen (einschließlich Verifikationskriterien). Konsistenz wird dadurch gefördert, dass eine Traceability in beide Richtungen zwischen der Systemarchitektur (einschließlich Verifikationskriterien) und den Softwareanforderungen (einschließlich Verifikationskriterien) erzeugt und gepflegt wird. (E) [Rob1999], [CMM2006], [VDA2007] Prüfbarkeit (die geforderte Funktionalität ist durch Messung nachweisbar). [Rob1999] Prüfen Sie die Anforderungsspezifikation, ob jede Anforderung mit den prüfbaren Kriterien dokumentiert ist. [Rob1999] Eindeutigkeit (die Anforderung wird von allen Beteiligten auf die gleiche Art und Weise verstanden) [Rob1999] [VDA2007] Verstehbarkeit (für alle Stakeholder verstehbar ). [Lev2000] Notation: informelle und formelle kombinieren

93 Anhang C: Identifizierte Maßnahmen 87 [Rob1999] Gültig und aktuell (beschreibt die Realität des Systems, die Beschreibung ist aktuell) [Rob1999], [CMM2006], [VDA2007] Realisierbarkeit ( bezüglich der technischen, zeitlichen und finanziellen Restriktionen umsetzbar). [CMM2006] Identify key requirements that have a strong influence on cost, schedule, functionality, risk, or performance. [Rob1999] Notwendigkeit (nur jene Leistungen und Eigenschaften, die vom Kunden tatsächlich gefordert werden) [Rob1999] Bewertet(nach Wichtigkeit oder Priorität). [VDA2007] Bewerte die Softwareanforderungen sowie der Änderungen der Systemanforderungen und/oder der Systemarchitektur hinsichtlich ihrer Kosten, Zeitplan und technischen Auswirkungen.(E) [VDA2007] Bewerte die Systemanforderungen und Änderungen an der Anforderungsbaseline des Kunden hinsichtlich ihrer Kosten, Zeitplan und technischen Auswirkungen.(E) [CMM2006] Identify technical performance measures that will be tracked during the development effort. (E) Dokumentierte Anforderungen sind nicht verfolgbar [Rob1999] Der Anforderung eine eindeutige ID geben. (E) [Rob1999], [VDA2007], [CMM2006] Die Quelle (vorzugsweise Namen von Leuten) der Anforderung registrieren. (E) [Rob1999], [Dam2006], [VDA2007] Gründe der Anforderung registrieren. Warum ist diese Anforderung für das Geschäft wichtig? (E) [Kna2007], [Dam2006], [CMM2006] Referenzieren von Anforderungen. zu Testfällen, um Anfordrungsüberdeckung durch Test zu verfolgen (E) [Fir2007] Tracking der Anf. explizit in Prozess aufnehmen, Benutzung eines Tools (E) [VDA2007] Stelle sicher die Konsistenz und Traceability in beide Richtungen zwischen den Kundenanforderungen und den Systemanforderungen. (E) [CMM2006] Bidirektionale Nachverfolgbarkeit der Anforderungen zwischen Anforderungen und Arbeitsergebnissen identifizieren und aufrechterhalten (E) [VDA2007] Erzeuge und pflege die Nachverfolgbarkeit in beide Richtungen zwischen der Systemarchitektur (einschließlich Verifikationskriterien) und den Softwareanforderungen (einschließlich Verifikationskriterien). (E) [CMM2006] Generiere die Anforderung Verfolgbarkeit-Matrix. Anforderungen sind nicht testbar dokumentiert [Kna2007] Testdesigner mit in die Anforderungserhebung mit einbeziehen (E) [Rob1999], [CMM2006], [VDA2007] (E) Schreiben Sie Testfälle für die Anforderungen oder passende Kriterien, anhand derer ist es dem Tester möglich zu beurteilen, ob das durchgeführte Produkt der Anforderung entsprochen hat. [Kna2007] Testszenarien unteranderem aus Use Cases ableiten [Rob1999], [VDA2007] (E/S) Prüfen Sie die dokumentierten Anforderungen auf die testbaren Kriterien. [Rob1999](E/S) Involvieren Sie Tester in Review-Prozess Inadäquate Anforderungsvalidierung [CMM2006] Validierung dient dazu, zu zeigen, dass ein Produkt oder eine Produktkomponente seinen/ihren geplanten Zweck erfüllt, wenn es/sie in seine/ihre Zielumgebung gebracht wird [Fir2007] Anforderung-Validierung im Zeit-, Budgetplan berücksichtigen (E) [Fir2007] Anforderung-Validierung explizit in Prozess aufnehmen (E) [IEE1998] Anforderungsvalidierungsplan können viel produktiver von einem guten SRS entwickelt werden [Dam2006] Testing According to Requirements (Prüfung entsprechend Anforderungen) (E)

94 Anhang C: Identifizierte Maßnahmen 88 [CMM2006] Anforderungen soweit angemessen unter Anwendung mehrerer Methoden validieren, um sicherzustellen, dass das entstehende Produkt sich in der Umgebung der Benutzer wie bezweckt verhält (E) [CMM2006] Discussions with the users, perhaps in the context of a formal review (E) [CMM2006] Prototype demonstrations (E) [CMM2006] Functional demonstrations (e.g., system, hardware units, software, service documentation, and user interfaces) (E) [CMM2006] Pilots of training materials (E) [CMM2006] Test of products and product components by end users and other relevant stakeholders (E) [CMM2006] Analyses of product and product components (e.g., simulations, modeling, and user analyses) (E) Inadäquate Verifikation der Anforderungen [VDA2007]: Software und System Verifikation können objektive Beweise liefern, dass die Arbeitsergebnisse einer bestimmten Phase des Softwareentwicklungs-Lebenszyklus (z. B. Anforderungen, Design, Implementierung, Tests) alle für diese Phase vorgeschriebenen Anforderungen erfüllen. [VDA2007], [Fir2007], [Dam2006], [CMM2006] Führe Peer-Reviews durch (Inspektionen; Walkthroughs) [Dam2006] Dokumentiere Testszenarien in der Spezifikation (E) [CMM2006], [VDA2007], [Rob1999] Etabliere objektive Kriterien für die Beurteilung und die Akzeptanz von Anforderungen, um adäquate Verifikation zu ermöglichen Examples of evaluation and acceptance criteria include the following:clearly and properly stated; Complete; Consistent with each other; Uniquely identified; Appropriate to implement; Verifiable (testable); Traceable.Examples of evaluation and acceptance criteria include the following:clearly and properly stated; Complete; Consistent with each other; Uniquely identified; Appropriate to implement; Verifiable (testable); Traceable (E) [Dam2006] Prüfung entsprechend Anforderungen [CMM2006] Führe Path coverage testing durch [CMM2006] Führe Load, stress, and performance testing durch [CMM2006] Führe Decision-table-based testing durch [CMM2006] Führe Functional decomposition-based testing durch [CMM2006] Führe Test-case reuse durch [CMM2006] Führe Acceptance tests durch [VDA2007]: Definition einer Strategie für die Verifikation von Softwareeinheiten und Verifizierung der integrierten Software. Die Strategie sollte festschreiben, wie die geforderte Qualität mit den verfügbaren Verfahren erreicht werden kann. (E) Zu den möglichen Verfahren zählen statische/ dynamische Analyse-, Code-Inspektionen/ Review, White/ BlackBoxTests, Codeabdeckung, etc. Entwicklung und Umsetzung einer Verifikationsstrategie einschließlich Verifikationsmaßnahmen mit den zugehörigen Methoden, Verfahren und Tools, Arbeitsprodukten oder Prozessen, die verifiziert werden, den Graden der Unabhängigkeit der Verifikation sowie einem Plan für die Durchführung dieser Aktivitäten. (E) [VDA2007]: Entwickle und Dokumentiere die Kriterien zur Verifikation, dass jede Softwareeinheit ihre Designanforderungen sowie ihre funktionalen und nicht funktionalen Anforderungen in der Verifikationsstrategie erfüllt. (E) Die Verifikationskriterien sollten Modul-Tests, Modul-Test-Daten, Code-Standards und Ziele hinsichtlich der Codeabdeckung beinhalten [VDA2007]: Führe die Verifikation der Softwareeinheiten anhand des Softwarefeindesigns nach Maßgabe der Verifikationsstrategie.(E) Protokolliere und ablege die Ergebnisse der Verifikation von Softwareeinheiten. Die Ergebnisse solle an alle relevanten Beteiligten in angemessener Form verteilt und kommuniziert. (E) [VDA2007]: Die Tests sollten aus Effizienzgründen weitestmöglich automatisiert werden. [VDA2007]: Die Verifikation des integrierten Systems kann unter Anwendung von Simulationsmethoden (z. B. Hardware in the Loop, Restbussimulation) erfolgen.

95 Anhang C: Identifizierte Maßnahmen 89 Unklare Anforderungen [McC2004] (E)Widersprüchlichkeit durch Anforderungen priorisieren mindern. [Rob1999] (E ): Bitte den Kunden die Anforderungen (auf der Skala von 1 bis 5) aus zwei Sichtpunkten zu beurteilen: "Wie glücklich werden Sie sein, wenn ich ein Lösung bereitstelle, die angemessene Kriterien der Anforderung erfühlt?" und " Wie unglücklich werden Sie sein, wenn ich keine Lösung bereitstelle?" => Verstehen wirklich Kunden-Prioritäten und Entscheidung treffen WELCHE/WANN/OB die Anforderungen zu implementieren (E) [Dam2006], [Dam2005] Requirements-Analyse-Sitzungen mit Beteiligung verschiedener Departments senkt die Widersprüchlichkeit der Anforderungen (E) [McC2004],[Dav2005], [Ras2007], [Rob1999] Benutze Low-Fidelity (pencil, paper, or whiteboard) prototypes bzw. High-Fidelity (automated) prototypes um die Anforderungen zu klären. [Ras2007] Setze die Prototypen in den face-to-face-meeting ein, um Feedback der Endbenutzer zu bekommen [Rob1999] Involviert die Stackeholder in die Aufklärung vager, komplizierter und schwieriger Ereignisse (E) [Rob1999] Wenn die Geschäftsereignis-Grenzen vage sind, dann untersuchen sie diese anhand einer ausführlichen Systemanalyse-Modellierung [Rob1999] Eine gute Weise, den echten Zweck des Systems zu verstehen, ist die wesentlichen Anforderungen zu bestimmen [Dam2005] Benutzung der Anforderungen für die Schätzung der Ressourcen führt nicht nur zu besseren Schätzung sondern auch zur besseren Verständnis der Anforderungen [CMM2006] Analysiere und validiere die Anforderungen (E/S). Betriebskonzepte und zugehörige Szenarios werden erstellt und gepflegt. Eine Definition der geforderten Funktionalität wird erstellt und gepflegt. Anforderungen werden analysiert, um sicherzustellen, dass sie notwendig und ausreichend sind. Anforderungen analysieren, um die Bedürfnisse der Betroffenen und die Rahmenbedingungen auszugleichen.anforderungen soweit angemessen unter Anwendung mehrerer Methoden validieren, um sicherzustellen, dass das entstehende Produkt sich in der Umgebung der Benutzer wie bezweckt verhält [VDA2007] Führe gemeinsames Review zur Analyse der Kundenanforderungen durch (E/S) Technische Anforderungen zu hoch [CMM2006],[VDA2007], [Rob1999] (E ) Prüfen Sie jeder dokumentierten Anforderung auf die technische Realisierbarkeit (Haben wir die technologischen Fachkenntnisse, um diese Anforderung zu erfüllen? Welche neuen Technologien sind notwendig) (E) Verlieren im Details [Kna2007] "Vision und den konkreten Überblick vorab methodisch und ggf. toolgestützt zu erarbeiten und erst darauf aufbauend die Anforderungen in verfolgbare Einheiten zu zerlegen" (E). Nicht-funktionale Anforderungen werden vernachlässigt [Rob1999] Beachten Sie folgende Typen der Anforderungen: FUNCTIONAL REQUIREMENTS: The Scope of the Work; The Scope of the Product; Functional and Data Requirements; NON-FUNCTIONAL REQUIREMENTS: Look and Feel; Usability and Humanity; Performance; Operational; Maintainability and Support; Security, Cultural and Political, Legal (E) [IEE1998]: Beachten Sie folgende Typen der Nicht-funktionalen Anforderungen: Performance requirements, Logical database requirements, Design constraints, Software system attributes [Rob1999] Vergleichen Sie jeden Ereignis/Use Case in Ihrer Spezifikation mit jedem Typ der nichtfunktionalen Anforderung. Stellen Sie diese Frage, um fehlende Anforderungen zu identifizieren: Ist dieser Typ der nicht-funktionalen Anforderung für diesen Anwendungs-Fall/Ereignis relevanten?) [Rob1999] Use the characteristics of the users to define the usability requirements for the product. (E) [Rob1999] Identifiziere Nicht-funktionalen Anforderungen [Rob1999], [Kna20007] Dokumentiere mit Abnahme- und Testkriterien( E) [Kna20007] Nicht-funktionalen Anforderungen priorisiert dokumentieren, [Kna20007] Erstelle und pflege ein Checkliste, die mögliche ] Nicht-funktionalen Anforderungen kurz skizzieren und detailliere diese mit dem Auftraggeber projektspezifisch

96 Anhang C: Identifizierte Maßnahmen 90 [Fir2007] Verwenden Qualitätsmodelle für Nicht-funktionalen Anforderungen Entwicklung falscher Funktionen und Eigenschaften [Ras2007], [Rob1999], [IEE1998] Mockups und Rapid prototyping techniques in den face-to-face- Meeting einsetzten um Feedback der Endbenutzer zu bekommen. (E/S) [Kuj2005]Frühzeitige Endbenutzer-Einbeziehung (E) [Dam2006] Decomposition (Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen), Anpassung der Spezifikation (Strukturierte Spezifikation. Zu jeder gewünschten Funktionalität detaillierte technische Anforderung und zu jeder Anforderung Beweggründe und Testszenario(en) dokumentieren) führen zu Reduzierung der Nacharbeit, die vorher durch Erfüllung von dem Kunden unerwünschten, aber von den Ingenieuren interpretierten Eigenschaften entstanden. (E) [Kna2007] Checkliste aus Erfahrung mit den 'falschen Sebstverständlichkeiten' minimiert Missverständnisse (E) [Boe1991], [Wall2004]Organisation-, Missionanalyse, Betriebskonzeptfomulierung, Prototyping, Analyse der Anwenderaufgaben/-rollen, früher Benutzerhandbücher (E) [CMM2006] Involviere alle relevanten Stakeholder in die Anforderungsentwicklung und -analyse (E/S) [CMM2006] Validiere die Anforderungen, um zu zeigen, dass ein Produkt oder eine Produktkomponente seinen/ihren geplanten Zweck erfüllt, wenn es/sie in seine/ihre Zielumgebung gebracht wird (E) [CMM2006] Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints. [CMM2006] Based on the established verification criteria, identify products that have not met their requirements or identify problems with the methods, procedures, criteria, and verification environment [VDA2007]: Verwende die Kundenanforderungen als Grundlage für die Ermittlung der geforderten Funktionen und Fähigkeiten des Systems (E ) [VDA2007]: Gemeinsames Review: Der Zweck des Prozesses bezüglich Gemeinsamer Reviews besteht darin, ein gemeinsames Verständnis mit den Stakeholdern bezüglich der Fortschritte im Vergleich zu den vereinbarten Zielsetzungen zu wahren, und abzustimmen, was getan werden sollte, um sicherzustellen, dass ein Produkt entwickelt wird, das zur Zufriedenheit der Stakeholder ist. Gemeinsame Reviews gibt es sowohl auf der Projektmanagementebene als auch auf der technischen Ebene und werden im Laufe der gesamten Projektdauer durchgeführt (E/S) [Rob1999]: Dokumentiere die Information zu Endbenutzer (je mehr Sie von den Endbenutzern wissen, desto wahrscheinlicher ist, dass das entwickelte Produkt der Arbeitsweise des Endbenutzer entspricht und seinen Vorlieben und Metaphern angepasst ist.)(e) Entwicklung falscher Benutzerschnittstelle [Ras2007], [Rob1999], [IEE1998] Mockups und Rapid prototyping techniques in den face-to-face- Meeting einsetzen um Feedback der Endbenutzer zu bekommen. (E/S) [Kuj2005]Frühzeitige Endbenutzer-Einbeziehung (E) [Dam2006] Decomposition (Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen), Anpassung der Spezifikation (Strukturierte Spezifikation. Zu jeder gewünschten Funktionalität detaillierte technische Anforderung und zu jeder Anforderung Beweggründe und Testszenario(en) dokumentieren) führen zu Reduzierung der Nacharbeit, die vorher durch Erfüllung von dem Kunden unerwünschten, aber von den Ingenieuren interpretierten Eigenschaften entstanden. (E) [Kna2007] Checkliste aus Erfahrung mit den 'falschen Sebstverständlichkeiten' minimiert Missverständnisse (E) [Boe1991], [Wall2004] Prototyping, Szenarien, Benutzerprofile, Analyse der Anwenderaufgaben (E) [CMM2006] Involviere alle relevanten Stakeholder in die Anforderungsentwicklung und -analyse (E/S) [CMM2006] Validiere die Anforderungen, um zu zeigen, dass ein Produkt oder eine Produktkomponente seinen/ihren geplanten Zweck erfüllt, wenn es/sie in seine/ihre Zielumgebung gebracht wird (E) [CMM2006] Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints. [CMM2006] Based on the established verification criteria, identify products that have not met their requirements or identify problems with the methods, procedures, criteria, and verification environment

97 Anhang C: Identifizierte Maßnahmen 91 [VDA2007]: Verwende die Kundenanforderungen als Grundlage für die Ermittlung der geforderten Funktionen und Fähigkeiten des Systems (E ) [VDA2007]: Gemeinsames Review: Der Zweck des Prozesses bezüglich Gemeinsamer Reviews besteht darin, ein gemeinsames Verständnis mit den Stakeholdern bezüglich der Fortschritte im Vergleich zu den vereinbarten Zielsetzungen zu wahren, und abzustimmen, was getan werden sollte, um sicherzustellen, dass ein Produkt entwickelt wird, das zur Zufriedenheit der Stakeholder ist. Gemeinsame Reviews gibt es sowohl auf der Projektmanagementebene als auch auf der technischen Ebene und werden im Laufe der gesamten Projektdauer durchgeführt (E/S) [Rob1999]: Dokumentiere die Information zu Endbenutzer (je mehr Sie von den Endbenutzern wissen, desto wahrscheinlicher ist, dass das entwickelte Produkt der Arbeitsweise des Endbenutzer entspricht und seinen Vorlieben und Metaphern angepasst ist.)(e) Gold Plating (unnötige, überflüssige Eigenschaften) [Rob1999] (E ): Prüfen Sie jede Anforderung nach, um zu bestimmen, ob es eine echte Anforderung ist, oder ob es "gold plating" ist. Die Schlüsselfrage ist dabei: trägt die Anforderung zum strategischen Plan für das Produkt bei? Gehen Sie zum Zweck des Projektes zurück und vergleichen Sie diese Anforderung mit dem messbaren Zweck. [Wal2004], [Boe1991] Anforderunge sauber definieren, Prototyping, Kosten-Nutzen-Analyse, Kostenbezogen planen (E) [Dam2006] Changemanagement und Feature-sizing führen zu erfolgreicher Abstimmung des Projektumfangs (E) [Kna2007] Use Cases stellen eine gute Basis zur Aufwandschätzung, grenzen den Systemumfang ab und erlecihtern Priorisierung (E) [Kuj2005] "user visits help in understanding underlying needs and identifying the most essential issues" (E) Ständige Änderung der Anforderungen [Jon2007], [IEE1998], [Rob1999]"Prototypes are also helpful in reducing the rates of downstream requirements changes." (E) [Tar2008],[Dam2005]Die Involvierung der Stakeholdern in der Anforderungsanalyse -Phase senkt die Anzahl der Änderungen in späteren Phasen (E) [Ver2005],[McC2004], [IEE1998] Minimierung der Projektdauer (E) [Fir2007], [CMM2006], [Ver2005], [Dam2005], [Wal2004] Änderungsmanagement-Prozess und formale Änderungskontrollprozeduren definieren (E) [Wal2004]Formale Auswirkungsanalyse. [CMM2006] To effectively analyze the impact of the changes, it is necessary that the source of each requirement is known and the rationale for any change is documented [Wal2004] Inkrementelle Auslieferung (E) [Jon1996] CHANGE-CONTROL BOARDS: A change-control board is a group of managers, client representatives, and technical personnel who decide which change to accept and which to reject. Can reduce the volume of changes made during the initial development of large systems by about 25 percent.(e) [Jon2007] "To deal with changes-iterative development " Unzureichendes Anforderungsmanagement (Behandlung von Änderungswünschen, Verwalten unterschiedlicher Versionen von Anforderungen, Propagieren der Änderung) CMM2006] Anforderungsmanagement dient dazu, die Anforderungen an die im Projekt erstellten Produkte und Produktkomponenten zu managen und Inkonsistenzen zwischen diesen Anforderungen und den Projektplänen sowie den Arbeitsergebnissen zu identifizieren [IEE1998] A formal change process should be initiated to identify, control, track, and report projected changes. Approved changes in requirements should be incorporated in the SRS in such a way as to 1) Provide an accurate and complete audit trail of changes; 2) Permit the review of current and superseded portions of the SRS. (E)

98 Anhang C: Identifizierte Maßnahmen 92 [CMM2006] Manage die Anforderungen und identifiziere die Widersprüche zu Projektplänen und Arbeitsergebnissen (E) [CMM2006] Manage die Anforderungsänderungen entsprechend ihrer Entwicklung im Projekt (E) [CMM2006] Erhalte aufrecht die Bidirektionale Nachverfolgbarkeit der Anforderungen und den Projektplänen sowie Arbeitsergebnissen.(E) [CMM2006] Identifiziere Inkonsistenzen zwischen den Projektplänen und Arbeitsergebnissen und den Anforderungen) (E) [CMM2006] Peer reviews involve a methodical examination of work products by the producers peers to identify defects and other changes that are needed. (E) [Dam2006] Durch strukturiertes Dokumentieren der Anforderungen wird das Change-Management erleichtert. (E) [VDA2007] Manage alle Änderungen der Kundenanforderungen gegenüber der Kundenanforderungsbaseline, um zu gewährleisten, dass Verbesserungen, die auf sich ändernde Technologie oder Kundenbedürfnisse zurückzuführen sind, festgestellt werden, und dass die von den Änderungen betroffenen Personen in der Lage sind, die Auswirkungen und Risiken zu bewerten und geeignete Änderungskontrollmaßnahmen, sowie Beherrschungsmaßnahmen einzuleiten. (E). Anforderungen können verschiedene Ursachen haben, z. B. Technologiewandel, sich ändernde Kundenbedürfnisse oder rechtliche Beschränkungen. [VDA2007] Führe eine einheitliche, definierte Vorgehensweise zum Änderungsmanagement ein und setze diese um. Mit dem Änderungsmanagement soll gewährleistet sein, dass Änderungen konsistent und nachvollziehbar erkannt, beschrieben, protokolliert, untersucht und verwaltet sind. Schnittstellen zu allen betroffenen Parteien sollen definiert und gepflegt werden. (E) Ineffektive Änderungskontrolle der Anforderungen (-> requirements creep) [IEE1998] A formal change process should be initiated to identify, control, track, and report projected changes. Approved changes in requirements should be incorporated in the SRS in such a way as to 1) Provide an accurate and complete audit trail of changes; 2) Permit the review of current and superseded portions of the SRS. (E) [CMM2006] Erhalte aufrecht die Bidirektionale Nachverfolgbarkeit der Anforderungen und den Projektplänen sowie Arbeitsergebnissen.(E) [CMM2006] Identifiziere Inkonsistenzen zwischen den Projektplänen und Arbeitsergebnissen und den Anforderungen) (E) [CMM2006] Peer reviews involve a methodical examination of work products by the producers peers to identify defects and other changes that are needed. (E) [Dam2006] Durch strukturiertes Dokumentieren der Anforderungen wird das Changemanagement erleichtert. (E) [VDA2007] Manage alle Änderungen der Kundenanforderungen gegenüber der Kundenanforderungsbaseline, um zu gewährleisten, dass Verbesserungen, die auf sich ändernde Technologie oder Kundenbedürfnisse zurückzuführen sind, festgestellt werden, und dass die von den Änderungen betroffenen Personen in der Lage sind, die Auswirkungen und Risiken zu bewerten und geeignete Änderungskontrollmaßnahmen, sowie Beherrschungsmaßnahmen einzuleiten. (E) Anforderungen können verschiedene Ursachen haben, z. B. Technologiewandel, sich ändernde Kundenbedürfnisse oder rechtliche Beschränkungen. [VDA2007] Führe eine einheitliche, definierte Vorgehensweise zum Änderungsmanagement ein und setze diese um. Mit dem Änderungsmanagement soll gewährleistet sein, dass Änderungen konsistent und nachvollziehbar erkannt, beschrieben, protokolliert, untersucht und verwaltet sind. Schnittstellen zu allen betroffenen Parteien sollen definiert und gepflegt werden. (E) [CMM2006] Etabliere und pflege die Beziehungen zwischen Anforderungen. Es kann bei der Auswertung des Einflusses von Änderungen helfen. (E) [CMM2006] To effectively analyze the impact of the changes, it is necessary that the source of each requirement is known and the rationale for any change is documented [Jon2007], [Fir2007], [Wie1993] Änderungen nur über offiziellen Prozess (E) Folgende Techniken können requirements creep reduzieren: [Jon1996] JOINT APPLICATION DESIGN: JAD is a method for developing requirements in which user representatives and development representatives work together with a facilitator to produce a point requirements specification. JAD can cut creeping requirements by almost half. (E)

99 Anhang C: Identifizierte Maßnahmen 93 [Jon2007], [Rob1999], [Jon1996] PROTOTYPES: building early prototypes can help move some changes to the front of the development cycle. Prototypes can reduce requirements creep and can be combined with other approaches such as JAD. By themselves, prototypes can reduce requirements creep by somewhere between 10 and 25 percent. (E) [Jon2007], [Jon1996] RAPID APPLICATION DEVELOPMENT:RAD schedules are somewhat shorter than conventional development. Finishing projects sooner obviously reduces the window of opportunity for changing requirements, so any way to shorten the schedule will also reduce requirements creep. Reduce requirements changes by about -10 percent (E) [Jon2007], [Jon1996] REQUIREMENTS INSPECTIONS. The classic formal inspection process can be applied to requirements as well as specifications and code.inspections significantly reduce the rate of requirements creep because they find errors and inconsistencies. Inspections can reduce requirements creep by about 30 percent.(e) [Jon1996] COST-PER-FUNCTION-POINT CONTRACTS (E) [Jon1996] QUALITY FUNCTION DEPLOYMENT: QFD is a way to analyze requirements in terms of user quality needs. QFD resembles JAD, but focuses on quality requirements rather than general features. (E) [Jon2007],[Jon1996] CHANGE- AND CONFIGURATION-IMANAGEMENT SYSTEMS: These tools do not reduce the rate of change, but they greatly facilitate the speed with which changes can be processed. Hence they reduce the overall costs of change management. These tools can also facilitate requirements traceability and help show the effect of change across multiple deliverables. Automating change control can reduce the effort of manually tracking changes by more than 70 percent. (E) [Tar2008] Benutzung eines klare Template in jeder Besprechung zwischen dem Team und Endbenutzer sowie Projektleiter und dem Team hilft dem Projektleiter die Änderungen zu erkennen (E) [Jon2007] Formal review of all change requests (E) [Jon2007] Revised cost and schedule estimates for all changes (E) [Jon2007] Prioritization of change requests in terms of business impact (E) Mangelhaftes Stakeholder Management (Analyse: Identifikation aller Stakeholder, ihrer Interessen, Ansprüche, Einflüsse; Planung: die Unterstützung der Stakeholder gewinnen; Uberwachung und Verfolgung) [Rob1999], [CMM2006], [VDA2007] Identifiziere alle Stakeholder ( E) [Rob1999] Here is a checklist of potential stakeholders: Client: The person responsible for paying for the development Customer: The person(s) or group(s) who will pay for the product User (potential at this stage): The person(s) or group(s) who will use the product to do work Sponsor Name: The person with organizational responsibility for the project Marketing Department Developer(s): Person(s) or group(s) responsible for developing the product Domain Expert(s): Sources of subject matter knowledge Technical Expert(s): Person(s) or group(s) who have expertise in the subjects relating to the product's nonfunctional requirements (e.g., machines, legal, operational environment; see the requirements template for an exhaustive list) Tester(s): Person(s) responsible for testing the quality of the requirements [Rob1999] Für jeden Typ der Stakeholder identifiziere und dokumentiere in der Anforderungsspezifikation: Stakeholder Identification (some combination of role/job title, person name, organisation name), Knowledge needed by the project, Necessary degree of involvement for that stakeholder/knowledge combination, Degree of influence for that stakeholder/knowledge combination, Agreement on how to address conflict between stakeholders who have an interest in the same knowledge.

100 Anhang C: Identifizierte Maßnahmen 94 Unklare Ziele [Rob1999], [Eng2006], [Kna2007] Vision, Ziele, Zweck des Produktes kommunizieren und in der Anforderungsspezifikation dokumentieren (E) [Kna2007] Reviews, um im Team eine einheitliche Sicht auf Anf. zu wahren (E) [VDA2007] Reviews, um ein gemeinsames Verständnis mit den Stakeholdern bezüglich der Fortschritte im Vergleich zu den vereinbarten Zielsetzungen zu wahren, und abzustimmen, was getan werden sollte, um sicherzustellen, dass ein Produkt entwickelt wird, das zur Zufriedenheit der Stakeholder ist. (E) Inadäquate Messungen [Rob1999] Identifiziere und dokumentiere Zweck des Produktes. The rationale behind the purpose- ask how will the client measure success (E) Unrealistische Erwartungen [Ver2005] Aufwandschätzung für jede Anforderung helfen den Kunden und Endanwendern ihre Erwartungshaltung zu reduzieren und sich auch realistische Zielvorgaben hinzubewegen (E) [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen.(E) [Rob1999] Do we unrealistic expectations for this product? [Kna2007] Use Cases stellen eine gute Basis zur Aufwandschätzung Mangel an Zeit [Kuj2005] Kunden und Endbenutzer während der Anforderungserhebung einbeziehen. Basieren die Anforderungen auf die realen Kunden- und Endbenutzter-Daten, so brauchen Sie wahrscheinlich weniger Zeit und Anstrengung später (E) [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen. (E) [Rob1999] Do we have an unrealistic schedule for delivering this product? What could happen if we don't have the product on time? [Rob1999] Dokumentiere Schedule Constraints in die Anforderungsspezifikation. To identify critical times and dates that have an effect on product requirements. If the deadline is short, then the requirements must be kept to whatever can be built within the time allowed. (E) [VDA2007] Schätze die Ressourcen für den Entwicklungslebenszyklus zur Erfüllung der Anforderungen ab. (E) [Kam2007] Qualitativ gute Dokumentation folgender Aspekte in der Software Requirements Spezifikation haben positiven Einfluss auf die Zeiteinhaltung: Purpose (Delineate the purpose of the SRS; b) Specify the intended audience for the SRS); Scope (Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.); Explain what the software product(s) will, and, if necessary, will not do; Describe the application of the software being specified, including relevant benefits, objectives, and goals; Be consistent with similar statements in higher-level specifications (e.g., the system requirements specification), if they exist.): Definitions, acronyms, and abbreviations; References (Provide a complete list of all documents referenced elsewhere in the SRS. Identify each document by title, report number (if applicable), date, and publishing organization; Specify the sources from which the references can be obtained.); Overview (Describe what the rest of the SRS contains; Explain how the SRS is organized). [Dam2006] Decompostion (Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen), Traceability (Verfolgbarkeit der Anforderungen durch Verweise auf Gründe, Gestaltung von Dokumenten und Testszenarien in der Spezifikation), Group Analysis Sessions (Wöchentliches Analysegruppetreffen zu decomposition), Cross Funktional Teams (Analysegruppen. Gruppenmitglieder aus unterschiedlichen Abteilungen) und Structered Req.Document (Strukturierte Spezifikation. Zu jeder gewünschten Funktionalität detaillierte technische Anforderung und zu jeder Anforderung Beweggründe und Testszenario(en) dokumentieren) reduzieren Nacharbeit => sparen Zeit und Kosten (E) [VDA2007] Qualitätskriterien und Projektrisiken können bei der Schätzung der Projektattribute berücksichtigt werden. [Wal2004], [Boe1991] Inkrementelle Auslieferung (S) [Wal2004], [Boe1991] Wiederverwendbare Software (S)

101 Anhang C: Identifizierte Maßnahmen 95 Unrealistische Schätzung der Zeit [CMM2006] The estimates should be consistent with project requirements to determine the project s effort, cost, and schedule [Wal2004], [Boe1991] Definiere sauber die Anforderungen (E) [IEE1998] A good Software Requirements Specification provides a basis for estimating costs and schedules. [VDA2007] Bewerte die Systemanforderungen und Änderungen an der Anforderungsbaseline des Kunden hinsichtlich ihrer Kosten und Zeitplan. (E) [Rob1999] Dokumentiere Schedule Constraints in die Anforderungsspezifikation. To identify critical times and dates that have an effect on product requirements. If the deadline is short, then the requirements must be kept to whatever can be built within the time allowed. (E) [Kna2007] Use Cases stellen eine gute Basis zur Aufwandschätzung (E) [VDA2007] Schätze die Ressourcen für den Entwicklungslebenszyklus zur Erfüllung der Anforderungen ab.(e) [VDA2007] Qualitätskriterien können bei der Schätzung der Projektattribute berücksichtigt werden.(e) [Wal2004], [Boe1991] Inkrementelle Auslieferung (S) [Wal2004], [Boe1991] Wiederverwendbare Software (S) Unzureichende Qualität des Projektergebnisses [Wal2004], [Boe1991] Benchmarking, Prototyping (E) [Wal2004], [Boe1991] Modellierung, Simulation (E/S) [Sch2007] Laufzeiteffizienz kann durch Simulationen und Modelle gefördert werden. Damit lassen sich Algorithmen, Protokolle und Durchlaufzeit optimieren [Ver2005] Tests, deren Gegenstand die Zeitprofile der Anwendung einschließlich Execution Flows, Datenzugriffen, Funktionsaufrufen und Systemaufrufen sind [CMM2006] Anforderungen validieren. Anforderungen soweit angemessen unter Anwendung mehrerer Methoden validieren, um sicherzustellen, dass das entstehende Produkt sich in der Umgebung der Benutzer wie bezweckt verhält (E) Examples of techniques used for requirements validation include the following: Analysis; Simulations; Prototyping; Demonstrations (E) Inadäquate Qualitätssicherung Definiere sauber die Anforderungen. [VDA2007] Führe aller Maßnahmen laut Qualitätssicherungsplan durch, um sicherzustellen, dass die Prozesse die festgelegten Anforderungen an das Projekt erfüllen (E) [VDA2007] Zu den Produktqualitätssicherungsmaßnahmen können Reviews, Audits, Problemanalysen, Berichte und Lessons Learned zählen, mit deren Hilfe die Arbeitsprodukte für die weitere Verwendung verbessert werden. Tests nicht oder zu wenig durchgeführt [Rob1999], [CMM2006], [VDA2007] (E) Schreiben Sie Testfälle für die Anforderungen oder passende Kriterien, anhand derer ist es dem Tester möglich zu beurteilen, ob das durchgeführte Produkt der Anforderung entsprochen hat. [Kna2007] Testszenarien unteranderem aus Use Cases ableiten [Rob1999], [VDA2007] (E/S) Prüfen Sie die dokumentierten Anforderungen auf die testbaren Kriterien. [Rob1999] Determine product purpose: Fit criteria for the test(s) that you will apply to determine whether the purpose has been met (E) [CMM2006] Verification includes selection, inspection, testing, analysis, and demonstration of work products.(e). Examples of verification methods for Software Engineering include the following: Path coverage testing; Load, stress, and performance testing; Decision-table-based testing; Functional decomposition-based testing; Test-case reuse; Acceptance tests. (E)

102 Anhang C: Identifizierte Maßnahmen 96 Mangel an qualifizierten Mitarbeitern [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen. [Rob1999] Do we have the people skills we need to build this product? What new skills are needed? ( E) Anhand dieser Analyse können unteranderen folgende Projektmanagement Maßnahmen geplant werden: Planung und Durchführung von Schulungen, Zuweisung der erforderlichen Qualifikation an Einzelpersonen. Falsche Besetzung des Projektteams [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen. [Rob1999] Do we have the people skills we need to build this product? What new skills are needed? ( E) Unzureichendes Change-Management im Projekt [VDA2007] Führe eine einheitliche, definierte Vorgehensweise zum Änderungsmanagement ein und setze diese um. Mit dem Änderungsmanagement soll gewährleistet sein, dass Änderungen konsistent und nachvollziehbar erkannt, beschrieben, protokolliert, untersucht und verwaltet sind. Schnittstellen zu allen betroffenen Parteien sollen definiert und gepflegt werden. (E) [CMM2006] Anforderungsmanagement dient dazu, die Anforderungen an die im Projekt erstellten Produkte und Produktkomponenten zu managen und Inkonsistenzen zwischen diesen Anforderungen und den Projektplänen sowie den Arbeitsergebnissen zu identifizieren [IEE1998] A formal change process should be initiated to identify, control, track, and report projected changes. Approved changes in requirements should be incorporated in the SRS in such a way as to 1) Provide an accurate and complete audit trail of changes; 2) Permit the review of current and superseded portions of the SRS. (E) [CMM2006] Manage die Anforderungsänderungen entsprechend ihrer Entwicklung im Projekt (E) [CMM2006] Peer reviews involve a methodical examination of work products by the producers peers to identify defects and other changes that are needed. (E) [Dam2006] Durch strukturiertes Dokumentieren der Anforderungen wird das Changemanagement erleichtert. (E) [VDA2007] Manage alle Änderungen der Kundenanforderungen gegenüber der Kundenanforderungsbaseline, um zu gewährleisten, dass Verbesserungen, die auf sich ändernde Technologie oder Kundenbedürfnisse zurückzuführen sind, festgestellt werden, und dass die von den Änderungen betroffenen Personen in der Lage sind, die Auswirkungen und Risiken zu bewerten und geeignete Änderungskontrollmaßnahmen, sowie Beherrschungsmaßnahmen einzuleiten. (E). Anforderungen können verschiedene Ursachen haben, z. B. Technologiewandel, sich ändernde Kundenbedürfnisse oder rechtliche Beschränkungen. Zu späte Integration [VDA2007] Der Softwareintegrationstestprozess sollte mit dem Beginn des Softwareentwicklungsprozesses beginnen. Es besteht eine enge Verbindung zwischen Softwareanforderungsanalyse und Anforderungsermittlung bei der Entwicklung von Testfällen und testbaren Anforderungen. (E) [VDA2007] Entwickele gemäß den Prioritäten und der Kategorisierung der Softwareanforderungen eine Strategie für die Softwareintegration und den Integrationstest für die mit dem Softwaredesign konsistenten Softwarebausteine (E) [VDA2007] Entwickele gemäß den Prioritäten und der Kategorisierung der Softwareanforderungen eine Strategie für die Softwareintegration und den Integrationstest für die mit dem Softwaredesign konsistenten Softwarebausteine (E) Unzureichende Projektplanung [CMM2006] Planning begins with requirements that define the product and project. [Dam2005] Benutzung der Anforderungen für die Schätzung der Ressourcen führt zu bessere Schätzung [Wal2004] Anforderungen sauber definieren (E) [Rob1999] Dokumentiere Schedule Constraints in die Anforderungsspezifikation. To identify critical times and dates that have an effect on product requirements. If the deadline is short, then the requirements must be kept to whatever can be built within the time allowed. (E)

103 Anhang C: Identifizierte Maßnahmen 97 [Rob1999] Dokumentiere Budget Constraints in die Anforderungsspezifikation The requirements must not exceed the budget. This limitation may constrain the number of requirements that can be included in the product. (E) [VDA2007], [CMM2006] Management der Änderungen der Kundenanforderungen. (E). [CMM2006] Anforderungsmanagement dient dazu, die Anforderungen an die im Projekt erstellten Produkte und Produktkomponenten zu managen und Inkonsistenzen zwischen diesen Anforderungen und den Projektplänen sowie den Arbeitsergebnissen zu identifizieren. [Kna2007] Use Cases stellen eine gute Basis zur Aufwandschätzung, grenzen den Systemumfang ab und erleichtern Priorisierung (E) [Boe1991], [Wal2004] Inkrementelle Entwicklung (S) [Boe1991], [Wal2004] Wiederverwendung von Software (S) Falsche Wahl von Projektressourcen Definiere sauber die Anforderungen (E) und [CMM2006]führe die Festlegung der Projektbeteiligten auf die Anforderungen herbei. Zu ehrgeizige Projektziele [Dam2006], [Dam2005] Benutzung der Anforderungen für die Schätzung der Ressourcen führt zu bessere Schätzung sowie besseren Verständnis der Anforderungen und Projektscope. Dadurch werden die zu ehrgeizigen Projektziele reduziert (E) [Kna2007] Use Cases stellen eine gute Basis zur Aufwandschätzung, grenzen den Systemumfang ab und erleichtern Priorisierung [Rob1999] Dokumentiere Schedule Constraints in die Anforderungsspezifikation. To identify critical times and dates that have an effect on product requirements. If the deadline is short, then the requirements must be kept to whatever can be built within the time allowed. (E) [Rob1999] Dokumentiere Budget Constraints in die Anforderungsspezifikation The requirements must not exceed the budget. This limitation may constrain the number of requirements that can be included in the product. (E) Mangel an Budget [CMM2006] The estimates should be consistent with project requirements to determine the project s effort, cost, and schedule [Kuj2005] "users and customers may provide essential information that improves the quality of requirements and makes the requirements definition more cost-effective" (E) [Wal2004], [Boe1991] Definiere sauber die Anforderungen (E) [IEE1998] A good Software Requirements Specification provides a basis for estimating costs and schedules. [Kam2007] Identifiziere und dokumentiere die Anforderungen, die Implementierung verzögern können in der Software Requirements Spezifikation. Dadurch wird die Kostenüberschreitung verhindert. (E) [VDA2007] Bewerte die Systemanforderungen und Änderungen an der Anforderungsbaseline des Kunden hinsichtlich ihrer Kosten und Zeitplan. (E) [Wal2004], [Boe1991] Inkrementelle Auslieferung (S) [Wal2004], [Boe1991] Wiederverwendbare Software (S) [VDA2007] Schätze die Ressourcen für den Entwicklungslebenszyklus zur Erfüllung der Anforderungen ab. (E) [VDA2007] Qualitätskriterien und Projektrisiken können bei der Schätzung der Projektattribute berücksichtigt werden.

104 Anhang C: Identifizierte Maßnahmen 98 [Dam2006] Decompostion (Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen), Traceability (Verfolgbarkeit der Anforderungen durch Verweise auf Gründe, Gestaltung von Dokumenten und Testszenarien in der Spezifikation), Group Analysis Sessions (Wöchentliches Analysegruppetreffen zu decomposition), Cross Funktional Teams (Analysegruppen. Gruppenmitglieder aus unterschiedlichen Abteilungen) und Structered Req.Document (Strukturierte Spezifikation. Zu jeder gewünschten Funktionalität detaillierte technische Anforderung und zu jeder Anforderung Beweggründe und Testszenario(en) dokumentieren) reduzieren Nacharbeit => sparen Zeit (E) [CMM2006] Analysiere Anforderungen, um Ausgewogenheit zu erreichen (E) Results of the analyses can be used to reduce the cost of the product and the risk in developing the product. Unrealistische Schätzung der Kosten [Kuj2005] "users and customers may provide essential information that improves the quality of requirements and makes the requirements definition more cost-effective" [Dam2005] Benutzung der Anforderungen für die Schätzung der Ressourcen führt zu bessere Schätzung [CMM2006] The estimates should be consistent with project requirements to determine the project s effort, cost, and schedule [Wal2004], [Boe1991] Definiere sauber die Anforderungen (E) [IEE1998] A good Software Requirements Specification provides a basis for estimating costs and schedules. [VDA2007] Bewerte die Systemanforderungen und Änderungen an der Anforderungsbaseline des Kunden hinsichtlich ihrer Kosten und Zeitplan. (E) [Rob1999] ( E) Machen Sie Ihre erste Schätzung des erforderlichen Aufwandes, um das Produkt zu bauen. Es kann auf einfacher Metrik basieren, wie die Anzahl von Ereignissen, dass das System bereitstellen muss oder die Anzahl von Use Cases.. Schätzen Sie den durchschnittlichen Aufwand, um ein Ereignis durchzuführen, und dann verwenden Sie diese Anzahl, um den Aufwand aller Ereignisse innerhalb zu schätzen. [Rob1999] Dokumentiere Budget Constraints in die Anforderungsspezifikation The requirements must not exceed the budget. This limitation may constrain the number of requirements that can be included in the product. (E) [Kna2007] Use Cases stellen eine gute Basis zur Aufwandschätzung (E) [VDA2007] Schätze die Ressourcen für den Entwicklungslebenszyklus zur Erfüllung der Anforderungen ab.(e) [VDA2007] Qualitätskriterien können bei der Schätzung der Projektattribute berücksichtigt werden.(e) [Dam2006] Decompostion (Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen), Traceability (Verfolgbarkeit der Anforderungen durch Verweise auf Gründe, Gestaltung von Dokumenten und Testszenarien in der Spezifikation), Group Analysis Sessions (Wöchentliches Analysegruppetreffen zu decomposition), Cross Funktional Teams (Analysegruppen. Gruppenmitglieder aus unterschiedlichen Abteilungen) und Structered Req.Document (Strukturierte Spezifikation. Zu jeder gewünschten Funktionalität detaillierte technische Anforderung und zu jeder Anforderung Beweggründe und Testszenario(en) dokumentieren) reduzieren Nacharbeit => sparen Kosten [Wal2004], [Boe1991] Inkrementelle Auslieferung (S) [Wal2004], [Boe1991] Wiederverwendbare Software (S) Fehlende Motivation des Projektteams [Wal2004] "Eine adäquate Risikoanalyse verringert die Frustration, die durch vermeidbare Probleme verursacht wird" [Rob1999] Dokumentiere Risiken in der Software Requirements Spezifikation. This section of your specification should contain a list of the most likely risks and the most serious risks for your project. For each risk, include the probability of that risk becoming a problem. (E) Schlechte Kommunikation [IEE1998] Prototyping: a) The customer may be more likely to view the prototype and react to it than to read the Software Requirements Specification and react to it. Thus, the prototype provides quick feedback.

105 Anhang C: Identifizierte Maßnahmen 99 [VDA2007] Führe Kommunikationsmechanismen ein für die Weitergabe der Systemanforderungen und Anforderungsaktualisierungen an alle Beteiligten. ( E/S) [VDA2007] Führe Kommunikationsmechanismen ein für die Weitergabe der Softwareanforderungen und Anforderungsaktualisierungen an alle Beteiligten. (E/S) [VDA2007] Protokolliere und ablege die Ergebnisse der Verifikation der Softwareeinheiten. Die Ergebnisse sollen an alle relevanten Beteiligten in angemessener Form verteilt und kommuniziert. (E/S) Dokumentiere Schnittstellen und angrenzende Systeme in der Anforderungsspezifikation. [Lev2000] Die Definition der Eigenschaften wie System-Grenze, Inputs und Outputs, Komponente, Struktur, Verhalten der Bestandteile und ihrer Wirkung auf System-Zustand, fördern Kommunikation. (E) [Dam2006], [Dam2005] Cross Functional Teams (Analysegruppen. Gruppenmitglieder aus unterschiedlichen Abteilungen), Group Analysis Sessions (Wöchentliches Analysegruppetreffen zu Zerlegung der Features (gewünschte Eigenschaften) in detaillierte Anforderungen) qualitativ gute Requirements Spezifikation erhöht die Qualität der Kommunikation. [Dam2005] Die Redundanz der Kommunikation auf Grund der Klärung widersprüchlichen Anforderungen wird minimiert. (E) [Ras2007] Graphische Elemente mit textuellen kombinieren verbessert die Kommunikation der Analytiker und Entwickler mit den Endbenutzern (E) Unzureichende Software-Entwicklungsmethoden [Rob1999] Analysiere die Anforderungen rückblickend. Um aus Erfahrung zu lernen, führe Review mit Einzelnen (Entwickler, Stakeholder, Manager) und in der Gruppe durch. (E ) "Here are some sample questions: If you had to do it again, what would you do differently? What would you do the same way? What was your best experience? What was your worst experience? Which tools were most helpful? Which tools impeded progress? How do you rate the traceability of your requirements? Would you work with the same team again? Why? What single change would result in most improvement to product quality? How do you rate management support? What did you learn by doing this project?" Ineffektiver Entwicklungsprozess [Rob1999] Analysiere die Anforderungen rückblickend. Um aus Erfahrung zu lernen, führe Review mit Einzelnen (Entwickler, Stakeholder, Manager) und in der Gruppe durch. (E) " Here are some sample questions: If you had to do it again, what would you do differently? What would you do the same way? What was your best experience? What was your worst experience? Which tools were most helpful? Which tools impeded progress? How do you rate the traceability of your requirements? Would you work with the same team again? Why? What single change would result in most improvement to product quality? How do you rate management support? What did you learn by doing this project?" [Fir2007] Tracking der Anforderungen. explizit in Prozess aufnehmen.(e) [Fir2007] Validierung der Anforderungen explizit in Prozess aufnehmen (E) [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen. [Rob1999] Do we have the correct management structure for this project? (E) Fehlende Projektmanagement-Methodik (z.b. kein Risikomanagement) [Wal2004] Erster Schritt im Rahmen eines Risikomanagementprozesses ist die Erfassung der Risiken [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen. [Rob1999] "The completeness of the requirements specification is a powerful indicator of likely risks (E)

106 Anhang C: Identifizierte Maßnahmen 100 Überschätzung der eigenen IT- Fähigkeiten [Boe1991], [Wal2004] Technische Analyse (E) [Boe1991], [Wal2004] Kosten-Nutzen-Analyse (E) [Boe1991], [Wal2004] Prototyping (E/S) [Wal2004] Stichproben (E) Äußere Einflüsse [CMM2006], [Rob1999] Analysiere und dokumentiere Risiken bei der Entwicklung der Anforderungen.(E) [Rob1999] What external influences are there on the project? For example, are there proposed changes to laws affecting this product? Will the company be reorganized before the product is delivered? Technologienwandel (Technologiewechselt während Projektlaufzeit stattgefunden, z.b. weil die vorgesehene Technologie sich nicht etabliert hat.) [VDA2007] Manage die Änderungen der Kundenanforderungen. Ermittle die Änderungen, die aufgrund des technologischen Wandels und der sich ändernden Kundenbedürfnisse entstehen. Schätze die damit verbundenen Risiken ab. Stelle sicher, dass die von den Änderungen betroffenen Personen in der Lage sind, die Auswirkungen und Risiken zu bewerten und geeignete Änderungskontrollmaßnahmen, sowie Beherrschungsmaßnahmen einzuleiten (S) [VDA2007] Gemeinsame Reviews sollten zur Verifikation verschiedener Aspekte (z. B. der Einführung neuer Technologien; der Technologieänderungen) durchgeführt werden. (E/S) Dokumentiere die Anforderungen in der Anforderungsspezifikation und keine Lösung. (E) [Ver2005] Voraussagen sie niemals einer bestimmten Technologie die goldene Zukunft gegenüber Ihrem Kunden Technologie Analphabetismus (die Unfähigkeit, die Technologie im Alltag so zu gebrauchen, wie es als selbstverständlich angesehen wird) [Rob1999] Review Requirement Viability (E) (Haben wir die technologischen Fachkenntnisse, diese Voraussetzung zu befriedigen?) Anwendung neuer Technologien [CMM2006], [VDA2007], [Rob1999] (E ) Prüfen Sie jeder dokumentierten Anforderung auf die technische Realisierbarkeit (Haben wir die technologischen Fachkenntnisse, um diese Anforderung zu erfüllen? Welche neuen Technologien sind notwendig) ( E) [VDA2007] Gemeinsame Reviews sollten zur Verifikation verschiedener Aspekte (z. B. der Einführung neuer Technologien; der Technologieänderungen) durchgeführt werden. (E/S) Die Qualifikation der Mitarbeiter und die für die Entwicklung des Projekts eingesetzten Technologien müssen bewertet werden und gegebenenfalls müssen Schulungen, ToolUpgrades, die Einführung neuer Technologien, etc. geplant werden. (E/S)

107 Anhang D: Fragebogen und Auswertung 101 Anhang D: Fragebogen und Auswertung

108 Anhang D: Fragebogen und Auswertung 102

109 Anhang D: Fragebogen und Auswertung 103

110 Anhang D: Fragebogen und Auswertung 104

111 Anhang D: Fragebogen und Auswertung 105