Requirements Management

Requirements Management, Anforderungs Management, Produktmanagement

Die GartnerGroup hat festgestellt, dass bis 2002 über 75 % der Software Projekte aufgrund von schwerwiegenden Fehlern gescheitert sind. Das durchschnittliche Budget der abgeschlossenen Projekte lag bei über 220% des geplanten Budgets.

Bereits in den ersten Phasen werden die entscheidenden Weichen über den Erfolg oder Misserfolg eines Projektes gestellt. Mangelnde Definition der Unternehmens- und Projektziele, unfokusierte Leistungsanforderungen, mangelnde Einbindung der Anwender und unkoordinierte Änderungen im Verlauf des Projektes sind entscheidende Gründe für das Scheitern von Projekten.

Grundsätzlich gesehen ist die Erstellung von Anforderungen relativ einfach. Anforderungen müssen nur vollständig, richtig, konsistent, testbar, verständlich, notwendig, eindeutig und umsetzbar sein. Die Kunst des erfolgreichen Requirements-Managements ist es jedoch, die Unternehmensziele mit dem Budget, den Stakeholdern, den Schnittstellen, den funktionalen Anforderungen und der zur Verfügung stehen Zeit unter einen Hut zu bekommen. Daraus kann dann ein motiviertes Projektteam mit einer gemeinsamen Mission geformt werden. Die erfordert umfangreiche Erfahrungen, eine politisch sensible und zielorientierte Vorgehenweise sowie eine auf den Kunden angepasste Methodik. 

Definition von Requirements Management

Requirements Management ist ein kundenorientierter Ansatz, die Wünsche der Kunden und des eigenen Managements zu erfassen, dem Softwareteam zur Verfügung zu stellen, die Implementierung mit den Anforderungen zu vergleichen und evtl. Abweichungen zu dokumentieren und während der Implementierung in den Entwicklungsprozess einfließen zu lassen.

Herausforderungen des Requirementsmanagement

Es gibt drei wesentliche Anforderungen, mit denen sich alle Stakeholder eines Softwareprojektes auseinander setzen müssen:

1. Zeitraum bis zur Nutzbarkeit der Software (Time to Market)
2. Produktqualität der erstellten Software
3. Anpassbarkeit der Software an neue Anforderungen (Requirements- und Change-Management)

Herausforderung 1: Wie schnell kann die Software in Betrieb gehen?

Um erfolgreich zu sein, muß sich ein Unternehmen sehr schnell entwickeln können. Alteingesessene Firmen müssen nicht mehr nur gegen ihre bisherigen Kokurrenten bestehen, sondern auch gegen neue Firmen, die nach einem e-Business Modell arbeiten. Um eine weltweite Präsenz zu erreichen, können diese Firmen auf die Infrastruktur des Internets zurückgreifen. dotCOM-Firmen, die sich durch ihre Wendigkeit auszeichnen, müssen ständig Neuigkeiten einführen, um gegen ihre Kokurrenten bestehen zu können. Beispielsweise hat sich Google einen loyalen Kundenstamm geschaffen, indem das vorhandene Angebot laufend erweitert und verbessert wurde.

Herausforderung 2: Wie läßt sich die Produktqualität steigern?

Das Verhältnis zwischen Verkäufer und Käufer wurde durch die Einführung des Internet ein anderes. Durch die Möglichkeiten, die Internettechnologie bietet, können Kundenzufriedenheit und -ansprüche gesteigert werden. Dem Kunden steht mehr Information und ein größeres Angebot zur Verfügung. Das gilt sowohl im Bereich B2C (Business to Consumer), wie beispielsweise Online-Börsenapplikationen, als auch Lösungen, wie die von ORACLE, die fast den gesamten Umsatz über das Web abwickeln. Die Qualität des Angebots kann an der Anwenderfreundlichkeit des Angebots, der Sicherheit und der Zuverlässigkeit gemessen werden. Dell hat als erster die Möglichkeit geschaffen, und dann noch perfektioniert, "customised" PC's direkt über das Web zu bestellen. Heute gibt es zahllose online Shops, die das nachmachen. Von jedem Ort der Welt aus kann man ein vollautomatisches Bestellsystem nutzen, um einen PC nach eigenen Wünschen zusammenzustellen, Preise zu vergleichen, die Auftragserledigung zu verfolgen, eine Bestellung aufzugeben oder den Kundendienst zu kontaktieren. Ein solcher Erfolg erfordert es Kundenwünsche und -erwartungen zu verstehen, auszuwerten und die Fähigkeit, die gewonnenen Erkenntnisse dann auch umzusetzen.

