"Das Aussortieren des Unwesentlichen ist der Kern aller Lebensweisheit."
(Laotse)

Anforderungslisten

Dass es funktionale Anforderungen (FR) und technische Anforderungen (NFR) gibt und dass diese alle schriftlich fixiert werden sollten, haben wir schon in den vorangehenden Seiten dieser Abhandlung herausgearbeitet. Aber wie sieht das nun genau aus? Wahl der Waffen   klein - In/Out-Liste     mittel - Excel/Word     groß - spezielle Tools   Ob Sie die Anforderungen auf Metaplan-/Karteikarten schreiben, als kleine nummerierte Liste führen, in Microsoft Excel verwalten und in Microsoft Word beschreiben, in einer kleinen Datenbank managen oder ein professionelles Tool einsetzen, hängt sicherlich von der Projektgröße, Ihrer Erfahrung und auch dem Typ und Budget des Projekts ab. Ihr Tailoring Ihres eingesetzten Softwareentwicklungsprozesses wird letztendlich entscheiden, wie Sie genau mit den Anforderungen in Ihrem Projekt umgehen werden. Ich stelle im Folgenden eine Auswahl von verschiedenen Möglichkeiten ("Kaliber") des Anforderungsmanagements dar.

Was die Anforderungen enthielten.

Bei XP (Extreme Programming) werden die Anforderungen gerne auf Metaplan- oder Karteikarten benannt und auf der Rückseite der Karte wird dann knapp deren Geschichte (ähnlich einer "casual use case story") beschrieben. Der Kunde prüft diese Geschichten sehr sorgfältig und hakt sie ab. Zu Beginn einer neuen kurzen Iteration bestimmt der Kunde, welche Anforderungen als nächstes umgesetzt werden und jeder Entwickler kann sich dann davon eine Karte aussuchen. Ist die Anforderung implementiert, wird nach sehr gründlichem Test die Karte zerrissen und weggeworfen. Wenn die Pinnwand leer ist, ist das Projekt zuende.

Bei der Analyse ist wichtig, dass sehr viel Klärung stattfindet: alle Anforderungen müssen aus- und bewertet und gegen das Hauptziel getestet werden, das während der Pre-Analyse definiert wurde. Es müssen also Entscheidungen getroffen werden, ob eine an das System gestellte Anforderung wirklich realisiert werden soll oder nicht. Bei vielen Entscheidungen werden Sie als Analytiker feststellen, dass sich Ihr Kunde sehr schwer tut und schwankt und eine große Unsicherheit an den Tag legt. Es ist aber wichtig, dass eine Entscheidung getroffen wird, die dann auch genauso formal und verbindlich wie alles andere behandelt wird. Erstellen Sie eine In/Out-Liste und nehmen Sie die Entscheidung dort auf:

Dieses Instrument ist höchst einfach, aber genauso effektiv. Es entspricht einer meiner Grundregeln für jedes Projekt: KISS (Keep it small and simple). Eine Entscheidung kann ja durchaus später revidiert werden, aber dann ist wenigstens klar, dass die Konsequenzen (d.h. der zeitliche und damit finanzielle Aufwand) ermittelt und in Rechnung gestellt werden können. Manchmal ist es auch sinnvoll, die In/Out-Liste parallel auf einem Flipchart-Blatt zu führen und dieses gut sichtbar im Projektraum aufzuhängen. Dann kann man immer schön mit dem Finger drauf zeigen :-)

Wenn bereits klar ist, dass die Software in mehreren Schritten erstellt wird, so kann der In/Out-Liste natürlich auch eine Spalte hinzugefügt werden, in der bei einem "In" eine Versions- oder Modulnummer oder vielleicht auch ein Datum eingetragen wird. Die Liste hilft in jedem Fall ganz deutlich dabei, die Pflicht und Kür zu trennen: die "Pflicht" muss rein und die "Kür" fliegt raus oder wird dann gemacht, wenn die Pflicht erledigt ist. Dies ist wieder eine meiner Grundregeln für jedes Projekt: Erst die Pflicht, dann die Kür!

