Anforderungsmanagement

Inhalt

1 Systematisches Anforderungsmanagement – ein Ansatz mit enormem Potential
1.1 Motivation
1.2 Situationsanalyse
1.3 Zielsetzung und Konzeption dieser Arbeit

2 Definition von Anforderung und Anforderungsmanagement
2.1 Der Anforderungsbegriff
2.2 Anforderungsmanagement

3 Ziele des Anforderungsmanagements

4 Klassifizierung von Anforderungen
4.1 Klassische Sichtweise
4.1.1 Funktionale Anforderungen
4.1.2 Nichtfunktionale Anforderungen
4.1.2.1 (Besondere) Qualitätsanforderungen
4.1.2.1.1 Interoperabilität
4.1.2.1.2 Sicherheit
4.1.2.1.3 Bedienbarkeit
4.1.2.1.4 Zuverlässigkeit
4.1.2.1.5 Verfügbarkeit
4.1.2.1.6 Änderbarkeit
4.1.2.2 Leistungsanforderungen
4.1.2.3 Restriktionen/Rahmenbedingungen
4.2 Ansatz nach Pohl
4.3 Anforderungen nach Kano

5 Anforderungsqualität
5.1 Qualitätskriterien für einzelne Anforderungen
5.2 Qualitätskriterien für Anforderungsdokumente

6 Haupttätigkeiten im Anforderungsmanagement
6.1 Steuerungstätigkeiten
6.1.1 Umsetzungs(-prozess-)management
6.1.2 Änderungsmanagement
6.1.3 Risikomanagement
6.2 Operative Tätigkeiten
6.2.1 Anforderungen erheben, analysieren und konsolidieren
6.2.1.1 Anforderungen erheben
6.2.1.2 Sprachliche Analyse von Anforderungen
6.2.1.2.1 Tilgung
6.2.1.2.2 Generalisierung
6.2.1.2.3 Verzerrung
6.2.1.3 Entwicklung innovativer Ideen
6.2.1.4 Auswirkungsanalyse
6.2.1.5 Anforderungen konsolidieren
6.2.1.6 Anforderungen dokumentieren
6.2.1.6.1 Natürlichsprachliche Dokumentation
6.2.1.6.2 Modellbasierte Dokumentation
6.2.1.7 Anforderungen qualitätssichern
6.2.1.7.1 Qualitätssicherung von Anforderungsdokumenten
6.2.1.7.2 Abnahmekriterien
6.2.1.8 Anforderungen verwalten
6.2.1.8.1 Nachverfolgbarkeit
6.2.1.8.2 Wiederverwendung

7 Anforderungen im Kontext von Vorgehensmodellen
7.1 Monumentale vs. agile Prozess-Modelle
7.1.1 Monumentale Prozessmodelle
7.1.2 Agile Prozessmodelle
7.2 Vor- und Nachteile schwer- bzw. leichtgewichtiger Prozessmodelle

8 Erfolgsfaktoren im Anforderungsmanagement
8.1 Kundenbindungsintensität
8.2 Qualität der Kommunikation im Team

9 Anforderungsmanagement im Kontext methodischer Qualitätssicherung
9.1 Capability Maturity Model Integration als Qualitätsmanagementmodell
9.2 Kombination der Qualitätsmethode Quality Function Deployment mit dem Anforderungsmanagement
9.3 Metriken im Anforderungsmanagement

10 Fazit

Abkürzungsverzeichnis

Tabellenverzeichnis

Glossar

Literatur

1 Systematisches Anforderungsmanagement – ein Ansatz mit enormem Potential

1.1 Motivation

Die Fähigkeit, schnell und effektiv auf wechselnde Anforderungen und neue Chancen in einem Marktumfeld wachsender Komplexität und zunehmender Dynamik zu reagieren, wird immer mehr zur zentralen Herausforderung moderner Unternehmen. Der intelligente Umgang mit den Ressourcen ist längst eine ökonomische Notwendigkeit. Zugleich ist die konsequente Umsetzung der Kundenanforderungen erfolgsentscheidend.

In diesem Spannungsfeld stellt systematisches Anforderungsmanagement einen Ansatz dar, der enormes Potential aufweist, nämlich die Differenzierung im Wettbewerb durch Vorteile in den Dimensionen Zeit, Qualität und Kosten.

1.2 Situationsanalyse

Besonders Großunternehmen sehen sich Herausforderungen gegenüber wie:

- stärkere Kundenorientierung,
- steigende Bedeutung softwareintensiver Systeme,
- steigende Komplexität,
- ständig steigende Anzahl von Stakeholdern,
- stetige Zunahme des Zeit- und Kostendrucks,
- zunehmender Verknüpfungsgrad von Software und Systemen,
- zunehmende Vernetzung der IT-Systeme mit denen von Partnern oder Kunden,
- gesetzliche Vorgaben,
- Erfordernis einer immer flexibleren Unterstützung der Geschäftsprozesse,
- Umstrukturierungen der IT-Organisation.

Ein zentrales Problemfeld stellen in vielen Unternehmen historisch gewachsene, starre Anwendungssilos dar. Diese wurden in der Vergangenheit für den Einsatz in einer stabilen, gleichbleibenden Umgebung erstellt. Unflexible Geschäftsprozesse richteten sich nicht selten nach der IT. Aus diesen Wurzeln hat sich eine vollkommen konträre Philosophie entwickelt. Heute wird eine anpassungsfähige Ausrichtung der IT an die geschäftsrelevanten Aufgaben angestrebt, um nicht zu sagen verlangt. Die fachliche Organisation der Anwendungslandschaft steht dabei im Vordergrund, wobei die Anwendungsarchitektur der Geschäftsarchitektur folgt und nicht umgekehrt. In diesem Zusammenhang hat das Thema Service Orientierte Architekturen (SOA) nicht an Aktualität verloren, weil viele Unternehmen inzwischen feststellen mussten, dass sie aufgrund ihrer starren IT-Infrastruktur so stark in ihrer Flexibilität eingeschränkt sind, dass sie dadurch an Wettbewerbsfähigkeit einbüßen. Änderungen, die sich beispielsweise durch ökonomische Einflüsse, dynamische Umfeldentwicklungen und/oder fachliche Anforderungen ergeben, müssen innerhalb kurzer Zeit umgesetzt werden können. Die Etablierung einer SOA ist jedoch mehr als nur die Entwicklung einzelner Services. SOA-Umgebungen benötigen die Unterstützung des gesamten Software Development Lifecycle (SDLC).

