Business Requirements Engineering. Wie können wir das Anforderungsmanagement standardisieren und welche Tools und Methoden gibt es?

III. Inhaltsverzeichnis

1 Einleitung

2 Ausgangslage
2.1 Problemstellung
2.2 Projekte und ihr Scheitern
2.3 Ziele und Zweck der Arbeit
2.4 Zentrale Fragestellungen
2.5 Abgrenzungen
2.6 Veränderung seit der Diplomarbeitsstudie
2.7 Arbeitsvorgehen
2.8 Kriterien für die Bewertung
2.8.1 Beschreibung Brainwriting Methode
2.8.2 Auflistung der Anforderungen - Kriterien für die Bewertung

3 Requirements Engineering Grundlagen
3.1 Begriffsdefinition Requirements-Engineering und -Management
3.2 Was sind Anforderungen?
3.2.1 Funktionale Anforderungen
3.2.2 Nicht funktionale Anforderungen
3.2.3 Kano-Modell
3.3 Was ist das Ziel des Anforderungsmanagements?
3.4 Warum braucht es das Anforderungsmanagement?
3.5 Ermittlung und welche Ergebnisse man erwarten kann
3.5.1 Speed-Creation
3.6 Analysieren von Anforderungen
3.7 Beschreibung und Darstellung von Anforderungen
3.7.1 Dokumente
3.7.2 Textuelle Dokumentation
3.7.3 Tabellarische Dokumentation
3.7.4 Modellbasierte, graphische Dokumentation
3.7.5 Prototyp-Verfahren / Screen-Mockups
3.8 Prüfung von Anforderungen (Validierung und Verifizierung)
3.9 RE in Vorgehensmodelle
3.9.1 Klassische phasenorientierte Vorgehensmodelle
3.9.2 Agile Modelle
3.10 Fazit

4 Varianten und Methoden
4.1 Welche Methoden gibt es?
4.1.1 SOPHISTen Schablone
4.1.2 Scrum Schablone
4.1.3 Behaviour Driven Development (BDD) Schablone
4.1.4 Feature Driven Development (FDD) Schablone
4.1.5 E.VA Schablone
4.2 Kriterien anwenden für die Methoden
4.2.1 Präferenzmatrix
4.2.2 Entscheidungsmatrix / Nutzwertanalyse
4.3 Variante und Methode empfehlen
4.4 Fazit

5 Tools und Werkzeuge zur Erfassung und Verwaltung
5.1 Tools und Werkzeuge
5.1.1 Zweck und Nutzen
5.1.2 Werkzeug Auswahl
5.1.3 Requirements Engineering Tools
5.2 Kriterien anwenden für die Tools und Werkzeuge
5.2.1 Präferenzmatrix
5.2.2 Entscheidungsmatrix / Nutzwertanalyse
5.3 Kostenvergleich
5.3.1 Berechnung der variablen Betriebskosten
5.3.2 Kostenvergleichsrechnung
5.4 Empfehlung Tools und Werkzeuge
5.5 Fazit

6 Kritische Erfolgsfaktoren für die Einführung
6.1 SWOT-Analyse
6.2 Risiken und Massnahmen
6.2.1 Risikokatalog
6.2.2 Massnahmen
6.2.3 Neubewertung der Risiken aufgrund der definierten Massnahmen
6.3 Empfehlung Risiken und Einführung
6.4 Fazit

7 Empfehlung

8 Schlussfolgerung
8.1 Beantwortung der zentralen Fragestellungen
8.2 Schlussfolgerung und persönliches Fazit

I. Vorwort

Zuerst gebührt mein Dank Herrn Nick Grossenbacher, der meine Diplomarbeit unermüdlich redigiert hat und Herrn David Weilenmann. Bei beiden Personen bedanke ich mich herzlich für die hilfreichen Anregungen und die konstruktive Kritik bei der Erstellung dieser Arbeit!

Besonders möchte ich mich auch bei meiner Familie, meinen Arbeitskollegen und all meinen Freunden für ihre motivierenden Worte und Unterstützung während der ganzen Zeit bedanken. Ein ganz besonderer Dank gilt meiner Frau, Ariane Lafferma, die mich auf meinem Weg bestärkt und unterstützt hat und mir viel Last im privaten Bereich in dieser Zeit von den Schultern genommen hat.

In der folgenden Arbeit wird aus Gründen der besseren Lesbarkeit ausschliesslich die männliche Form verwendet. Sie bezieht sich auf Personen beiderlei Geschlechts. Dies impliziert jedoch keine Benachteiligung des weiblichen Geschlechts, sondern soll im Sinne der sprachlichen Vereinfachung als geschlechtsneutral zu verstehen sein.

Patrick Lafferma

Bern, 27.08.2019

II. Management Summary

Die Bedeutung des Anforderungsmanagement wird immer grösser, was in der Ausgangslage dargestellt und auch an den Chaos Reports der Standish Group ersichtlich wird.

An der vergangenen Strategiesitzung der Geschäftsleitung wurde somit entschieden, dass eine standardisierte Business Requirements Engineering Methode einzuführen ist, um die Missstände in unserer kleinen IT-Unternehmung zu beheben.Ziel dieser Diplomarbeit ist das Aufzeigen von möglichen Methoden und Tools zur einheitlichen Erfassung und Verwaltung von Anforderungen im Unternehmen. Am Ende der Ausgangslage in Kapitel 2 werden die Kriterien für die Bewertung (vgl. Tabelle 1: Anforderungen - Kriterien) unter Anwendung der Brainwriting Methode ermittelt.Im ersten Teil (Kapitel 3) der Arbeit werden die verschiedenentheoretischen Grundlagen des Anforderungsmanagementsgem. Literatur erläutert resp. gibt die Arbeit einen Überblick über das Thema Requirements Engineering inklusive der Prozesse, Methoden und Werkzeuge. Im zweiten Teil (Kapitel 4) werden Methoden zur textuellen Erfassung von Anforderungen verglichen und bewertet, bevor im dritten Teil (Kapitel 5) verschiedene Tools zur Verwaltung der Anforderungen aufgezeigt, beurteiltund deren Kosten verglichen werden. Im vierten Teil (Kapitel 6) werden die Risiken für die Einführung einer Methode und eines Tools im Unternehmen ermittelt, bewertet und entsprechende Massnahmen dazu definiert.

Aufgrund der Bewertung der Methodikenund der Tools unter Anwendung verschiedener Techniken, wurden vom Autor folgende Empfehlungen zu handen der Geschäftsleitung der XY GmbH ausgearbeitet:

