Requirements Engineering in der Suva

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Management Summary

2 Einleitung
2.1 Die Suva
2.2 Business Analyse
2.3 Ablauf der Arbeit
2.4 Abgrenzung der Arbeit
2.5 Fragestellung

3 Theorie
3.1 Begriffsdefinitionen
3.2 Vorgehen im Requirements Engineering in der Literatur
3.2.1 Anforderungen ermitteln
3.2.1.1 Ziele und Stakeholders
3.2.1.2 Systemkontext, System- und Kontextgrenzen
3.2.1.3 Anforderungsermittlung
3.2.2 Anforderungen formulieren
3.2.2.1 Schablonen
3.2.2.2 Dokumentation von Anforderungen
3.2.2.3 Nicht-funktionale Anforderungen
3.2.3 Anforderungen validieren
3.2.3.1 Prüftechniken für Anforderungen
3.2.3.2 Qualitätsmessungen
3.2.4 Anforderungen verwalten
3.2.4.1 Requirements Management
3.2.4.2 Versionen und Zustände
3.2.4.3 Strukturen und Mengen
3.2.4.4 Change- und Release-Management
3.2.4.5 Wiederverwendung
3.3 Vorgehensmodelle in der Softwareentwicklung und ihr Beitrag zu Requirements Engineering
3.3.1 Übersicht über Vorgehensmodelle
3.3.1.1 Die sequenziellen Vorgehensmodelle
3.3.1.2 Die prototypischen Vorgehensmodelle
3.3.1.3 Die wiederholenden Vorgehensmodelle
3.3.1.4 Die wiederverwendungsorientierten Modelle
3.3.2 Familie der Vorgehensmodelle und ihre Vertreter

4 Methode
4.1 Quantitative oder Qualitative Verfahren
4.2 Qualitative Datenermittlung
4.3 Problemstellung und Hypothese
4.4 Erstellung des Leitfadeninterviews
4.4.1 Auswahl der Kandidaten
4.4.2 Grober Ablauf des Interviews
4.4.3 Einstiegsfrage
4.4.4 Anforderungen ermitteln
4.4.5 Anforderungen formulieren
4.4.6 Anforderungen validieren
4.4.7 Anforderungen verwalten
4.4.8 Persönliche Ergänzungen
4.4.9 Aufbereitung und Auswertung der Interviews

5 Ergebnisse
5.1 Vorgehen RE im eigenen Aufgabengebiet
5.2 Anforderungen ermitteln
5.3 Anforderungen formulieren
5.4 Anforderungen validieren
5.5 Anforderungen verwalten
5.6 Persönliche Ergänzungen
5.7 Zusammenfassung der Interviews

6 Empfehlungen
6.1 Beantwortung der Frage und Auswertung Hypothesen
6.2 Rolle des Requirements Engineer in der Suva verankern
6.3 Einheitliches Vorgehen im RE
6.4 Definierter Übergang vom Projekt in die Wartung

7 Persönliches Fazit

8 Literaturverzeichnis

9 Anhang A: Interviews
9.1 Verzeichnis der Interviewpartner
9.2 Interview mit Verantwortlichem aus der Wartung (WT1)
9.3 Interview mit Verantwortlichem aus der Wartung (WT2)
9.4 Interview mit Projektleiter (PR1)
9.5 Interview mit Projektleiter (PR2)
9.6 Interview mit Methodiker (MT1)

10 Anhang B: Grafiken
10.1 Inhaltsverzeichnis des Projektmanagement-Handbuches der Suva
10.2 E-Mail betreffend Requirements Engineer und Business Analyst
10.3 Prozesslandschaft Unternehmensentwicklung
10.4 Volere Requirements Process
10.5 gfs.bern – Methoden empirischer Sozialforschung
10.6 Manifesto

11 Anhang C: Eigenständigkeitserklärung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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 S. 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, 2008 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) XXXIV