Eine Schlüsselrolle nimmt hier das Anforderungsmanagement in der Analysephase ein. Insbesondere bei einem hohen Verknüpfungsgrad sind die Auswirkungen von Änderungen sorgfältig zu analysieren. Werden Abhängigkeiten identifiziert, so geht mit dem Änderungsaufwand ein Koordinationsaufwand einher.

Nicht nur die gestiegene Komplexität spricht für einen veränderten Umgang mit Anforderungen, sondern auch die neuen Rahmenbedingungen, wie z.B. ggf. die Kommunikation über eine größere Distanz. Ein weiteres großes Problemfeld in diesem Zusammenhang stellt die Modifikation der Organisationsstrukturen in der IT dar. Diese geht häufig mit einem Verlust an Kommunikation zwischen Fachbereich und IT einher, weil sich deren Geschäftsbeziehungen verändern. Durch eine zunehmende Formalisierung wird die Kommunikation erschwert. Dies wiederum kann die Komplexität erhöhen. Zudem sollen die Steuerbarkeit der IT-Dienstleistungen verbessert und deren Leistungsfähigkeit gesteigert werden. „Unternehmensintern erbrachte IT-Serviceleistungen stehen auf dem Prüfstand. Sie werden zunehmend unter Kostenaspekten betrachtet und auf Transparenz getrimmt.“ [Reic06, S. 1]

Die Konzentration auf das Kerngeschäft ist eine Möglichkeit, durch Spezialisierung die eigene Wettbewerbsfähigkeit zu steigern. Outsourcing und Offshoring sind Themen, die in diesem Zusammenhang kontrovers diskutiert werden. Es ist die zunehmende Tendenz zu beobachten, dass Software nach wie vor im eigenen Unternehmen geplant, beauftragt und überwacht wird, aber keine Entwicklung mehr erfolgt.

Umso mehr ist es von Bedeutung, dass die Anforderungen klar spezifiziert sind.

Desweiteren verläuft diversen Studien zufolge ein großer Teil der Softwareentwicklungs-projekte nicht erfolgreich. Eine Aufstellung über die zu dieser Thematik durchgeführten Studien findet sich in der Arbeit von Buschermöhle et al. (vgl.[Bus+06, S. 15]). Dort werden zudem die jeweils verwendete Forschungsmethode, das Untersuchungssubjekt bzw. -objekt und die ermittelte Erfolgsquote (falls ermittelt) übersichtsartig dargestellt.

Der aktuelle CHAOS Report der Standish Group kommt zu dem Ergebnis, dass weltweitnur 35 Prozentder Softwareprojekte, die in 2006 begonnen wurden, erfolgreich verliefen (vgl. [Rubi07]). Eine ähnliche Studie führte der F&E Bereich Sicherheitskritische Systeme des Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und – Systeme (OFFIS) mit seiner Umfrage SUCCESS (SUCCESS AND FAILUR EOF HARD- AND SOFTWARE PROJECT S) im Rahmen des vom Bundesministerium für Bildung und Forschung geförderten Projektes VSEK (Virtuelles Software-Engineering-Kompetenznetz) in 2005/2006 durch. Ziel war die Identifikation aktueller Erfolgs- und Misserfolgsfaktoren bei der Durchführung von Hard- und Softwareprojekten in Deutschland. Auf Basis der erhobenen Daten von 378 untersuchten Projekten wurde eine Erfolgsrate in Höhe von 50,7 Prozentermittelt (vgl. [Bus+06, S.289]).

Die Studienergebnisse sind zwar, nicht zuletzt aufgrund des unterschiedlichen Studiendesigns, nur beschränkt miteinander vergleichbar, dennoch lassen sie das Optimierungspotential von Softwareentwicklungsprojekten, die nach heutigen Standards abgewickelt werden, erkennen.

Die beschriebene Situation lässt erahnen, dass die zum Teil rasanten Veränderungen im IT-Umfeld einen veränderten Umgang mit Anforderungen erfordern. Die genannten Herausforderungen haben zur Konsequenz, dass kontinuierliches und systematisches Anforderungsmanagement für eine erfolgreiche Produktentwicklung immer mehr an Bedeutung gewinnt.

1.3 Zielsetzung und Konzeption dieser Arbeit

Im Rahmen dieser Arbeit soll beleuchtet werden, welchen Beitrag das Anforderungsmanagement für die Differenzierung eines Unternehmens im Wettbewerb leisten kann.

Die Relevanz des Themas wurde in der Situationsanalyse bereits vorgestellt.

Nach den Erläuterungen zur Zielsetzung und Konzeption dieser Arbeit findet eine Klärung der für diese Arbeit zentralen Begriffe Anforderung und Anforderungsmanagement statt. Darauf aufbauend werden die Ziele des Anforderungsmanagements formuliert. Das 4. Kapitel beschäftigt sich mit der systematischen Klassifizierung von Anforderungen. Nach der Betrachtung der Qualitätskriterien für Anforderungen und Anforderungsdokumente im 5. Kapitel befasst sich das Kapitel 6 mit den Haupttätigkeiten im Anforderungsmanagement.

Im Kapitel 7 werden Anforderungen im Kontext von Vorgehensmodellen beleuchtet.

Um ein Gefühl für die Erfolgsfaktoren im Anforderungsmanagement zu entwickeln, wird auf die kritischen im Kapitel 8 eingegangen.

