Requirements Engineering in der Suva Janine Franken

Requirements  Engineering in der Suva Janine Franken  

Inhaltsverzeichnis

Inhaltsverzeichnis   III

Abk  ürzungsverzeichnis  V

Abbildungsverzeichnis   VI

Tabellenverzeichnis   VII

1  Management Summary  VIII

2  Einleitung  1

2.1  Die Suva  2

2.2  Business Analyse  3

2.3  Ablauf der Arbeit  3

2.4  Abgrenzung der Arbeit  4

2.5  Fragestellung  4

3  Theorie  5

3.1  Begriffsdefinitionen  5

3.2  Vorgehen im Requirements Engineering in der Literatur  7

3.2.1  Anforderungen ermitteln  8

3.2.1.1  Ziele und Stakeholders  8

3.2.1.2  Systemkontext, System- und Kontextgrenzen  11

3.2.1.3  Anforderungsermittlung  13

3.2.2  Anforderungen formulieren  17

3.2.2.1  Schablonen  17

3.2.2.2  Dokumentation von Anforderungen  18

3.2.2.3  Nicht-funktionale Anforderungen  23

3.2.3  Anforderungen validieren  24

3.2.3.1  Prüftechniken für Anforderungen  25

3.2.3.2  Qualitätsmessungen.  28

3.2.4  Anforderungen verwalten  29

3.2.4.1  Requirements Management  29

3.2.4.2  Versionen und Zustände  30

3.2.4.3  Strukturen und Mengen  32

3.2.4.4  Change- und Release-Management  34

3.2.4.5  Wiederverwendung  36

3.3  Vorgehensmodelle in der Softwareentwicklung und ihr Beitrag zu  

Requirements  Engineering  36

3.3.1  Übersicht über Vorgehensmodelle  36

3.3.1.1  Die sequenziellen Vorgehensmodelle  37

3.3.1.2  Die prototypischen Vorgehensmodelle  37

3.3.1.3  Die wiederholenden Vorgehensmodelle  38

3.3.1.4  Die wiederverwendungsorientierten Modelle  39

3.3.2  Familie der Vorgehensmodelle und ihre Vertreter  40

4  Methode  42

4.1  Quantitative oder Qualitative Verfahren  42

4.2  Qualitative Datenermittlung  42

Seite III

Requirements  Engineering in der Suva Janine Franken  

4.3  Problemstellung und Hypothese  44

4.4  Erstellung des Leitfadeninterviews  44

4.4.1  Auswahl der Kandidaten  44

4.4.2  Grober Ablauf des Interviews  45

4.4.3  Einstiegsfrage  45

4.4.4  Anforderungen ermitteln  45

4.4.5  Anforderungen formulieren  46

4.4.6  Anforderungen validieren  46

4.4.7  Anforderungen verwalten  46

4.4.8  Persönliche Ergänzungen  46

4.4.9  Aufbereitung und Auswertung der Interviews.  47

5  Ergebnisse.  48

5.1  Vorgehen RE im eigenen Aufgabengebiet  48

5.2  Anforderungen ermitteln  49

5.3  Anforderungen formulieren  51

5.4  Anforderungen validieren  53

5.5  Anforderungen verwalten  54

5.6  Persönliche Ergänzungen  55

5.7  Zusammenfassung der Interviews  56

6  Empfehlungen  58

6.1  Beantwortung der Frage und Auswertung Hypothesen  58

6.2  Rolle des Requirements Engineer in der Suva verankern  59

6.3  Einheitliches Vorgehen im RE  61

6.4  Definierter Übergang vom Projekt in die Wartung  65

7  Persönliches Fazit  67

8  Literaturverzeichnis  IX

9  Anhang A: Interviews  XI

9.1  Verzeichnis der Interviewpartner  XI

9.2  Interview mit Verantwortlichem aus der Wartung (WT1)  XI

9.3  Interview mit Verantwortlichem aus der Wartung (WT2)  XVII

9.4  Interview mit Projektleiter (PR1)  XXI

9.5  Interview mit Projektleiter (PR2)  XXV

9.6  Interview mit Methodiker (MT1)  XXX

10  Anhang B: Grafiken  XXXIV

10.1  Inhaltsverzeichnis des Projektmanagement-Handbuches der Suva  XXXIV

10.2  E-Mail betreffend Requirements Engineer und Business Analyst  XXXV

10.3  Prozesslandschaft Unternehmensentwicklung  XXXVI

10.4  Volere Requirements Process  XXXVII

10.5  gfs.bern Methoden empirischer Sozialforschung  XXXVIII

10.6  Manifesto  XXXIX

Seite IV

Requirements Engineering in der Suva Janine Franken

Abkürzungsverzeichnis

Seite V

Requirements  Engineering in der Suva Janine Franken  

Abbildungsverzeichnis   

Abb.  1: Das Phasenmodell der Suva (Suva, 2009b) ohne RE  

Abb.  2: Organigramm der Suva (Suva, 2009a S. 3)  

Abb.  3: Inhalte des Requirements Engineering und Requirements Management  

  (Ebert, 2008 S. 34)  

Abb.  4: Zielmodell in Form eines Und-Oder-Baumes (Pohl/Rupp, 2009 S. 72)  

Abb.  5: The stakeholder map (Robertson/Robertson, 2008 S. 46)  

Abb.  6: System- und Kontextgrenze eines Systems (Rupp/SOPHISTen, 2009 S. 74)  