Abb. 21: Email - Business Analysten und Requirements Engineers XXXV

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

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

Abb. 24: gfs.bern - Methoden empirischer Sozialforschung. XXXVIII

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

Tabellenverzeichnis

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

Tabelle 2: Die Empfehlungsmatrix der Dokumentationstechniken (Rupp/SOPHISTen, 2009 S. 241)

Tabelle 3: Eigenschaften von Prüftechniken und mögliche Einflussfaktoren (Rupp/SOPHISTen, 2009 S. 308f.)

Tabelle 4: Die Qualitätsmerkmale im Überblick - eigene Darstellung (Rupp/SOPHISTen, 2009 S. 317)

Tabelle 5: Vertreter in den Familien der Vorgehensmodelle (Bunse/von Knethen, 2008 S. 172)

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

Tabelle 7: Auswertung Frage 1

Tabelle 8: Auswertung Frage 2

Tabelle 9: Auswertung Frage 3

Tabelle 10: Auswertung Frage 4

Tabelle 11: Auswertung Frage 5

Tabelle 12: Auswertung Frage 6

Tabelle 13: Auswertung Frage 7

Tabelle 14: Auswertung Frage 8

Tabelle 15: Auswertung Frage 9

Tabelle 16: Auswertung Frage 10

Tabelle 17: Auswertung Frage 11

Tabelle 18: Auswertung Frage 12

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

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

Tabelle 21: Aufgaben Requirements Engineer neu definiert

Tabelle 22: Prozessschritte im Requirements Engineering

Tabelle 23: Lieferobjekte für die Wartung

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. Die ganze Arbeit stellt das Buch „Requirements-Engineering und –Management“ von Chris Rupp und den SOPHISTen in den Mittelpunkt. 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. EinRequirements-Engineering-Konzept muss erstellt und ins Projektmanagement-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.

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^[1].

Abbildung in dieser Leseprobe nicht enthalten

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 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 Hauptsitzder 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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Organigrammder 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 Fachverantwortlichen, 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.

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 Vorgehens­modellenin der Softwareentwicklung wird am Ende des Theorieteils aufgezeigt^[2] 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/ Fachverantwortlichen 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.

3 Theorie

In diesem Kapitel werden die theoretischen Grundlagen zu Requirements Engineering erarbeitet.Als Grundlage wird das Buch „Requirements-Engineering und –Management“ 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^[3] (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:

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.»

RequirementsEngineer è 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 Theorieteilgeklärt.

RequirementsManagement è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)

3.2 Vorgehen im Requirements Engineeringin der Literatur

Das Anforderungsmanagementumfasst 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.

Schaut man sich das Vorgehen bei der neu geschaffenen Zertifizierung zum „Certified Professional forRequirements Engineering (CPRE)“ (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 Produktanforderungen 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:

Abbildung in dieser Leseprobe nicht enthalten

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). Sie haben den „VolereRequirementsProcess Model“ in 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, Anforderungen 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) wird der Schritt „Anforderungen ermitteln“ in die zwei Arbeitsschritte „Ziele, Informanten und Fesseln“ sowie „Anforderungsermittlung“ unterteilt. Im ersten Arbeitsschritt werden 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 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 Stakeholderkann 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 entsprechendenKategorie 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.

Abbildung in dieser Leseprobe nicht enthalten

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 Zielenund 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.

Pohl(Pohl, 2008 S. 89f.) stellt die Ziele ganz an den Anfang desRequirements 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 Stakeholderinnehaben 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 abgeleitet hat. Er bezeichnet diese Phase als „Business Engineering“.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 Stakeholdernist die „StakeholderMap“. Sie zeigt die verschiedenen Klassen von Stakeholder und die verschiedenen Rollen (Robertson/Robertson, 2008 S. 45f.).

Abbildung in dieser Leseprobe nicht enthalten

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-Prozess, welcher als „Requirements Skeleton“ bezeichnet wird. Die Stakeholder werden 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.)