Anschließend wird das Thema Anforderungsmanagement im Kontext methodischer Qualitätssicherung betrachtet.

Die Arbeit schließt mit einem Fazit.

2 Definition von Anforderung und Anforderungsmanagement

Der Begriff des „Anforderungsmanagements“ bezeichnet ein Forschungsgebiet, das in den letzten Jahren in neueren Publikationen eine zunehmende Bedeutung erfahren hat.

Trotz der mittlerweile großen Anzahl an Veröffentlichungen ist eine einheitliche terminologische Basis nicht sichtbar geworden.

2.1 Der Anforderungsbegriff

Literaturrecherchen fördern zutage, dass es keine allgemein anerkannte Definition davon gibt, was man unter dem Anforderungsbegriff versteht.

Im Standard IEEE 610.12-1990 ist der Begriff Anforderung (engl. requirement) wie folgt definiert:

Eine Anforderung ist:

(1) Eine Bedingung oder Fähigkeit, die von einem Benutzer benötigt wird, um ein Problem zu lösen.
(2) Eine Bedingung oder Fähigkeit, die ein System oder eine Systemkomponente aufweisen muss, um einen Vertrag zu erfüllen oder einem Standard, einer Spezifikation, oder anderen formellen Dokumenten zu genügen.
(3) Eine dokumentierte Darstellung einer Bedingung oder Fähigkeit gemäß (1) oder (2).

(Vgl. [IEEE 610.12-1990], Übersetzung des Autors)

Sommerville und Sawyer definieren den Anforderungsbegriff wie folgt:

Anforderungen werden in den frühen Phasen einer Systementwicklung definiert als eine Spezifikation dessen, was implementiert werden soll. Sie sind Beschreibungen dessen, wie sich das System verhalten soll, Beschreibungen einer Systemeigenschaft oder Qualitätsmerkmale. Sie können eine Auflage im Entwicklungsprozess des Systems darstellen.

(Vgl. [SoSa97, S. 4], Übersetzung des Autors)

Von Grady Booch stammt folgende Definition im Rahmen des Rational Unified Process (RUP):

„Eine Anforderung ist eine Voraussetzung oder eine Fähigkeit, die ein System erfüllen muss.“

[KrBo99, S. 142]

Definition nach Balzert:

"Aussage über eine zu erfüllende qualitative und/oder quantitative Eigenschaften eines Produktes; eine vom Auftraggeber festgelegte Systemspezifikation, um ein System für den Entwickler zu definieren."

[Balz96, S. 111]

Anforderungen (Lastenheft) gem. V-Modell® XT

„Das Produkt Anforderungen (Lastenheft) enthält alle an das zu entwickelnde System identifizierten Anforderungen. Es ist Grundlage für Ausschreibung und Vertragsgestaltung und damit wichtigste Vorgabe für die Angebotserstellung. Das Lastenheft ist Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer. Mit den Anforderungen werden die Rahmenbedingungen für die Entwicklung festgelegt, die dann vom Auftragnehmer in der Gesamtspezifikation (Pflichtenheft) detailliert ausgestaltet werden.“

[KBSt07, S.71]

In der DIN EN ISO 9000 ist der Anforderungsbegriff abstrakt definiert als:

"Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist."

[DIN06]

Von Rupp, Chris / SOPHIST GROUP stammt folgende Definition:

„Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen.“

[Rupp07, S. 13]

Die Synopse zeigt, dass der Begriff der Anforderung unterschiedlich weit gefasst wird und unterschiedliche Aspekte in den Vordergrund gestellt werden.

In der Definition des Instituts der Elektrik- und Elektronik-Ingenieure (vgl. [IEEE 610.12-1990]) fällt auf, dass auf die Wünsche und Ziele der Benutzer an erster Stelle eingegangen wird, bevor die Bedingungen und Fähigkeiten des Systems im zweiten Absatz behandelt werden. Die gewählte Reihenfolge lässt sich dahingehend interpretieren, dass der Erarbeitung kundenorientierter Lösungen ein hoher Stellenwert beigemessen wird. Ferner fällt auf, dass die Definition zwischen nicht dokumentierten und dokumentierten Anforderungen differenziert.

Die systematische Transformation von undokumentierten Anforderungen der Stakeholder in Anforderungsspezifikationen stellt eine Hauptaktivität im Anforderungsmanagementprozess dar.

Balzert (vgl.[Balz96]) stellt in seiner Definition auf die qualitativen und die quantitativen Eigenschaften eines Produktes aus Sicht der Rolle des Auftraggebers ab. Seine Definition zielt auf die Überprüfbarkeit der Anforderungen hinsichtlich der Erfüllung im Hinblick auf die spätere Produkt-Abnahme.

In der Grundlagenbeschreibung des V-Modell XT wird der Anforderungsbegriff doppelt belegt. Anforderungen werden hier zum einen als V-Modell XT-Produkt in Form des Lastenheftes und zum anderen als Rahmenbedingungen für die Entwicklung definiert. Die in Rede stehende Definition fokussiert rechtliche Aspekte (Lastenheft als Grundlage für Ausschreibung und Vertragsgestaltung). Daneben werden zwei Detailierungsgrade der Ausgestaltung von Anforderungen unterschieden, nämlich das Lasten- und das Pflichtenheft. Darüber hinaus werden die Rollen Auftraggeber und Auftragnehmer unterschieden.

In der Norm DIN EN ISO 9000 (vgl. [NORM DIN06]) ist der Anforderungsbegriff sehr allgemein definiert. Sie fasst den Anforderungsbegriff am weitesten. Anforderungen müssen nach dieser Definition nicht notwendigerweise explizit formuliert sein.

Die Definitionen von Grady Booch (vgl. [KrBo99]) sowie von Sommerville und Sawyer (vgl. [SoSa97]) stellen das zu implementierende System in den Vordergrund. Sommerville und Sawyer nehmen explizit eine Einschränkung auf die frühen Phasen einer Systementwicklung vor. Die Definition von Grady Booch wurde im Kontext des RUP formuliert. Der RUP ist ein schwergewichtigerer Softwareentwicklungsprozess. Im RUP wird ebenfalls versucht, den Großteil der Anforderungen möglichst früh festzuschreiben. Sommerville und Sawyer weiten den Begriff Anforderung explizit auf den Entwicklungsprozess aus.