Abb.  7: Das Kano-Modell zeigt, was Kunden wirklich glücklich macht  

  (Rupp/SOPHISTen, 2009 S. 82)  

Abb.  8: Anforderungsschablone mit Bedingung (Rupp/SOPHISTen, 2009 S. 166)  

Abb.  9: Informationsmodell für das Anforderungsmanagement (Schienmann, 2002  

150)   

Abb.  10: Zusammenhang nicht-funktionale Anforderungen, funktionale  

Anforderungen  , Use-Cases (Robertson/Robertson, 2008 S. 175)  

Abb.  11: Zustandsautomat einer Anforderung (Rupp/SOPHISTen, 2009 S. 371)  

Abb.  12: Der Service Lifecycle und die damit verbundenen Publikationen (Ebel,  

S.  36)  

Abb.  13: sequenzielles Vorgehensmodell (Bunse/von Knethen, 2008 S. 5)  

Abb.  14: prototypisches Vorgehensmodell (Bunse/von Knethen, 2008 S. 8)  

Abb.  15: inkrementelles Vorgehensmodell (Bunse/von Knethen, 2008 S. 12)  

Abb.  16: Spiralmodell von Böhm (Bunse/von Knethen, 2008 S. 13)  

Abb.  17: wiederverwendungsorientiertes Vorgehensmodell (Bunse/von Knethen,  

2008  S. 16)  

Abb.  18: Vorschlag Prozess Requirements Engineering.  

Abb.  19: Statusdiagramm für Anforderungen (Suva, 2009d S. 20)  

Abb.  20: Inhaltsverzeichnis Projektmanagement-Handbuch der Suva (Suva, 2009b  

S.  1)  

Abb.  21: Email - Business Analysten und Requirements Engineers  

Abb.  22: Prozesslandschaft Unternehmensentwicklung (Suva, o.J.)  

Abb.  23: Vereinfachter Volere Prozess (Robertson/Robertson, 2008 S. 18)  

Abb.  24: gfs.bern - Methoden empirischer Sozialforschung  

Abb.  25: Manifesto for Agile Software Development (Beck u.a., 2001)  

Seite VI

Requirements  Engineering in der Suva Janine Franken  

Tabellenverzeichnis   

Tabelle 1:  Ermittlungstechniken in der Praxis (Rupp/SOPHISTen, 2009 S. 110)  15

Tabelle 2:  Die Empfehlungsmatrix der Dokumentationstechniken (Rupp/SOPHISTen,  

2009  S. 241)  19

Tabelle 3:  Eigenschaften von Prüftechniken und mögliche Einflussfaktoren  

  (Rupp/SOPHISTen, 2009 S. 308f.)  26

Tabelle 4:  Die Qualitätsmerkmale im Überblick - eigene Darstellung  

  (Rupp/SOPHISTen, 2009 S. 317)  29

Tabelle 5:  Vertreter in den Familien der Vorgehensmodelle (Bunse/von Knethen,  

2008  S. 172)  40

Tabelle 6:  Aufbereitungsverfahren nach Mayring (Mayring, 2002 S. 85ff.) - eigene  

Darstellung   47

Tabelle 7:  Auswertung Frage 1  48

Tabelle 8:  Auswertung Frage 2  49

Tabelle 9:  Auswertung Frage 3  49

Tabelle 10:  Auswertung Frage 4  50

Tabelle 11:  Auswertung Frage 5  51

Tabelle 12:  Auswertung Frage 6  52

Tabelle 13:  Auswertung Frage 7  52

Tabelle 14:  Auswertung Frage 8  53

Tabelle 15:  Auswertung Frage 9  54

Tabelle 16:  Auswertung Frage 10.  54

Tabelle 17:  Auswertung Frage 11.  55

Tabelle 18:  Auswertung Frage 12.  56

Tabelle 19:  Aufgaben Requirements Engineer (Suva, 2009d S. 21)  59

Tabelle 20:  Aufgaben Business Analyst (Suva, 2009d S. 21)  60

Tabelle 21:  Aufgaben Requirements Engineer neu definiert  60

Tabelle 22:  Prozessschritte im Requirements Engineering  63

Tabelle 23:  Lieferobjekte für die Wartung  66

Seite VII

Requirements Engineering in der Suva Janine Franken

1 Management Summary

Die Suva ist ein selbstständiges Unternehmen des öffentlichen Rechts. Sie versichert über 2 Millionen Arbeitnehmer gegen die Folgen von Berufs- und Nichtberufsunfall sowie Berufskrankheiten. Für die Ausübung dieser Aufgaben benötigt sie verschiedene Applikationen. Diese werden von der eigenen Informatikabteilung entwickelt und unterhalten. In der Wartung kommt es immer wieder vor, dass Anpassungen an den Applikationen nachgebessert werden müssen. Unter anderem aus dem Grund, dass die Anpassungen an den Anforderungen nicht das Ziel und die fachliche Anforderung aufzeigen, sondern die Lösung. Daher soll in dieser Arbeit das Vorgehen im Requirements Engineering untersucht werden.

Requirements Engineering hat sich in den letzten Jahren sehr verändert. Die Bedeutung wurde immer grösser, was auch an den Chaos Reports der Standish Group ersichtlich wird. Es gibt viel Literatur über dieses Thema, aber der Theorieteil wird aufzeigen, dass die Unterschiede nicht gross sind. 'LH JDQ]H $UEHLW VWHOOW GDV %XFK Ä5HTXLUHPHQWV- Engineeringund ±0DQDJHPHQW³YRQ&KULV5XSSXQGGHQ623+,67HQLQGHQ0LWWHOSXnkt. Dieses Buch ist in der Suva bereits bekannt und bestehende Bemühungen im Bereich Requirements Engineering basieren auf diesem Buch.