a) Ermittlung der Anforderungen mittels der Speed-Creation Methode
b) Textuelle Dokumentation der Anforderungen nach Satzschablone von Scrum
c) Verwaltung der gesammelten Anforderungen in Jira von Atlassian Confluenceund Freigabe der Kosten von CHF 28’848.00für die Nutzung des Softwareproduktes über einen Zeitraum von fünf Jahren für insgesamt 20 Benutzer, inklusiveden variablen Kosten für Administration, Schulung, Support und spezifischen Anpassungen.
d) Reduktion der kritischen Erfolgsfaktoren durch Erstellung eines Einführungskonzeptes, internen Schulungsmassnahmen, Arbeitsanweisungen und Checklisten

Der Lerneffekt im Bereich Anforderungsmanagement in der XY GmbH, wird erst nach einer gewissen Zeit nach der Implementation ersichtlich werden.

IV. Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

In den diversen IT-Projekten haben wir in unserem Unternehmen heute keine einheitliche Methode für das Business Requirements Engineering. Das heisst, es gibt keine offiziellen Vorgaben, wie Anforderungen erhoben, bewertet und in einem Anforderungskatalog festgehalten werden. Also wird der Autor sich im Rahmen dieser Diplomarbeitzum Wirtschaftsinformatiker HF mit den verschiedenen Methoden und Tools für Business Requirements Engineering / Anforderungsmanagement befassen, wenn möglich die Vor- und Nachteile aufzeigen und eine ideale Methode mit entsprechenden Tools auswählen und empfehlen. Mit dieser Arbeit sollen alle notwendigen Schritte beschrieben werden, damit eine solche Methode in die internen und externen Projekte integriert werden kann.

In einem ersten "Wissensteil" dieser Arbeit werden die Grundlagen des Anforderungsmanagements näher erklärt. Um die Verständlichkeit der Ausführungen zu garantieren, werden zunächst einige wichtige Begrifflichkeiten beschrieben. Anschliessend die verschiedenen Methoden und Tools recherchiert, wenn möglich die Vor- und Nachteile aufgelistet und es werden Kriterien unter Anwendung von Kreativitätstechniken zur Bewertung mit der Geschäftsleitung, Projekt- und Teamleitern festgelegt und angewendet. Grundlage für die Erarbeitung dieserDiplomarbeitsind diverse Quellen aus dem Internet und Fachbüchern sowie Interviewsmit Projekt- und Teamleitern. Der Aufwand für die Einführung von zwei bis drei ausgewählten Toolsin das Unternehmen einzuführen, wird ermittelt und eine Empfehlung abgegeben.

In der Schlussfolgerung werden die zentralen Fragestellungen reflektiert und die Ergebnisse aufgelistet. Zusätzlich erfolgt ein persönliches Fazit des Autors zur Diplomarbeit.

Wo sinnvoll, wird jeweils am Ende des Kapitels ein kurzes Fazit eingefügt, das einen Überblick über die behandelten Themen und gewonnenen Erkenntnisse liefern soll.

Die restlichen Kapitel beinhalten das Management Summary, das Inhaltsverzeichnis, diverse weitere Verzeichnisse sowie den Anhang, die Diplomarbeitsstudie und die Selbstständigkeitserklärung.

2 Ausgangslage

Dieses Kapitel beinhaltet die Problemstellung, die zentralen Fragestellungen, die Zielsetzungen und den Zweck dieses Dokumentes sowie dessen Abgrenzungen. Es wird dargelegt, welche Veränderungen seit der Diplomarbeitsstudie vorgenommen wurden, wie das Arbeitsvorgehen des Autors ist und die Kriterien für die späteren Bewertungen festgelegt.

2.1 Problemstellung

Der Autor arbeitet für die XY GmbH. Die kleine IT-Unternehmung mit Sitz in Bern bietet ihren Kunden Unterstützung in der Realisierung von IT-Projekten an. Das Unternehmen wurde im Jahr 2008 gegründet und besteht aus vier Mitarbeitern/-innen. Das Haupttätigkeitsfeld der Firma liegt in der Beratung von Grosskunden im Telekommunikations- und Versicherungsumfeld, vereinzelt auch im KMU-Sektor. Die Beratungstätigkeiten beziehen sich auf IT-Projektleitung, System- und Plattform-Management, Projektarbeit und im First-, Second- und Third-Level Support von IT-Systemen. Weiter setzt die Firma Subunternehmer im Umfeld von Datenbank- und Softwaredesign bei Kunden ein. Der grösste und wichtigste Kunde ist die Swisscom (Schweiz) AG. Somit werden Entwicklungen von Produkten und Systemen nicht durch das Unternehmen selbst durchgeführt, sondern dafür mit entsprechenden Lieferanten zusammengearbeitet. Bis heute wird von der Geschäftsleitung keine einheitliche Methode für Business Requirements Engineeringresp. Anforderungsmanagement vorgegeben, genauso fehlen einheitliche Tools, die es den Mitarbeitern ermöglicht, immer nach dem gleichen Schema zu arbeiten und diese zentral und einheitlich zu verwalten. D.h. es gibt keine offiziellen Vorgaben, wie Anforderungen dokumentiert werden.Dies hat zur Folge, dass Projekte nicht effizient durchgeführt werden könnenresp. das Anforderungsmanagement in jedem Projekt neu und unterschiedlich gehandhabt wird und somit personelle und finanzielle Ressourcen verschwendet werden.

Diese Situation ist für die Firma suboptimal. Daher wurde an der letzten Strategiesitzung der GL entschieden, dass eine standardisierte Business Requirements Engineering Methode einzuführen ist, damit diese Missstände in diesem Bereich bei IT-Projekten endlich behoben werden können. Es ist somit ein Anliegen der GL, eine Methode im Unternehmen zu etablieren, die für alle internen und externen IT-Projekte in Zukunft zur Anwendung kommt. Deshalb wurde der Autor beauftragt, eine Analyse von zwei bis drei verschiedenen Anforderungsmanagement Methoden durchzuführen. Die Methoden werden mit ihren Hauptmerkmalen vorgestellt. Dazu greift der Autor auf Literatur zurück.

Mittels der Kreativitätstechnik (Brainwriting Methode) werden mit der Geschäftsleitung, den Projektleitern, den Testern, einem Auftraggeber (Kunde, Stakeholder) der Swisscom sowie einem Entwicklungsleiter von einem Lieferanten die Kriterien für die Requirements Engineering Methode und die Tools für das Requirements Management definiert, die zukünftig im Unternehmen eingesetzt werden sollen.