Abbildung in dieser Leseprobe nicht enthalten

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 Entwicklungsfacetten. Diese werden mit den drei Typen von Kontextaspekten „Anforderungsquellen“, „Betrachtungsgegenstände“ und „Eigenschaften und Beziehungen der Betrachtungsgegenstände“ bereichert. Diese Strukturierung des Systemkontexts unterstützt gemä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.

«Business events und business use cases allow us to carve out a cohesive piece ofthe work for further modeling and study. By first understanding the effect each ofthe 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 Stakeholdernin welchem Mass wichtig sind. Aus diesem Grund wird das Kano-Modell von Dr. Noriaki Kano aus dem Jahre 1978 vorgestellt.

Das Kano-Modell

Abbildung in dieser Leseprobe nicht enthalten

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 Basisfaktoren,Muss-Faktoren oder grundlegendeFaktoren 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,Plus-Faktoren oder Aufregungsfaktoren sind die Anforderungen, die der Kunde nicht erwartet und nicht spezifisch fordert. Jede zusätzliche Anforderung in dieser Kategorie kann den Zufriedenheitsgrad des Kunden steigern.(Rupp/SOPHISTen, 2009 S. 81f.)(Michel, 2007 S. 143)

Gemäss Rupp (Rupp/SOPHISTen, 2009 S. 82ff.)sind die Anforderungen der Kategorie Leistungsfaktoren am einfachsten zu ermitteln. Diese Faktoren wünscht der Stakeholder bewusst. Hingegen die Basisfaktoren müssen „ausgegraben“ werden. Diese sind im unbewussten Wissen und müssen spezifisch befragt werden. Die Begeisterungsfaktoren sind sehr schwer zu ermitteln, da sie der Stakeholder nicht spezifisch fordert. Hierzu benötigt es Innovation und Kreativität.

Beim CPRE (Pohl/Rupp, 2009 S. 30f.)wird ebenfalls das Kano-Modell für das Verständnis bei der Anforderungsermittlung erklärt. Zusätzlich verwendet CPRE(Pohl/Rupp, 2009 S. 132) das Kano-Modell auch als eine der Techniken für die Priorisierung von Anforderungen.

Ebert (Ebert, 2008 S. 224ff.)verwendet eine andere Methode als Hilfsmittel für die Priorisierung von Anforderungen, das Quality FunctionDeployment (QFD). Dieses ermöglicht gemäss Ebert nicht nur eine Priorisierung der Anforderungen, sondern zeigt auch deren Einflüsse auf die Realisierung.

Pohl (Pohl, 2008 S. 534ff.)verwendet das Kano-Modell nicht als Unterscheidung von Anforderungstypen, aber als Hilfsmittel für die Anforderungspriorisierung. Er beschreibt, wie die einzelnen Systemmerkmale in die drei Faktoren klassifiziert werden können. Er geht nicht wie Rupp auf die Besonderheit der Basisfaktoren ein.

Schienmann(Schienmann, 2002 S. 81ff.)verwendet wie Ebert das QFD. Er erklärt das Modell anhand vom Kano-Modell. Für ihn ist die Unterscheidung wichtig, was mit dem Produkt erreicht werden will. Soll es auf dem Markt erfolgreich sein oder gar neue Märkte gewinnen, dann sind die Begeisterungsfaktoren wichtiger. Er bezeichnet die Basisanforderungen auch als fundamentale Produktanforderungen.

Bei Robertson und Robertson (Robertson/Robertson, 2008 S. 332ff.)wird vom Kundenwert gesprochen. Dieser wird je Anforderung in einer Skala für Gefallen und Missfallen gemessen. Diese Bewertung wird später für die Priorisierung von Anforderungen verwendet. Diese setzt sich aus dem Kundenwert, dem Marktwert, den Implementierungskosten und der Komplexität der Implementierung zusammen.

