Requirements Engineering in kleinen und mittleren Unternehmen. Dringend notwendig oder eher sinnlos und unnötig?

Inhaltsverzeichnis

1. EINLEITUNG
1.1. Ausgangssituation und Problemstellung
1.2. Zielsetzung und Forschungsfragen
1.3. Methodische Vorgehensweise
1.4. Aufbau der Arbeit
1.5. Stand der Literatur

2. THEORIE
2.1. Requirements Engineering
2.1.1. Definitionen
2.1.2. Sichten auf Requirements/Anforderungen
2.1.3. Arten von Requirements/Anforderungen
2.1.4. Methoden und Werkzeuge
2.1.5. Chancen und Risiken
2.2. Kleine und Mittlere Unternehmen
2.2.1. Definition KMU
2.2.2. Überblick laut Definition
2.2.3. Gliederung ÖNACE vs. WKO
2.2.4. Arbeitsplätze
2.2.5. Wirtschaftskraft
2.2.6. EU-Vergleich
2.3. Konsequenzen
2.3.1. Gewährleistung
2.3.2. Garantie
2.3.3. Schadenersatz
2.3.4. Zusammenfassung

3. PRAXIS
3.1. Qualitative Experten-Analyse Requirements Engineering
3.2. Die Auswirkungen von Requirements Engineering auf den wirtschaftlichen Erfolg eines Unternehmens
3.3. Zusammenfassung der Auswertungsergebnisse

4. CONCLUSIO

LITERATURVERZEICHNIS

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ANHANG

Danksagung

An dieser Stelle bedanke ich mich bei allen Personen, die durch ihre Mitwirkung und Unterstützung die Erstellung meiner Masterarbeit zum Thema Requirements Engineering ermöglicht haben.

Ein besonderer Dank gilt meinem Betreuer des FH Campus Wien, Hr. Dipl.-Ing. Herbert Paulis, für seine Unterstützung bei der Ausarbeitung des von mir gewählten Themas.

Besonders möchte ich mich auch bei meiner Familie, all meinen Freunden für ihre motivierenden Worte und Unterstützung während der Studienzeit bedanken. Ohne diesem Support wäre ich alleine nicht ans Ziel gekommen.

Ein weiterer besonderer Dank gilt allen 20 Spielern und 6Trainingsgästen des P.A.C. Wien, die wöchentlich für einen wunderbaren Ausgleich zum Arbeits- und Studienalltag gesorgt haben.

Ein ganz besonderer Dank gilt meiner Frau, Daniela Feigl, die mich auf meinem Weg bestärkt und unterstützt hat. Ohne ihrer Unterstützung wären zwei berufsbegleitende Studien in Folge nicht möglich gewesen.

Reinhard Feigl

PS: Sollte ich jemanden vergessen haben… DANKE! ;-)

Kurzfassung

Diese Arbeit beschäftigt sich mit der Bedeutung des Requirements Engineering in kleinen und mittleren Unternehmen der heimischen IT-Branche.

Das Hauptproblem ist der Mangel an vorliegenden Informationen in wie weit Requirements Engineering in den Unternehmen eingesetzt wird.

Das Potential von Requirements Engineering den wirtschaftlichen Erfolg zu erhöhen wird von kleinen und mittleren Unternehmen oft unterschätzt.

Der erste Teil der Masterarbeit gibt einen Überblick über das Thema Requirements Engineering inklusive der Prozesse, Methoden, Werkzeuge, Chancen und Risiken. Der zweite Teil setzt sich mit einer qualitativen Analyse von zwölf geführten Interviews auseinander.

Nur zwei der befragten Unternehmen setzen Requirements Engineering ernsthaft ein, weitere sechs Unternehmen halten sich an das Grundgerüst des Requirements Engineering und vier Unternehmen verzichten auf den Einsatz von Requirements Engineering.

Zusammengefasst ist zu sagen, dass großes Potential am heimischen Markt für externe Berater vorhanden ist kleinen und mittleren Unternehmen zu helfen die Vorteile von Requirements Engineering zu erkennen und einzusetzen.

Abstract

The master thesis deals with the meaningfulness of Requirements Engineering in small and medium-sized companies in the IT sector.

The main problem is the lack of existing information about the usage of Requirements Engineering in these kind of companies.

The potential of Requirements Engineering to increase the economic success of a company is underrated by small and medium-sized companies.

The first part of the master thesis explains the Requirements Engineering with all its processes, methods, tools, chances and risks to have an overview of Requirements Engineering. The second part is a qualitative survey of twelve small and medium-sized IT companies.

Only two companies implemented Requirements Engineering companywide, six companies deal with Requirements Engineering Basics and four companies don’t use the techniques of Requirements Engineering.

This master thesis´ conclusion indicates that there is a lack of Requirements Engineering consultants to help small and medium-sized companies in the IT sector to recognize the advantages.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Schlüsselbegriffe

Anforderungsmanagement

Anforderung

Chance

IEEE 610.12-1990

Konsequenzen

Requirements

Requirements Engineering

Risiko

Risikomanagement

Kleine und mittlere Unternehmen

Wirtschaftlicher Erfolg

1. Einleitung

1.1. Ausgangssituation und Problemstellung

„Kleine und mittlere Unternehmen (KMU) bilden das Rückgrat der Unternehmenslandschaft und haben damit wesentlichen Einfluss auf die Wirtschaftsstruktur. Dies gilt für die gesamte Europäische Union und im Besonderen für Österreich, wo der unternehmerische Mittelstand besonders ausgeprägt ist.“

In Österreich gibt es laut einer statistischen Erhebung der Wirtschafts-kammer Österreich (WKO) 313.729 kleine und mittlere Unternehmen, welche rund 1,9 Millionen Personen beschäftigen. Die Definition von KMUs ist europaweit durch eine Empfehlung der Europäischen Kommission wie folgt geregelt:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: Übersicht Definition KMU und der Unterklassen

Aufgrund der wirtschaftlichen Bedeutung von KMUs in Österreich stellt sich daher die Frage, welche Möglichkeiten KMUs haben, um ihren wirtschaftlichen Erfolg zu sichern. Betrachtet man dies aus verschiedenen Perspektiven, so könnte eine Möglichkeit in der detaillierten Anforderungsanalyse der Aufträge liegen. Dies führt zu einer detaillierten Betrachtung des Themas Requirements Engineering.

In einer Welt, die sich immer schneller dreht, gilt es auch für KMUs, nicht nur die monetären, sondern auch die zeitlichen Ressourcen vernünftig zu planen und zu nutzen. Ein altes Sprichwort sagt schon „Zeit ist Geld“, die-se abgedroschene Floskel bringt aber viel Wahres mit sich. Aus diesem Grund gilt es herauszufinden ob, vernünftiges Requirements Engineering nicht nur Zeit kostet, sondern auch Geld einbringt. Oft werden Aufträge nicht vernünftig verifiziert, Rahmenbedingungen nicht klar dargestellt bzw. der Rahmen nicht ausreichend definiert. Dies führt zu Unzufriedenheit, Mehraufwänden, Zeit- und Geldverlust und endet oft in Streitigkeiten, die vor Gericht geklärt werden müssen.

Es stellt sich auch die Frage, ob KMUs bewusst ist, welche Möglichkeiten und Chancen Requirements Engineering mit sich bringt und ob vielleicht trotz diesem Wissen bewusst darauf verzichtet wird. Jede Branche wird für sich ihre eigenen Anforderungen haben und daher wird es keine pauschale Aussage geben. Aufgrund der Tatsache, dass diese Arbeit im Zuge des Masterstudiums Technisches Management geschrieben wird, gilt es die Fragen für technisch orientierte Unternehmen zu beantworten.

1.2. Zielsetzung und Forschungsfragen

Das Ziel ist es mittels einer literarischen und einer qualitativen Studie herauszufinden, ob Requirements Engineering für kleine und mittlere Unternehmen in Österreich sinnvoll oder doch eher sinnlos ist. Dies führt zu einer umfassenden Studie der Thematik Requirements Engineering und der Bedeutung der KMU für die österreichische Wirtschaft. Anhand dieser Themen wurden folgende Forschungsfragen formuliert:

Forschungsfrage 1:

Welche Chancen und Risiken bringt der Einsatz von Requirements Engineering für KMU der heimischen IT-Branche mit sich?

Forschungsfrage 2:

Kann Requirements Engineering positiven Einfluss auf den wirtschaftlichen Erfolg von heimischen IT Unternehmen haben?

Forschungsfrage 3:

Ist den KMU der heimischen IT-Branche bewusst welche Chancen und Risiken der Einsatz bzw. der Nicht-Einsatz von Requirements Engineering mit sich bringt?

1.3. Methodische Vorgehensweise