Die Definition von Rupp, Chris / SOPHIST GROUP (vgl. [Rupp07]) bezieht den Entwicklungsprozess ebenfalls ein und darüber hinaus die nachgelagerten Prozesse wie Wartung und Support. Rupp, Chris / SOPHIST GROUP betont, dass ein Produkt und nicht nur ein System als Endergebnis einer Entwicklung erbracht werden muss. „Der Begriff ‚Produkt‘ in der Definition meint jedoch mehr als nur ‚System‘, umfasst Software und Hardware und zum Beispiel auch Abnahmekriterien, Handbücher, Protokolle, Planungsdokumente und so weiter.“ [Rupp07, S. 13]

Diese umfassende Sichtweise wird auch in dieser Arbeit vertreten.

Es sei darauf hingewiesen, dass sich Anforderungen verändern können. Versteegen et al. definieren den Änderungsbegriff als „modifizierten Anforderungswunsch“ (vgl. [Ver+03, S. 5]).

(Neue) Anforderungen entstehen während des gesamten Lebenszyklus eines Systems. Schienmann gibt eine durchschnittliche Änderungsrate von 2 Prozent der Anforderungen pro Monat an (vgl. [Schi01, S. 46]).

Als Ursachen für die Änderung von Anforderungen können beispielsweise angeführt werden:

- Fehler im Betrieb oder
- Kontextänderungen (Wandel in den Nutzungswünschen der Stakeholder, Gesetzesänderungen, neue Technologien oder zusätzliche Konkurrenzprodukte)

(vgl. [Pohl07, S. 547 – 549]).

Die Terminologie für die dokumentierte Form von Anforderungen ist ebenfalls nicht einheitlich. Beispielsweise wird hierfür im Standard IEEE 610.12-1990 (vgl. [IEEE 610.12-1990]) und von Rupp, Chris / SOPHIST GROUP (vgl. [Rupp07]) der Begriff der Anforderungsspezifikationverwendet. Balzert (vgl. [Balz96]) hingegen verwendet in seiner Arbeit den Begriff Produkt-Definition, um „[…] Verwechslungen mit dem Begriff <<Spezifikation>> im Entwurf zu vermeiden […]“ [Balz96, S. 92]. Pohl (vgl. [Pohl07]) benutzt für die dokumentierte Form den Begriff Anforderungsartefakt. Er unterscheidet präzise zwischen dokumentierten und spezifizierten Anforderungen. „Eine dokumentierte Anforderung ist nur dann eine spezifizierte Anforderung, wenn sie die vorgegebenen Spezifikationsvorschriften für Anforderungen erfüllt.“ [Pohl07, S, 220]

2.2 Anforderungsmanagement

Wie eben festgestellt wurde, sind Anforderungen grundsätzlich nicht stabil und ändern sich.

Versteegen schreibt, dass Änderungen auf Zuruf zwar für den Kunden recht nett sein mögen und auch eine scheinbare Flexibilität vortäuschen, jedoch aber in höchstem Maße unprofessionell seien (vgl. [Ver+03, S. 5]).

Seine Aussage gilt vor allem, wenn die Anzahl der Stakeholder groß und das Unternehmen sehr arbeitsteilig organisiert ist.

„Das Anforderungsmanagement dient dazu, diese unvermeidlichen Änderungen von Anforderungen im Vorfeld zu erkennen, zu planen und zu steuern, sowie ihre Auswirkungen lokal zu halten.“ [Schi01, S. 21]

Grady Booch definiert Anforderungsmanagement im Rahmen des Rational Unified Process (RUP) wie folgt:

„Das aktive Management der Anforderungen umfasst drei Aktivitäten:

- Das Entdecken, Organisieren und Dokumentieren der vom System geforderten Funktionalität und Zusammenhänge
- Das Einschätzen der Änderungen dieser Anforderungen und das Einschätzen ihrer Auswirkungen
- Das Verfolgen und Dokumentieren der vorgenommenen Änderungen und der Entscheidungen“

[KrBo99, S. 142]

Von Leffingwell und Widrig stammt die Definition:

Anforderungsmanagement ist ein systematischer Ansatz, die Erfordernisse des Systems zu ermitteln, zu verwalten und zu dokumentieren, sowie ein Prozess, der die Vereinbarung zwischen dem Kunden und dem Projektteam über die sich ändernden Erfordernisse des Systems herstellt und aufrecht erhält.

(Vgl. [LeWi99, S. 16], Übersetzung des Autors)

Definition nach Kruchten:

Anforderungsmanagement ist ein systematischer Ansatz des Ermittelns, Verwaltens, Kommunizierens und des Managens der Änderungsanforderungen eines softwareintensiven Systems oder einer Anwendung.

(Vgl. [Kruc03, S. 25], Übersetzung des Autors)

Die angeführten Definitionen sind sehr ähnlich was das Ermitteln, Verwalten und Dokumentieren von Anforderungen betrifft. Die Definition von Grady Booch beinhaltet explizit das Einschätzen von Änderungen und das Einschätzen ihrer Auswirkungen. In der Praxis ist dieser Aspekt des Anforderungsmanagements von zentraler Bedeutung. Aufgrund des zunehmenden Verknüpfungsgrades von Systemen oder Systemkomponenten können scheinbar harmlose Änderungen beträchtliche Auswirkungen haben, wenn diese unzureichend bedacht werden.

Schnittstellen des Anforderungsmanagements sind das Projekt- und das Qualitätsmanagement.

3 Ziele des Anforderungsmanagements

Zu den Zielen des Anforderungsmanagements zählen:

- Vorgaben für kundenorientierte/marktgerechte/passgenaue Lösungen,
- Steigerung der Qualität der fachlichen Anforderungen,
- ggf. Vertragsgrundlage,
- schneller Abstimmungsprozess zwischen Auftraggeber und Auftragnehmer durch klar definierte Prozesse,
- Effektivität,
- Beschleunigung des SDLC-Prozesses durch planvolles und zielgerichtetes Vorgehen,
- Transparenz,
- Wirtschaftlichkeit und Effizienz,
- Optimierung der Wettbewerbsdimensionen Zeit, Qualität und Kosten,
- Wissenserhaltung,
- kontinuierliche Verständigung durch Kommunikation,
- Aufrechterhaltung von Entscheidungen bei unveränderten Rahmenbedingungen,
- Mitarbeiterzufriedenheit.

Betriebliche Informationssysteme werden zur Lenkung der betrieblichen Leistungserstellung oder zur Erstellung von Dienstleistungen eingesetzt. Als maschinelle Aufgabenträger müssen sie bestimmte Informationsverarbeitungs-Aufgaben erfüllen.

„Wesentliche Aufgabe und Zielsetzung des Anforderungsmanagements ist es, die aus diesen Aufgabenstellungen resultierenden Anforderungen an das System zu spezifizieren und an Veränderungen des Anwendungsbereichs anzupassen.“ [Schi01, S. 18]

Dazu muss in erster Linie die Aufgaben-/Problemstellung genau bekannt sein, damit eine geeignete Lösung entwickelt werden kann. Entscheidend ist, in welchem Maße die Kundenanforderungen erfüllt werden (nähere Ausführungen hierzu finden sich im Kapitel 4.3 - Anforderungen nach Kano). Die Auswirkungen der Lösungsmöglichkeiten müssen genauestens analysiert werden, um die richtigen Entscheidungen treffen zu können. Ungewollte Seiteneffekte sind zu verhindern, Inkonsistenzen aufzulösen, Aufwandstreiber nach Möglichkeit zu eliminieren.

Zwischen allen Beteiligten (im Wesentlichen Auftraggeber und Auftragnehmer) muss ein einheitliches Verständnis über das zu entwickelnde System herbeigeführt werden. Mögliche Interessenskonflikte gilt es frühzeitig zu erkennen und aufzulösen. Getroffene Vereinbarungen müssen dokumentiert und sollten danach grundsätzlich nicht mehr in Frage gestellt werden.

Nachdem die Anforderungen an das System idealerweise nach vorgegebenen Qualitätskriterien (siehe Kapitel 5 - Anforderungsqualität) spezifiziert sind, muss deren Umsetzung zielgerichtet gesteuert und nachgehalten werden. Die Anforderungen müssen dazu koordiniert an die zuständigen Verantwortlichkeiten adressiert werden. Das erfordert verbindliche, klar definierte (messbare) an der Unternehmensstrategie ausgerichtete Prozesse an Stelle informeller Strukturen auf Basis persönlicher Beziehungen.

Das ökonomische Ziel der Wirtschaftlichkeit kann nur durch planvolles Vorgehen im Umsetzungsprozess erreicht werden. Hierzu bedarf es einer konsequenten und klaren Prioritätensetzung unter Einbeziehung der relevanten Stakeholder.

Entscheidungskriterien zur Priorisierung von Anforderungen sind:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: Entscheidungskriterien zur Priorisierung von Anforderungen (vgl. [Pohl07], S. 528f.)

Neben der wirtschaftlichen Umsetzung von Anforderungen sind Transparenz und kontinuierliche Verständigung durch Kommunikation im Umsetzungsprozess von hoher Bedeutung.

Nicht unerwähnt soll der Aspekt der Mitarbeiterzufriedenheit bleiben. Diese wird dadurch erreicht, dass passgenaue Lösungen entwickelt werden, die eine hohe Akzeptanz des neuen Systems erwarten lassen und so zum Erfolg für alle Beteiligten werden.

4 Klassifizierung von Anforderungen

4.1 Klassische Sichtweise

Durch das Anforderungsmanagement soll die Frage beantwortet werden, was genau in welcher Qualität entwickelt werden soll.

Anforderungen können nach den geforderten Eigenschaften klassifiziert werden. Die als klassische Sichtweise bezeichnete Differenzierung bezieht sich die Unterscheidung von funktionalen und nicht-funktionalen Anforderungen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Traditionelle Klassifizierung von Anforderungen

4.1.1 Funktionale Anforderungen

„Eine Funktion beschreibt eine Tätigkeit oder eine klar umrissene Aufgabe innerhalb eines größeren Zusammenhangs.“ [Balz96, S. 116]

Funktionale Anforderungen entstehen aus einer fachlichen Motivation und spezifizieren die Funktionen und das Verhalten des geplanten Systems. Klassisch werden die drei Perspektiven Funktionssicht, Datensicht und Prozesssicht unterschieden. Sie beschreiben, was in einem Softwaresystem gemacht wird.

- Funktionssicht :

Die Funktionssicht beschreibt die Transformation der Daten von der Eingabe über die maschinelle Informationsverarbeitung bis zur Datenausgabe.

- Verhaltenssicht :

Die Verhaltenssicht beschreibt die Systemabläufe. Hier wird definiert, welche Aktionen, welche Systemreaktionen auslösen. Hierzu zählen z.B. Zustände und (erlaubte) Zustandsübergänge

- Datensicht :

Die Datensicht ist die inhaltliche Ausgestaltung der Informationsobjekte sowie die Beziehungen zwischen den Informationsobjekten (Struktur).