Ermittlungstechniken

Es gibt eine Vielzahl von Ermittlungstechniken. Rupp (Rupp/SOPHISTen, 2009 S. 85ff.)unterteilt diese in die Kategorien Kreativitätstechniken, Beobachtungstechniken, Befragungstechniken, artefaktbasierte Techniken und die unterstützenden Techniken. In all diesen Kategorien gibt es verschiedene Techniken, die bei Rupp mit Vor- und Nachteilen vorgestellt werden. Rupp (Rupp/SOPHISTen, 2009 S. 85ff.)hat die verschiedenen Techniken in der Praxis geprüft und gibt Empfehlungen ab, für welche Situation welche Technik angewendet werden soll.

Auf die Beschreibung der einzelnen Techniken wird hier verzichtet, da dies nicht Bestandteil dieser Arbeit ist.

Abbildung in dieser Leseprobe nicht enthalten

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

Um die geeignete Ermittlungstechnik auszuwählen, istes gemäss Rupp(Rupp/SOPHISTen, 2009 S. 111)wichtig, zuerst die Kategorie aufgrund der Zuordnung zum Kano-Modell zu berücksichtigen. Anschliessend müssen die wichtigsten drei bis vier Einflussfaktoren gemäss obiger Abbildung markiert werden. Zum Schluss sollen die unterstützenden Techniken noch berücksichtigt werden. Diese können beim Einsatz der Ermittlungstechnik helfen.

Eine Vielzahl von Erhebungstechniken werden bei Schmidt (Schmidt, 1991 S. 116) aufgezählt: Interview, Fragebogen, Beobachtung, Dokumentenstudium, Selbstaufschreibung, Systeme vorbestimmter Zeiten, Schätzungen. Für Schmidt (Schmidt, 1991 S. 162) «[…] kommt es auf die zweckmässige Kombination einzelner Erhebungstechniken an.». Zudem können die verschiedenen Erhebungstechniken parallel oder sequenziell durchgeführt werden. Aber auch für ihn gibt es kein Rezept für die richtige Erhebungstechnik bzw.Erhebungsmix. Kriterien, wie Kosten und Zeit haben einen grossen Einfluss auf die Wahl der Technik. (Schmidt, 1991 S. 162f.)

Da Anforderungen von verschiedenen Stakeholdern und somit von verschiedenen Menschen formuliert werden, benötigt es eine spezielle Möglichkeit, Informationsverluste, Unvollständigkeiten und Zweideutigkeiten zu erkennen und so zu formulieren, dass alle Stakeholdern das Gleiche darunter verstehen. «Um dieses Problem zu lösen, haben wir Methoden aus den Disziplinen Linguistik, Informatik, Psychologie und Psychotherapie im sogenannten „SOPHIST-REgelwerk“ vereinigt.» (Rupp/SOPHISTen, 2009 S. 116). Mithilfe dieses Regelwerkes sollte es möglich sein, Lücken und Transformationen in den Anforderungen aufzufinden und durch eine entsprechende Umformulierung der Anforderung zu eliminieren. (Rupp/SOPHISTen, 2009 S. 115ff.)

Im CPRE (Pohl/Rupp, 2009 S. 32ff.)werden die Ermittlungstechniken ebenfalls in die fünf Kategorien unterteilt. Einflussfaktoren für die Wahl der Ermittlungstechnik werden aufgezeigt. Dazu gehören die Faktoren des Kano-Modells. Hinzu kommen Termin- und Budgetvorgaben, Verfügbarkeit der Stakeholder, Erfahrungen des Requirements Engineers sowie Chancen und Risiken des Projektes. Es wird aber keine Hilfeleistung geboten, wie in oben gezeigter Tabelle.