Der Theorieteil der Masterarbeit wird mittels primären Literaturquellen und für die heimische Wirtschaft bedeutende Internetquellen erarbeitet. Es wird darauf geachtet, dass die Literatur facheinschlägig und auf aktuellem Stand ist. Im Bestfall werden hier auch renommierte Lehrbücher für diese Thematik herangezogen. Die Internetquellen werden nach ihrer Bedeutung und Seriosität ausgewählt. Beispiele hierfür sind die Internetpräsenz des Bundesministerium für Wissenschaft, Forschung und Wirtschaft, der Statistik Austria und der Wirtschaftskammer Österreich.

Für den Praxisteil kommt die qualitative Forschung zur Anwendung. Zu einem wird ein Experteninterview durchgeführt um eine allgemeine Sicht zu der gewählten Thematik zu erhalten und zum anderen werden Vertreter 12 verschiedener IT-Unternehmen der österreichischen Wirtschaft befragt. Die Befragung deckt das persönliche Wissen, den Einsatz von Requirements Engineering und die Kenntnisse über Methoden und Werkzeuge ab. Ebenfalls wird eine Einschätzung über die Beeinflussung des wirtschaftlichen Erfolgs mit den Interviewpartner erörtert. Diese Auswertung soll einen Überblick über die Branche bringen.

1.4. Aufbau der Arbeit

Die vorliegende Masterarbeit ist in zwei Teile unterteilt. Im ersten Teil, dem Theorieteil, wird das Thema Requirements Engineering im Allgemeinen, Methoden, Vorgehensweisen und Werkzeuge erläutert. Das zweite Thema behandelt die kleinen und mittleren Unternehmen der heimischen Wirtschaft. Diese Kapitel gibt einen Überblick über Definitionen, die Bedeutung von KMU für die heimische Wirtschaft und liefert einen direkten EU-Vergleich. Das dritte Unterkapitel beschäftigt sich mit möglichen rechtlichen Konsequenzen, die Unternehmen treffen können. Hier werden weitere Argumente für den Einsatz von Requirements Engineering geliefert.

Der Praxisteil ist untergliedert in eine allgemeine Branchenanalyse des auserwählten Experten, einer Beschreibung der möglichen Auswirkungen von Requirements Engineering auf den wirtschaftlichen Erfolg eines Unternehmens und der Auswertung der Befragungen von 12 Vertretern der heimischen IT-Branche.

Zum Abschluss werden die wichtigsten Ergebnisse der Arbeit zusammengefasst um die formulierten Forschungsfragen zu beantworten.

1.5. Stand der Literatur

In der vorliegenden Masterthesis werden nur Primärquellen verwendet. Das älteste Werk stammt aus dem Jahr 2005. Die Grundlagen des als heute bekannten Requirements Engineerings gehen bis in die frühen 90er Jahre zurück. Aus diesem Grund ist der Stand der verwendeten Literatur als aktuell zu betrachten.

Die Werke von Ebert, C „Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten“ und Pohl, K „Requirements Engineering. Grundlagen, Prinzipien, Techniken“ bieten einen Überblick über die Basisinformationen über die Methoden, Techniken und Werkzeuge des Requirements Engineerings.

Mit Hilfe von aktuellen Internetquellen wie dem Bundesministerium für Wissenschaft, Forschung und Wirtschaft, der KMU Forschung, Statistik Austria und der Wirtschaftskammer Österreich wird die Bedeutung der kleinen und mittleren Unternehmen der österreichischen Wirtschaft erarbeitet.

2. Theorie

Dieses Kapitel beschäftigt sich mit der theoretischen Auseinandersetzung der Themen Requirements Engineering, kleine und mittlere Unternehmen in der österreichischen marktorientierten Wirtschaft und den möglichen Konsequenzen beim Verzicht von Requirements Engineering. Dieser Teil ist eine rein literarische Recherche und soll dem Leser ein Basiswissen für die Erarbeitung des Praxisteils vermitteln.

2.1. Requirements Engineering

Das Thema Requirements Engineering bildet den Kern der vorliegenden Masterthesis. Die Ausarbeitung des Themas ist essentiell notwendig um fundierte Vorkenntnisse für den Praxisteils aufzubauen. In den nachfolgenden Unterkapiteln werden die Begriffe Requirements und Requirements Engineering erläutert. Wie funktioniert Requirements Engineering, welche Chancen und Risiken bringt es mit sich. Welche Methoden und Werkzeuge stehen zur Verfügung und wie kann es eingesetzt werden.

2.1.1. Definitionen

2.1.1.1. Requirements/Anforderungen

Im ersten Schritt ist der Begriff „Requirements“ oder auch im deutschen „Anforderungen“ zu definieren. Hierfür gibt es verschiedenste Definitionen und Beschreibungen, jedoch haben alle eine sehr ähnliche Aussage. In dieser Arbeit gilt die Definition des Institute of Electrical and Electronics Engineers, kurz genannt IEEE. Im Standard der IEEE 610.12- 1990 sind Anforderungen wie folgt definiert:

„Eine Eigenschaft oder Bedingung, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.

Eine Eigenschaft oder Bedingung, die ein System oder eine Systemkomponente erfüllen muss, um einen Vertrag, eine Norm oder andere, formelle vorgegebene Dokumente zu erfüllen.

Eine dokumentierte Repräsentation einer Eigenschaft oder Bedingung wie in den ersten beiden Punkten beschrieben.“ [Ebe14]

Zusammengefasst beschreibt es die vom Kunden erwarteten Anforderung, Bedingungen, Eigenschaften, Nutzen und Ziele eines Produktes. Ein Produkt kann in diesem Fall eine Softwarelösung, ein komplexes IT-System, eine Hardwarekomponente, eine Dienstleistung und noch vieles mehr sein.

2.1.1.2. Requirements Engineering / Anforderungsmanagement

Der Begriff Requirements ist für diese Arbeit wie in Kapitel 2.1.1.1. definiert und führt daher zur nächsten wichtigen Definition, die des Requirements Engineerings, dieser Arbeit. Aufgrund der Vielzahl an Möglichkeiten in der Literatur gilt für die vorliegende Arbeit folgende Definition für den Begriff „Requirements Engineering“:

„Requirements Engineering ist das disziplinierte und systematische Vorgehen zur Ermittlung, Dokumentation, Analyse, Prüfung, Abstimmung und Verwaltung von Anforderungen unter kundenorientierten, technischen und wirtschaftlichen Vorgaben“. [Ebe14]

Das bedeutet, Requirements Engineering verfolgt das 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. Die Risiken der Umsetzung als auch die Qualität der Realisierung werden genau betrachtet. Im Endeffekt hilft Requirements Engineering ein erfolgreiches Produkt zu entwickeln welches den Anforderungen der Kunden entspricht und nicht ein Zufallsprodukt welches einer Ansammlung von Funktionen gleicht. (vgl. [Ebe14])

Die Zielsetzung des Requirements Engineerings ist sehr breit gefächert, da die Sichtweise auf die Ziele eine entscheidende Rolle spielt. Im Folgenden eine Auflistung von Zielen aus den verschiedenen Perspektiven:

„Kunden und Benutzern geht es um die Erfüllung ihrer Wünsche bezüglich Funktion und Leistung.

Das Management ist an Quantifizierung und Überwachung der Randbedingungen für die Systemerstellung interessiert.

Der Systemanalytiker oder Anforderungsingenieur, als Ersteller der Anforderungsdefinition, möchte ein leicht prüf- und änderbares Dokument.

Entwurfsspezialisten und Systementwickler erwarten präzise Vorgaben zur Erstellung der Funktionen unter den angegebenen Beschränkungen.

Und schließlich erhoffen sich Systemtester Unterstützung für den (späteren) Nachweis, dass alle Anforderungen erfüllt sind.“ [PAR10]

In der Literatur wird Requirements Engineering meist in Bezug auf die Softwaretechnik erläutert. Requirements Engineering ist jedoch weitaus vielfältiger und kann daher nicht nur in den Bereichen der Ingenieurswissenschaften eingesetzt werden.

2.1.2. Sichten auf Requirements/Anforderungen

Die Anforderung dient der Konzeption der gewünschten Lösung, jedoch spielt hier die Sicht auf die Anforderung eine wesentliche Rolle. Die Anforderungen werden hierzu in Markt-, Produkt,- und Komponentenanforderungen untergliedert.

2.1.2.1. Marktanforderungen

Die gestellten Anforderungen werden aus der Sicht des Kunden beschrieben und werden daher in der Praxis auch als Kundenanforderungen bezeichnet. Es wird beschrieben warum ein Projekt bzw. ein Produkt umgesetzt wird. Gemessen wird das erzielte Ergebnis rein an den Wahrnehmungen und der Zufriedenheit des Kunden. Diese Anforderungen werden in dem dafür vorgesehenen Lastenheft dokumentiert.