Herausforderung 3: Wie lassen sich Änderungen verwalten und gezielt und gesteuert umsetzen?

Wenn neue Software entsteht und der Anwender die Software benutzt und bedient bekommt er zwangsläufig neue Ideen, wie alles noch einfacher und noch schneller geht. Dieses Problem ist dem menschlichen Denken immanent. Wir können von dem was wir sehen und kennen ein Stpck weiter denken. Aber eben nicht beliebig weit. Das ist beim Schachspielen zu beobachten, wo selbst Spieler der Weltklasse nur 20 Züge vorausdenken können. Wenn nun die neue Situation da ist, oder wir nur ein paar Schritte in Richtung der neuen Situation vorangeschritten sind, können wir weiter denken. So schafft das Voranschreiten im Projekt zwangsläufig neue Anforderungen, die allesamt gut und richtig sind, aber den ursprünglichen Plan teilweise in Frage stellen.

Die neuen Anforderungen zu erfassen, festzustellen, ob man noch auf dem richtigen Pfad ist, die Richtung zu ändern, Requirements neu zu priorisieren und all das geregelt und gesteuert in die Sofftwareentwicklung einfließen zu lassen, ist die hohe Kunst des Requirementsmanagements und des Changemanagements.

Die 6 wichtigsten Aktivitäten des Requirements Managements

1. Erfassen der Unternehmens-, Projekt- und Produktziele
2. Erfassen und Priorisieren der funktionalen Anforderungen
3. Erfassen und Priorisieren der nicht funktionalen Anforderungen (Systemumgebung, Laufzeit Schnittstellen zu anderen Systemen, Verfügbarkeit etc...)
4. Zuordnen der Requirements zu den geplanten Implementierungsphasen
5. Überprüfen der Implementierung in jeder Phase in Bezug auf die Anforderungen
6. Change- und Konfigurationsmanagement

1. Erfassen der Unternehmens-, Projekt- und Produktziele

Der Requirements-Prozess beginnt mit der Definition der Unternehmens- Projekt- und Produktziele, die dem Softwareprojekt zugrunde liegen. Dies geschieht durch die systematische Analyse gemeinsam mit dem Management und den Stakeholdern. Die Ziele, oder auch Mission genannt, bilden die gemeinsame Basis über die gesamte Projektlaufzeit und den Massstab für den Erfolg des Projektes.

Diese Ziele werden typischerweise anhand strategischer Unternehmensziele wie die Schaffung von Wettbewerbsvorteilen, Erweiterung von Geschäftsfeldern oder Marktanteilen, Investitionsmöglichkeiten und Umsatzsteigerungen definiert. Viele Versuche Software zu erstellen sind gescheitert, weil diese Ziele nicht von Anfang an definiert und ausreichend kommuniziert wurden.

2. Erfassen und Priorisieren der funktionalen Requirements

Nachdem die Unternehmensziele definiert wurden, besteht der nächste Schritt des Requirement Management Prozesses darin, Anforderungen aus den vorhandenen Informationen zu bilden und diese für das Projekt zu priorisieren. Die funktionalen Anforderungen werden mit Hilfe von Anwenderszenarien erfasst und strukturiert abgespeichert. Zur Erfassung und Verwaltung stehen leistungsfähige Requirements Werkzeuge zur Verfügung. Ergänzend hat sich die Erstellung von Software- und GUI-Prototypen bewährt, die Funktionalität, Ergonomie und Darstellung beschreiben.

Die Priorisierung der Anforderungen wird zur Gliederung des Projektes in Meilensteine genutzt, die später zur schrittweisen Realisierung (Inkrementelle Vorgehensweise) und zur schrittweisen Einführung der Software dienen. Somit können die Softwareteile mit der höchsten Dringlichkeit zuerst eingeführt werden. Dies ist auch wichtig, um alle Anwenderrollen zu berücksichtigen. Ergänzend zu den Kunden wird es auch interne Anwender der Software geben, wie z.B. die Auftragsbearbeitung, der Kundendienst und die Administratoren. Für eine erfolgreiche Umsetzung müssen alle Anwenderrollen des Systemes berücksichtigt werden.

3. Erfassen und Priorisieren der nicht funktionalen Requirements