Ebert (Ebert, 2008 S. 124ff.)zeigt eine Vorgehensweise auf, welche aus acht Schritten besteht. Die Schritte müssen aber nicht in der gegebenen Reihenfolge durchlaufen werden. Bei jedem dieser Schritte zeigt er verschiedene Techniken auf, die zur Ermittlung verwendet werden können. Diese sollen situativ genutzt werden.Ebert (Ebert, 2008 S. 126) analysiert bereits jetzt die Anforderungen, was Rupp (Rupp/SOPHISTen, 2009 S. 157) erst im nächsten Schritt, bei „Anforderungen formulieren“ macht. Ebert(Ebert, 2008 S. 129f.) erwähnt besonders den Workshop als ein ideales Mittel zur Ermittlung von Anforderungen.

Pohl(Pohl, 2008 S. 323ff.) kennt fünf verschiedene Gewinnungstechniken. Er beschreibt diese im Detail und bewertet sie aufgrund ihres Aufwandes, ihrer Eignung zur Identifikation und Gewinnung von Anforderungen und zur Entwicklung innovativer Anforderungen. Anschliessend beschreibt er Assistenztechniken zur Gewinnung von Anforderungen und bewertet sie nach den gleichen Kriterien wie die Gewinnungstechniken.

Schienmann(Schienmann, 2002 S. 196ff.)unterscheidet bei den Techniken für die Ermittlung von Anforderungen zwischen Dokumentenanalyse, Befragung von Betroffenen, Gruppentechniken, Beobachtungen und Mitarbeit. Er erwähnt, dass sich diese Techniken gut miteinander kombinieren lassen und dass seine Liste der Techniken nicht vollständig ist. Ebenfalls zeigt er eine Bewertung der verschiedenen Techniken in Bezug auf Erhebungsziel, Erhebungsart, Erhebungsaufwand, Daten und Ressourcen, Tätigkeiten und Rollen, Prozesse und Zeiten sowie AM-Prozessbereich.

«Let’s start with a fundamental truth: Requirements come from people. Your task as a requirements analyst is to talk to people, understand them, listen to what they say, hear what they don’t say, and understand what they need. Most of the time you learn requirements from people at work. Here’s another fundamental truth: Requirements are not solutions. You need to learn the requirements before you can find the solution. It just won’t work the other way round.»(Robertson/Robertson, 2008 S. 93).Mit diesem einleitenden Absatz beginnen Robertson und Robertson die Beschreibung der Ermittlungstechniken. Es werden verschiedene den Ermittlungstechniken vorgestellt. Sie werden anschliessend für die möglichen Projektgrössen bewertet. Robertson und Robertson(Robertson/Robertson, 2008 S. 132) erwähnen, dass die Auswahl für die richtige Technik nicht einfach ist. Es kommt erstens auf den Wissensstand der betroffenen Personen an, also wie vertraut sind sie mit der Technik. Zweitens kommt es auch auf die Person an, da nicht alle Techniken für jeden Typ Mensch anwendbar sind. Daher ist es wichtig verschiedene Techniken zu verwenden, oder zu kombinieren. Eine spezielle Erwähnung finden die Ermittlungstechniken Szenarien und Prototypen. (Robertson/Robertson, 2008 S. 93ff.)

Bei den Prototypen gibt es zwei Arten. Die „Low-Fidelity“ und die „High-Fidelity“ Prototypen. Bei der ersten Art handelt es sich um Hilfsmittel, welche bereits vorhanden sind wie Schreiber, Papier, Whiteboard, Flipchart, Post-it und ähnliche. Hierbei geht es um eine Visualisierung von den Anforderungen ohne zusätzliche Investitionen. Hingegen ist die zweite Art von Prototyp die bereits teilweise entwickelte Software. Diese Art von Prototyp hilft den Stakeholdern, ein realistisches Bild vom endgültigen Produkt zu bekommen. Das wiederum hilft die Anforderungen an das Benutzerinterfacezuklären. Es dürfen dabei aber nicht die anderen Anforderungen wie Sicherheit und Schnittstellen vernachlässigt werden. (Robertson/Robertson, 2008 S. 288ff.)