Diese Arbeit untersucht das bestehende Vorgehen im Bereich Requirements Engineering in der Suva. Dafür werden Interviews durchgeführt. Aus diesen Interviews geht hervor, dass es bis jetzt kein einheitliches Vorgehen gibt. Aus den Interviews werden Mängel bei der Übergabe eines Projektes an die Wartungsorganisation sichtbar. Die Interviews zeigen aber auch, dass zurzeit daran gearbeitet wird, ein neues Tool für das Requirements Engineering einzuführen. Aufgrund der Interviews sowie der Literatur werden folgende Empfehlungen für die Suva ausgearbeitet:

1. Die Rolle des Requirements Engineer mit seinen Aufgaben muss offiziell etabliert werden. Im Projektmanagement-Handbuch der Suva ist die Rolle nicht definiert. Das Requirements Engineering wird als projektmanagementnaher Prozess bezeichnet. Die Verantwortung für den Prozess Requirements Engineering ist bei der Informatik. Diese Verantwortung muss an die richtige Stelle übergeben werden, damit die Bedeutung des Requirements Engineering in der Suva höher bewertet wird.

2. Ein Requirements-Engineering-Konzept muss erstellt und ins Projektmanage-ment-Handbuch integriert werden. Dieses Konzept muss alle, gemäss der Theorie benötigten Themen abdecken. Dazu gehören Prozesse, Methoden, Vorgehensweisen, Techniken und ein RE-Tool.

3. Die Übergabe vom Projekt an die Wartung muss klar definiert werden. Es soll im Projektmanagement-Handbuch ersichtlich sein, welche Lieferobjekte in welchem Zustand an die Wartungsorganisation übergeben werden müssen.

Seite VIII

Requirements Engineering in der Suva Janine Franken

2 Einleitung

Gemäss dem Chaos Report 2006 der Standish Group (Standish Group, 2006, In: Pohl/Rupp, 2009) wurden 2006 über 10 % mehr Projekte erfolgreich abgeschlossen als 1994, zwölf Jahre zuvor. Dies wird gemäss Jim Johnson, Vorsitzender der Standish Group, vor allem der Tatsache gutgeschrieben, dass sich in diesen zwölf Jahren das Requirements Engineering (RE) massiv verbessert hat. Damit wird auch die Bedeutung des Requirements Engineering hervorgehoben. Gemäss Klaus Pohl (Pohl, 2008 S. 9) bestätigen andere Studien, dass für annähernd die Hälfte der Probleme in Projekten die Gründe bei den Anforderungen zu suchen sind.

Und je später ein Fehler in der Anforderung behoben wird, desto teurer ist er. Gemäss Pohl (Pohl/Rupp, 2009 S. 10) kostet eine Beseitigung eines Fehlers bei der Entwicklung das 20-fache, als wenn der Fehler bei der Requirements Engineering bereits gefunden und korrigiert worden wäre. Dies streicht nochmals die Bedeutung des Requirements Engineering hervor.

Wenn man aber das Projektmanagement-Handbuch (PMH) der Suva (Suva, 2009b) studiert, fällt besonders das Kapitel Requirements Engineering auf, da es nicht als eigener Teil im Vorgehen beschrieben ist. Requirements Engineering wird als projektmanagementnaher Prozess bezeichnet ¹ .

Abb. 1: Das Phasenmodell der Suva (Suva, 2009b) ± ohne RE

Das Phasenmodell richtet sich an das Management eines Projektes, das heisst die Planung und Koordination sowie Ressourcen- und Kostenmanagement. Ein zusätzliches Kapitel befasst sich mit dem Requirements Engineering im weiteren Sinn. Es nimmt

¹ VLHKHÄInhaltsverzeichnis des Projektmanagement-Handbuches der Suva³LP$QKDQJ%

Seite 1

Requirements Engineering in der Suva Janine Franken

aber keinen direkten Bezug auf das Phasenmodell. Die Rolle des Requirements Engineer oder auch Business Analyst ist bisher in der Suva nicht etabliert.

2.1 Die Suva

Die Suva, vormals Schweizerische Unfallversicherungsanstalt, wurde 1918 aufgrund des Bundesgesetzes über die Kranken- und Unfallversicherung gegründet. Mit der Einführung des Bundesgesetzes über die Unfallversicherung (UVG), in Kraft seit 1984, wurden alle Arbeitnehmer und Arbeitnehmerinnen obligatorisch versichert. Die Suva gilt immer noch als wichtigste Trägerin der obligatorischen Unfallversicherung. Mit ihrem in über 90 Jahren aufgebauten Know-how in der obligatorischen Unfallversicherung und in der Unfallverhütung sowie einem jahrzehntelangen Fachwissen in der Rehabilitation spielt sie eine wichtige Rolle im schweizerischen Sozialversicherungssystem. Der Hauptsitz der Suva ist in Luzern. Als selbstständiges Unternehmen des öffentlichen Rechts versichert die Suva über 110'000 Unternehmen bzw. rund 2 Millionen Berufstätige und Arbeitslose gegen die Folgen von Berufs- und Freizeitunfällen sowie Berufskrankheiten (Stand Ende 2009). Die Suva arbeitet nicht gewinnorientiert und erhält keinerlei Subventionen. Ihre Organe sind der Verwaltungsrat mit seinen Ausschüssen (vom Bundesrat gewählt und paritätisch zusammengesetzt), die Geschäftsleitung als oberstes geschäftsführendes Organ und die Agenturen.