Anschliessend werden die Methoden und Tools verglichen und mit den Kriterien bewertet. Zusätzlich zu der Analyse der RE Methoden werden auch die möglichen Aufwände für die Einführung von einem passenden Tool im Unternehmen ermittelt. Es wird keine Kosten-Nutzen-Analyse oder Aufstellung der anfallenden Betriebskosten nach Einführung durchgeführt, da die GL in erster Linie die Missstände korrigieren will und die finanziellen Aspekte sekundär sind. Jedoch wird eine Kostenvergleichsrechnung oder Investitionsrechnung für die vorgeschlagenen Tools erarbeitet. Sind all diese Informationen ausgewertet, kann ein Entscheid für eine Methode und ein Tool gefällt werden. Oder aber es stellt sich heraus, dass eine Adaption verschiedener Methoden notwendig sein wird. In diesem Fall wird der Autor einen entsprechenden Vorschlag, der genau den Ansprüchen der XY GmbH entspricht, empfehlen.

Die Arbeit soll der GL eine Entscheidungsgrundlage für ein einheitliches Business Requirements Engineering / Anforderungsmanagement in der Firma bieten.

In der Praxis bestehen im Bereich der Erfassung und der Dokumentierung von Anforderungen resp.dem Requirements Engineering sowie im Bereich der Verwaltung von Anforderungen resp. dem Requirements Management einige Defizite, die das nachfolgende Kapitel aufzeigt. Der Autor erlebt diese Erfahrungen auch in der Praxis bei seinen diversen Mandaten als Berater, Projektleiter, ProductOwner, Scrum Master und System Engineer bei den jeweiligen Kunden. Zum Beispiel wird das Requirements Engineering, je nach Geschäftsbereich innerhalb der Grossunternehmungen, sehr unterschiedlich gelebt.

2.2 Projekte und ihrScheitern

Projektleiter werden bei der Planung und Durchführung eines Projektesenorm gefordert. Es gibt verschiedene Gründe warum Projekte scheitern, aber selten sind sich alle Beteiligten über die Gründe einig.Die Standish Group, die regelmässig Marktforschungsuntersuchungen durchführt um Projekte zu verbessern, untersuchte in mehreren Studien verschiedene Entwicklungsprojekte hinsichtlich ihrer Erfolgsfaktoren bzw. ihrer Misserfolgsfaktoren. Für das Scheitern von Projekten wird als entscheidende Ursache ein ungenügendes Requirements Engineering genannt. Ein standardisiertes Anforderungsmanagementkann im Projektverlauf und für zukünftige Projekte mit Sicherheit helfen.

Wie aus der nachfolgenden Grafik zu entnehmen ist, sind "Unklare Anforderungen und Ziele" der zweit meiste Grund, warum Projekte scheitern:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Warum Projekte scheitern (Quelle: GPM Deutsche Gesellschaft für Projektmanagement und PA Consulting Group, 2008)

Gem. dem Chaos Report der Standish Group haben 46% der IT-Vorhaben zumindest teilweise nicht die Wünsche und Anforderungen der Auftraggeber erfüllt. Jedes fünfte Projekt ist ein Totalausfall.Dies streicht nochmals die Bedeutung des Requirements Engineering hervor. Wie nachfolgende Grafik zeigt, sind zu 19% die Hauptgründe für Projektprobleme bei den unzureichenden Anforderungen zu finden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Hauptgründe für Projektprobleme (Quelle: Ebert, 2019, S. 5)

Unvollständige Anforderungen, unzureichende Benutzereinbeziehung, unrealistische Erwartungen und Änderungen von Anforderungen sind auf Defizite im Requirements Engineering zurückzuführen. Die Qualität und die Aktualität der einzelnen Anforderungen spielt somit eine wichtige Rolle für den Projekterfolg. Das Requirements Engineering und das Requirements Management sind somit wesentliche Erfolgsfaktorenin Projekten.

Oftmals ändern sich im Laufe des Projektfortschrittes die Anforderungen und zum Teil ist es sogar erst während des Entwicklungsprozesses möglich, bestimmte Anforderungen zu erheben. Solche nicht vermeidbaren Schwankungen können nur durch standardisierte Methoden und dem Einsatz geeigneter Tools (IT-Werkzeuge) im Rahmen des Anforderungsmanagements bewältigt werden.

Die Rolle des Requirements Engineering und des Requirements Managements wird in Unternehmungen oftmals unterschätzt. Die Folge sind fehlerhafte, implizierte, inkonsistente, missverständliche, oberflächliche und fehlende Anforderungen. Solche Schwächen werden oft erst in späteren Entwicklungsphasen des Projektes entdeckt und sind damit in ihrer Behebung kostenintensiv. Wenn ein Anforderungsfehler erst in der Umsetzungsphase bemerkt wird, erzeugt die Behebung dieses Fehlers einen um den Faktor 20 höheren Aufwand als ein Beheben während der Anforderungsentwicklung. Für die Entdeckung und Behebung eines Anforderungsfehlers zum Zeitpunkt der Abnahme des Produktes erhöht sich dieser Faktor auf 100. Aus diesen Gründen ist es sinnvoll, durch ein gutes Anforderungsmanagement sicherzustellen, dass die Dokumentation der Anforderungen möglichst vollständig und fehlerfrei ist. (vgl. Dumke 2003, S. 35; Pohl 2008, S. 7ff.; Versteegen 2004, S. 15ff.)

Gem. Klaus 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. Je später ein Fehler in der Anforderung behoben wird, desto teurer ist er. Gem. Pohl/Rupp (2015 S. 2) kostet eine Beseitigung eines Fehlers bei der Entwicklung das zwanzig-fache, als wenn der Fehler während des Requirements Engineering bereits gefunden und korrigiert worden wäre.Gem. Ebert (2019, S. 10) werden 50% aller Funktionen nie verwendet und 80% der Fehler während dem Test resultieren aus unzureichendem Requirements Engineering. Eine Verdoppelung des RE-Aufwandes auf 10%, würde einen Projektnutzen (Effizienzpotenzial) von 20-40% schaffen.

2.3 Ziele und Zweck der Arbeit

Die Arbeit soll die aktuelle Lage innerhalb der XY GmbH aufzeigen. Die Grundlagen von Business Requirements Engineering / Anforderungsmanagement sollen beleuchtet und verschiedene Satzschablonen analysiert werden. Die Arbeit beschreibt, wie Anforderungen erfasst und dokumentiert undmit Hilfe welchen Tools diese verwaltet werden können. Mit dieser Arbeit sollen alle notwendigen Schritte beschrieben werden, damit die für das Unternehmen passendste Methode sowie das dienlichste Tool in unserem Unternehmen implementiert werden können. Der GL wird am Ende eine Lösung zur Umsetzung vorgeschlagen.

Ziele der Arbeit sind:

- Aufzeigen, welche Methoden in Bezug auf "Business Requirements Engineering" resp. Anforderungsmanagement es in der Theorie gibt und welche zwei bis drei ausgewählten Methoden geeignet sind für IT-Projekte in unserem IT-Unternehmen. Die Ergebnisse sind bis zum 02.09.2019 vorliegend.
- Aufzeigen, welche zwei bis drei Tools es zur Erfassung und Verwaltung von Anforderungen gibt, die funktionellen und finanziellen Aspekte vergleichen sowie bewerten, für eine mögliche Beschaffung für unser IT-Unternehmen. Die Ergebnisse sind bis zum 02.09.2019 vorliegend.
- Ermittlung der kritischen Faktoren bis zum 02.09.2019, um die Einführung einer solchen Methodik und einem Tool bestmöglich im Unternehmen zu verbreiten, mit der Empfehlung an die GL der XY GmbH diese einzuführen.

2.4 Zentrale Fragestellungen

In dieser Arbeit werden folgende zentrale Fragestellungen (Probleme im Arbeitsumfeld) beantwortet:

- Frage 1: Was für Möglichkeiten und Methoden gibt es für Business Requirements Engineering / Anforderungsmanagement gem. Literatur und Best Practice und welche finanziellen und funktionellen Aspekte haben zwei bis drei ausgewählte Methoden, damit Anforderungen vom Auftraggeber und von Geschäftsbereichen standardisiert erhoben und formuliert werden können?
- Frage 2: Mit welchen Tools können Anforderungen umfassend aufgenommen und verwaltet werden, um die Projektabwicklung positiv zu beeinflussen und was sind die funktionellen und finanziellen Aspekte von zwei bis drei Tools bei der Beschaffung im Bereich Anforderungsmanagement?
- Frage 3: Welche kritischen Faktoren müssen berücksichtigt werden, um die Einführung einer solchen Methodik und einem Tool bestmöglich im Unternehmen zu verbreiten?

2.5 Abgrenzungen

Dieses Dokument erstellt lediglich Empfehlungen zum Thema "Requirements Engineering"resp. Anforderungsmanagement. Es wird kein Konzept und keine neue Methodik erstellt, wie im Detail das Anforderungsmanagement und die Anforderungsverwaltung zukünftig umgesetzt wird.Obwohl gewisse Aspekte betroffen und angeschnitten werden und die Arbeit auch einen Bezug zu diesen Gebieten aufweist, befasst sie sich im Detail aber nicht mit Changemanagement, Releasemanagement, Konfigurationsmanagement, Qualitätsmanagement, Projektmanagement und den einzelnen Vorgehensmodellen, Systems Engineering, Business Engineering, Information Engineering und auch nicht mit Prüftechniken resp. Testmanagement.

Nicht behandelt oder nur angerissen werden auch:

- Kreativitätstechniken zur Lösungsfindung
- Macht und Einflussgrössen in Veränderungsprozessen
- Modellierung von Anforderungen im Kontext von Application Engineering sowie Methoden zum technischen Design und Implementierung von Anforderungen

Wie in der Problemstellung in Kapitel 2.1 erwähnt, werden nur die Kosten für die Einführung desTools berechnet, da die anfallenden Betriebskosten für die GL sekundär sind, gem.des Beschlusses an der letzten Strategiesitzung.

2.6 Veränderung seit der Diplomarbeitsstudie

Es wurden keine grundsätzlichen Veränderungen seit der Diplomarbeitsstudie vorgenommen. Im Verlaufe der Erstellung von Kapitel 2 "Ausgangslage" und Recherche in der Literatur wurde aufgrund des Umfanges der Thematik "Requirements Engineering" und der Vielzahl an Informationen dazu, spezifischer ausgearbeitet, welche Bestandteile genauer untersucht werden müssen, damit a) der Rahmen dieser Arbeit nicht gesprengt wird und b) dies in die Gesamtkonstellation der Firma und ihrem Einsatzgebiet passt.

2.7 Arbeitsvorgehen

Zu Beginn wird die aktuelle Situation im Unternehmen untersucht - dies auch mit Hilfe von Stakeholdern, Mitarbeitern und Vorgesetzten sowie die Anforderungen der XY GmbH aufgenommen. In einem nächsten Schritt wird sich der Autor mit wissensbasierter Recherche von Fachliteratur und Internetbeiträgen zum Thema „Requirements Engineering“ resp. Anforderungsmanagement auseinandersetzen. Mit diesen Schritten sollten genug Informationen vorhanden sein, um mit dem Schreiben beginnen zu können. Als nächstes werden die funktionellen Aspekte der einzelnen Methoden erarbeitet und auf die Anforderungen der XY GmbH abgeleitet. Mit den gewonnenen Erkenntnissen kann der Autor verschiedene Lösungen am Markt vergleichen und geeignete SW-Lösungen dank der Paarvergleichsmethode und einer Entscheidungsmatrix finden. Zum Schluss soll der GL die passendste Methode und das idealste Tool vorgeschlagen werden und einen Antrag zur Beschaffung der Lösung unterbreitet werden. Wenn eine erste Version der Arbeit vorliegt, wird diese zum Gegenlesen an verschiedene Personen mit und ohne Fachbezug sowie an den Experten und Promoter verteilt. Das erhaltene Feedback wird dann in einer 2. Version miteinbezogen, die wiederum reviewt wird, bevor die Abgabe erfolgt.

2.8 Kriterien für die Bewertung

Der Autor hat mit der GL, mit den Projektleitern, den Testern, einem Auftraggeber (Kunde, Stakeholder) der Swisscom sowie einem Entwicklungsleiter von einem Lieferanten, mittels der Kreativitätstechnik (Brainwriting Methode) die Kriterien für die spätere Bewertung der Requirements Engineering Methode definiert, die zukünftig im Unternehmen eingesetzt werden sollen.

2.8.1 Beschreibung Brainwriting Methode

Nach Böhm (1999, S. 190) ist Brainwriting besonders geeignet, Probleme und deren Themenumfeld zu erkunden und zu durchleuchten und dazu Ideen und Stoffsammlungen zu generieren. Brainwriting wird oft auch als Brainpool bezeichnet.

Wie bei anderen Kreativitätstechniken, beispielsweise 6-3-5 Methode oder Kartentechnik (Kärtchenmethode), werden bei der Brainwriting Methode in einer Gruppensitzung Ideen schriftlich festgehalten und dann unter den Teilnehmern ausgetauscht, um diese Ideen gegebenenfalls weiter auszubauen und zu verbessern. Sie hat den Vorteil gegenüber der 6-3-5 Methode, dass jeder Teilnehmer seine Ideen ohne Einschränkungen in Bezug auf Zeit oder Umfang notieren kann. Ideen und Lösungen, besonders bei wenig strukturierten Themen, lassen sich so schnell erstellen. Probleme und Fragen mit geringerer bis mittlere Komplexität sollten im Fokus liegen.

1. Schritt:

Alle Teilnehmer sitzen um einen Tisch herum (optimal sind Teams von vier bis maximal acht Personen).