Parallel zu den funktionalen Anforderungen müssen die technischen Rahmenbedingungen der neuen Software definiert und  Abhängigkeiten zu anderen Softwaresystemen formuliert werden. Insbesondere Schnittstellen bilden immer wieder problematische Stolpersteine beim Betrieb und der Inbetriebnahme der Software, weil beispielsweise vergessen wurde festzulegen, was bei Nichtverfügbarkeit der Gegenseite der Schnittstelle zu tun ist.

Zuletzt werden die Anforderungen den jeweiligen Zielen zugeordnet. Dies hat den Vorteil, dass sofort erkennbar wird, welche Anforderungen noch nicht umgesetzt wurden. Ein weiterer Vorteil ist auch, dass der Einfluss bei Änderungen sofort sichtbar gemacht werden kann.

4. Zuordnen der Requirements zu den geplanten Implementierungsphasen

Alle funktionale und nicht funktionalen Anforderungen werden nun verschiedenen Releases der Software zugeordnet. Dabei wird berücksichtigt welche Funktionalitäten der Software im Zusammenhang Sinn machen, und was das minimale System ist, das dem Anwender nutzbare Vorteile bringt. Auf diesem minimalen System werden nun weitere Versionen mit ergänzendem Funktionsumfang aufgesetzt, bis das System den geforderten Funktionsumfang zur Verfügung steht.

In diesem Zusammenhang müssen die Aufwendungen berücksichtigt werden, die durch die Verteilung der Software und durch Updates der bestehenden Software entstehen. Weitere wichtige Punkte sind in diesem Zusammenhang die Datenübernahme und die Migration der bestehenden Software sowie die Schulung der Anwender. Das wird in vielen Projektplänen schlicht vergessen.

Ausgestattet mit diesen strukturierten Requirements hat das Softwareteam nun alle Informationen, um die Implementierung und die Softwareverteilung zu planen. Wenn der Zeitdruck gross ist, ist eine schrittweise Einführung der Services empfehlenswert. Durch Berücksichtigung der Prioritäten und dem Implementierungsaufwand kann jedes Requirement einer bestimmten Version zugeordnet werden.

5. Überprüfen der Implementierung in jeder Phase in Bezug auf die Anforderungen

Kurz vor Erreichen jeder einzelnen Version muss die Implementierung mit den Anforderungen verglichen werden. Dazu können zu jedem Requirement verschiedene Testmöglichkeiten, sinnvoller Weise Geschäftsprozesse (Use Cases) definiert werden, um die richtige Umsetzung zu validieren. Innerhalb des Requirements-Prozesses werden diese Tests auf die entsprechenden Requirements abgebildet. Dieser Prozess garantiert, dass alle Requirements getestet wurden und sorgt dafür, dass der Projektstatus jederzeit sichtbar wird.

6. Change- und Konfigurationsmangement

In der Praxis werden die vorgenannten 5 Aktivitäten meist parallel ablaufen. Während ein Geschäftsmodell fortlaufend verfeinert wird, werden neue Anforderungen eingeführt und/oder die Unternehmensziele verändern sich. Da viele Anwender das System benutzen, werden oft alte Anforderungen durch neue ersetzt. Der Requirements-Prozess nimmt sich dieser erwarteten Änderungen an, indem er mit erprobten Change-Management (CM) und Konfigurationsmanagement (KM) Prozessen hilft, diese Vorschläge aufzunehmen, auszuwerten und geordnet in die Entwicklung einzuführen. Dies wird durch die Verknüpfungen innerhalb des Requirements-Prozess ermöglicht, der dadurch den Einfluss einer Änderung auf das Gesamtsystem sichtbar macht und die Entscheidungsfindung unterstützt.

Dem Softwareteam obliegt es, die durch die Änderungen bedingten und zu erwartenden Auswirkungen auf das Projekt transparent darzustellen. Der Fachabteilung oder dem Management obliegt dann die Entscheidung, ob diese Änderungen in das Projekt aufgenommen werden und die erwarteten Auswirkungen auf das Projekt wie z.B. Mehrkosten, späterer Fertigstellungstermin etc. akzeptiert werden. Die Entscheidungen über Änderungen der Anforderungen müssen nachvollziehbar und transparent dokumentiert werden, damit Abweichungen der ursprünglichen Rahmenbedingungen von allen Projektbeteiligten jederzeit argumentiert werden können.