Die Suva ist in die 4 Hauptbereiche Führung & Support (FSP), Versicherungsleistungen und Rehabilitation (Suva Care), Gesundheitsschutz (Suva Pro und Suva Liv) und Finanzen (Suva Risk) aufgeteilt. Wie im folgenden Organigramm dargestellt, werden die 18 Agenturen der Suva auf die drei Hauptbereiche aufgeteilt.

Seite 2

Requirements Engineering in der Suva Janine Franken

Abb. 2: Organigramm der Suva (Suva, 2009a S. 3)

2.2 Business Analyse

Die Autorin arbeitet als Business Analystin im Bereich Versicherungstechnik. Die Aufgaben einer Business Analystin decken sich mit denen eines Requirements Engineers. Details zu dieser Funktion werden im Theorieteil beschrieben. Dieses Aufgabengebiet existiert in der Suva noch nicht lange und ist erst im Aufbau. Bisher haben die Fachverant-wortlichen, welche für den Unterhalt der Applikationen zuständig sind, direkt mit der Informatik diskutiert und die Anforderungen spezifiziert. Fachverantwortliche sind in den verschiedensten Bereichen und Abteilungen zu finden.

2.3 Ablauf der Arbeit

In der Einleitung wurde bereits die Relevanz dieser Arbeit aufgezeigt und das Unternehmen Suva vorgestellt. Dazu gehört auch das Arbeitsgebiet der Autorin. Am Ende der Einleitung wird die Abgrenzung der Arbeit aufgezeigt und die zentrale Frage gestellt. Im Theorieteil werden die Grundlagen zu Requirements Engineering dargestellt, insbesondere in Bezug auf das Vorgehen. Die verschiedenen Theorien werden miteinander verglichen.

Im Kapitel Methodik wird beschrieben, warum für diese Arbeit als Methode Interviews gewählt wurden und wie die Fragen für die Interviews erarbeitet wurden. Die Problemstellung wird nochmals aufgegriffen und die Hypothese wird formuliert.

Seite 3

Requirements Engineering in der Suva Janine Franken

Im folgenden Kapitel Ergebnisse werden die durchgeführten Interviews innerhalb der Suva ausgewertet und die Resultate präsentiert.

Im Kapitel Empfehlungen werden aufgrund der Resultate aus dem vorherigen Kapitel und der Theorie Empfehlungen für die Suva ermittelt und konkrete Massnahmen aufgezeigt.

2.4 Abgrenzung der Arbeit

In dieser Arbeit geht es um das Vorgehen betreffend Requirements Engineering innerhalb eines bestehenden Vorgehensmodelles in der Softwareentwicklung. Eine Auswahl von verschiedenen Vorgehensmodellen in der Softwareentwicklung wird am Ende des Theorieteils aufgezeigt ² mit Bezug auf das Requirements Engineering. Diese Arbeit wird für die Suva nicht ein neues Vorgehen im Bereich Requirements Engineering erarbeiten.

2.5 Fragestellung

Was muss in der Suva geändert werden, damit die Applikationsverantwortlichen / Fach-verantwortlichen nicht mehr die technische Umsetzung, sondern die fachliche Anforderung definieren?

Diese Frage führt zu einer Zusatzfrage: Wie ist der Istzustand heute?

Das Ziel dieser Arbeit sind Empfehlungen, welche mit Hilfe der Theorie und den Resultaten aus den Interviews erarbeitet werden. Diese zeigen mögliche Ablaufschritte, welche die Suva zum Einführen eines neuen / geänderten Vorgehen im Bereich Requirements Engineering durchführen sollte. Eine grobe Skizzierung des Vorgehens aufgrund der Theorie und den Resultaten aus der Datenerhebung wird zur Verfügung gestellt.

² Siehe "Vorgehensmodelle in der Softwareentwicklung und ihr Beitrag zu Requirements Engineering" auf Seite 36

Seite 4

Requirements Engineering in der Suva Janine Franken

3 Theorie

In diesem Kapitel werden die theoretischen Grundlagen zu Requirements Engineering erarbeitet. Als Grundlage wird das Buch Ä5HTXLUHPHQWV-Engineering und ±0DQDJHPHQW³ von Chris Rupp (Rupp/SOPHISTen, 2009) genommen. Die Wahl fiel auf dieses Buch, weil in der Suva aufgrund dieses Buches die ersten Schulungsunterlagen und Dokumentationen im Bereich Requirements Engineering erstellt wurden. (Suva, 2009c) (Suva, 2009d). Dieses Buch bestimmt das Vorgehen in diesem Kapitel und die verschiedenen Theorien aus der Literatur werden miteinander verglichen. Da bei zwei Büchern eine Verwechslung stattfinden könnte, weil der erste Autor der gleiche ist (Klaus Pohl), wird das eine Buch jeweils im Text als CPRE ³ (Pohl/Rupp, 2009) bezeichnet und das andere als Pohl (Pohl, 2008).

3.1 Begriffsdefinitionen

Um den Lesefluss zu vereinfachen, werden vorgängig einige Begriffe erklärt.

Requirements Î Anforderung