Die funktionalen Anforderungen erfahren in der Regel die größere Aufmerksamkeit im Softwareentwicklungsprozess. Sie sind zugegebenermaßen einfacher zu definieren als Qualitätsanforderungen. Ein Softwareentwicklungsprozess, der dem Entwicklerteam viel Freiraum für Kreativität einräumt, eröffnet einerseits Chancen, indem dem Kunden zusätzliche Features als Begeisterungsfaktoren angeboten werden können, andererseits besteht aber auch die Gefahr, dass hier Schaden durch eine falsche Prioritätensetzung oder durch „Function-Overhead“ bzw. „Gold Plating“ entsteht. Optionen sind genau zu hinterfragen. Die Entscheidungen sollten in jedem Fall bewusst vor dem Hintergrund getroffen werden, ob freie Kapazitäten z.B. sinnvoller für andere wichtigere Anforderungen (noch nicht realisierte aber spezifizierte funktionale Anforderungen oder Qualitätsanforderungen, wie z.B. Maßnahmen, die die Wartbarkeit verbessern) zu nutzen sind. Im Entscheidungsprozess ist zu prüfen, wie stark die zusätzlichen Funktionen voraussichtlich genutzt werden, welchen Wartungsaufwand sie ggf. neben den zusätzlichen Entwicklungskosten erzeugen und wie sie die übrigen Funktionen beeinflussen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Durch Function-Overhead verursachter Schaden [BöFu+02, S. 459]

4.1.2 Nichtfunktionale Anforderungen

Anforderungen an ein System, die nicht unter die funktionalen Anforderungen fallen, sind nicht-funktional. Sie beschreiben z.B. besondere Qualitätsanforderungen, Leistungsanforderungen oder Restriktionen/Rahmenbedingungen. Nicht-funktionale Anforderungen beschreiben die Art und Weise der Umsetzung der geforderten Funktionalität. Der Erfüllungsgrad der meisten nicht-funktionalen Anforderungen ist schwer messbar. Um zu vermeiden, dass ein Interpretationsspielraum entsteht, müssen diese Anforderungen operationalisiert werden. Die nicht-funktionalen Anforderungen werden im Ergebnis konkretisiert. Leistungsanforderungen werden dazu quantitativ mit entsprechenden Werten als Vorgaben definiert. Nicht immer kann die Erfüllung einer nicht-funktionalen Anforderung direkt gemessen werden. Die Operationalisierung kann in diesen Fällen mittels geeigneten indirekten Indikatoren erfolgen. Nicht-funktionale Anforderungen haben zum Teil erheblichen Einfluss auf die Systementwicklung und spielen damit eine gewichtige Rolle im Anforderungsmanagementprozess.

4.1.2.1 (Besondere) Qualitätsanforderungen

Qualitätsanforderungen definieren qualitative Eigenschaften. Sie können sich auf einzelne funktionale Anforderungen oder auch auf das gesamte System beziehen. Im Allgemeinen beziehen sie sich jedoch nicht auf Prozesse oder Personen. Als Qualitätskriterien lassen sich die in der Norm DIN EN ISO66272 definierten Qualitätsmerkmale und auch deren Teilmerkmale anwenden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Qualitätsmodell nach DIN EN ISO 66272 (vgl.[DIN04, S. 310f.])

Im Folgenden werden für ausgewählte Qualitätskriterien wichtige Aspekte herausgearbeitet.

4.1.2.1.1 Interoperabilität

Interoperabilität bezeichnet die Fähigkeit unabhängiger heterogener Systeme zur herstellerunabhängigen Zusammenarbeit auf Anwendungsebene. Aufgrund der zunehmenden Vernetzung von IT-Systemen über die Unternehmensgrenzen hinweg, gewinnt dieser Aspekt zunehmend an Bedeutung. Der Datenaustausch muss reibungslos, medienbruchfrei, vom Hersteller und vom technischen Umfeld unabhängig erfolgen. Interoperabilität wird durch konsequente Nutzung offener Standards erreicht, d.h. durch Verwendung von hersteller- und produktunabhängigen technischen Standards, die öffentlich verfügbar und von jedem einsetzbar sind. Vorgaben dieser Art können auch als Rahmenbedingung definiert werden.

4.1.2.1.2 Sicherheit

Wenn personenbezogene Daten verarbeitet werden, ist der Rahmen für die Sicherheitsanforderungen gesetzlich normiert. Unabhängig davon sind aber auch nicht-personenbezogene Daten schützenswert. Klassische Anforderungen an die Sicherheit umfassen die Aspekte Vertraulichkeit, Verbindlichkeit, Authentizität und Integrität. Sicherheit in heterogenen IT-Systemen zu gewährleisten, bedeutet hohe Komplexität.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2: Sicherheitsanforderungen

Auf zukünftige Anforderungen in diesem Bereich sind eingebettete PKI-Infrastrukturen ausgerichtet. Diese müssen bereits im Design des Systems berücksichtigt werden. Ansonsten kann es zu Einbußen beim erreichbaren Sicherheitsniveau kommen. Neue Lösungen müssen ggf. an bereits existierende PKI-Systeme angebunden werden.

4.1.2.1.3 Bedienbarkeit

Gerade in heterogenen Anwendungslandschaften sind einheitliche und durchgängige Bedienkonzepte von zentraler Bedeutung, nicht nur für die leichte Erlernbarkeit. Vielschichtige Prozesse und höchste Ansprüche an die Funktionalität von IT-Systemen erfordern Lösungen, die das immer Komplexere immer einfacher machen. Ziel ist die Bereitstellung eines benutzerfreundlichen Human Machine Interface (HMI). Diesen Herausforderungen gilt es zu lösen. Usabillity (Gebrauchstauglichkeit) hat das Potenzial, die Kundenzufriedenheit zu erhöhen. Daneben können Einsparpotentiale durch Produktivitätsverbesserungen generiert werden. Im Blickpunkt von HMI steht nicht nur die intelligente Benutzerführung über eine Mensch-Maschine-Schnittstelle in grafischer Form (GUI). Ein Beispiel für künftige Herausforderungen sind Eye-Tracking Systeme als HMI, die in der Marktforschung oder in der Fahrzeugtechnik zum Einsatz kommen.

4.1.2.1.4 Zuverlässigkeit