Egal wie und womit Sie die Anforderungen fixieren, Sie sollten ab einer gewissen Projektgröße den Anforderungen Attribute zuordnen. Es ist sogar eine gute Idee, dies auch bei den kleinsten Projekten zu tun, denn der Aufwand ist stets minimal im Vergleich zum Nutzen! Über die "Priorität" (z.B. "hoch", "mittel", "niedrig" oder vielleicht auch "muss", "soll", "kann") können Sie später filtern und Reihenfolgen bestimmen. Auch zur Zerlegung des Projekts in Teilprojekte oder mehrere Module ist die Priorität sehr gut geeignet. Dabei werden Sie als Analytiker feststellen, dass es den Kunden immer sehr schwer fällt, etwas nicht in die höchste Priorität einzustufen, denn eigentlich will der Kunde immer alles - und meist auch sofort. Nach einigem Hin und Her finden sich aber doch oft Anforderungen, die zugunsten einer früheren Einführung der Software zurückgestellt werden können.

Attribute   Priorität     Stabilität     Komplexität     Risiko     Quelle     Ansprechpartner     Autor     Status

Über die "Stabilität" (z.B. "hoch", "mittel", "niedrig") können Sie verfolgen, ob sich eine Anforderung häufig ändert. Manche Anforderungen gab es von Anfang an so und da waren sich auch alle einig und da ändert sich offensichtlich auch nichts mehr dran. Andere Anforderungen konnten noch nicht entschieden werden und werden von verschiedenen Leuten auch ganz verschieden beschrieben. Hier muss man sich fragen, wie hoch die Wahrscheinlichkeit ist, dass sich diese Anforderungen nach einer endlich gefällten Entscheidung doch noch mal ändern.

Die "Komplexität" sagt eine Menge über die Detailliertheit der zugehörigen Geschäftsprozesse und damit über den Implementierungsaufwand aus. Sie ist als Vorlage für Abschätzungen wichtig, weil komplexe Anforderungen zur realistischen Abschätzung ggf. erst noch in Teilanforderungen zerlegt werden sollten.

Das "Risiko" fasst die drei oben genannten Attribute als Beurteilung zusammen: eine instabile komplexe Anforderung hoher Priorität stellt ein viel höheres Risiko für das Projekt dar als eine stabile einfache Anforderung niedriger Priorität. Daran können Sie einerseits erkennen, wo noch Klärungsbedarf vor der Abschätzung besteht und andererseits festlegen, was zuerst realisiert werden sollte - nämlich immer das höchste Risiko!

Sie sollten ggf. ferner notieren, wer diese Anforderung wann gestellt hat (Quelle), wer als Ansprechpartner für diese Anforderung definiert wurde und wer sie bearbeitet (Autor). Ein "Status" (aktiv, gelöscht, umgesetzt, etc.) kann bei längeren Analysephasen oder bei der Arbeit mit einem Team von mehreren Analytikern ggf. auch sehr hilfreich sein.

Damit ist die In/Out-Liste zu einer echten Anforderungsliste (Download) angewachsen. Diese kann sehr pragmatisch mit Microsoft Excel geführt werden und passt ausgedruckt in der Regel querformatig auf wenige Blätter Papier.

Das nebenstehende Beispiel stammt aus einem konkreten Projekt, in dem ich unter anderem als Analytiker tätig bin. Ich führe in der Liste mittlerweile etwa 200 Anforderungen, wobei die hellgrauen bereits fertig implementiert sind oder nicht implementiert werden müssen (out, also gelöscht, sind). Hinter den vielen roten Dreiecken verbergen sich Kommentare, die erläutern, was mit der Anforderung gemeint ist, welcher AF sich dahinter verbirgt, warum Priorität, Komplexität und Risiko so eingestuft wurden, wie sie sind und ggf. auch, was an dem Meeting wichtiges gelaufen war. An den Datumsangaben können Sie auch erkennen, dass dieses Projekt bereits seit mehreren Jahren läuft (sogar länger, als ich hier schon schreibe) und mittlerweile auch bereits die zweite Pre-Analyse-Runde hinter sich hat.

Sie sehen in der obigen Anforderungsliste auch eine Spalte "Teilziele", in der ich notiere, welche Teilziele von der jeweiligen Anforderung abgedeckt werden. Wenn Sie nach der vermeintlichen Fertigstellung der Anforderungsliste in einem Test feststellen, dass es Teilziele gibt, die von keinen Anforderungen abgedeckt werden, sollten Sie in einer weiteren Anforderungsiteration diese Teilziele erneut in Frage stellen. Wenn Sie anders herum Anforderungen haben, die Sie keinem Teilziel zuordnen können, sollte entweder der Rahmen des Projekts durch weitere Teilziele erweitert werden oder die Anforderungen gehören raus! Eine Analyse der Anforderungen ist jedenfalls erst möglich, wenn Sie durch diesen Test die Lückenlosigkeit und Widerspruchsfreiheit von Teilzielen und Anforderungen feststellen können - alles andere gibt nur Ärger!