Gemäss den SOPHISTen (Rupp/SOPHISTen, 2009 S. 14) ist eine Anforderung eine Aussage über eine Eigenschaft oder eine Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen. Gemäss IEEE (IEEE Standards Board, 1991) gibt es aber eine etwas längere Beschreibung: «Eine Anforderung ist:

1. Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. 2. Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.

3. Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäss (1) oder (2).»

Dabei gibt es auch eine Unterscheidung von funktionalen und nicht-funktionalen Anforderungen. Funktionale Anforderungen sind die Funktionen, die das System bereitstellen muss. Nicht-funktionale Anforderungen sind Anforderungen an die Technik, an die Qualität, an die Benutzeroberfläche, etc. (Rupp/SOPHISTen, 2009 S. 17f.)

Requirements Engineering Î Prozess zur Ermittlung der Anforderung Gemäss CPRE (Pohl/Rupp, 2009 S. 12) kann Requirements Engineering folgendermassen definiert werden:

«Das Requirements Engineering ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist zu gewährleisten, dass:

³ CPRE: Certified Professional for Requirements Engineering

Seite 5

Requirements Engineering in der Suva Janine Franken

1. alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind,

2. die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen,

3. alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind.»

Requirements Engineer Î Anforderungsspezialist

Für Rupp (Rupp/SOPHISTen, 2009 S. 11) ist dies der Vermittler zwischen zwei Welten. Er wird auch als Systemanalytiker, als Anforderungsanalytiker oder als Business Analyst bezeichnet. Er muss die Welt der Anforderungen, also die fachliche Welt verstehen. Ebenso muss er sich in der Welt der Informatik bewegen können. Für CPRE (Pohl/Rupp, 2009 S. 14) steht der Requirements Engineer während dem Projekt im Mittelpunkt des Geschehens. Er muss sich in das Fachgebiet einarbeiten und dies fachfremden Architekten und Entwicklern erklären, damit sie es umsetzen. Er ist also ein Art Dolmetscher. Im CPRE (Pohl/Rupp, 2009 S. 15f.) werden sieben Fähigkeiten angegeben, welche ein Requirements Engineer benötigt: analytisches Denken, Empathie, Kommunikationsfähigkeit, Konfliktlösungsfähigkeit, Moderationsfähigkeit, Selbstbewusstsein und Überzeugungsfähigkeit. Warum der Requirements Engineer diese Fähigkeiten haben muss, wird im Theorieteil geklärt.

Requirements Management Î Anforderungsmanagement

«Das Requirements-Management gibt dem Analytiker Techniken und Richtlinien an die Hand, mit denen Anforderungen und die dazugehörigen Informationen verwaltet werden können. Durch Requirements-Management wird ein definiertes Verfahren etabliert, mit dessen Hilfe die oftmals unüberschaubare Anzahl an Anforderungen bzw. Anforderungsdokumenten komplexer Projekte beherrschbar wird.» (Rupp/SOPHISTen, 2009 S. 20)

Seite 6

Requirements Engineering in der Suva Janine Franken

3.2 Vorgehen im Requirements Engineering in der Literatur

Das Anforderungsmanagement umfasst gemäss Rupp (Rupp/SOPHISTen, 2009 S. 1f.) folgende Schritte: 1. Anforderungen ermitteln

Anforderungen müssen in harter Arbeit aus einer Vielzahl von Quellen zusammengetragen werden. 2. Anforderungen formulieren

Sind alle Anforderungen erst einmal bekannt, müssen sie schriftlich niedergelegt werden. 3. Anforderungen validieren

Qualitätssicherung ± für manche Leid, für manche Freud. Auch Anforderungen sind keine Ausnahme und müssen einer Prüfung unterzogen werden. 4. Anforderungen verwalten

Anforderungen sind nicht in Stein gehauen, sondern ändern sich mit der Zeit und müssen verwaltet werden.