Ungeplante Systemausfälle werden in der Hauptursache durch Software verursacht und können enorme ökonomische Folgen haben. Mit steigender Komplexität erhöht sich das Risiko von Mängeln an der Softwarezuverlässigkeit. Zuverlässigkeit bezeichnet die Fähigkeit eines Systems, über eine bestimmte Zeitspanne hinweg seine geforderte Funktion in korrekter Form bereitzustellen. Wichtige Aspekte hierbei sind die Robustheit und die Wiederherstellbarkeit. Anforderungen zur Robustheit spezifizieren das Systemverhalten in Fehlersituationen. Anforderungen zur Wiederherstellbarkeit definieren die Fähigkeit, die Bereitstellung zu dem Punkt wiederherzustellen, zu dem ein Ausfall erfolgt ist. Die Fähigkeit zum schnellen Wiederherstellen erfordert nicht nur die Verfügbarkeit aktueller Datensicherungen. Vielmehr muss auch ein vordefinierter Sicherungs- und Wiederherstellungsplan vorhanden sein, um diese Daten schnell und wirksam wiederherstellen zu können.

4.1.2.1.5 Verfügbarkeit

Als Systemverfügbarkeit wird die Zeitspanne quantifiziert, wie lange das System für die operationale Nutzbarkeit innerhalb eines vereinbarten Zeitrahmens erreichbar sein soll. Für einen geschäftskritischen Einsatz muss die Umgebung mit hoher Verfügbarkeit ausgelegt sein. Betriebsunterbrechungen müssen in solchen Fällen auf ein Minimum reduziert werden. Die Verfügbarkeit hat je nach Erfordernis große Auswirkungen auf die Anforderungen bezüglich Zuverlässigkeit und Wartbarkeit.

4.1.2.1.6 Änderbarkeit

Änderungen am System sind unumgänglich. Besonders Anwendungen, die von einer großen Anzahl von Benutzern eingesetzt werden, sind vielen Änderungswünschen ausgesetzt, die weder planbar noch vorhersagbar sind. Die Änderbarkeit beschreibt Anpassungsfähigkeit eines Systems an neue Anforderungen und den damit verbundenen Aufwand. Die Kosten für die Änderungen der Software in der Nutzungsphase des Sofware-Lebenszyklus sind abhängig von der Änderungshäufigkeit und von der Flexibilität oder Anpassbarkeit des Systems und können erheblich sein. Neben den in der Norm DIN 66272 genannten Teilmerkmalen spielt auch die Nachvollziehbarkeit (engl. traceability) von Anforderungen eine nennenswerte Rolle. Abhängigkeiten zwischen mehreren Artefakten und auch den Artefakttypen werden schneller sichtbar. So können Abhängigkeiten von Anforderungen, die in zeitlichem oder inhaltlichem Kontext stehen auf einfache Weise identifiziert werden. Ebenso verhält es sich mit den von der Änderung betroffenen Artefakttypen (z.B. Dokumentationen, Quellcode, Testfälle, etc.).

4.1.2.2 Leistungsanforderungen

Leistungsanforderungen beziehen sich auf die geforderten Leistungsmerkmale. Sie definieren zeitliche Schranken und skizzieren erwartete Mengengerüste. Wichtige Aspekte sind z.B. das geforderte Antwortzeitverhalten, das erwartete Datenvolumen, oder die Anzahl der Benutzer, die voraussichtlich gleichzeitig mit dem System arbeiten werden. Leistungsanforderungen beeinflussen die System-Architektur maßgeblich. Zugleich haben diese Anforderungen großen Einfluss auf die Kundenzufriedenheit, da die Benutzer die Qualität eines Systems u.a. nach der wahrgenommenen Performanz beurteilen.

4.1.2.3 Restriktionen/Rahmenbedingungen

Rahmenbedingungen stellen Restriktionen dar, die den Lösungsraum mehr oder weniger stark einschränken. Sie geben klare Grenzen vor und können normalerweise nicht oder nur schwer verändert werden. Rahmenbedingungen können intern und extern vorgegeben sein.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 3: Rahmenbedingungen

Rahmenbedingungen können für das zu entwickelnde Produkt gelten, aber auch für den Entwicklungsprozess. Rahmenbedingungen als Anforderung haben zwar eine einschränkende Wirkung, leisten jedoch auch einen Beitrag zur Fehlervermeidung.

4.2 Ansatz nach Pohl

An dieser Stelle sei erwähnt, dass die klassische Differenzierung zwischen funktionalen und nicht-funktionalen Anforderungen künftig zu überdenken ist. Dabei soll nicht ein völlig neuer Ansatz zum Tragen kommen. Vielmehr geht es um eine Präzisierung der klassischen Differenzierung zwischen funktionalen und nicht-funktionalen Anforderungen. Bei näherer Betrachtung kann diese zu Abgrenzungs- und Klassifikationsproblemen führen. Pohl rät stattdessen zu einer Unterscheidung folgender Anforderungsarten:

- Funktionale Anforderungen
- Qualitätsanforderungen
- Rahmenbedingungen

(vgl. [Pohl07, S. 14-20]).

Nach Pohls Auffassung, welche auch in dieser Arbeit vertreten wird, lässt sich die Klasse der nicht-funktionalen Anforderungen unterteilen in unterspezifizierte funktionale Anforderungen und in Qualitätsanforderungen. Unterspezifizierte funktionale Anforderungen lassen sich nach seinen Ausführungen bei entsprechender Detaillierung in funktionale Anforderungen bzw. ggf. in Qualitätsanforderungen überführen.

Die Frage der Klassifizierung von Anforderungsarten ist nicht nur akademischer Natur. In der Praxis führen gerade die von Pohl fokussierten Unschärfen zu Problemen. Unterspezifizierungen im Bereich der nicht-funktionalen Anforderungen können fatale Auswirkungen haben, wenn Unterspezifizierungen zu spät als solche erkannt werden. Eine späte Detaillierung führt dann zu Problemen, wenn die System-Architektur nicht entsprechend des Bedarfs ausgelegt ist. Ein Beispiel hierfür sind Echtzeitanforderungen. Zudem eröffnen Unterspezifikationen generell einen Interpretationsspielraum. Vollständige Spezifikationen erlauben eine sichere Planung, erhöhen die Produktivität und verringern das Risiko potentieller Streitigkeiten zwischen Auftraggeber und Auftragnehmer.