Auch Änderungen an bestehenden Produkten aber auch in laufenden Projekten können von Marktanforderungen ausgelöst werden. Hierfür ist sehr viel Abstimmungsaufwand und die Einschätzung des tatsächlichen Nutzens wichtig. Eine Änderung, die als notwendig erscheint, kann sehr schnell zu einem Flop werden. Nicht jede Funktionalität, die zum Beispiel ein Smartphone bietet, ist für jeden Nutzer von bedeutsamer Notwendigkeit geprägt. Zusammengefasst versuchen Marktanforderungen Wünsche zu erfüllen und erlebbar zu machen. Es sollen viele Wünsche zusammengetragen werden, diese aus den verschiedensten Perspektiven betrachtet werden und realisierbare Anforderungen für den Zielmarkt geschaffen werden. (vgl. [Ebe14])

2.1.2.2. Produktanforderungen:

Produktanforderungen werden nicht wie Marktanforderungen aus der Sicht des Kunden beschrieben, sondern aus Sicht der späteren Realisierung. Das bedeutet es wird der Raum für die Lösung festgelegt. Diese Anforderungen werden auch als Eigenschaften oder Systemanforderung bezeichnet und beschreiben daher was der Kunde mit dem Produkt machen kann. Daher sollten alle Produktanforderungen in einem Pflichtenheft festgehalten werden. (vgl. [Ebe14])

2.1.2.3. Komponentenanforderungen:

Wie der Name schon sagt, werden hier die Anforderungen an einzelne Komponenten beschrieben. Sie beschreiben wie die die Produktanforderungen durch die einzelnen Komponenten realisiert werden können. Durch die Gliederung in Komponentenanforderungen werden die Produktanforderungen in kleinere Teile untergliedert. Dies liefert mehr Transparenz und die Anforderungen können wesentlich leichter abgearbeitet werden. Aus diesem Grund werden Komponentenanforderungen wie Produktanforderungen im Pflichtenheft dokumentiert.

Zusammengefasst ist festzuhalten, dass alle drei Kategorien gemeinsam auftreten und wirklich nur die Rolle des Betrachters ausschlaggebend ist. (vgl. [Ebe14])

2.1.3. Arten von Requirements/Anforderungen

Studiert man die Theorie des Requirements Engineerings so stößt man in der Literatur auf folgende Untergliederung von Anforderungen. Es wird unterschieden in funktionale Anforderungen, Qualitätsanforderungen und Rahmenbedingungen.

2.1.3.1. Funktionale Anforderungen

Eine funktionale Anforderung beschreibt wie der Name schon sagt eine Funktion eines betrachteten Systems oder einer einzelnen Komponente des Systems. Das bedeutet eine detaillierte Beschreibung wie das Produkt reagieren soll. Anhand dieser Anforderung von bestimmten Abläufen der Funktionen können Szenarien gebildet oder Use Cases abgebildet werden die dem Nutzer zur Verfügung gestellt werden sollen. Dies wiederum ermöglicht es Testszenarien für das Produkt zu entwickeln welche in späterer Folge zur Anwendung kommen können. Als simples Beispiel kann eine Datenumwandlung herangezogen werden. Es ist definiert wie die Eingabeparameter, die Ausgabeparameter und der Algorithmus dazwischen zu funktionieren haben. An Hand dieser Parameter ist es sehr leicht möglich mit Hilfe von Tests die Funktionalität zu überprüfen und redundante Tests durchzuführen. Funktionale Anforderungen werden daher auch in drei Perspektiven untergliedert. Es handelt sich um die Funktionsperspektive, Datenperspektive und die Verhaltensperspektive. (vgl. [Poh08])

2.1.3.2. Qualitätsanforderungen

Qualitätsanforderungen, in der Literatur auch als nicht funktionale Anforderungen bekannt, beschreiben die gewünschten Qualitätsmerkmale des Nutzers, des geplanten Produkts oder Systems. Aus diesem Grund sind die Anforderungen an die Qualität des Produkts oder des Systems ebenfalls so detailliert wie möglich zu beschreiben wie die funktionalen Anforderungen. Dies führt dazu den Interpretationsspielraum so gering wie möglich zu halten. Dies ist bei Qualitätsmerkmalen wesentlich schwieriger und nimmt daher auch mehr Zeit in Anspruch. Jedoch erhöht dies die Nachverfolgbarkeit und erleichtert die Überprüfung nach Herstellung des Produkts oder Systems. Beispiele für Qualitätsanforderungen sind zum Beispiel

- Performancewerte, zB wie schnell ist ein Request abzuarbeiten?
- Sicherheitsaspekte, zB welcher Standard ist zu etablieren?
- Skalierbarkeit, zB welche Methoden zur Skalierbarkeit werden eingesetzt?
- und weitere (vgl. [Ebe14])

2.1.3.3. Rahmenbedingungen

Die dritte Kategorie neben den funktionalen Anforderungen und den Qualitätsanforderungen sind die definierten bzw. gegebenen Rahmenbedingungen um ein Produkt oder System zu realisieren. Hier werden organisatorische und technische Anforderungen dokumentiert welche die Art und Weise der Realisierung einschränken. Diese Einschränkungen können zum Beispiel durch etablierte Geschäftsprozesse, vorhandene Infrastruktur, die gelebte Organisationsform, der gegebenen Marktsituation, und ähnlichen ergeben. (vgl. [Ebe14])

Auch gesetzliche Vorgaben oder marktübliche Standards können Einschränkungen ergeben bzw. zu funktionalen Anforderungen oder Qualitätsanforderungen werden. Die Dokumentation der Rahmenbedingungen ist essentiell wichtig, da diese aufgrund der Restriktionen die Realisierung der gestellten Anforderungen verhindern. Somit müssen andere Wege für die Realisierung gefunden werden oder das Vorhaben muss abgebrochen werden. (vgl. [Poh08])

2.1.4. Methoden und Werkzeuge

2.1.4.1. Anforderungen ermitteln

Zweck und Ziel

Anforderungen werden ermittelt um eine gemeinsame Sicht aller beteiligten Gruppen zu schaffen. Werden Ziele klar definiert und von allen akzeptiert ist die Wahrscheinlichkeit eines Projekterfolges bzw. einer Produktumsetzung wesentlich höher. Wird auf die Definition von gemeinsamen Zielen verzichtet so läuft man in Gefahr Ressourcen zu verschwenden. Entweder werden so viele Features aufgenommen, so dass der Zeitrahmen nicht eingehalten werden kann oder der finanzielle Rahmen wird gesprengt und diese zusätzlichen Leistungen werden vom Kunden nicht bezahlt. Als weitere Möglichkeit kann ein Produkt entstehen welches weder den Vorstellungen noch den Qualitätsansprüchen des Kunden entspricht. Aus diesem Grund ist es sehr wichtig gemeinsame Ziele zu definieren und hier so wenig wie möglich Interpretationsspielraum für alle beteiligten Gruppen zu ermöglichen. Um dieser Problematik entgegen zu wirken sind die Anforderungen nach Markt und Kunden zu richten. Eine Anforderungsermittlung liefert folgende Ergebnisse:

- „Vision des Projekts oder des Produkts
- Bedürfnisse und Erwartungen an das Projekt
- Kontext und Randbedingungen
- Dokumentierte Anforderungen als gemeinsame Basis für Marketing, Entwicklung und Kunden“ [Ebe14]

Damit die aufgelisteten Ergebnisse erarbeitet werden können, sind für die Anforderungsermittlung folgende Einflüsse prägend und sollten nicht außer Acht gelassen werden. Im Zuge der Ermittlung der Anforderungen stellen sich sehr viele Fragen.

Kunden

Welche Ziele verfolgt mein Kunde? Wie sieht die Umgebung des Kunden aus? Haben wir alle Basisinformationen über unseren Kunden? Wie sieht die Wettbewerbssituation unseres Kunden aus? Wie sieht es mit der Zufriedenheit unseres Kunden aus? Etc.

Strategie

Wie sieht unsere eigene Unternehmensstrategie aus? Wie ist unser Unternehmen am Markt positioniert? Wie haben sich unsere Umsätze entwickelt? Etc.

Wettbewerb

Liegen aktuelle Wettbewerbsdaten vor? Wie hoch sind unsere Marktanteile? Wie entwickelt sich der Markt in dem wir uns befinden? Etc.

Produkte

Wie alt ist die Produktidee? Wie hoch ist der Innovationsgrad? Wie hoch sind die Fehlerkosten? Wie hoch ist die Verfügbarkeit? Welchen Nutzen hat das Produkt? Wie sind die Kosten des bisherigen Produkts strukturiert? Können die Kosten reduziert werden? Ist eine interne Systemverbesserung notwendig? Wie hoch ist der Wartungsanteil? Etc.

Technologien