Prototyp wird bei Rupp(Rupp/SOPHISTen, 2009 S. 298)für die Validierung und nicht für die Erhebung von Anforderungen verwendet. Hingegen die erste Art von Prototyp, die „Low-Fidelity“ wird bei Rupp (Rupp/SOPHISTen, 2009 S. 102ff.)als unterstützende Technik bezeichnet.

3.2.2 Anforderungen formulieren

In diesem Bereich werden bei Rupp(Rupp/SOPHISTen, 2009 S. 157) zuerst die verschiedenen Schablonen erklärt, welche für dieDokumentation verwendet werden. Anschliessend werden alle zu dokumentierenden Artefakte beschrieben und die verschiedenen Techniken aufgezeigt. Im dritten Teil geht es um die Nicht-Funktionalen Anforderungen.

3.2.2.1 Schablonen

Der Ansatz von Schablonen basiert auf sprachlichen und philosophischen Grundlagen. Diese Schablonen sind bei der Konstruktion und bei der Qualitätssicherung von Anforderungen hilfreich.Die Schablone hilft auch, den Aufwand beim Schreiben der Anforderungen zu minimieren. Somit haben alle Anforderungen eine ähnliche Struktur. (Rupp/SOPHISTen, 2009 S. 160f.)

Rupp (Rupp/SOPHISTen, 2009 S. 162ff.)erklärt im Detail die verschiedenen Arten von Schablonen:

- Anforderungsschablone ohne Bedingung
- Anforderungsschablone mit Bedingung
- Schablone für Prozesswörter
- Schablone für Begriffsdefinitionen von Substantiven
- Schablone für allgemeingültige Begriffe
- Schablone für Abkürzungen

Abbildung in dieser Leseprobe nicht enthalten

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

In CPRE(Pohl/Rupp, 2009 S. 61ff.) wird diese Art von Schablonen ebenfalls gezeigt und als Technik für die Dokumentation von natürlich sprachlicher Anforderung verwendet. Sie bezeichnen diese Technik als Satzschablone. Es wird zusätzlich darauf hingewiesen, dass, «um eine lexikalische Eindeutigkeit der Dokumentation zu erreichen, empfiehlt sich in Verbindung mit der Satzschablone der Einsatz eines Projektglossars.» (Pohl/Rupp, 2009 S. 61).

Ebert (Ebert, 2008 S. 148ff.)verwendet ebenfalls die gleiche Schablone. Er zeigtverschiedene Satzstellungen bei verschiedenartigen Anforderungen auf. Dabei unterscheidet er zwischen Basisanforderungen, funktional oder nicht funktional, mit oder ohne Schnittstellen,mit oder ohne Bedingungen oder Projektrandbedingungen.

Bei Pohl (Pohl, 2008 S. 245f.)werden diese Schablonen als syntaktische Anforderungsmuster bezeichnet. Ermacht aber keinerlei Unterscheidungen für die verschiedenartigen Anforderungen.

Schienmann(Schienmann, 2002 S. 239f.)kennt Satzmuster, welche auf die Musterarten Partizipation, Inklusion, Partition, Fähigkeit, Prozess und Regel bezogen sind. Er verwendet diese Satzmuster für die Standardisierung von Aussagen. Aufgrund dieses Satzmusters kann er das Klassendiagramm ableiten.

Bei Robertson und Robertson (Robertson/Robertson, 2008)werden keine Schablonen für die Darstellung von Anforderungen erwähnt.

[...]

---

^[1] siehe „Inhaltsverzeichnis des Projektmanagement-Handbuches der Suva“ im Anhang B

^[2] Siehe "Vorgehensmodelle in der Softwareentwicklung und ihr Beitrag zu Requirements Engineering" auf Seite 36

^[3] CPRE: Certified Professional for Requirements Engineering