Die vorgeschlagene Klassifizierung kann dazu genutzt werden, Anforderungsdokumenten eine grobe Struktur zu geben.

4.3 Anforderungen nach Kano

Das Ziel des Schaffens von erfolgreichen Produkten kann nur erreicht werden, wenn dem Kunden eine als attraktiv empfundene Lösung geboten werden kann. Die Kundenzufriedenheit wird seit Jahren zu einer wesentlichen Zielgröße auf Käufermärkten gerechnet. Sie bildet die Grundlage für eine dauerhafte Kundenbindung. Für das Anforderungsmanagement ist es daher elementar, die Kundenzufriedenheit im Blickfeld zu behalten und als Steuerungsgröße zu berücksichtigen. Um gezielt auf die Kundenzufriedenheit einwirken zu können, ist es entscheidend, Kenntnis über die Erwartungen der Kunden zu haben. Mittels des Kano-Modells lassen sich Kundenanforderungen strukturieren und deren Einfluss auf die Zufriedenheit bestimmen.

Kano unterscheidet in seinem Modell drei Klassen von Kundenanforderungen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Anforderungen nach Kano (in Anlehnung an die Maslowsche Bedürfnispyramide)

- Basisanforderungen

Diese umfassen alle wesentlichen Erwartungen des Kunden, deren Erfüllung dieser als selbstverständlich voraussetzt und deshalb in der Regel auch nicht explizit formuliert. Die Erfüllung von Basisanforderungen führt nicht zu einer Kundenzufriedenheit, während die Nichterfüllung eine hohe Unzufriedenheit beim Kunden auslösen würde.

- Leistungsanforderungen

Diese Klasse der Kundenanforderungen wird nicht als selbstverständlich angenommen, sondern bewusst gewünscht. Die Zufriedenheit der Kunden verhält sich bei diesen Anforderungen proportional zur Erfüllung und die Unzufriedenheit proportional zur Nicht-Erfüllung. Damit entsprechen Leistungsanforderungen einem linearen Zusammenhangsmuster. Der Erfüllungsgrad beeinflusst in hohem Maße die Position im Wettbewerb.

- Begeisterungsanforderungen

Begeisterungsanforderungen sind jene Eigenschaften eines Produktes, die in der Lage sind, beim Kunden Begeisterung auszulösen. Sie werden nicht explizit erwartet. Mit der Erfüllung von Begeisterungsfaktoren kann sich jedoch ein Anbieter von seinen Mitbewerbern besonders abheben. Sie lassen ein Produkt innovativ erscheinen. Das Nichtvorhandensein von Begeisterungsfaktoren löst keine Unzufriedenheit aus.

Die Zusammenhänge sind in der nachfolgenden Abbildung visualisiert:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Anforderungsarten im Kano-Modell [KaBr05, S. 127]

Es gilt zu beachten, dass das Kano-Modell eine zeitliche Dynamik besitzt. Besonders die Begeisterungsfaktoren sind davon stark betroffen. Sobald eine gewisse Verbreitung gegeben ist, werden sie nur mehr als Leistungsfaktoren wahrgenommen. Ebenso sind heutige Leistungsanforderungen an ein Produkt, die Basisanforderungen von morgen. Weiterhin müssen bei der Klassifizierung auch Unterschiede in den Kundensegmenten beachtet werden.

Eine wichtige Erkenntnis, die aus dem Kano-Modell gewonnen werden kann, ist die enorme Bedeutung von Begeisterungsfaktoren. Die Herausforderung liegt im Aufspüren dieser Faktoren. Abhängig von der Innovationskraft eines Unternehmens bietet sich diesem die Chance von zeitlich begrenzten Wettbewerbsvorteilen oder gar die Erschließung gänzlich neuer Märkte. Vor diesem Hintergrund wird eine kooperative Wertschöpfungzwischen den unternehmerischen Disziplinen des Anforderungsmanagements, des Innovationsmanagements und des Marketings empfohlen.

5 Anforderungsqualität

Anforderungen sind die Basis für alle weiteren Tätigkeiten im Softwareentwicklungsprozess und schlagen sich bis zu den Endergebnissen^[1] durch. Dementsprechend haben sie erheblichen Einfluss auf den Projekterfolg, insbesondere auf die Qualität der Projektergebnisse und die Einhaltung der Termin- und Zeitvorgaben sowie des Kostenrahmens. Die möglichen Auswirkungen mangelnder Anforderungsqualität liegen auf der Hand. Die Anforderungsqualität wird zum einen durch die Qualität der einzelnen Anforderungen und zum anderen durch die Qualität der Anforderungsdokumente bestimmt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Anforderungsqualität

5.1 Qualitätskriterien für einzelne Anforderungen

Die Merkmale guter Anforderungen werden im IEEE Standard 830-1998 (vgl.[IEEE830]) mit acht Eigenschaften beschrieben. Die meisten Autoren schlagen ähnliche Kriterien vor (vgl. [Balz96, S. 94f.]; [Pohl07, S. 222f.]; [Rupp07, S. 27-30]; [Schi01, S. 176-183]). In Anlehnung an die genannten Arbeiten werden die wichtigsten Qualitätskriterien nachstehend aufgeführt und erläutert:

- Korrektheit

Eine Anforderung ist korrekt, wenn sie vollständig und in richtiger Weise den Bedarf der relevanten Stakeholder wiedergibt.

[...]

---

^[1] Hier wurde bewusst der Plural gewählt, da im Rahmen dieser Arbeit zu den Projektergebnissen das realisierte System inkl. der sonstigen gelieferten Artefakte gezählt wird.