Wie aktuell sind die verwendeten Technologien? Können diese erneuert bzw. abgelöst werden? Gibt es neue Forschungsergebnisse? Gibt es neue Produkte am Markt? Wurden neue Standards entwickelt? Gibt es neue Lieferanten am Markt? Sind neue Werkzeuge am Markt verfügbar? Etc.

Verfügbare Ressourcen

Haben wir genug Zeit? Haben wir die Fähigkeiten zur Realisierung im Unternehmen? Sind genug Mitarbeiter verfügbar? Sind die benötigten Technologien und Komponenten ausrechend im Unternehmen vorhanden? Etc.

Die Anforderungsermittlung ist dann abgeschlossen, wenn alle beteiligten Stakeholder die wesentlichen Anforderungen und Ziele verstanden und akzeptiert haben. (vgl. [Ebe14])

Bedürfnisse verstehen und Ziele vereinbaren

Die Praxis zeigt, dass realistische, klar definierte und vereinbarte Ziele erreicht werden. In den meisten Fällen werden die Anforderungen meist nur gesammelt und dann auf die Entwicklung einer Gesamtanforderung die der Vision des Kunden entspricht, verzichtet. Aus diesem Grund entstehen viele Missverständnisse und diese führen zu hohen und ungeplanten Nacharbeiten, Zusatzkosten, die der Kunde nicht tragen möchte bzw. wird. Es entstehen oft Verzögerungen und Terminkollisionen. Es werden auch zusätzliche Funktionen entwickelt, die in die Anforderungen hinein interpretiert werden. Zu keinem Zeitpunkt gibt es eine Gesamtsicht auf die Entwicklung. In diesem Fall spricht man von einer „Feature-orientierten“ Entwicklung.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Anforderungsermittlung traditionell [Ebe14]

Aus den bereits beschriebenen Gründen sollte daher ein Umdenken in der Ermittlung der Anforderungen stattfinden. Beachtet man die beschrieben Einflüsse so können Ziele abgeleitet und Produktvisionen gemeinsam mit dem Kunden entwickelt werden. Aus der Vision und den Zielen werden konkrete Anforderungen entwickelt, modelliert, spezifiziert und analysiert. Die benötigten Funktionen werden vor Beginn der Entwicklung priorisiert und erst danach systematisch umgesetzt. In diesem Fall gibt es eine Gesamtsicht auf die Entwicklung und die Wahrscheinlichkeit für unerwartete hohe Nacharbeiten wird dadurch sehr gering gehalten.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Anforderungsermittlung zielorientiert [Ebe14]

Im Zuge des Anforderungsmanagements ist es sinnvoll Ziele nicht zu hart bzw. zu konkret zu formulieren. Aufgrund einer Vielzahl von Zielen ist eine Priorisierung notwendig. Sind die Ziele zu hart formuliert, ist es oft schwierig ein Produkt zur Abnahme zu bringen. Eine bessere Variante ist es hierfür Zielbereiche zu definieren. Diese Zielbereiche spiegeln die Sicht der Benutzer wieder. Jedes Ziel wird mit den drei Werten Hervorragend (optimales Ziel), Ziel (wünschenswert), Minimum (minimal Ziel).

Funktionen bzw. Anforderungen, die niedrig priorisiert wurden und auf der Liste ewig als niedrig priorisiert gelten und nie umgesetzt werden, sollten nach einiger Zeit wieder verworfen werden um Platz für neue innovativere Ideen zu machen.

Das Lastenheft sollte daher gemeinsam mit dem Kunden abgestimmt werden, da dieses meist als Vertragsgrundlage gilt. Stehen Anforderungen im Vertrag die der Kunde nicht benötigt, kann dies frühzeitig erkannt und abgeändert werden. Zusammengefasst gilt, wird der Kunde verstanden und fühlt sich wohl so werden für beide akzeptable Ziele festgelegt und machbare Anforderungen abgeleitet. (vgl. [Ebe14])

Stakeholder managen

Steakholder, auch Anspruchsträger genannt, sind natürliche, juristische und abstrakte Personen - Repräsentanten einer ganzen Gruppe von Beteiligten - die Einfluss auf die Umsetzung der Lösung haben. Aus diesem Grund können diese nicht außer Acht gelassen werden und müssen gemanagt werden. Im Zuge eines Projekts oder der Entwicklung gibt es verschiedene Rollen. Im Requirements Engineering wird versucht die Rollen „Auftraggeber“ und „Lieferant“ klar zu unterscheiden um zu verstehen was genau die Problematik und was die dazugehörige Lösung ist. Eine einzige Rolle, die versucht diese beiden Rollen zu vereinigen, wird aufgrund eines massiven Interessenkonflikts scheitern. Wichtig ist, auch die andere Seite zu verstehen um die beste mögliche Lösung zu erarbeiten.

Um die Stakeholder managen zu können, ist eine Stakeholder-Analyse hilfreich. Mit Hilfe dieser Analyse werden Anspruchsträger identifiziert und deren Interessen bewertet. Dies schafft einen Überblick über alle Interessen und schafft die Möglichkeit Risiken und Chancen zu identifizieren und Konflikte im Vorfeld zu vermeiden. Nicht alle Stakeholder haben die gleichen Interessen, jedoch können diese unterschiedlichen Einfluss auf das Projekt bzw. die Umsetzung des Produkts haben. Folgende acht Schritte zur Analyse der Steakholder gelten nicht als Gesetzt, jedoch verfolgen diese einen „Best-Practice“- Ansatz.

Schritt Eins - Identifizieren

Im ersten Schritt werden die möglichen Stakeholder identifiziert. Um hier eine vollständige Auflistung zu erhalten, ist die Sicht von außen auf das Projekt wichtig. Die bereits erhobenen Ziele der jeweiligen Anspruchsträger können hier helfen. Auf Kundenseite spielt die Rolle des Steakholders ebenfalls eine wichtige Rolle, da Benutzer eine andere Sicht auf die Dinge haben als die Controller.

Schritt Zwei - Beziehungen

In diesem Schritt werden die Beziehungen der Stakeholder untereinander und zum Projekt dokumentiert. Hier zeigt sich schnell wer hat auf wen Einfluss, wie ist jemand gegenüber dem Projekt eingestellt oder wer hat welche Rolle. Die wichtigste Frage ist jedoch, wer hat großes Interesse am Erfolg oder gar am Scheitern des Projekts. Oft ist es schwer diese Beziehungen und Rollen genau festzuhalten, aber nach und nach wird sich der Kreis schließen und die Informationen und Beobachtungen können nachträglich dokumentiert werden.

Schritt Drei - Priorisierung

Im dritten Schritt werden die erfassten Beziehungen priorisiert. Die für das Projekt wichtigsten Beziehungen sollten herausgearbeitet werden. Diese können wie bereits erwähnt positiv als auch negativ sein. Anhand der Priorisierung werden einige Gruppen in der weiteren Betrachtung rausfallen, jedoch ist hier Vorsicht geboten, da schnell ein Key- Player, welcher noch nicht als solcher zu erkennen ist, ausgeschlossen wird. Festgelegt wird auch welche Rollen und Personen sollen für welche Zwecke genutzt werden.

Schritt Vier - Konfliktpotenzial

Als nächstes werden die möglichen Konfliktpotenziale der jeweiligen Anspruchsträger analysiert. Es gilt festzuhalten welche Stakeholder Konflikte untereinander austragen könnten. Hier sollte man auch an die jeweiligen internen Organisationen denken, da oft eine Organisationseinheit vom Versagen der anderen profitiert. Hier ist es wichtig mit dem Projektteam verschiedenste Szenarien zu entwickeln um ein Gefühl für den jeweiligen Steakholder zu entwickeln.

Schritt Fünf - Win-win

Im fünften Schritt der Steakholder-Analyse werden so genannte Win-win-Möglichkeiten für den jeweiligen Anspruchsträger identifiziert und auch die damit hereingehenden Risiken. Dies soll helfen die Stakeholder mit an Bord des Projekts zu holen. Sie sollen sich eingebunden, stark und als Entscheidungsträger fühlen. Es ist sehr aufwendig alle Stakeholder bei Laune zu halten, daher sollte man niemals versuchen die Stakeholder gegeneinander auszuspielen. Dies kann oft das Gegenteil bewirken und die Konflikte ufern aus.

Schritt Sechs - Kommunikation

In diesem Schritt ist es besonders wichtig mit den relevanten Stakeholdern zu kommunizieren. Nicht jeder Anspruchsträger benötigt die gleiche Information. Daher ist es notwendig auf jeden der einzelnen Steakholder individuell einzugehen. Dieses Vorgehen wird helfen die Win-win-Möglichkeiten zu realisieren und gegebenenfalls können durch die stärkere Einbindung der Steakholder die Risiken eines Konflikts gemindert werden.

Schritt Sieben - Perspektiven