2. Schritt

In der Mitte des Tisches wird ein Stapel leerer Karten positioniert oder allenfalls mit bereits einer notierten Idee zum genannten Ansatz.

3. Schritt:

Jeder Teilnehmer nimmt sich eine Karte vom Stapel und notiert eine Idee.

4. Schritt:

Anschliessend reicht man die Karte seinem rechten Nachbarn, nimmt sich eine weitere Karte, notiert eine weitere Idee und reicht die Karte ebenfalls nach rechts weiter. Dies führt man nun für jede Idee aus.

5. Schritt:

Vom Nachbarn erhaltene Karten werden kurz gelesen, gegebenenfalls ergänzt und wie eigene Karten weitergereicht. Alternativ, wenn man gerade mit der Formulierung einer Idee beschäftigt ist, kann die Karte auch ungesehen durchgereicht werden.

6. Schritt:

Erhält man eine seiner eigenen Karten zurück und möchte man diese nicht weiter ergänzen, so wandert sie auf einen Stapel/Haufen (Pool) in der Mitte des Tisches.

Teilnehmern, denen gerade keine eigene neue Idee einfällt, können sich von diesem Stapel willkürlich eine Karte nehmen, diese eventuell ergänzen und die Karte wieder in Umlauf bringen. Nach einer gewissen Zeit, wenn allen Teilnehmern die Ideen ausgegangen sind und die Karten aus dem Stapel schon mehrfach die Runde gemacht haben, ohne dass Ergänzungen erfolgten, ist das Brainwriting beendet. Die Sitzung sollte aber nicht länger als ca. 40 Minuten dauern. Bewerten oder Ausarbeiten der Lösungsvorschläge erfolgt im Anschluss durch die Gruppe selbst, durch den Auftraggeber oder eine Gruppe von Fachspezialisten.

2.8.2 Auflistung der Anforderungen - Kriterien für die Bewertung

Nachfolgend sind die definierten Kriterien zur Implementierung einer Requirements Engineering Methode und Tools im Unternehmen anhand der durchgeführten Brainwriting Methode mit den entsprechenden Teilnehmern aufgelistet:

Tabelle 1: Anforderungen - Kriterien (Quelle: Autor)

Abbildung in dieser Leseprobe nicht enthalten

Aufgrund der Grösse der IT-Unternehmung (Kleinst-KMU) und der Tatsache, dass die XY GmbH vorwiegend bei den Kunden vor Ort arbeitet und in den jeweiligen Projekten auch die Projektmethode (Vorgehensmodell) sowie die Requirements Engineering Prozesse und Methoden des jeweiligen Kunden übernimmt, wurde entschieden, dass man sich auf die Art und Weise der Formulierung (textuelle Dokumentation resp. Spezifizierung) und der Verwaltung von Anforderungen in der weiteren Analyse fokussieren sollte. Dies bringt intern und extern den grössten Nutzen für die Unternehmung.

Des Weiteren wurde festgehalten, dass weder die Software, das Tool, noch die Methode überdimensioniert sein soll und dass das Unternehmen keine vollständige standardisierte Requirements Methode (im Sinne von IEEE, Volere, V-Modell, RUP, CMMI) benötigt und auch keine Software, diezusätzlich Lifecycle-, Entwicklungs-und/oder Testmanagement-Funktionalitäten beinhaltet.

Gem. der Tabelle 1 sind aus Sicht der Geschäftsleitung folgende MUSS-Kriterien (Killerkriterien oder Ausschlusskriterien) für die Auswahl der Methode definiert:

- Nr. 1: Adaptierbar, Wiederverwendbar
- Nr. 2: Einfache Anwendung, geringer Schulungsaufwand

Folgende MUSS-Kriterien wurden für die Auswahl der Software definiert:

- Nr. 1: Adaptierbar, Wiederverwendbar
- Nr. 2: Einfach, verständlich, geringer Schulungsaufwand
- Nr. 3: Schlank, günstig
- Nr. 8: Zentral und Plattform unabhängig
- Nr. 10: Mandantenfähig

3 Requirements Engineering Grundlagen

In diesem Kapitel werden die Grundlagen von Requirements Engineering resp. Anforderungsmanagement behandelt und dem LeserBasisinformationen und Begriffe vermittelt, um ein einheitliches Verständnis zu schaffen.Der Autor muss davon ausgehen, dass nicht jeder Leser mit der Thematik vertraut ist und um ein Gesamtbild zu schaffen es notwendig ist, die Grundlagen des Anforderungsmanagement zu vermitteln. Die möglichen Rollen, deren Kompetenzen und Aufgaben im Requirements Engineering werden nicht oder nur sehr oberflächlich in dieser Arbeit behandelt. Die Theorie bzgl. Anforderungsmanagement ist sehr umfangreich, was dazu führen kann, dass dieses Kapitel einen grossen Teil der Arbeit einnimmt sowie unter Umständen gewisse Aspekte des Anforderungsmanagement trotzdem nur teilweise, minimal oder gar nicht in dieser Arbeit behandelt werden. Spezielle Begrifflichkeiten werden teilweise direkt im Text erklärt oder allenfalls im Glossar (Wortverzeichnis) beschrieben.

3.1 Begriffsdefinition Requirements-Engineering und -Management

Nach Pohl/Rupp (2015, S. 4) kann Requirements Engineering (RE) 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.

Beschreibung des Begriffes Stakeholder nach Tremp/Ruggiero (2011, S. 56): "Stakeholder sind Anspruchsgruppen (wie z.B. Auftraggeber, Kunden, Benutzer, Programmierer, Tester, IT-Betreiber, Supporter, etc.), die ein begründetes Interesse an den Produkten und Dienstleistungen einer Organisation haben und Einfluss darauf nehmen möchten. (…) Je nach Interessenlage haben die verschiedenen Stakeholder auch unterschiedliche Vorstellungen an das künftige Verhalten des Anwendungssystems." Stakeholder sind also Interessenvertreter; resp. Personen, die am Produktentwicklungsprozess beteiligt sind oder irgendwelchen Einfluss darauf haben und Vorstellungen hinsichtlich des Verhaltens haben.

Folglich sind auch Gesetze und Standards ebenfalls als Stakeholder zu betrachten."Das Requirements Engineering hat die Aufgabe, diese Vorstellungen aufzunehmen und für alle verständlich zu dokumentieren."(Tremp/Ruggiero, 2011, S. 56).

Stakeholder liefern somit die Anforderungen an das zu entwickelnde System. Sie werden in die Anforderungsdefinition mit eingebunden und helfen, diese Anforderungen vollständig zu erfassen.

Je nach Literatur sind im Requirements Engineering grundsätzlich ähnliche Schritte mit zum Teil unterschiedlichen Ausprägungen definiert.