6FKDXW PDQ VLFK GDV 9RUJHKHQ EHL GHU QHX JHVFKDIIHQHQ =HUWLIL]LHUXQJ ]XP ÄCertified Professional for Requirements Engineering &35(³(Pohl/Rupp, 2009) an, gibt es einige wenige Abweichungen. Es gibt auch hier die Kapitel Anforderungen ermitteln, dokumentieren, prüfen und abstimmen sowie verwalten. Hinzu kommt, dass die Definition des Systemkontextes bei Chris Rupp als Bestandteil von Anforderungen ermitteln gilt, hingegen beim CPRE ist dies ein eigener Schritt.

Im grossen Nachschlagewerk von Klaus Pohl (Pohl, 2008 S. 44ff.) sind diese Schritte schwerer zu erkennen. Er konzentriert sich, wie beim CPRE zuerst auf den Systemkontext. Er bezeichnet aber seine Kernaktivitäten zum Requirements Engineering als Dokumentation, Gewinnung und Übereinstimmung. Dazu kommen die beiden Querschnittsaktivitäten Validierung und Management.

Bei Bruno Schienmann (Schienmann, 2002 S. 33) ist das Anforderungsmanagement (AM) in verschiedene Hauptaufgaben aufgeteilt, welche wieder dem Vorgehen von Chris Rupp ähnlich sind. Die Hauptaufgaben bei Schienmann sind: Anforderungsermittlung, Anforderungsanalyse, Anforderungsverständigung, Anforderungsdokumentation und Anforderungsqualitätssicherung. Er unterscheidet zwischen Kunden-AM, Produkt-AM und Projekt-AM. Das Kunden-AM stellt die Kundenbedürfnisse sicher. Das Produkt-AM sorgt für Nachhaltigkeit und Profitabilität. Und das Projekt-AM überprüft die Produktan-forderungen mit den gesetzten Rahmenbedingungen. Diese Unterteilung ist sonst nicht gebräuchlich.

Ein weiterer Autor ist Christof Ebert (Ebert, 2008 S. 34), welcher ähnliche Schritte aufzeigt, wie wir sie schon bei den anderen deutschsprachigen Autoren gesehen haben. Er hat dafür eine interessante Darstellung gewählt:

Seite 7

Requirements Engineering in der Suva Janine Franken

Abb. 3: Inhalte des Requirements Engineering und Requirements Management (Ebert, 2008

S. 34)

Einen anderen Weg haben die Engländer Robertson und Robertson gewählt (Robertson/Robertson, 2008) 6LH KDEHQ GHQ Ä9ROHUH 5HTXLUHPHQWV 3URFHVV 0RGHO³ LQ ihrem Buch beschrieben. Eine vereinfachte Darstellung des Prozesses ist im Anhang B zu sehen. Dieser Prozess beschreibt alle Schritte, die notwendig sind, um Requirements zu ermitteln und umzusetzen. Sie verwenden dazu sehr viele Checklisten und Vorlagen. Im ITIL® ist das Requirements Engineering eine Funktion im System Design. Gemäss Ebel (Ebel, 2008 S. 323) sind die folgenden Schritte dabei durchzuführen: Anforderungen ermitteln (funktionale Anforderungen, Management- und Betriebsanforderungen und Anforderungen an die Benutzerfreundlichkeit), Anforderungen dokumentieren, An-forderungen als Designbasis verwenden, Anforderungen als Test- / Evaluationsbasis verwenden und Anforderungen als Abnahmebasis verwenden. ITIL ist auf die Prozesse in der IT aufgebaut und wird daher nur bei den Change- und Releasemanagement Bereichen wieder zum Vergleich genommen.

In den nächsten Kapiteln werden die verschiedenen Vorgehensweisen im Detail gegenübergestellt. Aufgebaut wird dies, wie bereits einleitend erwähnt, am Vorgehen im Buch von Rupp (Rupp/SOPHISTen, 2009).

3.2.1 Anforderungen ermitteln

Bei Rupp (Rupp/SOPHISTen, 2009 S. 57) ZLUGGHU6FKULWWÄ$QIRUGHUXQJHQHUPLWWHOQ³LQ die zwei AUEHLWVVFKULWWH Ä=LHOH ,QIRUPDQWHQ XQG )HVVHOQ³ VRZLH Ä$QIRUGHUXQJVHUPLWt-OXQJ³XQWHUWHLOW,PHUVWHQ$UEHLWVVFKULWWZHrden die Ziele und die Stakeholders definiert und anschliessend wird der Systemkontext festgelegt. Im nächsten Schritt werden die Anforderungen mit Hilfe von verschiedenen Techniken ermittelt.

3.2.1.1 Ziele und Stakeholders

«Unter einem Ziel versteht man die intentionale Beschreibung eines von Stakeholdern (zum Beispiel Personen oder Organisationen) gewünschten charakteristischen Merkmals des zu entwickelnden Systems bzw. des zugehörigen Entwicklungsprojekts.» (Pohl/Rupp, 2009 S. 71). Die Bedeutung der Ziele auf das Produkt wird durch diese Definition hervorgehoben. Ziele sollen schriftlich festgehalten und quantifizierbar sein, und sie sollen in natürlich sprachlicher Form verfasst sein (Rupp/SOPHISTen, 2009 S. 61). Um die Ziele zu finden und diese korrekt zu bewerten, müssen die Stakeholder definiert

Seite 8

Requirements Engineering in der Suva Janine Franken