Im siebenten Schritt der Stakeholder-Analyse werden die Perspektiven der jeweiligen Stakeholder betrachtet. Die unterschiedlichen Anspruchsträger haben die verschiedensten Sichtweisen wie das Produkt genutzt werden soll. Aus diesem Grund ist es immer wichtig die unterschiedlichen Perspektiven der Steakholder einzunehmen um zu verstehen was damit bezweckt werden soll. Mit dieser Methode sollen Hauptnutzen und Nebeneffekte des Produkts herausgearbeitet werden können. Das Ergebnis liefert einen guten Input für die Festlegung der Anforderungen.

Schritt Acht - Wiederholung

Der letzte und achte Schritt ist wichtig für die Konstanz der Entwicklung. Die StakeholderAnalyse soll in regelmäßigen Abständen wiederholt werden. Der Status des Projekts ändert sich laufend und die Anspruchsträger auch. Es gilt festzustellen welcher Steakholder hat neue Perspektiven, gibt es neue Anspruchsträger im Projekt oder gibt es sogar geänderte oder neue Anforderungen für die entstehende Lösung.

Zusammengefasst ist die Steakholder-Analyse ein brauchbares Werkzeug, jedoch nur dann wenn die Analyse regelmäßig wiederholt wird. Eine initiale Analyse bringt sicher einen ersten guten Input, jedoch wird die Qualität der Anforderungen über die Dauer des Projekts nicht erhöht. (vgl. [Ebe14])

Um ein besseres Gespür für die Motive und Perspektiven der relevanten Steakholder des Projekts zu bekommen, ist eine Betrachtung der jeweiligen Rollen notwendig. Jede dem Projekt zugeordnete Person nimmt eine, kann aber auch mehrere Rollen zeitgleich wahrnehmen. Die Wahrnehmung mehrerer Rollen wird zu einem Zielkonflikt führen. Ein Projektleiter hat ganz klar andere Interessen als der Produktmanager oder der verantwortliche für den Betrieb. Der Projektmanager hat Interesse an einem positiven Projektabschluss, während der Vertrieb primäres Interesse an einer langfristigen positiven Beziehung zu dem Kunden hat. Es können nicht alle Rollen die jemals vergeben wurden, aufgelistet werden, aber es werden die am häufigsten verwendeten Rollen in Projekten, die Requirements Engineering betreiben, aufgelistet und kurz beschrieben.

Auftraggeber

Der Auftraggeber oder auch als Kunde bekannt, hat die Anforderungen an die Umsetzung einer Lösung und gibt bestimmte Rahmenbedingungen vor. In den meisten Fällen ist der Kunde einer externen Organisationseinheit zugeordnet. Aus diesem Grund wird das Verhältnis zwischen Auftraggeber und Auftragnehmer im Normalfall vertraglich geregelt. Diese Rolle kann sehr viel Konfliktpotenzial mitbringen, da ein Auftraggeber mehrere Perspektiven einnehmen und die Stimmung sehr schnell schwanken kann.

Benutzer

Die Benutzer stehen in den meisten Fällen auf der Kundenseite. Sie betreiben und nutzen das gekaufte System. Manche Systeme können vom Kunden weiterentwickelt oder einfach nur eingekauft werden. Man darf jedoch nicht den Fehler machen und Benutzer und Auftraggeber in einen Topf, den „Kundentopf“, zu werfen. Die Benutzer haben ganz andere Sichten auf die Lösung, da Funktionalität wesentlich wichtiger ist als der Kostenfaktor. Während der Auftraggeber doch eher die monetäre Seite der Umsetzung betrachten wird.

Projektmanager

Der Projektmanager trägt die gesamtheitliche Verantwortung für das Projekt. Er trägt die verschiedenen Anforderungen zusammen und sorgt für den reibungslosen Ablauf. Er versucht Aufwände, Qualität und Zeit im Einklang miteinander zu halten. Außerdem vertritt er das Projekt nach außen und gilt in den meisten Fällen als Single Point of Contact. An Hand dieser Funktion werden auf Projektdiskontinuitäten aufgezeigt, Lösungen erarbeitet und an den Auftraggeber bzw. den Projektlenkungsausschuss zur Entscheidung vorgelegt.

Produktmanager

Der Produktmanager ist der Produktverantwortliche während des gesamten Produktlebenszyklus. Dies bedeutet, er folgt den etablierten ProduktmanagementGeschäftsprozessen und verantwortet den gesamten Business Case und die dafür vorgesehenen operative Umsetzung. Der Produktmanager hat Interesse an einem langfristigen Produkterfolg und nicht an einem schnellen Projekterfolg. Dies kann zu Konflikten innerhalb des Projekts führen.

Marketing

Der Bereich des Marketings sorgt für die bestmögliche Vermarktung des Produkts. Es wird enger Kontakt zu bestehenden und möglichen Kunden gepflegt um deren aktuelle Bedürfnisse zu verstehen und zu befriedigen. Oft müssen Märkte und Bedürfnisse erst geschaffen werden, dies ist die größte Herausforderung für die Marketingabteilung. Hier entstehen oftmals Konflikte bei der Festlegung der Anforderungen, da nicht immer aus einer reinen Kundensicht gehandelt wird.

Vertrieb

Der Vertrieb ist die direkte Schnittstelle zu den Kunden. Er schließt Verträge zwischen Auftraggeber und Lieferanten ab. Da der Vertrieb an seinen Umsätzen gemessen wird, ist dieser gegenüber dem Kunden sehr flexibel um einen Vertragsabschluss zu erzielen. Dies führt oft zu Zusagen, die in weiterer Folge nicht gehalten werden und löst entweder einen internen Konflikt zwischen Projekt und dem Vertrieb oder dem Projekt und dem Kunden aus. Hier ist große Vorsicht geboten. Für das Requirements Engineering gelten Marketing und Vertrieb jedoch als gute Quelle für Anforderungen und Änderungen.

Kernteam

Das Kernteam ist gemeinsam mit dem Projektmanager für die Steuerung des Projekts verantwortlich. Das Team prüft regelmäßig gemeinsam den Fortschritt, arbeitet Diskontinuitäten auf und prüft regelmäßig die Risiken. Alle Vertreter des Kernteams haben ein großes Interesse an einem erfolgreichen Projektabschluss. Eine weitere wichtige Aufgabe des Teams ist das Changemanagement, auch Änderungsmanagement genannt. Da das Kernteam das Projekt steuert und dadurch alle Facetten kennt, ist die Bewertung von Änderungen im Gesamtkontext des Projekts wesentlich einfacher und zielführender. In großen Projekten empfiehlt es sich die Rolle des Changemanagers zu vergeben.

Requirements-Ingenieur

Der Requirements-Ingenieur, auch bekannt als Systemanalytiker oder Business-Analyst, stellt das Bindeglied zwischen den einzelnen Key-Playern dar. Er verantwortet die Ermittlung und Dokumentation der Anforderungen seitens des Kunden und der daraus abgeleiteten Anforderungen für die Umsetzung. Er gilt als neutrale Stelle.

Entwickler

Die Entwickler sind jene Gruppe welche mit der Umsetzung der vereinbarten Anforderungen beauftragt wird. Sie neigen dazu oft eigene Ideen und Anforderungen umzusetzen. Als goldene Regel gilt zuerst die vertraglich vereinbarten Anforderungen umsetzen und dann über zusätzliche Ideen mit dem Projektleiter sprechen. Dieser ist dann gefragt eine Entscheidung herbei zu führen. Anforderungen sollten vom Entwickler nicht bewertet, interpretiert oder geändert werden. Kann eine Anforderung aufgrund fehlender Details, Informationen oder fehlendem Knowhow nicht umgesetzt werden so ist dies nicht als negativ zu sehen. Erst bei der Umsetzung ist eine bestimmte Granularität der Anforderungen notwendig. In Summe führt dies aber oft zu erhöhtem Konfliktpotenzial.

Qualitätssicherung

Die Qualitätssicherung als neutrale und unabhängige Kontrollinstanz sichert die Erfüllung der gestellten Anforderungen an das Produkt und die Prozesse. Aus Kostengründen wird die Qualitätssicherung meist stichprobenartig durchgeführt und dadurch kann niemals absolute Qualität garantiert werden. Daher ist der Prozess des Testens sehr wichtig, dieser obliegt jedoch dem Requirements-Ingenieur.

Dies ist nur ein Überblick über die wichtigsten in der Praxis verwendeten Rollen. Fast man alle Rollen die in einem Projekt vergeben werden in einer Tabelle zusammen inkl.

Aufgabenbeschreibung, Verantwortung, Kontaktdaten und zusätzlichen Hintergrundinformationen so hat man es als Projektleiter leichter den Überblick zu behalten. Diese Tabelle ist jedoch niemals für das gesamte Projektteam oder die Steakholder selbst gedacht. Sie dient rein als Merkzettel für den Projektleiter. (vgl. [Poh08])

Zehn Schritte Methode