So z. B. beschreibt Pohl/Rupp (2015) für diesen Teil des RE, dass man Anforderungen ermitteln, dokumentieren, prüfen und abstimmen sowie verwalten soll.

"RE ist das disziplinierte und systematische Vorgehen (d.h. Engineering) zur Ermittlung, Dokumentation, Analyse, Prüfung, Abstimmung und Verwaltung von Anforderungen unter kundenorientierten, technischen und wirtschaftlichen Zielvorgaben." (Ebert, 2019, S. 33)

Das RE umfasst gem.Rupp/SOPHISTen (2014, S. 2 ff.) folgende Schritte:

1. Anforderungen ermitteln

Anforderungen müssen aus einer Vielzahl von Quellen und Stakeholdern zusammengetragen werden. NachPohl/Rupp (2015, S. 33) werden die Stakeholder als wichtigste Quelle für Anforderungen bezeichnet.Es wird auf verschiedene Techniken zurückgegriffen, um die Anforderungen zu gewinnen, zu detaillieren und zu verfeinern. Nähere Informationen zu gewissen Aspekten der Erhebung / Ermittlung von Anforderungen sind in Kapitel 3.5 und 3.6 aufgeführt.

2. Anforderungen formulieren (dokumentieren)

Sind alle Anforderungen erst einmal bekannt, müssen sie schriftlich niedergelegt und dokumentiert werden. Für die textuelle Formulierung wird auf die Hilfe von Schablonen und für die Beschreibung und Darstellung auf verschiedene Modelle und Methoden zurückgegriffen. Dazu sind nähere Informationen im Kapitel 3.7 zu finden.

4. Anforderungen prüfen und bewerten (validieren und verifizieren)

Auch Anforderungen sind keine Ausnahme und müssen einer Prüfung unterzogen werden. Die Validierung und Verifizierung der Anforderungen zur Qualitätssicherung können mittels verschiedener Methoden erfolgen und müssen frühzeitig geprüft und abgestimmt werden. Teile davon sind in Kapitel 3.8 erläutert.

5. Anforderungen verwalten

Anforderungen sind nicht starr, sondern ändern sich mit der Zeit und müssen strukturiert und verwaltet werden. Die Verwaltung von Anforderungen wird im Kapitel 5 genauer betrachtet.

Nach Ebert (2019, S. 33) wird das RE in folgende sechs Schritte eingeteilt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Einteilung Requirements Engineering (Quelle: Ebert, 2019, S. 33)

Das Requirements Engineering beschreibt ein systematisches Vorgehen zur Ermittlung, Analyse, Prüfung, Dokumentation, Abstimmung und Verwaltung von Anforderungen. Resp. beschreibt der Begriff Requirements Engineering also alle Tätigkeiten, die bei der Entwicklung von Anforderungen notwendig oder beteiligt sind.Das Wort Engineering bringt hier zum Ausdruck, dass systematische und wiederholbare Techniken zum Einsatz kommen.

Jedoch verläuft der RE-Prozess iterativ ab, unabhängig davon wie die einzelnen Schritte benannt werden, was in Abbildung 5dargestellt wird.Die einzelnen Schritte, die beim Requirements Engineering Prozess nötig sind, können auch mehrmals durchlaufen werden.

Gem. Rupp/SOPHISTen (2014, S. 15) wird das Requirements Engineering (RE) wie folgt beschrieben: "Requirements-Engineering beschreibt einen systematischen Weg von der Projektidee über die Ziele zu einem vollständigen Satz von Anforderungen. Neben dem Vorgehen werden auch die Qualitätskriterien definiert, die jede einzelne Anforderung, aber auch die gesamte Anforderungsspezifikation erfüllen muss."

Nachfolgend eine mögliche Darstellung des Anforderungsmanagement Prozesses mit der Unterteilung des Requirements Engineering und dessen Komponenten zur vollständigen Aufnahme von Anforderungen sowie des Requirements Management und dessen Aspekte zur Verwaltung über die gesamte Dauer der Anforderungsermittlung in Anlehnung an die verschiedene Literatur:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Requirements Engineering und -Management (Quelle: Autor)

Der Begriff Requirements Management beschäftigt sich mit dem Verwalten und Steuern von Anforderungen.Im deutschen Sprachgebrauch werden die beiden Begriffe Requirements Engineering und Requirements Management einheitlich mit dem Ausdruck Anforderungsmanagement übersetzt.

3.2 Was sindAnforderungen?

In diesem Kapitel ist der Begriff "Requirements" oder im deutschen "Anforderungen" genauer zu definieren.Wenn man von Anforderungen spricht, gibt es in der Literatur eine Vielzahl von Definitionen und Erläuterungen dazu, obwohl alle eine sehr ähnliche Aussage dazu machen.

Nach den SOPHISTen(2015, S.8) wird der Begriff Anforderung wie folgt definiert:"Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen."

Anforderungen beschreiben also zusammengefasst die vom Kunden erwarteten Wünsche, Vorstellungen, Bedingungen, Eigenschaften, Nutzen und Ziele eines Produktes.

Ein Produkt kann in diesem Fall eine Softwarelösung, eine Dienstleistung, eine Hardwarekomponente, ein IT-System und noch vieles mehr sein. Anforderungen sind also eine Fähigkeit, Voraussetzung, Bedingung oder Eigenschaft, die ein System oder Produkt erfüllen oder besitzen muss. In dieser Arbeit wird der Begriff System analog zu dem Begriff Produkt verwendet.

IEEEStandard610.12 (1990, S. 62) liefert eine alternative Definition des Begriffs der Anforderungen. Eine Anforderung istgem. Übersetzung des Autors:

"1. Eine Bedingung oder Eigenschaft, die ein System oder eine Person benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.
2. Eine Bedingung oder Eigenschaft, die ein System oder eine Systemkomponente aufweisen muss, um einen Vertrag, um einem Standard, um einer Spezifikation oder um ein anderes formelles Dokument zu erfüllen.
3. Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft wie es in den ersten beiden Punkten definiert ist."

Wie Ziele auch, sollen Anforderungen S pezifisch, M essbar, A kzeptiert, R ealistisch, T erminierbar (SMART) sein.

Anforderungen lassen sich gem. Tremp/Ruggiero (2011, S. 58) aus verschiedenen Perspektiven betrachten und klassifizieren, die in der nachfolgenden Tabelle dargestellt werden:

Tabelle 2: Klassifizierung von Anforderungen (Quelle: Autor)

Abbildung in dieser Leseprobe nicht enthalten

Um qualitativ hochstehende Anforderungen zu erhalten, muss die Anforderung mehrere Qualitätskriterien erfüllen, damit diese auch vernünftig geprüft werden kann. "Eine Qualitätsanforderung definiert eine qualitative Eigenschaft des gesamten Systems, einer Systemkomponente oder einer Funktion."(Pohl, 2008, S. 16)