Sie sollten die Anforderungsliste dann auch um Anforderungsbeschreibungen (Download) ergänzen, denn der Name einer Anforderung ist oft nicht sehr aussagekräftig. Hier haben Sie die Möglichkeit, mit wenigen Zeilen und Sätzen jede einzelne Anforderung zu erläutern - ebenfalls sehr pragmatisch in Microsoft Word. Wenn Sie mit wenigen Sätzen nicht auskommen, kann dies ein Zeichen für eine hohe Komplexität der Anforderung sein und es könnte Sinn machen, diese in Teilanforderungen zu zerlegen, um die Komplexität besser in den Griff zu bekommen.

Ein weiterer wichtiger Aspekt ist die Definition von Akzeptanzkriterien, die dann bei der Abnahme geprüft werden können. Deshalb werden sie gerne auch direkt als "Abnahmekriterien" bezeichnet. Außerdem definiert sich oft die Qualität der Software über die Akzeptanzkriterien. Dies gilt sicherlich nicht für alle Anforderungen, weil oft schon aus der Anforderung hervorgeht, wann sie erfüllt ist. Dies muss aber nicht immer der Fall sein und manchmal ist es auch einfach hilfreich zusätzliche objektive Kriterien zu definieren. Bei dem oben erwähnten Kennzahlensystem kann es hilfreich sein anzugeben, dass die Kennzahlen bei einem Multiprojektmanagementsystem nach einer Formel aus Projektdauer, Anzahl Ressourcen und durchschnittlichem Stundensatz vor und nach jedem Einzelprojekt zu bilden und zum Vergleich über alle Projekte tabellarisch darzustellen sind. Diese Aussagen können bei der Abnahme als Akzeptanzkriterien zur Prüfung der eigentlichen Anforderung herangezogen werden: Wenn vor und nach jedem Einzelprojekt eine Kennzahl nach der Formel aus den angegebenen Daten gebildet wird und wenn es eine tabellarische Darstellung dieser Kennzahlen über alle Projekte gibt, ist die Anforderung an die Software, dass ein Kennzahlensystem enthalten sein muss, hinreichend abgedeckt. Konkrete Beispiele dienen gerade bei abstrakten Anforderungen zur Veranschaulichung und Vervollständigung; sie reduzieren außerdem das Risiko der Fehlinterpretation der Anforderung.

Die Definition der Akzeptanzkriterien bringt Sie oft automatisch vom "was" zum "wie", denn der Kunde ist in der Regel nicht gewohnt, sich so strikt an Prozesse und Phasen zu halten und die anderen Sichtweisen auf später zurückzustellen. Als Anbieter sind wir ja zurzeit eigentlich noch im Erstgespräch mit dem Kunden, haben ja eigentlich gerade erst von ihm das Fachkonzept (oder etwas Adäquates) erhalten, werfen einen ersten Blick darauf, bilden uns einen ersten Eindruck davon und vermitteln die notwendigen weiteren Schritte. Wir begründen also gerade, warum die Durchführung einer Pre-Analyse so wichtig ist. Die Anforderungen, die in unserem Gespräch bis jetzt gefallen sind, haben wir uns schon notiert und können daraus viele Fragen ableiten, die uns bei der Begründung der Pre-Analyse helfen. Sie werden als Anbieter kaum ein Fachkonzept mit einer Anforderungsliste inkl. der oben genannten Attribute und Akzeptanzkriterien bekommen, können aber sicherlich darstellen, dass die bereits vorhandenen Informationen eine gute Basis zur Aufarbeitung darstellen und die Pre-Analyse deshalb wohl sehr kurz ausfallen kann.

Die professionellen Tools für das Anforderungsmanagement wie DOORS von Telelogic [L24] oder RequisitePro von Rational [L7] haben den immensen Vorteil, dass sie fertige Strukturen vorgeben und auch die Verknüpfung zu anderen Dokumenten und Diagrammen bieten und damit eine direkte Weiterverwendung der Anforderungen in den folgenden Phasen und oft auch ein Reverse-Engineering unterstützen. Die Anforderungen mitsamt der Beschreibungen und Attribute werden dabei in einem Datenbanksystem geführt und können automatisch anhand von Vorlagen zu vollständigen Dokumenten zusammengesetzt werden. Diese wiederum können dann zur weiteren Verwendung als PDF- oder Word-Dokument an den Kunden übergeben werden. Sie werden beim Kunden im Gespräch wahrscheinlich aber oft nur Papier und Bleistift dabei haben und erst später im Büro die Notizen mit einem solchen Tool aufarbeiten; sonst ist der Kunde ggf. schnell überfordert und fühlt sich zu sehr gesteuert und verwaltet. Dies muss natürlich im Einzelfall entschieden werden und hängt sicherlich auch davon ab, ob Ihr Ansprechpartner einer von den jungen dynamischen Managern oder ein strukturiert arbeitender Ingenieur ist.