Mit Hilfe dieser Methode werden in zehn aufeinander folgenden Schritten Anforderungen zielorientiert entwickelt.

Schritte Eins - relevante Steakholder

Zuerst ist wie bereits beschrieben eine Steakholder-Analyse durchzuführen. Die wirklich relevanten Steakholder sind vertraglich festzuhalten. Es ist klar zu definieren wer bezahlt das Produkt oder Projekt, wer sind die Kommunikationsschnittstellen und wer darf Anforderungen an das Projekt oder Produkt stellen. Auch die Kommunikationswege und Eskalationswege sollten im Vorhinein klar definiert werden.

Schritt Zwei - die Produktvision

Im zweiten Schritt ist es notwendig zu verstehen was den Kunden bewegt, welche Ziele er erreichen möchte, was dem Kunden wirklich wichtig ist. Die Aussagen des Kunden sind zu hinterfragen um so viele Details wie möglich zu erhalten. Es werden im Zuge der Gespräche viele Ideen genannt, nicht alle werden realisiert aber wichtig ist es alle Ideen zu dokumentieren und später erst zu bewerten. Es geht nicht darum gleich eine Lösung zu entwickeln sondern klare zielorientierte Anforderungen zu definieren. Die Produktvision gilt als die Leitlinie für die Umsetzung der Lösung. Durch die Vision werden einige Anforderungen bereits definiert. Es stellt sich die Frage nach der Zielgruppe, dem Alleinstellungsmerkmal, dem Nutzen, der möglichen Veränderung für die Kunden und wie damit Geld verdient werden wird. Im Wesentlichen werden die gesammelten Ideen und Ziele mit der möglichen Marktpositionierung verknüpft und sollen in zwei bis drei Sätzen den Leser in seinen Bann ziehen. Die Vision steht an oberster Stelle darunter stehen die Ziele und davon werden die Anforderungen abgeleitet.

Schritt Drei - Abstimmung Umfang

Der Zusatznutzen für den Kunden muss klar ersichtlich sein. Daher ist klar herauszuarbeiten welche Änderung das Produkt für den Kunden konkret herbeiführen wird. Funktionen die vom Kunden nicht gewünscht sind oder bei denen der Wert noch unklar ist, sollten an dieser Stelle bereits verworfen werden. Jetzt sollte festgelegt werden wohin die Reise gehen soll. Wichtig ist auch als Auftragnehmer zu sagen welche Rahmenbedingungen benötigt werden. Danach werden die Systemumgebung und der Systemkontext festgelegt. Hier ist zu klären in welcher Umgebung das System eingesetzt wird und was genau Bestandteil des Systems ist und was nicht und was die Schnittstellen des Systems sind. Zusammengefasst bedeutet dies, der Lösungsraum wird gemeinsam mit dem Auftraggeber festgelegt. Der Systemkontext beschreibt die Grenzen der zu entwickelnden Lösung und definiert dadurch die Schnittstellen nach außen. Durch die Definition der Schnittstellen werden auch die Eingangs- und Ausgangsparemeter festgelegt. Nach den ersten drei Schritten wurden bereits einige Ideen gestrichen, die Produktvision wurde entwickelt und der Umfang der Lösung ist ermittelt.

Schritt Vier - methodische Entwicklung

Im vierten Schritt werden die Anforderungen für die spätere Lösung entwickelt und identifiziert. Hier werden bereits funktionale Anforderungen, Qualitätsanforderungen aber auch Rahmenbedingungen festgelegt. Die Struktur der Anforderungen spielt hier noch eine untergeordnete Rolle. Im Vordergrund steht der kreative Austausch und die Entwicklung von Anforderungen unter der Berücksichtigung von verschiedenen Quellen wie Marktstudien, Benutzergruppen, interne Organisationseinheiten, externe Dienstleister, Vertragspartner, uvm. Unbekannte Anforderungen sind schwierig zu ermitteln und können nicht einfach so formuliert werden. Jedoch wären genau diese meist die interessantesten Aspekte, da daraus meist echte Innovationen entstehen. Wichtig ist es auch negative Anforderungen zu formulieren, sprich was das Produkt oder die Lösung nicht können oder berücksichtigen soll. Auch auf diesem Weg ergeben sich neue zielorientierte Anforderungen. Für die Entwicklung der Anforderungen gibt es die verschiedensten Techniken. Die aufgeführten Techniken sind nur ein Auszug und bei weitem keine vollständige Auflistung:

Marktanalyse: Marktstudien, Fragebögen, Interviews, Auswertungen von Messebesuchen, Kundenworkshops

Kreativitätstechniken: Brainstorming, Rollenspiele, Workshops, Gruppenarbeiten, Fokusgruppen

Experimente: Prototyping, Simulation, Ablaufmodell, Benutzerschnittstelle, Konzepttests Kognitive Verfahren: Protokollanalyse aus Gesprächen und Workshops, Verhaltensbewertung von Benutzern, Benutzbarkeitsanalyse

Kontextbewertung: Demografische Analysen (Marktverhalten, Kaufverhalten, Vorlieben,…) ethnografische Analysen (kulturelle Besonderheiten und Verhalten), Farben und Symbolik

Schritt Fünf - Vertiefungsworkshops

Die Workshops dienen der Vertiefung der Anforderungen gemeinsam mit den einzelnen Steakholdern. Bereits formulierte Anforderungen werden nochmal diskutiert, ergänzt oder doch verworfen. Es werden auch neue Anforderungen entwickelt. Der Vorteil bei den Workshops ist es, das alles offen angesprochen werden kann und Konflikte an Ort und Stelle ausgetragen werden können. Dies mindert das Konfliktpotential während dem Projekt. Sollten die Teilnehmer diese Chance auslassen so werden die Konflikte später ausgetragen. Aus diesem Grund sollte darauf geachtet werden, dass die Teilnehmer offen diskutieren können. Ein möglicher Ablauf für Vertiefungsworkshops kann wie folgt aussehen:

Vorbereitung: Es gilt die bisherigen Ergebnisse zu verstehen und Einzelgespräche mit den einzelnen Stakeholdern zu führen. Sollte dies aus Zeitgründen nicht möglich sein, so sollten zumindest die Gespräche mit den kritischen Anspruchsträgern geführt werden.

Warm-up: Kommunikation der Ziele und der Zeitplanung des Workshops an die Teilnehmer. Sollten sich einige Teilnehmer nicht kennen ist eine Vorstellungsrunde empfehlenswert.

Rollen klären: Mit einfachen Übungen oder Fragestellungen ergibt sich die Verteilung der Rollen sehr rasch.

Prozess klären: In dieser Phase des Workshops wird der Prozess zur Zielerreichung definiert.

Umsetzung: Die Teilnehmer arbeiten in Gruppen oder gemeinsam die Aufgaben ab, diskutieren Zwischenergebnisse und lösen Probleme am Weg zur Zielfindung.

Zusammenfassung: Die Ergebnisse werden zusammengefasst und dokumentiert Schritt Sechs - Dokumentation

Die Anforderungen sind systematisch zu dokumentieren und werden mit einem Nummerischen Code für eine bessere Nachverfolgung versehen. Eine detaillierte Beschreibung und Zusammenhänge dürfen nicht fehlen. Durch die vergebenen Codes können später bei Änderungen als Referenz die vergebenen Codes angegeben werden für eine vollständige Nachvollziehbarkeit.

Schritt Sieben - Analyse

Im siebenten Schritt werden die Anforderungen auf Vollständigkeit, Widerspruchsfreiheit, Validierbarkeit, Erreichbarkeit, Konsistenz und Verständlichkeit geprüft. Diese Prüfung ist notwendig um zu analysieren ob alle Anforderung im Gesamtkontext realisierbar sind oder untereinander oder mit Rahmenbedingungen konkurrieren. Die Wertschöpfung der Anforderung ist ebenfalls zu beachten, da diese die Motivation des Kunden beeinflussen um die Lösung anzuschaffen. Diese Aspekte zu überprüfen ist empfehlenswert, da zu diesem Zeitpunkt meist die Vertragsverhandlungen laufen. Sind Anforderungen erst mal vertraglich fixiert und dem Kunden zugesichert so ist es sehr schwierig diese im Laufe des Projektes wegzudiskutieren. Dies kann mitunter zu großen Konflikten mit den relevanten Anspruchsträgern führen. Mehr zum Thema Konsequenzen im Kapitel 2.3.

Schritt Acht - Konfliktlösungen

Immer wieder taucht das Wort Konflikte im Zuge der Ermittlung von zielorientierten Anforderungen auf. Genau hier liegt das Problem. Jeder Steakholder vertritt seine eigenen Ansichten und verfolgt seine eigenen Ziele. Aus diesem Grund ist hier große Vorsicht geboten. Auch wie bereits erwähnte vertraglich festgehaltene Anforderungen die nicht realisierbar sind, werden im Laufe der Zeit zu einem großen Problem. Es muss ein Mehrwert für beide Seiten geschaffen werden, so können Konflikte eingedämmt oder sogar vermieden werden.