Eine Zusammenfassung der möglichen Qualitätskriterien gem. Literatur sind in der nachfolgenden Grafik dargestellt. (vgl. Ebert, 2019, S. 184 ff.; Rupp/SOPHISTen, 2014, S. 26 ff.; Pohl/Rupp, 2015, S. 47 ff.):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Eine Anforderung muss... (Quelle: Autor)

Anforderungen lassen sich in verschiedene Arten oder Kategorienunterteilen und je nach Literatur gibt es eine Vielzahl von unterschiedlichen Anforderungsarten.

Hinsichtlich der Priorisierung gibt es gem. Literatur verschiedene Möglichkeiten, wie Anforderungen priorisiert resp. die Verbindlichkeit der Anforderung definiert werden kann. Aus Sicht des Autors ist es vor allem wichtig, dass eine Priorisierung stattfindet, in welcher Form, Ausprägung oder nach welcher Methode diese erfolgt ist eher sekundär.

Im nachfolgenden Kapitel wird im Rahmen dieser Arbeit kurz der Unterschied von funktionalen und nicht funktionalen Anforderungen erläutert sowie ein Einblick auf das Kano-Modell gegeben.

3.2.1 Funktionale Anforderungen

Funktionale Anforderungen beschreiben die Funktionalitäten (WAS) des zu entwickelnden Systems bzw. Produktes oder Funktionen. Eine funktionale Anforderung kann als Stakeholder-Anforderung sehr allgemein beschrieben sein, jedoch innerhalb einer Spezifikation muss eine funktionale Anforderung detailliert die Eingaben und Ausgaben sowie bekannte Ausnahmen wiedergeben.Die funktionalen Anforderungen beschreiben also, was das Produkt tun soll (Aktionen) und wie es reagieren soll (Systeminteraktionen).Z. B.: Funktionen vom Produkt, dessen Daten, Schnittstellen oder Verhalten.Sie können mit Worten und/oder anhand von Modellen beschrieben werden, die in Kapitel 3.5 ff näher erläutert werden.

3.2.2 Nicht funktionale Anforderungen

Pohl (2008, S. 16) beschreibt nicht funktionale Anforderungen wie folgt: "Eine Qualitätsanforderung definiert eine qualitative Eigenschaft des gesamten Systems, einer Systemkomponente oder einer Funktion."

Die nichtfunktionale Anforderung (Qualitätsanforderung) legt also fest, welche Eigenschaften (Qualitätsmerkmale) das Produkt haben soll. (z.B. Antwortzeiten, Benutzeroberfläche, etc.). Resp. WIE die einzelnen Funktionen arbeiten sollen.

Sie betreffen also nur Qualitätsanforderungen an das Produkt, wie z. B.:

- Problemsuche / Problembehebung (Troubleshooting)
- Architektur / Design zur Erreichung der geforderten Verfügbarkeit
- Zuverlässigkeit und Stabilität (Ausfallsicherheit)
- Verwaltbarkeit (Manageability)
- Portabilität oder Plattformunabhängigkeit
- Benutzerfreundlichkeit
- Datensicherung, Wiederherstellung (Backup &Recovery) und Sicherstellung der Datenintegrität
- Geschwindigkeit, Antwortzeiten (Performance)
- Skalierbarkeit: Nicht jede Anwendung unterstützt mehr Benutzer und mehr Transaktionen, wenn Prozessoren hinzugefügt werden und der Hauptspeicher vergrössert wird.
- Installationsanforderungen
- Konfigurationsanforderungen
- Betriebsanforderungen
- Archivierung und Zugriff auf die archivierten Daten
- Monitoring: Überwachung der Anwendung muss explizit gefordert werden

Zu den nicht funktionalen Anforderungen gehören auch Angaben zu benötigten Ressourcen für Design- und Architektur-Entscheidungen sowie für das System/Produkt relevante Randbedingungen wie gesetzliche und betriebliche Normen und Vorschriften. Nichtfunktionale Anforderungen können ebenso kritisch für den Erfolg eines Systems sein wie die funktionalen Anforderungen.

Nachfolgende Grafik gibt einen Überblick der nicht funktionalen Anforderungen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Nicht funktionale Anforderungen (Quelle: Ostermann, o.J.)

3.2.3 Kano-Modell

Anforderungen können nach Tremp/Ruggiero (2011, S. 59) auch anhand des Kano-Modells nach Herzberg klassifiziert werden. Hierbei werden der Erfüllungsgrad der Kundenerwartungen und die Kundenzufriedenheit zueinander in Beziehung gesetzt, wobei der Erfüllungsgrad zur Leistungsqualität des Gesamtprodukts beiträgt.

Folgende drei Anforderungsarten (Faktoren) werden zur Klassifizierung im Kano-Modell verwendet:

- Basisfaktoren: Diese beziehen sich auf Funktionen, die der durchschnittliche Benutzer voraussetzt und die als selbstverständlich angesehen werden (z.B. intuitive Benutzeroberfläche, Online-Hilfe, Plausibilitätsprüfung, etc.). Bei fehlen oder mangelnder Erfüllung dieser Basisfaktoren, sinkt die Kundenzufriedenheit rapide. Jedoch wird die Kundenzufriedenheit nicht erhöht, wenn diese vorhanden sind.
- Leistungsfaktoren: Funktionen die von Benutzern explizit gefordert werden. Je mehr Leistungsfaktoren erfüllt werden, desto höher ist die Kundenzufriedenheit und umgekehrt.
- Begeisterungsfaktoren: Dies bezieht sich auf Funktionen, die der durchschnittliche Benutzer noch nicht kennt, die aber als nützliche und angenehme Überraschung empfunden werden. Das Fehlen wirkt sich nicht negativ auf die Kundenzufriedenheit aus. Im Verlaufe der Zeit werden diese Begeisterungsfaktoren aber zu Basisfaktoren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Kano-Modell (Quelle: QZ-Online.de, o.J.)

3.3 Was ist das Zieldes Anforderungsmanagements?

Das Anforderungsmanagement verfolgt einerseitsdas Ziel die einzelnen genannten Disziplinen unter einen Hut zusammen zu fassen und dadurch qualitativ hochwertige Anforderungen zu entwickeln und die Realisierung der Anforderungen vernünftig zu verwalten. Am Anfang steht der Kunde - am Ende auch! Andererseits hat das Anforderungsmanagement auch zum Ziel die Qualität der Produkte und Dienstleistungen positiv zu beeinflussen und den gesamten Software-Entwicklungsprozess zu stärken.