werden. «Ein Stakeholder eines Systems ist eine Person oder Organisation, welche (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat» (Pohl/Rupp, 2009 S. 12). Somit kann es sein, falls am Anfang nicht alle wichtigen Stakeholder an Bord sind, dies später zu unnötigen Change-Requests führen kann (Rupp/SOPHISTen, 2009 S. 65).

Wichtig ist es, nicht nur den Namen des Stakeholders zu kennen, sondern vor allem dessen Rolle im System, seine Verfügbarkeit, sein Wissen, die Relevanz und natürlich verschiedene Kontaktmöglichkeiten. Diese Informationen sind nicht statisch, sie müssen während dem Lifecycle des Produktes immer wieder überprüft und aktualisiert werden. Mit den Informationen über die Stakeholder kann eine Stakeholder-Analyse durchgeführt werden. Hierbei werden die Motivation und der Einfluss gegenübergestellt. Es geht dabei um eine Klassifizierung der Stakeholder. Diese Analyse sollte aber nicht öffentlich gemacht werden, da sich selbst vermutlich nicht jeder Stakeholder in der entsprechenden Kategorie sieht (Rupp/SOPHISTen, 2009 S. 67ff.). Nun können die Stakeholder befragt und die Ziele definiert werden. Die Ziele werden schriftlich festgehalten. Als Vorschlag von Rupp (Rupp/SOPHISTen, 2009 S. 72) wird die Zielschablone genommen. Diese beinhaltet die wichtigsten Punkte: Welches Ziel soll erreicht werden, wer profitiert von der Erreichung des Ziels, welche Arbeitsprozesse sind betroffen, welche Faktoren können eine Lösungsauswahl einschränken und sonstige Anmerkungen, die für das Verständnis des Ziels wichtig sind (Rupp/SOPHISTen, 2009 S. 71f.).

Beim CPRE (Pohl/Rupp, 2009 S. 11) werden die Stakeholder «als wichtigste Quelle für Anforderungen» bezeichnet. Die Zieldefinition wird nicht in den Vordergrund gestellt, sondern erst bei der Dokumentation der Anforderungen genauer beschrieben. Dabei wird eine Technik gezeigt, wie Ziele grafisch dargestellt werden können, die Und-Oder-Bäume.

Abb. 4: Zielmodell in Form eines Und-Oder-Baumes (Pohl/Rupp, 2009 S. 72) Bei Ebert (Ebert, 2008 S. 114) ist der erste Schritt bei der Anforderungsermittlung ebenfalls die Definition von Zielen und Visionen. Nur mit Hilfe von Visionen kann aus Anforderungen ein Produkt werden. Hingegen sind für Ebert (Ebert, 2008 S. 79ff.) die Stakeholder zu wichtig, als dass sie einfach ein Arbeitsschritt in der Anforderungsermittlung sind. Für ihn ist dies ein eigener Schritt vor der eigentlichen Anforderungsermittlung. Hierbei geht es um die Rollen und Verantwortung in einem System. Auch für ihn ist eine Analyse der Stakeholder elementar für den Verlauf und Erfolg des Projektes.

Requirements Engineering in der Suva Janine Franken

Pohl (Pohl, 2008 S. 89f.) stellt die Ziele ganz an den Anfang des Requirements Engineering. Er betont, wie wichtig ein zielorientiertes Requirements Engineering ist und dadurch folgende positive Auswirkungen auf das Requirements Engineering erkennbar sind: Besseres Systemverständnis Gewinnung von Anforderungen Identifikation und Bewertung von Lösungsalternativen Aufdecken irrelevanter Anforderungen Rechtfertigung von Anforderungen Vollständigkeit von Anforderungsspezifikationen Identifikation und Auflösung von Konflikten Stabilität von Zielen

Bei Pohl (Pohl, 2008 S. 97) gibt es zwei Arten, wie Ziele dokumentiert werden können. Entweder textuell, aber mit Hilfe von Schablonen, oder in Form eines Zielmodells. Die Stakeholder sind für Pohl eine Anforderungsquelle. Er (Pohl, 2008 S. 65) beschreibt kurz die möglichen Rollen, die ein Stakeholder innehaben kann, aber er geht nicht tiefer darauf ein.

Hingegen bei Schienmann (Schienmann, 2002 S. 305) werden die Zieldefinitionen losgelöst vom Anforderungsmanagement. Er bezieht sich mehr auf den externen Kunden, der vorgängig seine Ziele definiert haben muss und daraus auch die Geschäftsprozesse DEJHOHLWHW KDW (U EH]HLFKQHW GLHVH 3KDVH DOV Ä%XVLQHVV (QJLQHHUing³ Für ihn (Schienmann, 2002 S. 53) sind die Stakeholder wichtige Interessengruppen, die dazu beitragen, dass keine monopolistischen Entscheide gefällt werden. Er bezeichnet kurz die beteiligten Personengruppen, aber auf eine detailliertere Definition oder Analyse geht er nicht ein.

Bei Robertson und Robertson (Robertson/Robertson, 2008 S. 57) müssen die Ziele wichtige Aspekte verfolgen. Sie müssen den Zweck des Produktes und einen realistischen Businessnutzen aufzeigen. Zudem müssen sie messbar sein. Das Ziel muss erreichbar und machbar sein. Auch die Stakeholder sind ein wichtiger Bestandteil und müssen vorgängig bestimmt werden. Eine interessante Darstellung von Stakeholdern LVWGLHÄ6WDNHKROGHU0DS³6LH]HLJWGLHYHUVFKLHGHQHQ.ODVVHQYRQ6WDNHKROGHUXQGGLH verschiedenen Rollen (Robertson/Robertson, 2008 S. 45f.).

Requirements Engineering in der Suva Janine Franken

Abb. 5: The stakeholder map (Robertson/Robertson, 2008 S. 46)

Es wird ein Template zur Verfügung gestellt, mit welchem die Stakeholder systematisch erfasst werden können. Dies ist ein Schritt im Volere-3UR]HVV ZHOFKHU DOV Ä5HTXLUe- ments 6NHOHWRQ³EH]HLFKQHWZLUGDie Stakeholderwerden vor der Anforderungsermittlung bereits definiert. (Robertson/Robertson, 2008 S. 373)

3.2.1.2 Systemkontext, System- und Kontextgrenzen

«Der Systemkontext ist jener Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen des betrachteten Systems relevant ist.» (Pohl/Rupp, 2009 S. 19). Damit aber der Systemkontext definiert werden kann, muss er seine Grenzen kennen, und zwar die Grenzen zum System und die zum Kontext. «Die exakte Systemgrenze können Sie erst gegen Ende des Requirements-Engineering-Prozesses präzise festlegen.» (Rupp/SOPHISTen, 2009 S. 75). Damit ist klar, dass der Systemkontext, bzw. die Systemgrenzen während des Projektes regelmässig überprüft und angepasst werden muss. Hingegen muss die Kontextgrenze, das heisst die Grenze zu der irrelevanten Umgebung bereits zu diesem frühen Zeitpunkt definiert sein. Die Ergebnisse der Kontextabgrenzung sollen schriftlich festgehalten werden. (Rupp/SOPHISTen, 2009 S. 72ff.)