Schritt Neun - Priorisierung

In diesem Schritt geht es um die Priorisierung der ermittelten Requirements. Im besten Fall kann die Priorisierung direkt mit dem Kunden ausverhandelt werden. Ist dies nicht möglich so sollten die Requirements die erfolgsentscheidend sind hoch priorisiert werden. Wichtig ist es die erstellte Prioritätenliste gemeinsam mit dem Kunden abzustimmen, da der Kunde andere Geschäftsziele und Interessen verfolgt und daher eine andere Meinung haben wird welche Anforderungen wichtig sind und welche nicht. Hierfür können verschiedenste Methoden verwendet werden. Eine Möglichkeit ist das Kano-Modell, welches ursprünglich für die Messung der Kundenzufriedenheit entwickelt wurde. Da die dafür heranzuziehenden Parameter passend sind, ist dies im Requirements Engineering eine zulässige Möglichkeit um die Priorisierung der ermittelten Anforderungen durchzuführen. (vgl. [Ebe14])

Das Modell wurde in den 80er Jahren von Professor Noriaki Kano entwickelt um die Kundenzufriedenheit anhand der Klassifizierung der drei Produkteigenschaften, Basismerkmale (Grundforderungen), Leistungsmerkmale (Leistungsforderungen) und Begeisterungsmerkmale (Begeisterungseigenschaften) zu messen.

Basismerkmale sind jene Produkteigenschaften die der Kunde als selbstverständlich empfindet ohne diese explizit einzufordern. Leistungsmerkmale sind vom Kunden genannte Produkteigenschaften und bestimmen dadurch auch den Preis. Begeisterungsmerkmale sind jene Merkmale welche vom Kunden nicht erwartet oder gefordert werden, den Kunden jedoch begeistern und dessen Motivation das Produkt anzuschaffen steigern. (vgl. [PPM15])

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Anforderungs- und Bedürfnisbewertung [Ebe14]

Die drei genannten Merkmale werden verschiedenen Perspektiven (Rollen) zugeordnet. Durch diese Gruppierung wird schnell ersichtlich welche Anforderungen umzusetzen sind und auch den größten Kaufanreiz bieten. (vgl. [Ebe14])

Schritt Zehn - Entscheidung

Der letzte Schritt dient der Entscheidungsfindung. Die dokumentierten und priorisierten Anforderungen werden noch einmal intern abgestimmt und es wird entschieden wie mit diesen Anforderungen umgegangen wird. Die Anforderung wird entweder abgelehnt und muss neu mit den relevanten Steakholdern formuliert werden, sie ist unvollständig und ist zu ergänzen oder wird akzeptiert. Aus diesem Grund ist der gesamt Prozess ein iterativer Prozess, da jeder Schritt mehrmals durchgeführt wird, bis die Anforderungen so formuliert sind, dass beide Seiten einer Vertragsunterzeichnung zu stimmen. Ein guter Rat ist im Vorfeld ein Changemanagement für nicht stabile Anforderungen aufzugleisen und die Projektlaufzeit so kurz wie möglich zu halten. Dies reduziert eine Änderungsflut während des laufenden Projekts.

Zusammengefasst gilt für diesen Prozess das gleiche Grundprinzip wie bei der Steakholder-Analyse. Nur wenn der Prozess immer wieder durchgeführt wird, ist dieser auch zielführend. Der beste skizzierte und definierte Prozess wird für die Zielerreichung nichts bringen, wenn dieser in der Organisation nicht gelebt wird. (vgl. [Ebe14])

2.1.4.2. Anforderungen dokumentieren

Die Dokumentation der Anforderungen wurde in dem vorhergehenden Kapitel bereits angerissen. Dieses Kapitel soll die Notwendigkeit einer strukturierten und vollständigen Dokumentation der formulierten Anforderungen unterstreichen und einen Überblick über die Methoden an sich geben.

Zweck und Ziel

Das klare Ziel ist es, vollständig dokumentierte Anforderung vorliegen zu haben die keinen Interpretationsspielraum ermöglichen. Requirements, die klar beschreiben was benötigt wird, können auch richtig umgesetzt werden. Aus diesem Grund sollten Spezifikationen für die Umsetzung geschrieben werden. Die Spezifikationen sind zu versionieren und zentral für alle am Projekt Beteiligten abzulegen, so das jederzeit sichergestellt werden kann, dass alle denselben Weg gehen. Jede Änderung, Ergänzung oder Streichung einer Anforderung ist in den Anforderungsspezifikationen nachzuziehen und als neue Version abzulegen, da in Projekten immer die aktuellste Version Gültigkeit hat und so wird gewährleistet das jeder die Änderung kommuniziert bekommt. Es sollte einem bewusst sein, dass jeder einzelne Schritt im Requirements Engineering die Bearbeitung eines Dokuments bedeutet. (vgl. [Poh08])

Lasten- und Pflichtenheft

Im Requirements Engineering werden wie bereits beschrieben Bedürfnisse auf Lösungen abgebildet. Dies führt zu einer Trennung in eine Anforderungsspezifikation und in eine Lösungsspezifikation. Die Perspektive der Anforderungsspezifikation, auch Lastenheft genannt, ist die dokumentierte Sicht des Kunden und liegt daher in seiner Verantwortung und ist Teil des schriftlich vereinbarten Vertrages. Es wird detailliert beschrieben was gemacht werden soll und wofür es dienen wird. Die Lösungsspezifikation, auch besser bekannt als Pflichtenheft, deckt die Perspektive des Auftragnehmers ab. In diesem Dokument wird beschrieben wie etwas umgesetzt werden soll. Aus diesem Grund ist das Pflichtenheft die Basis für alle Schritte in der Entwicklungsphase. In beiden Dokumenten werden inhaltliche Überlappungen vorzufinden sein, jedoch ist dies kaum zu vermeiden. Klar formulierte und vollständige Spezifikationen bieten einige Vorteile. Folgende drei Vorteile sind herauszustreichen:

Einheitliche Basis: Eine gemeinsame Sicht der Dinge führt zu einem gemeinsamen Weg. So wissen Projektmanager, Produktmanager, Vertrieb, Entwickler und Tester was wie umzusetzen ist. Mit Hilfe der gemeinsamen Basis werden Inkonsistenzen und unnötige Nacharbeiten vermieden werden.

Vertragsbasis: Beide Seiten haben eine gemeinsame Sicht der Dinge und können sich auf die Spezifikationen berufen. Ist die Anforderungsspezifikation Bestandteil des Vertrages so können diese als Meilensteine herangezogen werden. Die Entwicklung der Lösung wird für die Beteiligten greifbarer und wesentlich messbarer. Ein detaillierter Projektfortschritt kann nicht geliefert werden, aber eine Abschätzung für die Fertigstellung der einzelnen Komponenten kann realistischer eingeschätzt werden. Es wird die Möglichkeit geboten die Spezifikation für die Verrechnung der zu liefernden Lösung heranzuziehen.

Testbarkeit: Mittels konkret beschriebener Anforderungen und einer detailliert beschriebenen Lösung können direkt Testfälle abgeleitet werden. Es steht so ganz klar fest welche Funktion wird wie getestet und welche Ergebnisse sind zu erwarten.

Vorlagen

Vorlagen sind sehr hilfreich bei der Dokumentation der Requirements. Der Text ist kurz und klar zu formulieren, damit die Anforderung ganz klar verständlich ist und keinen Interpretationsspielraum zulässt. Es empfiehlt sich der Verzicht oder sparsame Einsatz von Hilfsverben wie „soll“, „kann“ oder „muss“.

Die Anforderungen werden in einer Spezifikation strukturiert um sie modellieren, analysieren ändern und verfolgen zu können. Mit Hilfe von passender Werkzeugunterstützung und einer klaren Struktur können umfangreiche Spezifikationen leichter gehandelt werden. Best Practice Ansätze können helfen die Struktur und die Definition der Anforderungen zu vereinfachen. Ein gutes Beispiel hierfür ist der Aufbau von Anforderungen nach dem Bereits genannten IEEE-Standard. Mit Hilfe dieser Vorlage können die einzelnen notwendigen Attribute befüllt werden. (vgl. [Ebe14])

Es ist ratsam einmal die Zeit und die Ressourcen in die Erstellung einer Vorlage für ein Unternehmen zu investieren. Der einmalige Aufwand rentiert sich bereits ab der Erstellung der zweiten Spezifikation, da hier bereits sehr viel Zeit eingespart werden kann. Eine Excel- Tabelle, oder ein anderes derartiges Programm, ist hierfür völlig ausreichend. Es müssen daher keine teuren Tools angeschafft werden. Die Scheue den Initialaufwand zu investieren ist daher abzulegen. Die Vorlagen sind regelmäßig einem Review zu unterziehen und gegebenenfalls anzupassen, da sich hier Veränderungen auftun können. (vgl. [Poh08])