Sie sollten als Lieferant versuchen, die Anforderungen auf Vollständigkeit (bzw. Auslassungen) zu prüfen. Im Gegensatz zu anderen Prüfungen (beispielsweise auf Widerspruchsfreiheit) ist dies aber in der Tat schwierig, denn woher wollen Sie wissen, ob Ihr Kunde einen Wunsch vergessen hat? Letztendlich ist der Kunde natürlich für die Vollständigkeit der Anforderungen verantwortlich, aber durch gezielte Fragen anhand der Geschäftsprozessmodelle können Sie Ihren Kunden aus der Reserve locken. Eine andere Möglichkeit sind Brainstorming-Sitzungen mit verschiedensten Akteuren, Vergleiche mit Featurelisten ähnlicher Standardsoftwareprodukte im Markt, Interviews von Beratern und Experten aus der gleichen Branche oder auch die Suche nach Lücken in Darstellungen, Listen, Aufzählungen, Dokumenten, etc. Ein Vergleich mit der Arbeitsweise des Altsystems oder den Papieren, die im Geschäftsgang produziert werden, liefert oft Hinweise.

Anforderungen prüfen   Auslassungen?     Widersprüche?     Mehrdeutigkeiten?     Ungenauigkeiten?     irrelevante Informationen?     zu viel Design?

Fehlen Anforderungen?   Zustände/Stati?     Berechtigungskonzept?     Revisionssicherheit?     Was-wäre-wenn-Szenarien?     Multiuser-Fähigkeit?     Security/Datensicherheit?     Arbeitsumgebung?   Die Prüfung auf Vollständigkeit der technischen Anforderungen ist sicherlich einfacher, weil diese sich auch bei inhaltlich (also fachlich) völlig verschiedenen Projekten oft wiederholen. Damit erhalten Sie die Möglichkeit zum Aufbau einer Checkliste, die Sie von Projekt zu Projekt verbessern und erweitern können. Technische Anforderungen mit großem Einfluss auf die Architektur der Software sind beispielsweise Multiuser-Fähigkeit (Sollen mehrere Mitarbeiter gleichzeitig von verschiedenen Plätzen aus Artikel im gleichen Lieferschein ergänzen können?) oder die massive Unterstützung von Zuständen im Geschäftsmodell (Ist es wichtig, ob das Stückgut schon auf der Palette, der Barge oder dem RoRo-Schiff ist?). Zur Unterstützung solcher Anforderungen müssen dann ggf. spezielle Transaktionssysteme oder Statemachines verwendet werden, was beispielsweise zu völlig anderen Aufwänden führen kann.

Auch Aspekte wie die Revisionssicherheit (Versionierung, Historisierung), Security (Verluste bei Übertragungen, Verschlüsselung von Daten, Autorisierung, Authentifizierung, Verwendung von Zertifikaten) und die Steuerung von unterschiedlichen Berechtigungen für unterschiedliche Akteure in gleichen Anwendungsfällen führen zu einer deutlichen Verkomplizierung der Realisierung, inkl. der Tests, Bedienungsanleitung und Anwenderschulung. Die Möglichkeit für Was-wäre-wenn-Szenarien kann besonders tückisch sein, wenn die Ergebnisse verschiedener Szenarien auch noch als Variantenübersicht abrufbar und sogar später noch nachvollziehbar sein sollen. Oft wird auch die Umgebung des Arbeitsplatzes völlig vergessen: wenn die Software von einem Kranführer mit Handschuhen auf einem Touch-Screen bedient werden können muss, wird das Programm anders gestaltet werden, als wenn eine Leitstelle in einem Spezialraum möglichst viele Daten des zu überwachenden Systems gleichzeitig darstellen soll.

Bei den obigen Anforderungen bzw. Aspekten ist es teilweise schon schwierig, sie sauber als "funktional" oder "technisch" einzustufen. Ihnen ist sicherlich aufgefallen, dass ich einige davon schon bei den funktionalen Anforderungen als "typisch" dargestellt hatte. Manchmal werden diese Anforderungen einfach nur aus verschiedenen Sichten von verschiedenen Akteuren bzw. Interessensgruppen geäußert.