Wurden Sie bei der Einführung oder Entwicklung neuer IT-Applikationen auch schon mit folgenden Aussagen konfrontiert? «Hier hätte ich eigentlich erwartet, dass das System mich besser unterstützt.» «So kann ich nicht arbeiten, dieser Dialog muss viel schneller erscheinen!» «Wir haben für die Wartung doch immer dieses Tool verwendet. Das geht ja jetzt nicht mehr.» Häufig empfinden die einzelnen Stakeholder einer neuen Applikation ihre Bedürfnisse als mangelhaft oder schlecht abgedeckt. Dabei war man eigentlich zufrieden mit der Entwicklungsmannschaft, man hatte die Spezifikation abgenommen und das Projekt wurde termin- und budgetgerecht in der geforderten Qualität umgesetzt.
Die Gründe für die skizzierte Unzufriedenheit sind vielschichtig. Die genannten Mängel finden ihren Ursprung oftmals bereits in der Aufnahme der Anforderungen. Häufig zeigt sich hierbei, dass die Anwender bezüglich der Anforderungen an das neue System nur unklare Vorstellungen haben. Um unangenehmen Diskussionen zu entgehen und keine definitiven Entscheidungen fällen zu müssen, werden die Anforderungen daher gerne unscharf formuliert. Je länger diese Unklarheit im Entwicklungsprozess bestehen bleibt, desto schwerer wiegen später die Folgen. Haben die Implementierungsarbeiten erst einmal begonnen, ist eine Nachspezifizierung aufwendig, teuer und für den sauberen Projektverlauf störend. Um nicht destruktiv zu wirken, füllt der Business-Analyst oder im schlimmeren Fall der Entwickler die Lücken dann häufig mit Annahmen auf. In diesem Fall sind Enttäuschungen im Projekt oder spätestens bei der Einführung der Anwendung vorprogrammiert.
In diesem Artikel werden Methoden für eine strukturierte Aufnahme von Anforderungen in Tiefe und Breite aufgezeigt. Ausserdem soll dargelegt werden, wie man die Erwartungen der Stakeholder in Einklang bringt, um Enttäuschungen im Projekt oder bei der Einführung vorzubeugen.
Zur Erfassung eindeutiger und in der Tiefe vollständiger Anforderungen empfiehlt sich die Definition eines linguistischen Musters, welches Regel und Struktur einer Anforderung beschreibt. Dieses enthält Vorgaben zur Formulierung und zu relevanten Erfassungsbereichen. Ein wesentlicher Bestandteil dieses Musters sind Abnahmekriterien. Diese beschreiben die Bedingungen für die Entscheidung, ob eine Anforderung erfüllt ist oder nicht. Ein Kriterium wie «Die Dialoge müssen den Benutzer bei der Bearbeitung so gut wie möglich unterstützen» ist weder eindeutig noch messbar. Eine klare Beschreibung wäre zum Beispiel: «Der Dialog muss die Eingaben in den Feldern a, b und c durch Wertelisten unterstützen.» Klare Abnahmekriterien beschreiben die Leis-tung des Systems. Validiert man diese mit den Stakeholdern, wird schnell deutlich, ob sich hinter bestimmten Anforderungen abweichende Erwartungen verbergen.
Doch wie sieht es mit der Vollständigkeit der Erfassung von Anforderungen in der Breite aus? Naturgemäss wird bei der Anforderungsanalyse das Augenmerk auf die funktionalen Anforderungen gelegt. Die sogenannten nichtfunktionalen Anforderungen werden oft vernachlässigt. Während die Fragestellung bei den funktionalen Anforderungen «Was muss die Lösung können?» lautet, beschäftigen sich die nichtfunktionalen Anforderungen unter anderem mit der Frage «Welche Restriktionen muss die Lösung einhalten?». Wird diese Art von Anforderungen nicht vollständig und korrekt erhoben, sind Probleme während des Projektverlaufs und darüber hinaus wahrscheinlich. Das folgende reale Beispiel aus einem Projekt zur Ablösung eines veralteten Clients soll dies veranschaulichen:
Die Business-Analysten haben die Anforderungen strukturiert und nach einem bewährten Muster in ausreichender Tiefe aufgenommen. Kurzum, sie haben bei der Aufnahme der funktionalen Anforderungen gute Arbeit geleis-tet. Im Verlauf des Projekts wurde jedoch deutlich, dass einige wichtige Begebenheiten nicht vollständig berücksichtigt wurden. Man entschied sich gegen eine browserbasierte und für eine Rich-Client-Lösung, welche eine bessere Unterstützung des Anwenders in Bezug auf Geschwindigkeit und Eingabeplausibilisierung bot. Innerhalb des weltweiten Firmennetzes kann die Software automatisch verteilt werden. Dabei wurde jedoch vergessen, dass auch externen Kunden des Unternehmens der Zugang zur Anwendung mit einer eingeschränkten Funktionalität ermög-licht werden sollte. Da die Betriebssicherheit vorschreibt, dass Firmenapplikationen nur innerhalb des Unternehmens betrieben werden dürfen, musste eine Lösung gefunden werden, um dieser Anforderung zu genügen. Man entschied sich dafür, den externen Kunden die benötigte Funktionalität über eine neu zu entwickelnde browserbasierte Applikation zur Verfügung zu stellen, wodurch zusätzliche Entwicklungs- und Wartungskosten anfielen.
Das Beispiel zeigt auf, dass neben den «klassischen» Effizienzanforderungen, durch die zum Beispiel Antwortzeiten und Ressourcenbedarf beschrieben werden, weitere wichtige Bereiche der nichtfunktionalen Anforderungen existieren, deren Nichtbeachtung starken Einfluss auf den Projekterfolg haben.
Die Grafik «Nichtfunktionale Anforderungen» stellt dar, welche nichtfunktionalen Anforderungen in einem Projekt und dessen Umfeld beachtet werden sollten. Falsche oder vergessene nichtfunktionale Anforderungen wirken sich auf der Kostenseite genauso negativ aus wie falsche oder vergessene funktionale Anforderungen. Sind sie allerdings zu streng formuliert oder unnötig, können sie ein Projekt auch verteuern. Dies zeigt sich auch im Projekt zur Client-Ablösung. Der neue Client sollte weltweit eingesetzt werden, also wurde eine Verfügbarkeit von 24 Stunden an 7 Tagen der Woche definiert. Dies ist eine sehr strenge Vorgabe, da die Applikation überdurchschnittlich robust konstruiert und durch einen Bereitschaftsdienst überwacht werden musste, was sich direkt in den Kosten widerspiegelte. Bei der Einführung des neuen Clients war die Enttäuschung der Benutzer jedoch gross, da sich gegenüber dem Altsystem die Verfügbarkeit kaum verbessert hatte. Was waren die Gründe dafür?
Da Abstürze des Systems häufig die Arbeit der Benutzer blockierten, hatten diese die Anforderung der 24/7-Verfügbarkeit formuliert. Tatsächlich aber waren die Abstürze gar nicht auf den Client, sondern auf Ausfälle des Backends zurückzuführen. Es wurde deutlich, dass für das Backend kein konkreter Wartungsplan vorlag, geschweige denn eine 24/7-Verfügbarkeit gegeben war. Die Verfügbarkeitsanforderung an den Client war also nicht konsistent mit den Gegebenheiten, was durch eine ausführliche Validierung der Anforderung hätte erkannt werden können. Eine frühzeitige Definition eines auf Client und Backend abgestimmten Wartungsplans hätte an dieser Stelle zu einem wesentlich besseren und kostengüns-tigeren Ergebnis geführt.
Neben der vollständigen Erfassung der Anforderungen in Tiefe und Breite ist eine einheitliche Erwartungshaltung der Stakeholder unbedingt notwendig. Diese stufen naturgemäss ihre jeweils eigenen Anforderungen als die wichtigsten ein und messen die Applikation in ihrer Gesamtheit daran. Bringt man diese Erwartungen nicht in Einklang, sind Enttäuschungen, wie sie in den Aussagen am Beginn dieses Artikels zum Ausdruck kommen, vorprogrammiert. Um diesen entgegenzuwirken, empfiehlt sich eine Priorisierung der Anforderungen, die gemeinsam mit den Stakeholdern abgestimmt wird. Die einfachste Methode hierzu ist die sogenannte Moscow-Methode, mit deren Hilfe die Anforderungen in folgende Prioritätsgruppen eingeteilt werden:
- Must: Muss erfüllt werden, um Business-Anforderungen zu genügen.
- Should: Sollte erfüllt werden, wenn möglich. Der Projekterfolg ist jedoch nicht davon abhängig.
- Could: Nice-to-have-Funktionen, die umgesetzt werden können, wenn die Umsetzung wichtigerer Funktionen dadurch nicht beeinträchtigt wird.
- Would: Wird für eine Umsetzung in einer zukünftigen Version vorgemerkt.
Kommt man hierbei nicht zu einer akzeptablen Verteilung, empfehlen wir einen paarweisen Vergleich von jeweils zwei Anforderungen, um hierdurch eine eindeutige Prioritätshierarchie festzulegen. Können sich die Stakeholder immer noch nicht auf eine gemeinsame Priorisierung einigen, hat sich die feingranulare Business-Value-Methode bewährt. Mittels Summierung und Vergleich von gewichteten Kennzahlen wird der Nutzen der einzelnen Anforderungen bewertet und in Beziehung zueinander gesetzt. Die Bewertungskriterien und deren Gewichtung sind dabei im Vorfeld festzulegen. Entscheidungen, dass niedrig priorisierte oder mit niedrigem Business Value behaftete Anforderungen nicht umgesetzt werden, sind somit für die Stakeholder besser nachvollziehbar, was wiederum Enttäuschungen vorbeugt.
Erst wenn alle Anforderungen in voller Breite und ausreichender Tiefe beschrieben sind, kann die Anforderungsanalyse abgeschlossen werden. Bei der Entscheidung über den Abschluss der Analyse helfen – neben Erfahrungswerten – Checklisten, mit denen die Vollständigkeit geprüft werden kann.
Die Vollständigkeit in der Erhebung und Analyse sämtlicher Anforderungen sowie deren eindeutige Beschreibung erhöht die Projektsicherheit. Ein frühzeitiges Management der Erwartungen beugt Enttäuschungen vor und erhöht die Zufriedenheit mit der neuen Applikation.