"Das Ziel von RE ist es, qualitativ gute - nicht perfekte - Anforderungen zu entwickeln und sie in der Umsetzung risiko- und qualitätsorientiert zu verwalten." (Ebert, 2019, S. 33)

Im Endeffekt hilft das Anforderungsmanagement ein erfolgreiches Produkt zu entwickeln,das den Bedürfnissen und Wünschen der Kunden entspricht.Präzisere Anforderungen und Akzeptanzkriterien verhindern Missverständnisse und minimieren den Abstimmungs-Aufwand. Die Erhöhung der Kundenzufriedenheit und der Qualität sind nebst der Kostenreduktion und Durchführung von erfolgreichen Projekten die massgebendsten Ziele des Anforderungsmanagements. Dies kann zum wirtschaftlichen Erfolg eines Unternehmens beitragen.

3.4 Warum braucht es das Anforderungsmanagement?

Jede nicht erhobene oder falsch dokumentierte Anforderung führt zu Fehlern oder Mängeln beim Ergebnis und werden meist erst am Ende eines Abnahmeverfahrens,z. B. durch einen Review oder sogar erst nach Produktivsetzung festgestellt. Wie auch schon in Kapitel 2.2 erwähnt führt dies zu hohen Folgekosten, je später diese entdeckt werden.Die Qualität der Anforderungen und somit letztlich des Produktes / Systems wird durch das Anforderungsmanagement erhöht.Dies führt in Projekten zu kürzeren Testdurchläufen, weniger Fehlern, weniger Change-Requests (Änderungsanträge) und weniger Korrekturzyklen. Zusammengefasst erkennt man eine klare Reduzierung der Kosten. Gem. Literatur wird davon ausgegangen, dass man 5- 10 % des Aufwandes in Requirements Engineering investiert, dafür aber eine Reduktion des Gesamtaufwandes um 20 - 40 % erreicht.

Der Entwicklungszyklus und die Produktivität im Zuge der Umsetzung wird durch gutes Anforderungsmanagement gesteigert und die Durchlaufzeit der Projektewird verkürzt. Dies sind gem. Ebert (2019) weitere Punkte, die unter anderem die Kosten reduzieren.

Kennzeichen eines mangelhaften Anforderungsmanagements:

- Anforderungen sind komplett undokumentiert
- Anforderungen sind nicht mit den Stakeholdern abgestimmt
- Keine Nachverfolgung von Anforderungen möglich
- Anforderungen wurden einmal sehr aufwändig erfasst und nie wieder beachtet
- Anforderungen werden nicht verstanden und auch nicht hinterfragt
- Anforderungen werden falsch verstanden und nicht überprüft
- Änderungen von Anforderungen werden nicht dokumentiert
- Anforderungen werden aufgrund von Änderungen inkonsistent
- Anforderungen sind von Spezialisten erfasst worden, welche die Bedürfnisse der Konsumenten nicht kennen
- Die Stakeholder haben ein unterschiedliches Verständnis der Anforderungen
- Anforderungen beschreiben das WIE und nicht das WAS

Um dem entgegen zu wirken, werden klassischerweise in Projekten sogenannte Reviews durchgeführt. Die Projektergebnisse werden auf Form und Inhalt geprüft und bewertet (vgl. Jenny B. 1998, S. 328 ff). Auf das Thema Validierung wird aber noch speziell im Kapitel 3.7 eingegangen.

3.5 Ermittlung und welche Ergebnisse man erwarten kann

In diesem Kapitel wird beschrieben, wie Anforderungen ermittelt werden und welche Ergebnisse erwartet werden können.

Gewöhnlich beginnt alles mit vagen Ideen und Visionen, Absichtsbekundungen, Bedürfnissen und Wünschen.Aus den Bedürfnissen werden die Ziele abgeleitet. Aus den Zielen wird der Umfang bestimmt und daraus die einzelnen Anforderungen definiert. Die nachfolgende Tabelle zeigt die Unterschiede von Problem, Vision, Idee, Bedürfnis, Ziel, Funktionsmerkmal, Anforderung und Rahmenbedingung:

Tabelle 3: Unterschiede Problem zu Anforderung (Quelle: Autor)

Abbildung in dieser Leseprobe nicht enthalten

Wie in jedem Projekt, so müssen auch beim Requirements Engineering zum einen die Stakeholder ermittelt sowie erfasst werden und zum anderen der Systemkontext (In-Scope& Out-of-Scope) betrachtet und definiert werden. Da dies Bestandteile von einem Projektauftrag sind, aber auch in anderen Bereichen ein wichtiges Element wiederspiegeln, wird im weiteren Verlauf der Arbeit weder theoretisch, noch praktisch detaillierter darauf eingegangen.

Ein idealisierter Ablauf einer Verfeinerung von Anforderungen könnte wie folgt dargestellt werden. Dies in Anlehnung an das V-Modell von Boehm sowie andie Spezifikationslevel von Rupp/SOPHISTen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Idealisierter Ablauf (Quelle: Autor)

Rupp/SOPHISTen (2014, S. 39 ff.) haben diese Verfeinerung als Spezifikationslevel für herkömmliche und agile Vorgehen dargestellt. Die meisten Begrifflichkeiten aus dieser Grafik werden in dieser Arbeit aber nicht detaillierter erläutert. Sie soll dem Leser aber einen Überblick geben, bei welchem Vorgehen, in welcher Stufe / Ebene, welche Spezifikationen oder Dokumentationen zum Tragen kommen.

Nachfolgend die Grafik der Spezifikationslevels nach Rupp/SOPHISTen mit den entsprechenden Begrifflichkeiten:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Spezifikationslevels (Quelle: Rupp/SOPHISTen, 2014, S. 39)

Wie schon erwähnt können Anforderungen aus verschiedenen Quellen und Stakeholdern ermittelt werden. Nach Tremp/Ruggiero (2011, S. 61 ff) besteht die Kunst der Anforderungserhebung darin, aus der Vielfalt der Erhebungstechniken diejenigen auszuwählen, die den geringsten Aufwand erzeugen um an das Ziel zu gelangen. Aufgrund der üblichen Restriktionen in einem Projekt (beschränkte Zeit, Ressourcen und Budget) werden weiterhin "weisse Flecken" bestehen bleiben.Anforderungen können auch durch Marktstudien ermittelt werden.

Es gibt gem. Literatur verschiedene Ermittlungstechniken, die wie folgt unterteilt werden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Ermittlungstechniken (Quelle: Autor)

Nachfolgend ist eine tabellarische Auflistung von möglichen Erhebungstechniken gem. verschiedener Literatur aufgeführt,diese wird aber aufgrund der Vielzahl von Techniken nicht vollständig sein:

Tabelle 4: Erhebungstechniken (Quelle: Autor)

Abbildung in dieser Leseprobe nicht enthalten

[...]