Struktur und Lesbarkeit

Eine klare Struktur der dokumentierten Anforderungen schafft für alle am Projekt beteiligten Mitarbeiter erhöhte Lesbarkeit. Die erhöhte Lesbarkeit vereinfacht die Modellierung und Analyse der Requirements. Hierzu mehr im nächsten Kapitel. Folgende Tipps können bei der Organisation der Struktur berücksichtigt werden:

- „Klare Nummerierung der Anforderungen
- Änderungen und Beziehungen ständig pflegen und nicht abwarten
- Strukturierung anhand von Klassen und Gruppen
- Segmentierung gemäß Quellen, Funktionen
- Abhängigkeitsbeziehungen zu funktionalen Beschreibungen (z.B. Implementierungssicht, SW-Klassen, Komponenten)
- Attributierung zum Filtern, Sortieren, etc.
- Metainformationen anhand definierter Begriffe aus dem Glossar!“ [Ebe14]

Die einfachste Form für die Lesbarkeit einer Spezifikation ist die natürliche Sprache. Sie ist leicht zu schreiben und von allen zu verstehen. Dies soll aber nicht bedeuten die Spezifikation in einem unstrukturierten Text niederzuschreiben. Die Vorlage wie in Angang (Anhang 1 - Aufbau von Anforderungen nach IEEE-Standards) ersichtlich, zeigt wie diese Struktur aussehen kann.

Die Verwendung eines Glossars ermöglicht die Dokumentation für Begriffe, Datenfelder und der Beschreibung der Verwendung von Daten. Es wird ständig erweitert und wachsen, da immer wieder Begriffe ins Spiel gebracht werden die für alle einheitlich zu dokumentieren sind. Dies führt zu gemeinsamen Verständnis und einem gemeinsamen Sprachgebrauch. Dadurch werden Missverständnisse und Ungenauigkeiten weitgehendst vermieden. Es empfiehlt sich eine zentrale Ablage und Verwaltung und ist projektbegleitend zu pflegen. Die Einträge sind in einer einheitlichen Struktur zu tätigen, die Verantwortlichkeit für die Eintragungen ist festzulegen und es ist für alle im Projekt verbindlich zu verwenden. Mit Hilfe dieser Regeln macht der Einsatz eines Glossars auf jeden Fall Sinn. (vgl. [Ebe14])

2.1.4.3. Anforderungen modellieren und analysieren Zweck und Ziel

Eine Systemanalyse schafft ein Gesamtbild über das System selbst und seine Grenzen zur Umgebung in der das System eingesetzt werden soll. Für die Entwicklung einer den Anforderungen entsprechenden Lösung ist die Beschreibung der Funktionen, der Zustände, der Interaktionen, des Informationsaustauschs und der Schnittstellen notwendig. Die Modellierung und Analyse basiert auf der Beschreibung der Lösung, dem bereits beschriebenem Pflichtenheft. Das Requirements Engineering bietet verschiedenste Methoden um die Anforderungen zu analysieren und zu modellieren. Die geplante Lösung wird hinsichtlich Korrektheit, möglicher Inkonsistenzen, Validierbarkeit und Vollständigkeit geprüft. Eine vernünftige Analyse kann jedoch nur dann durchgeführt werden, wenn die Anforderungen klar definiert sind. Im Zuge der Analyse ist es vernünftig bereits ein Änderungsmanagement im Einsatz zu haben. Die Praxis zeigt, dass durch die Analysen viele Änderungen hervorgebracht werden und diese nachvollziehbar zu steuern sind. Die Beschreibung oder Modellierung der Anforderungen zeigt nicht nur Probleme auf und führt zu Änderungen der Lösung sondern ist auch Auslöser für die Formulierung neuer Requirements. (vgl. [Rup09])

Modelle und Methoden

Analysemethoden definieren wie bei der Entwicklung eines Analysemodells vorgegangen wird. Die Methode gibt Regeln und Richtlinien vor um das Modell zu beschreiben. Analysemethoden werden für Anforderungsmodelle, welche den Problemraum erläutern, und für die notwendigen Lösungsmodelle angewandt. Das Anforderungsmodell entwickelt sich in den frühen Projektphasen und mit Konkretisierung der Anforderungen wird dieses auch immer stabiler. Mit Hilfe des Anforderungsmodells kann eine erste Aufwandsschätzung für die Umsetzung der Lösung erstellt werden. In weiterer Folge wird das Anforderungsmodell als Basis für die Erstellung eines guten Lösungsmodells verwendet. Mit Hilfe des Lösungsmodells können Entwurfsentscheidungen abgewogen werden und bereits vorhandene Komponenten auf ihre Wiederverwendbarkeit geprüft werden. Ein wesentlicher Bestandteil des Lösungsmodells ist die Kostenanalyse und damit auch Teil des Vertrages.

Die in der Analysephase entwickelte Lösung zeigt normalerweise die drei Perspektiven, Strukturperspektive, Funktionsperspektive und Verhaltensperspektive, auf.

Strukturperspektive: Die Strukturperspektive zeigt welche Struktur das System aufweisen muss um die gewünschten Anforderungen zu erfüllen. Es werden Kommunikationswege und Interaktionen innerhalb des Systems beschrieben. In diesem Zusammenhang werden Qualitätsanforderungen an das Gesamtsystem entwickelt. Für die Beschreibung der Datenperspektive eignet sich unter anderem ein Klassendiagramm der Modellierungssprache UML.

Funktionsperspektive: Diese Perspektive beschreibt welche Funktionen das System für die Umsetzung der Anforderung zur Verfügung stellen muss. Der Fokus liegt hierbei auf den funktionalen Anforderungen und der Art und Weise wie sich das System verhält. Daraus entstehen Anwendungsfälle, Datenflussdiagramme und Aktivitätendiagramme. Es beschreibt quasi die Sicht des Benutzers auf die Funktionalität des Systems.

Verhaltensperspektive: Es wird das Soll-Verhalten des Systems beschrieben. Zustandsorientiert werden die Reaktionen auf Ereignisse und Bedingungen dokumentiert, so kann jederzeit nachvollzogen werden wie das System reagieren muss. Für die Dokumentation dieser Perspektive eignen sich am besten Zustandsübergangsmodelle.

Aufgrund der Abhängigkeiten der drei Perspektiven können diese nicht sequentiell abgearbeitet werden. Eine parallele Bearbeitung ist zwingend notwendig.

Eine zusammengefasste Auflistung der Analysemethoden befindet sich unter Anhang 2 - Analysemethoden und die zugehörigen Modelle.

Keine der aufgelisteten Methoden gilt als die optimalste Methode, jedoch ist jede Methode besser als ein unkontrolliertes drauf los entwickeln. Durch jede der drei genannten Methoden wird man gezwungen, systematisch und strukturiert vorzugehen und es werden wesentlich bessere Ansätze entwickelt. In einer frühen Phase entsteht bereits Transparenz und Flüchtigkeitsfehler werden massiv reduziert. (vgl. [Rup09])

Modellierung

Die Modelle beschreiben die Kommunikation und nicht die konkrete Implementierung. Folgende Kriterien sind von einem guten Modell zu erfüllen:

- „Konkret und verständlich
- Vollständig und eindeutig
- Konsistent und widerspruchsfrei
- Minimal, also nicht überladen mit Details
- Änderbar und wartbar
- Nutzenorientiert“ [Ebe14]

Für die Modellierung von Requirements gibt es unterschiedlichste Notationen. Diese kommen abhängig von den bestehenden Anforderungen zum Einsatz. Für die Modellierung von Geschäftsprozessen kommt die Notation BPMN (Business Process Model and Notation) zum Einsatz. Im Falle eines Softwaresystems wird UML (Unified Modeling Language) eingesetzt. Die dritte Möglichkeit kommt aus der Systemtechnik. Bei einem Software-Hard-System verwendet man SysML (Systems Modeling Language). Alle drei Modellierungssprachen sind international vereinheitlicht und von der OMG (Object Management Group) standardisiert.

Mit Hilfe der Notationen lassen sich komplexe Zusammenhänge grafisch darstellen. Die Palette reicht von Diagrammen über Szenarien bis hin zu Use Cases. Durch die Visualisierung der Einheiten und Beziehungen wird ein gemeinsames und verständliches Bild geschaffen. UML bietet dem Modellierer beispielsweise 13 verschiedene Diagrammtypen und SysML erweiterter UML um den Diagrammtyp Anforderungen.

UML Diagramme können in zwei verschiedene Typen, Strukturen und Verhalten eingeteilt werden. Diese sind für drei verschiedene Phasen, Anforderungen, Analyse und Entwurf, im Projekt vorgesehen:

[...]