Requirements Engineering in der Suva Janine Franken

Abb. 6: System- und Kontextgrenze eines Systems (Rupp/SOPHISTen, 2009 S. 74) Beim CPRE (Pohl/Rupp, 2009 S. 19ff.) wird die Definition des Systems und seinen Grenzen als Arbeitsschritt vor die Anforderungsermittlung gestellt. Andere Unterschiede zu Rupp sind nicht ersichtlich.

Bei Ebert (Ebert, 2008 S. 126) ist das Festlegen der Systemgrenze ein Schritt innerhalb der Anforderungsermittlung. Durch die Analyse der Anforderungen, Zusammenhänge und Einschränkungen kann das System in der Umgebung ermittelt und die Systemgrenzen können definiert werden.

Bei Pohl (Pohl, 2008 S. 51) ist die Erfassung des Systemkontexts ein wichtiger Teil vor der Anforderungsermittlung. Pohl (Pohl, 2008 S. 59) weist darauf hin, dass bei einer Verschiebung der Systemgrenze zusätzlich die Auswirkungen auf die Anforderungen überprüft werden müssen. Ein anderer Schwerpunkt bei Pohl (Pohl, 2008 S. 63) ist die Kontextstrukturierung. Hierbei geht es um die Unterteilung des Kontexts in Teilbereiche sowie die Klassifikation der Kontextaspekte. Er (Pohl, 2008 S. 64) unterscheidet vier Facetten: Gegenstandsfacetten, Nutzungsfacetten, IT-Systemfacetten und Entwick- OXQJVIDFHWWHQ'LHVH ZHUGHQ PLW GHQ GUHL 7\SHQ YRQ .RQWH[WDVSHNWHQ Ä$QIRUGHUXQJs-TXHOOHQ³ Ä%HWUDFKWXQJVJHJHQVWlQGH³ XQG Ä(LJHQVFKDIWHQ XQG %H]LHKXQJHQ GHU %e- trachWXQJVJHJHQVWlQGH³ EHUHLFKHUW'LHVH 6WUXNWXULHUXQJ GHV 6\VWHPNRQWH[WV XQWHr- stütztgemäss Pohl (Pohl, 2008 S. 81) die Kategorisierung von Anforderungen. Eine Unterteilung in Teilbereiche ist aus dem System-Engineering bekannt. Dort heisst der Begriff Untersysteme oder Subsysteme. (Daenzer u.a., 1989 S. 16) (Böhm u.a., 1994 S. 10f.)

Bei Schienmann (Schienmann, 2002 S. 59) werden weder Systemgrenzen noch der Kontext definiert. Er unterscheidet zwischen Systemessenz und Systeminkarnation. Die Systemessenz entspricht der fachlichen Seite, das heisst Aufgaben und Eigenschaften des gewünschten Systems ohne Berücksichtigung von Technologie. Hingegen ist die Systeminkarnation die Sicht des Systems aus der technologischen Sicht. Robertson und Robertson (Robertson/Robertson, 2008 S. 70ff.) gehen vom Groben ins Detail. Zuerst definieren sie den Umfang der Arbeit, mit Hilfe von Geschäftsereignissen und Szenarien wird der Umfang des Produktes definiert.

Requirements Engineering in der Suva Janine Franken

«Business events und business use cases allow us to carve out a cohesive piece of the work for further modeling and study. By first understanding the effect each of the adjacent systems has on the work, we can come to understand the optimal product to build for that work. We arrive at the product scope by understanding the work in its context, not by presupposing that there will be a user and a computer, or by slavishly following the existing technology.» (Robertson/Robertson, 2008 S. 90)

3.2.1.3 Anforderungsermittlung

«Ziel ist es, mit möglichst geringem Aufwand und angepasst an die Projektrahmenbedingungen die Ziele und Anforderungen zu erfassen, um ein System zu entwickeln, das den Stakeholdern möglichst viel Gewinn bringt.» (Rupp/SOPHISTen, 2009 S. 80). Daher wird oft der Mittelweg zwischen Risikoreduktion und Kostenexplosion gesucht. Gemäss Rupp (Rupp/SOPHISTen, 2009 S. 80f.) werden die Anforderungen aber nicht einfach geliefert, sondern diese müssen mit verschiedenen Techniken ermittelt werden. Ein geschicktes Kombinieren dieser Techniken führt zum Ziel. Es ist aber wichtig zu wissen, welche Anforderungen den Stakeholdern in welchem Mass wichtig sind. Aus diesem Grund wird das Kano-Modell von Dr. Noriaki Kano aus dem Jahre 1978 vorgestellt.

Das Kano-Modell

Abb. 7: Das Kano-Modell zeigt, was Kunden wirklich glücklich macht (Rupp/SOPHISTen,

2009 S. 82)

Das Kano-Modell unterscheidet zwischen drei verschiedenen Produktfaktoren. Die Ba-sisfaktoren, Muss-Faktoren oder grundlegende Faktoren sind die Anforderungen, welche als selbstverständlich erwartet werden. Wenn Anforderungen aus dieser Kategorie im System fehlen, dann ist der Kunde nicht nur völlig unzufrieden, sondern auch der Erfüllungsgrad ist völlig unzureichend. Die Leistungsfaktoren oder Soll-Faktoren sind die bewusst geforderten Anforderungen. Fehlen Anforderungen aus dieser Kategorie, ist der Kunde unzufrieden und der Erfüllungsgrad ist unzureichend. Die Begeisterungsfaktoren,