Qualität - Was kann man tun, damit ein Anforderungsdokument gut wird?


Zusammenfassung
Qualitätssicherung - Auch beim Anforderungsdokument und in der Fachabteilung!
Checkliste für Qualitätsanforderungen an ein Anforderungsdokument
Testbarkeit von Anforderungen
Walkthrough - Der Analytiker erklärt die Spezifikation
Aufspüren logischer Fehler - Der strukturierte Ansatz des Analytikers
Review - Was man beim Review beachten sollte!
Namen sind nicht Schall und Rauch
Der versteckte Fehler - Wieviel übersieht der Anwender?

vgl. auch Arbeitsorganisation, ein auf Grund von Leserwünschen erweiterter Abschnitt, der im Dezember 2003 in ein eigenes Kapitel ausgelagert wurde


Zusammenfassung

Dieses Kapitel setzt sich mit der Frage ausweinander, wie ein Anforderungsdokument qualitativ gut wird. Aufgezeigt werden formale und intuitive Methoden, mit denen ein Analytiker sein Dokument selbst sichten und prüfen kann. Ein umfangreicher Abschnitt widmet sich der Frage, wie verläßliche Prognosemodelle für all die Anforderungen erstellt werden können, die vom Fachanwender nicht ausgesprochen wurden, sowie dafür, festzustellen, wie verläßlich die Durchsicht des Anforderungsdokuments durch den Fachanwender ist. Eine Checkliste und eine Wortliste unscharfer und in Anforderungsdokumenten zu vermeidender Begriffe wird hier dargestellt. Auf Walkthroughs und die Review-Prozedur wird am Rande eingegangen. - Methoden zur eigenen Arbeitsorganisation und eine detaillierte Darstellung der Kommunikationstechniken mit Anwendern inkl. Fragetechniken zur Vollständigkeit und Richtigkeit der Anforderungen findet sich in den verlinkten Kapiteln.

Qualitätssicherung - Auch beim Anforderungsdokument und in der Fachabteilung!

Qualitätsmanager haben einen merkwürdigen Ruf. Sie gelten entweder als Bürokraten, Esoteriker oder Pessimisten - oder alles drei in einem. Qualitätsmanager werden fast prinzipiell als Feinde betrachtet, die ein Projekt nur aufhalten. Wahr ist, dass ein Optimist als Qualitätsmanager etwa so gut wie ein Bock als Gärtner ist. Wahr ist weiterhin, dass Qualität vernachlässigt wird, wenn es nicht klar definierte Kriterien gibt, die auch überprüft werden. Wahr ist zudem, dass Verbesserung nur dann erzielt werden kann, wenn der damit verbundene Fortschritt auch gemessen werden kann. Aufgabe eines Qualitätsmanagers ist es, zunächst Qualitätsstandards im gegebenen Arbeitsumfeld zu definieren, dann für deren Einhaltung zu sorgen und laufende Verbesserung anzustreben. In großen Organisationen verselbstständigt sich solch ein Prozess relativ leicht und degeneriert dann tatsächlich zum bürokratischen Monster. Ärgerlich wird es immer dann, wenn sich heraus stellt, dass vom QM-Prozess Ausnahmen existieren, z.B. bei Geschäftsführung, Marketing, bestimmten Fachabteilungen, einzelnen Mitarbeitern in produktionskritischen Schlüsselpositionen oder gar beim Qualitätsmanager selbst. In einer professionellen Organisation kann der Qualitätsmanager als die mächtigste Figur betrachtet werden und er ist bei IT-Projekten ein wichtiger Verbündeter des Business Analysten.
Beispiel aus der Praxis

Ich bat einmal einen QM-Spezialisten eines indischen Unternehmens, der im Auftrage eines Unternehmens für das ich auch gerade tätig war, einen Vortrag für die Auszubildenden der IT zu halten. Nach dem Vortrag stellte einer der Azubis die Frage was passiert, wenn die Geschäftsführung auf der Auslieferung eines qualitativ mangelhaften Produkts beharrt, obwohl der Qualitätsmanager dagegen ist. Der QM-Spezialist antwortete, dass der Qualitätsmanager über die interne Abnahme und Kundenfreigabe entscheidet, der Geschäftsführung nicht weisungsgebunden ist und jede diesbezügliche Entscheidung der Geschäftsführung ausser Kraft setzen könne. Dies sei in seinem Unternehmen bereits mehrfach geschehen.
Die Realität, gerade bei kleineren und mittleren Betrieben, sieht leider nicht ganz so aus.
Beispiel aus der Praxis

Bei einem Vorstellungsgespräch in einem mittelständischen Unternehmen stellte der Bewerber dieselbe Frage wie oben der Azubi. Der Geschäftsführer antwortete, dass man Qualitätsmanagement implementieren wolle, dass er sich aber im Zweifelsfall die Entscheidung über eine Produktauslieferung bei zweifelhafter Qualität selbst vorbehält.  Der Bewerber entschied sich, weiter selbstständig zu bleiben.
Im technischen Umfeld professioneller Organisationen der IT bzw. mit großen IT-Abteilungen ist ein definierter QM-Prozess nichts ungewöhnliches. Es gibt Dokumentationsvorlagen, Arbeitsvorschriften und Checklisten, manuelle Arbeitsschritte werden dokumentiert, Zeiten und Tätigkeiten werden belegt und Code-Verwaltungs- und Bug-Tracking-Systeme werden benutzt. Die Eintragungen in das Bug-Tracking-System werden auch statistisch ausgewertet. Dabei geht es nicht darum, einen Underperformer ausfindig zu machen, sondern im laufenden Projekt festzustellen, wo man eigentlich gerade steht und von einem Projekt zum nächsten Verbesserungen zu erarbeiten. Stellt sich z.B. heraus, dass die teuersten Fehler ein Resultat unzureichend spezifizierter Fachanforderungen sind, so wird das Analystenteam darüber nachdenken müssen, woran das liegt. Hat der zuständige Analyst Mehrdeutigkeiten stillschweigend geduldet? Wurde der Anwender zu einer Abnahme gedrängt, z.B. wegen Zeitdrucks, obwohl die Spezifikation nicht komplett verstanden worden war? Oder wurde die Spezifikation abgenommen, weil der Anwender nicht weiter interessiert war? Oder haben die Entwickler nicht nachgefragt sondern eigene Deutungen implementiert? War gar die Mehrdeutigkeit von der Organisation, die den Analytiker bezahlt, aus politischen Gründen gefordert? Stellt sich dagegen z.B. heraus, dass korrekt spezifizierte Features einfach nicht umgesetzt wurden, dann dürfte eine engere Betreuung der Designer und Entwickler durch den Analytiker im nächsten Projekt angezeigt sein.

Software wird vor Auslieferung getestet. Dabei soll nicht etwa Qualität in ein System hinein getestet werden, der Test soll vielmehr die von der Entwicklungsabteilung gelieferte hohe Qualität bestätigen. Testgrundlage ist der Wille des Auftraggebers, der sich ausschließlich im abgenommenen Anforderungsdokument und den für die aktuelle Produktversion angenommenen Change Requests niederschlägt. Getestet wird gegen dieses Anforderungsdokument. Damit dies möglich ist, muss es gut genug sein, um überhaupt ein IT-System bauen zu können. Gerade deshalb ist es sinnvoll, dass sich auch der Analytiker und die Fachabteilung über Qualitätsmanagement den Kopf zerbrechen und QM-Prozessen folgen, die eine hinreichend gute Spezifikation in annehmbarer Zeit bei akzeptablen Kosten liefert.

Checkliste für Qualitätsanforderungen an ein Anforderungsdokument

Ein Anforderungsdokument muss vollständig und richtig sein. Man sollte beim Einreichen einer Spezifikation zum Review folgende Punkte aushaken können:
Die Frage nach subjektiven Befindlichkeiten darf gestellt werden. Wenn sich ein Fachanwender oder der Analytiker nicht gut fühlt bzgl. der Spezifikation, dann sollte dem nachgegangen werden, auch wenn zunächst kein rational nachvollziehbarer Grund feststellbar ist.

Abschließend muss festgestellt werden, dass der Kundenkontakt für die aktuelle Version abgeschlossen ist, dass also vom Kunden keine Anforderungen für die nun zu entwickelnde Produktversion mehr eingebracht werden.

Checklisten zur Business Analysis und andere IT-nahe Themen finden sich auch bei Construx.com  (inzwischen ist eine Registrierung notwendig) und http://www.rspa.com/checklists/. Diese Checklisten bildeten für mich lange Zeit eine Basis für meine eigene Arbeitsweise.

Testbarkeit von Anforderungen

Aus dem Anforderungsdokument wird ein Testplan für den Abnahmetest (acceptance test) erarbeitet. Im Grunde genommen machen Tester und Programmierer sehr ähnliche Arbeiten: Der Programmierer entwirft einen Algorithmus, der die aus dem Anforderungsdokument ableitbaren Anwendungsfälle vollständig abdeckt, der Tester erarbeitet Testszenarien, die dasselbe tun. Man kann als Faustregel festhalten:

Ist eine Anforderung nicht testbar, so kann sie auch nicht programmiert werden.

Vollständigkeit des Anforderungsdokuments ist dann nicht gegeben.

Bei der Erstellung des Testplans wirkt der Business Analyst mit, häufig erstellt er den Plan komplett selbst. Um die Testbarkeit der Anforderungen nachzuweisen liegt es nahe, die Testszenarien parallel zur Anforderungsanalyse zu erstellen. In der Praxis sollte davon allerdings Abstand genommen werden. Da sich Anforderungen häufig in der Spezifikationsphase ändern, müsste der Testplan mit geändert werden. Wenn eine spezifizierte Anforderung jedoch vollständig genug ist, sodass sie zum Review vorgelegt werden kann, kann als letzter Schritt vor der Vorlage ein Positivtest spezifiziert werden. Diese Vorgehensweise sollte allerdings mit dem Kunden abgesprochen sein, da die Kosten für die Testplanung parallel zur Spezifikationsphase entstehen. Mehrkosten fallen allerdings nicht an, d.h. nur dann, wenn der Kunde nach dem Review auf die Implementierung einer Funktion verzichtet.

In der Realität werden Testpläne jedoch nicht parallel zur Anforderungsanalyse erstellt, sondern parallel zur Entwicklung des Produkts. Somit ist für die Qualität des Analysedokuments nichts gewonnen. Der Analytiker sollte jedoch immer ein Augenmerk auf die Testbarkeit jeder Anforderung haben, meist kann sie intuitiv festgestellt werden. Im Abschnitt über den Review einige Abschnitte weiter unten findet sich folgende (erfundene) nichtssagende Anforderung, die bestimmt nicht testbar ist:
Erfundenes Beispiel

Auch bei überdurchschnittlicher Systemlast soll das Systemantwortverhalten im Normalfall gut sein, jedoch kann ausnahmsweise auch eine langsamere Antwortzeit akzeptiert werden. Die Mehrheit der Anfragen sollte z.B. in drei Sekunden wunschgemäß beantwortet sein. Hohe Systemlast tritt normalerweise vor wichtigen Feiertagen wie Weihnachten usw. auf.
Solche nicht quantifizierbaren und somit auch nicht testbaren Anforderungen findet man leider immer wieder. Offensichtlich können hierzu keine Testfälle konstruiert werden, die Spezifikation ist hier also noch nicht brauchbar.

Walkthrough - Der Analytiker erklärt die Spezifikation

Bei einem Walkthrough stellt der Business Analyst seine Spezifikation dem Fachanwender vor. Dabei geht er sie Schritt für Schritt durch und erklärt sie.

Ziel des Walkthrough ist es einerseits sicher zu stellen, dass der Fachanwender die Spezifikation nachvollziehen kann, andererseits sollen Verständnisprobleme des Fachanwenders behoben werden. Außerdem werden bei dieser Gelegenheit Fehler und Unschärfen gefunden und meistens werden gemeinsam Optimierungen einzelner Prozesse oder Prozessschritte erarbeitet. Ein gemeinsamer Walkthrough ist wesentlich effektiver als das einsame Durchsehen des Anforderungsdokuments im stillen Kämmerlein, vor allem, wenn der Anwender die Spezifikation erstmalig zu Gesicht bekommt.

Als Vorbereitung auf einen Walkthrough reicht es aus, wenn der Fachanwender den zu betrachtenden Teil gründlich liest. Falls ihm bereits Unklarheiten auffallen, sind Notizen dazu natürlich nicht falsch, aber die Gründlichkeit der Vorbereitung muss bei weitem nicht so tief sein, wie vor einem Review. Im Rahmen des Walkthroughs kann erwartet werden, dass evtl. sogar schwerwiegende Fehler entdeckt werden, und eine Lösung hierfür kann interaktiv zwischen Business Analyst und Fachanwender erarbeitet werden.

Walkthroughs müssen nicht immer die gesamte Spezifikation betreffen. Der Normalfall ist eher, dass ein Prozess oder Anwendungsfall herausgelöst aus seinem Kontext betrachtet wird, wenn er aus Sicht des Analytikers erstmalig fertig modelliert worden ist. Diese Stückelung hat den Vorteil, dass die Vorstellung des Prozesses relativ zügig erfolgen kann. Häufig lässt sich ein Walkthrough einfacherer Prozesse sogar telefonisch erledigen.

Es lohnt sich auch, das logische Datenmodell bzw. sogar das physikalische ERM mit dem Fachanwender durch zu sprechen, allerdings nur, wenn beim Fachanwender genügend Kompetenz dafür vorhanden ist. Dasselbe gilt auch für konkrete algorithmische Ansätze. In beiden Fällen ist jedoch Vorsicht geboten, dann man bewegt sich bereits im technischen Umfeld des IT-Projekts, also dort, wo der Business Analyst und der Fachanwender eigentlich nichts zu suchen haben. Datenmodelle und technische Algorithmen kommen i.d.R. auch nicht vom Business Analysten, sondern vom DB-Administrator bzw. DB-Programmierer oder vom Software-Designer. Die Vorstellung komplexer Abläufe kann ziemlich ins Auge gehen, wenn sie nicht verstanden werden.
Beispiel aus der Praxis

Im Rahmen eines zeitkritischen Abrechnungsalgorithmus sollten als Endresultat für den Anwender je Abrechnung eine definierte Menge Transaktionen angezeigt werden. Ursprünglich sollte der Algorithmus einmal pro Nacht laufen. Da sich das Ziel bewegte, wurde die Forderung gestellt, dass mehrere Abrechnungsläufe in einer Nacht simuliert werden müssten. Zunächst schlug der Business Analyst vor, dass der Abrechnungslauf zweimal pro Nacht laufen sollte. Da sich jedoch der Fachanwender weder auf die Anzahl der zu verarbeitenden Daten noch auf eine maximale Anzahl notwendiger Abrechnungsläufe festlegen wollte, lehnte der DB-Admin nach einer kurzen überschlägigen Rechnung mehrere Abrechnungsläufe ab. Er konnte alleine auf Basis der verfügbaren Vorgaben nicht garantieren, dass mehr als ein Abrechnungslauf pro Nacht auf der vorhandenen Hardware machbar sei. Der IT-Projektleiter informierte den Fachanwender über die stattfindenden Überlegungen, was dieser jedoch eher so verstand, dass die Kosten weiter in die Höhe getrieben werden sollten. Der Business Analyst, der auch als Algorithmentheoretiker ganz brauchbar war, arbeitete ein Verfahren aus, bei dem anstatt mehrere physikalische Transaktion zu erzeugen nur eine einzige physikalische Transaktion erzeugt und mehrere virtuelle angezeigt werden sollten. Die Funktionstüchtigkeit des Verfahrens ließ sich von ihm formal beweisen, ebenso, dass dessen Performance klar besser ist. Weder der zuständige Mitarbeiter des Unternehmens, das mit der Gesamtprojektleitung betraut war, noch der eigene Projektleiter des IT-Teams, noch der Fachanwender verstanden das Verfahren. Dies ging so weit, dass der Fachanwender unterstellte, dass das IT-Team die Anforderung übersehen hätte und der Gesamtprojektleiter sich nicht vorstellen konnte, dass das dynamische Erzeugen und Anzeigen von virtuellen Transaktionen schneller gehen sollte, als das Lesen und Anzeigen ausschließlich physikalisch gespeicherter Transaktionen.
Der Walkthrough ist innerhalb von IT-Projekten eine recht normale Angelegenheit. Der Business Analyst macht auch einen Walkthrough mit dem Software-Designer. Um sicher zu stellen, dass fertiger Code auch den Anforderungen entspricht, macht der Entwickler mit dem Analytiker häufig einen Code-Walkthrough des fertigen Codes und zuvor des Design-Ansatzes bzw. Pseudocodes. Ebenso stellt der Analytiker dem Tester die Spezifikation vor, und der Tester seinen Testplan dem Analytiker.

Aufspüren logischer Fehler - Der strukturierte Ansatz des Analytikers

Ein Analytiker wird hauptsächlich fürs Denken bezahlt. Eine der leichtesten Übungen für ihn ist dabei das Aufspüren logischer Fehler auf Grund eines soliden strukturierten Vorgehens. Dieselbe Methodik, die zur Suche logischer Fehler benutzt werden kann, kann auch im Rahmen der Gap Analysis benutzt werden.

Folgende logische Fehler lassen sich ohne weiteres durch strukturierte Analysemethodik erkennen:
fehlerhafter Prozess - EVA

Der Analytiker kann durch formales Vorgehen häufig lediglich feststellen, dass ein logischer Fehler vorhanden ist, nicht jedoch genau wo. Fällt z.B. eine Ausgabe eines Prozesses einfach vom Himmel, so kann diese Ausgabe entweder gar nicht notwendig, vielleicht sogar gar nicht gewünscht sein, oder aber es wurde lediglich vergessen, die zugehörige Verarbeitungsvorschrift zu definieren, oder es fehlt sowohl der notwendige Satz Eingabedaten als auch die zugehörigen Verarbeitungsschritte. Liegt z.B. eine Eingabe vor, die nicht weiter verarbeitet wird, so kann entweder die Eingabe tatsächlich überflüssig sein, oder aber die notwendigen Verarbeitungsschritte wurden noch nicht definiert, evtl. soll die Eingabe auch nur durchgereicht werden und nur die Ausgabe fehlt.

Eine einfache, wenn auch zeitaufwendige Nachweismethodik für die Vollständigkeit der Daten besteht in der tabellarischen Auflistung jedes einzelnen Datenelements, das innerhalb des Anforderungsdokuments auftaucht. Dabei werden für jedes einzelne Datenelement folgende Informationen zusammen getragen:
Kann eine Spalte nicht ausgefüllt werden, dann liegt offensichtlich ein Fehler vor.

Die Verarbeitungsschritte der meisten Prozesse bzw. Anwendungen sind so trivial, dass ein algorithmisches bzw. mathematisches Beweisverfahren nicht notwendig ist, sondern der Augenschein genügt. Es reicht also, für die Standardfälle jeden Verarbeitungsschritt nochmals nachzuvollziehen und im Analysedokument auszuhaken. Komplexe Algorithmen sollten formal bewiesen werden und alles, was nicht vollkommen trivial ist, sollte zumindest mit zwei oder drei Beispielen, die auch die Randbedingungen (Einschwingverhalten, eingeschwungenes System, Ausschwingverhalten) abdecken, nachvollzogen werden. Diese Beispiele gehören in die Spezifikation, sodass sie auch vom Fachanwender beim Review kritisch betrachtet werden können.

Review - Was man beim Review beachten sollte!

Beim Review handelt es sich um einen formalisierten Prozess der dazu dient, den Inhalt des Anforderungsdokuments zu verifizieren. Ein Review sollte nicht mit einem normalen Meeting verwechselt werden, das dem Austausch von Informationen, der Gewinnung neuer Erkenntnisse oder der Festlegung und Verteilung von Arbeitspaketen dient. Zwar gelten für die Vorbereitung eines Review dieselben Regeln wie für alle Meetings. In einem Review werden jedoch keine neuen Erkenntnisse gesucht oder Kreativität angestrebt und es findet auch keinerlei Austausch oder Diskussion zwischen den Teilnehmern statt, sondern das zu reviewende Dokument soll inhaltlich auf Lücken und Fehler untersucht werden. Wichtig ist, dass sicher gestellt ist, dass das Dokument auch vor dem Review komplett und gründlich durchgesehen wird und Lücken oder Fehler mit einem Korrekturvorschlag reklamiert werden müssen. Die Review-Teilnehmer kommen mit fertigen Arbeitsergebnissen (= ihre Anmerkungen zum Dokument) in das Review-Meeting und teilen diese nur mit. Vage Hinweise oder die Äußerung von Wünschen oder Forderungen haben zu unterbleiben, diese Dinge müssen schon vorab geklärt und die daraus erarbeiteten Ergebnisse im Anforderungsdokument festgehalten sein.
Beispiel aus der Praxis

Ein 50-seitiges Dokument sollte durch den ersten Review. Der Projektleiter, der die Moderation übernommen hatte, hatte eine Stunde Zeit angesetzt. Er begann mit dem ersten Abschnitt auf Seite 5. Seine Frage "Gibt es zu Seite 5 Kommentare?" wurde zunächst zur Kenntnis genommen. Er machte weiter: "Seite 6? Seite 7?" Schließlich stellte sich heraus, dass die meisten Teilnehmer das Dokument nur überfolgen und nicht gezielt auf Lücken hin untersucht hatten. Das Review-Meeting wurde sofort abgebrochen. Die Teilnehmer hatten nicht verstanden, dass im Review weder kreativ gearbeitet wird noch das Dokument gelesen wird, sondern lediglich Lücken aufzuzeigen sind.
Das Anforderungsdokument sollte vor einem Review mit dem Kunden zunächst informell durchgesehen und nochmals nachkorrigiert werden. Die informelle Durchsicht hilft vor allem, Mehrdeutigkeiten aufzudecken. Es hat sich bewährt, sowohl in Dokumenten als auch im Gespräch auf vage oder subjektive Begriffe zu achten. Meine Liste enthält:

usw., etc., z.B., das ist klar, offensichtlich, normal, schnell, langsam, durchschnittlich, einige, viele, wenige, manchmal, immer, gewöhnlich, meist, häufig, oft, nie, ausnahmsweise, regelmäßig, sicher, deshalb, darum, daraus folgt. Dazu kommt das explizite Aushaken von Aufzählungen bzw. Listen und ein Augenmerk auf Alternativen (oder) sowie das Hinterfragen von pauschalen Verarbeitungs-Begriffen wie zurückgewiesen, verarbeitet, gelöscht, geändert, neu angelegt, ignoriert, behandelt und nicht-Festlegungen wie flexibel, wunschgemäß, ordnungsgemäß. Besonders bei quantitativen Überlegungen muss auf vage Wertungen wie gut, schlecht, unterdurchschnittlich, durchschnittlich, überdurchschnittlich, normal, angemessen, ausreichend, befriedigend, mangelhaft, ungenügend, mehrheitlich / Mehrheit / Mehrzahl, Minderzahl, wichtig, unwichtig.

Folgendes Beispiel ist von mir frei erfunden, ich stolpere aber über derartige Aussagen immer wieder, die zwar eine Befindlichkeit und subjektive Sichtweise ausdrücken, nicht jedoch geeignet sind, um von einem Technik-Team als messbare Zieldefinition akzeptiert zu werden.
Beispiel (erfunden)

Auch bei überdurchschnittlicher Systemlast soll das Systemantwortverhalten im Normalfall gut sein, jedoch kann ausnahmsweise auch eine langsamere Antwortzeit akzeptiert werden. Die Mehrheit der Anfragen sollte z.B. in drei Sekunden wunschgemäß beantwortet sein. Hohe Systemlast tritt normalerweise vor wichtigen Feiertagen wie Weihnachten usw. auf.
Neben den nichtssagenden markierten Begriffen müsste noch erklärt werden, wie das Systemantwortverhalten gemessen wird, wodurch sich eine Anfrage auszeichnet und nach welchen Kriterien die Systemlast gemessen wird. Zwar wird eine Aussage gemacht, dass vor bestimmten Feiertagen etwas passiert, aber nicht genau, wie lange vorher. Handelt es sich um Tage, Wochen oder Monate? Zwar wird gefordert, dass eine Anfrage binnen drei Sekunden beantwortet sein muss, aber es wird nicht gesagt, wie dieses Antwortverhalten definiert ist. Time to first byte, time to last byte, Beginn der Verarbeitung nach Eintreffen der Anfrage?

Jede Regel und jede Entität und deren Zusammenfassungen in einem Prozess muss auf Vollständigkeit und Richtigkeit geprüft werden. Bei Prozessen lassen sich grob drei Verhaltensweisen erkennen: Einschwingverhalten, eingeschwungenes System und Ausschwingverhalten. D.h., dass der erste Durchlauf des Prozesses, der "normale" Durchlauf und der letzte Durchlauf betrachtet werden müssen. Wird die Vollständigkeit und Richtigkeit eines Prozesses bestätigt, so sollte dies auch schriftlich fixiert werden, sodass der Prozess nicht mehr im nächsten Review diskutiert werden muss.

Eine brauchbare Spezifikation enthält für jede Rechenvorschrift auch mehrere Beispiele, bei denen Randwerte und "normale" (zufällige) Werte dargestellt werden. Auch die Richtigkeit dieser Beispiele ist zu verifizieren, und zwar vor Beginn des Review-Meetings. Gelegentlich zeigt sich jedoch, dass es Verständnisprobleme gab, die, wenn es schnell genug geht, noch während des Reviews ausgeräumt werden können.

Falls Algorithmen und Datenstrukturen auch graphisch dargestellt werden, so muss die Darstellung gegen die begleitenden Texte abgeglichen werden.

Über das Review wird ein Protokoll geführt, in dem jeweils (am besten tabellarisch) steht:
Sofern sich im Rahmen einer gefundenen Lücke heraus stellt, dass die Korrektur noch zu erarbeiten ist, können Arbeitspakete verteilt werden. In diesem Fall wurde aber schlechte Vorarbeit geleistet und bei den informellen Durchsichten der Spezifikation wurde nachlässig gearbeitet.

Als Auftraggeber bzw. Fachanwender sollten Sie sich nicht zurück halten, denn es geht um Ihr Produkt. Wenn Sie etwas im Rahmen der Vorbereitung zum Review nicht verstehen, dann reklamieren Sie dies auch im Review als unklaren bzw. unverständlichen Abschnitt. In der nächsten Version des Dokuments sollte dann eine Formulierung gewählt werden, die klarer ist. Ihr Ehrgeiz sollte sein, dass das Anforderungsdokument, das Ihnen Ihr Analytiker gegeben hat, zerstört wird. Nur, wenn Ihnen dies nicht einmal mehr mit den teuflischten Szenarien gelingt, die Sie sich ausdenken können, ist es gut genug, um als solides Fundament für das darauf aufzubauende IT-System zu dienen.

Als Zeitdauer für einen Review sollte man nicht mehr als eineinhalb oder zwei Minuten je Seite plus vielleicht 15 Minuten für allgemeines blabla ansetzen. Das Dokument wird nur seitenweise durchgegangen, und über gefundene Fehler oder Lücken gibt es nur selten Diskussionsbedarf. Die Gesamtdauer eines Reviews sollte zwei Stunden nicht überschreiten, da sonst bei den Teilnehmern Ermüdungserscheinungen auftreten. Nötigenfalls kann eine dritte kreative Stunden nach dem Review angehängt werden, sollte doch noch Bedarf für die Klärung von Fragen oder die Erarbeitung von Lösungen herrschen.

Namen sind nicht Schall und Rauch

Wird ein Produkt und seine zugehörigen Prozesse neu erfunden, so entsteht auch eine dem Team eigene Gruppensprache. Für bestimmte Daten, Verarbeitungsschritte oder Produktteile werden Namen erfunden. Diese Namen sollten in einem Glossar zusammen gefasst und erklärt werden, wobei Projekt abhängig auch jeweils eine deutsche und eine englische Bezeichnung vereinbart werden sollte. Gerade bei mehrsprachigen Umgebungen, z.B. deutsch sprechende Auftraggeber, die ein deutsches Anforderungsdokument wollen, das aber für ein englisch sprechendes Team professionell übersetzt werden muss, ist diese zweisprachige Vorgabe sinnvoll. Die Namen sollten auch im gesamten Dokument einheitlich verwendet werden, jede abweichende Verwendung sollte vermieden werden, und wenn sie unvermeidlich ist, dann muss auf die Abweichung hingewiesen werden.

Die Erfahrung zeigt, dass Namen gelegentlich redefiniert werden oder sich ändern. Die Erfahrung zeigt weiterhin, dass IT-Mitarbeiter dem sehr leidenschaftslos gegenüber stehen. Sie nennen intern etwas X und auf dem zugehörigen Bildschirmformular steht Y. Fachanwender tun sich dabei schwerer. Wenn am Ende Y auf dem Bildschirm zu lesen ist, dann wollen sie auch Y im Anforderungsdokument sehen. Dies kann im Rahmen der Implementierung z.T. in Forderungen gipfeln, deren Sinn dem IT-Mitarbeiter verschlossen bleibt.
Beispiel aus der Praxis

Eine Abteilung einer Behörde ließ in der hauseigenen Software-Abteilung ein Programm entwickeln, das Daten über die Bezahlung der Mitarbeiter im Hause verwalten sollte. Das Screen-Design blieb dem Entwickler überlassen, konkrete Anforderungen vor Entwicklungsbeginn wurden nicht gestellt. Bei der ersten Vorführung wurde reklamiert, dass auf einem Formular vor dem fraglichen Geldbetrag Gehalt stand, obwohl es sich um einen Beamten handelte, und Bezüge korrekt sei; bei einem Arbeiter müsse es Lohn heißen und nur beim Angestellten Gehalt. Der Entwickler machte eine etwas lockere Bemerkung dahingehend, dass er nicht wisse, ob er zu dieser Änderung noch Lust habe. Die Reaktion darauf war die Aussage, dass die Anzeige nicht korrekt sei und man den richtigen Text braucht. Der Entwickler entgegnete, dass dort auch das Wort Kohle stehen könnte, und das Produkt dennoch die richtigen Informationen liefern würde. Der Entwickler kündigte noch in der Probezeit.
Dem Business Analysten bleibt leider kaum etwas anderes übrig, als regelmäßig das gesamte Dokument zu überarbeiten, wobei darauf geachtet werden muss, dass der fragliche Begriff in anderem Zusammenhang durchaus korrekt sein kann. Deshalb und dank der Unwägbarkeiten der deutschen Grammatik tut es ein einfaches suchen und ersetzen nicht.
Beispiel aus der Praxis

Ein ungeduldiger Fachanwender empfahl suchen und ersetzen in einem werdenden Anforderungsdokument mit über 100 Seiten und zeigte wenig Verständnis dafür, dass der Analytiker sich einen Vormittag Zeit für die Überarbeitung des Dokuments wegen der Änderung eines halben Dutzends Begriffe heraus nahm. Der Analytiker erklärte darauf, dass er bei dieser Gelegenheit noch die verbleibenden Unschärfen, Mehrdeutigkeiten und grammatikalischen Fehler des letzten suchen und ersetzen - Laufes korrigiert hatte, die durch den Fachanwender einige Wochen zuvor auf diese Weise verursacht worden waren. U.a. war dabei ein Begriff A in B geändert worden, wobei B erst danach in C geändert wurde, also A und B nun C waren und aus einer alten Dokumentversion und dem jeweiligen Kontext wieder rekonstruiert werden mussten.
Die Einheitlichkeit der Begrifflichkeit, deren konsequente Verwendung und ein Konsens im gesamten Team über deren Bedeutung hat hohe Priorität.

Der versteckte Fehler - Wieviel übersieht der Anwender?

Grundlegende Überlegungen

Nicht das, was ein IT-Team nicht weiß, bringt ein Projekt zu Fall, sondern das, was es zu wissen glaubt.

Im Rahmen der Reviews bzw. schon im Rahmen der vorherigen informellen Durchsichten des Anforderungsdokuments ist der Business Analyst immer wieder im Zweifel darüber, ob auch alle Lücken und Fehler im Anforderungsdokument aufgedeckt werden. Wissen, das ihm fahrlässig vorenthalten wird, kann vom Analytiker nur dann erkannt werden, wenn sich logische Fehler in Abläufen einschleichen. Wenn jedoch in sich schlüssige Abläufe bereits vom Fachanwender falsch oder unvollständig kommuniziert werden, dann hat ein Analytiker ohne Detailkenntnis der konkreten Fachabteilung schlechte Karten, und selbst hervorragende Fachkenntnisse sind keine Garantie, wenn er mit gleichwertigen Alternativen zu tun hat, die vom Fachanwender fallabhängig gewählt werden.
Beispiel aus der Praxis

Bei der Betrachtung von Kapitallebensversicherungen im Rahmen eines Versicherungswirtschaft nahen Projekts wurde dem Analytiker nicht kommuniziert, dass (beim iebenfalls nur m Rahmen des Projekts zu betrachtenden Tarifs) eine Beitragsübernahme durch den Versicherer im Berufsunfähigkeitsfall gewünscht ist. Diese Lücke wurde nur zufällig noch vor Abnahme der Spezifikation entdeckt, nachdem der Business Analyst bei seinem Fachanwender eine dbzgl. Rückfrage gestellt hatte, da er sich selbst gerade bei der Konkurrenz über verschiedene Tarife informiert hatte und eigentlich nur wissen wollte, ob es nicht eine billigere Variante gibt.
Dies sind die wirklich teuren Fehler, denn sie führen dazu, dass die erste Version der gelieferten Software für den Fachanwender unbrauchbar ist. Lediglich die direkte Beobachtung der Fachanwender bzw. die direkte Mitarbeit vor Ort kann dem Analytiker helfen, solche versteckten Vorgänge oder Regeln zu finden. Bei einem neuen Produkt, zu dem es noch gar keine existierenden Vorgänge gibt, kann allerdings dieses Mittel nicht angewendet werden.

Der Analytiker muss also einen Weg suchen, um eine Metrik zu erarbeiten, anhand derer er feststellen kann, wie aufmerksam seine Fachanwender sind, wenn sie Prozesse überprüfen. Auf Basis dieser Metrik soll ermittelt werden können, wie viele Fehler und Schwächen im Dokument übersehen werden bzw. wie lange es dauert, bis sie aufgedeckt werden. Hier dargestellt sind nur Vorgehensweisen, die ich selbst angewendet habe. Kommentare und Erfahrungsberichte zu anderen Vorgehensweisen sind willkommen (Kontakt, oder eine Diskussion im Forum).

Der absichtliche Fehler als Basis für eine Metrik übersehener Fehler

Das sicherste Mittel, das ich bisher fand, ist das bewusste und absichtliche Einstreuen von Fehlern in das Analysedokument, und zwar noch bevor es der Fachanwender das erste Mal zu sehen bekommt. Diese Fehler sollten nicht rein zufällig verstreut und auch nicht offensichtlich sein. In meiner Praxis hat sich folgendes Vorgehen in doppelter Hinsicht bewährt: Erstens erhält man eine relativ verläßliche Metrik oder doch einen sicheren Hinweis auf einen Trend, zweitens macht man sich unbeliebt.

Nach internem Abschluss einer ersten Version eines Anforderungsdokuments, das der Business Analyst seinen Fachanwendern aushändigen will, schiebt der Analytiker noch einen Zwischenschritt ein. Zunächst sucht er sich einen Ansprechpartner, der ein gewisses Maß an Sachverstand aus dem zu untersuchenden Fach und aus der IT mitbringt. Dies kann der Projektleiter oder ein anderer Analytiker sein, evtl. auch ein Mitarbeiter der Fachabteilung, der aber ansonsten nichts mit dem Analyseprozess zu tun hat. Mit diesem Ansprechpartner wird zunächst eine Art informeller interner Review gemacht, bei dem sicher einige Fehler, Schwächen oder interpretierbare Passagen gefunden werden. Ist solch ein Ansprechpartner nicht aufzutreiben, dann reicht es auch, dass sich der Analytiker einen Zuhörer sucht, z.B. einen Werkstudenten, dem er sein Dokument Seite für Seite vorträgt. Alleine durch die Verständnisfragen des Studenten werden ebenfalls Fehler gefunden. Man kann auch "schöne" Fehler, die man als Analytiker alleine noch vor Freigabe des Dokuments gefunden hat, drin lassen.

Diese Fehler werden protokolliert. Dann überlegt sich der Analytiker, welche der Fehler er vor Auslieferung des Dokuments noch behebt. Außerdem ändert er noch bewusst Prozesse, von denen er glaubt oder weiß, dass sie richtig sind, so ab, dass sie Fehler enthalten. Auch diese zusätzlich eingebauten Fehler werden protokolliert. Das Fehlerspektrum sollte von vollkommen offensichtlichem Unsinn bis zu möglichst versteckten Fehlern führen, also z.B. von fehlenden Eingaben, die im Laufe des Prozesses verarbeitet werden, oder extrem vagen Formulierungen bis zu Vorzeichenfehlern oder verrutschten Dezimalpunkten in komplexen Berechnungen; oder Abläufe, bei denen Alternativen fehlen, zu falschen Resultaten führen oder bei denen Produkte (wie z.B. der Versicherungstarif im Fallbeispiel)  falsch oder unvollständig beschrieben werden etc. Als Daumenpeilwert setzte ich etwa eine solchen Fehler pro fünf bis zehn Seiten Spezifikation oder einen solchen Fehler auf drei bis fünf Anwendungsfälle an, ausnahmsweise auch etwas mehr.

Diese Version wird dann dem Anwender zur Prüfung gegeben und man wartet ab, was beim Review passiert. Im Review-Protokoll werden alle Reklamationen der Fachanwender festgehalten. Diese Reklamationen gleicht man nun gegen seine eigene Fehlerliste ab. Dabei lassen sich folgende Fehlerkategorien unterscheiden:

Fehlertyp

 Anzahl bekannt

 Anzahl gefunden
vom Anwender
 Prozentualer Erfolg des Anwenders
absichtlich übrig gelassene Fehler
 x1 (=100%)
 a1
 e1 = a1 / x1 * 100
absichtlich eingebaute Fehler
 x2 (=100%)
 a2
 e2 = a2 / x2 * 100
echte (neue) Fehler
 x3 (unbekannt,
 =100%)
 a3

Zur Abschätzung von x3, also der Gesamtzahl der noch nicht entdeckten Fehler, kann man folgende Rechnung anstellen:

Die Gleichung (G1 * e1 + G2 * e2) / 2 = a3 / x3 * 100 wird nach x3 aufgelöst:

x3 = (200 * a3) / (G1 * e1 + G2 * e2)

Dabei sollte die hier dargestellte Formel nicht zum Glauben verleiten, dass es sich um ein exaktes Verfahren handelt. Bei den absichtlichen Fehlern handelt es sich abhängig von der Spezifikationsgröße wahrscheinlich nur um 10 oder 15 Stück. Werden drei Fehler zufällig gefunden, dann sieht das Ergebnis deutlich besser aus, als es ist. Man sollte also eher eine Tendenz herleiten und prüfen, ob e1 und e2 im oberen, mittleren oder unteren Drittel anzusiedeln ist und daraus schließen, dass die Reviewqualität ein hohes, mittleres oder niedriges Projektrisiko darstellt.

G1 und G2 sind Gewichte, mit denen man das Auffinden der übrig gelassenen bzw. absichtlich eingebauten Fehler verstärkt oder abgeschwächt in die Schätzung der echten noch nicht gefundenen Fehler einfließen lässt. In erster Näherung können G1 = G2 = 1 sein. Zeigen sich jedoch massive Abweichungen zwischen den Werten e1 und e2, so lassen sich Rückschlüsse auf die Qualität der versteckten Fehler ziehen. Ist der prozentuale Erfolg des Anwenders deutlich größer bei den absichtlich eingebauten Fehlern als bei den absichtlich übrig gelassenen Fehlern, so waren die selbst erfundenen Fehler nicht gut genug. G2 sollte dann klein angesetzt werden, sodass sich G2 * e2 an e1 annähert. Deutlich größer bedeutet ein Unterschied von einem Drittel oder mehr. Im Nebeneffekt stellt der Analytiker dabei fest, dass er selbst noch nicht genug Fachwissen mitbringt, um den Anwender zu täuschen bzw. um für Spezialisten offensichtliche Fehler zu erkennen.

Ist das Verhältnis anders herum, die absichtlich eingebauten Fehler werden nicht so leicht gefunden, wie die absichtlich übrig gelassenen, dann sollte man als Analytiker ins Grübeln kommen. Dies kann ein Indiz sein, dass die Fachanwender weit weniger Verständnis von der Materie haben, als der Analytiker annimmt. Auf jeden Fall ist es ein Indiz, dass zwar natürliche Fehler in den Prozessen erkannt werden, nicht jedoch grobe Schnitzer des Analytikers. Man weiß also, wo man suchen muss. Der Analytiker sollte G2 abhängig von seiner eigenen Berufserfahrung wählen, ein Anfänger sollte eher einen Wert bis 1,5 ansetzen, ein erfahrender Analytiker, der seine Stärken und Schwächen kennt, einen Wert um 1 oder sogar darunter.

Das Prinzip basiert auf der Annahme, dass der Anwender ungefähr genau so viele echte Fehler entdeckt, wie absichtlich übrig gelassene bzw. eingebaute. Nähert sich der gemessene prozentuale Erfolg des Anwenders an 100% an, so hat man gute Chancen, dass auch die meisten echten Fehler gefunden wurden. Liegt der Wert sehr niedrig, unter 50%, was bei einer Schulnote ein "mangelhaft" wäre, dann müssen sofort Maßnahmen ergriffen werden, damit sich das Ergebnis in der nächsten Runde verbessert. Ursachenforschung ist angebracht, häufig haben die Fachanwender sich nur nicht genügend vorbereitet. Eine Verbesserung ist in den seltensten Fällen eine Kompetenzfrage, die zur Folge hätte, dass der Ansprechpartner auf Fachanwenderseite ausgewechselt werden muss. Meist ist es eine Frage der Zeit (Tagesgeschäft, andere Aufgaben erscheinen wichtiger, nicht genügend Zeit zum Studium der Spezifikation), des Engagements  ("nine to five - Mentalität"), der Reaktivität (keine eigene Initiative) und der Gründlichkeit der Vorbereitung (der Fachanwender geht davon aus, dass alles stimmt).
Beispiel aus der Praxis

Im Rahmen eines Projekts sollten Daten bestimmter Produkte verwendet werden. Der Projektleiter hatte ernsthafte Sorgen, dass die mit der Datenpflege betrauten Fachanwender gründlich genug bei der Durchsicht von Spezifikationen waren und nicht zuverlässig verifizieren könnten, ob auch alle gewünschten Daten geliefert werden könnten. Aus diesem Grund bat er mich, ein geeignetes Verfahren zu entwickeln, um abzuschätzen, wie genau die Durchsicht war. Dies war die Geburtsstunde dieses Verfahrens. Ich kannte die Datenwelt fachlich gesehen selbst nicht gut genug, also schrieb ich munter Unsinn zu fast jedem Produkt, ließ Daten weg, von denen ich wusste, dass sie vorhanden waren, vertauschte Daten von Produkten oder fügte sinnlose Daten hinzu. Ich übertrieb etwas, denn pro Produkt (etwa 15 Stück) waren ein oder zwei absichtliche Fehler eingebaut worden. Ich ging davon aus, dass ich den Umschlag, in dem ich alle absichtlichen Fehler aufgelistet mitgebracht hatte, dringend zu meiner "Entlastung" brauchen würde. Aufgedeckt wurden nur etwa ein Fünftel aller Fehler. Der Projektleiter eskalierte den Vorfall und ich wurde dafür freigestellt, jedes einzelne Datum selbst zu verifizieren.
Ist die Zahl der absichtlichen Fehler groß genug, kann noch nach der Fehlerschwere klassifiziert werden. Werden komplizierte Fehler in demselben Maß entdeckt, wie offensichtliche?

Nach dem Review sollte man die nicht gefundenen absichtlichen Fehler nicht aufdecken. Wenn sie im nächsten oder übernächsten Review gefunden werden, lässt dies den Schluss zu, dass sich das Gesamtergebnis ebenfalls verbessert hat. Man kann jedenfalls mit zunehmender Anzahl Reviews eine Tendenz ermitteln, wie viele Fehler noch übrig sein dürften.

Fachanwender bzw. Fachabteilungen sind in den seltensten Fällen mit qualitätssichernden Maßnahmen im Sinne der IT vertraut. Ein QM-Prozess, der Qualität misst und dafür genutzt wird, kontinuierliche Verbesserungen zu implementieren, ist dort kaum anzutreffen. Häufig wird auch das dahinter steckende Prinzip nicht verstanden: Man sucht Lösungen und Verbesserungen, nicht Schuldige.

Wenn man als Analytiker das von mir vorgestellte Verfahren anwenden will, dann sollte sich darüber im Klaren sein, dass dieses Verfahren beim Fachanwender nur selten auf Gegenliebe stößt. Da implizit eine Überprüfung seiner Arbeitsergebnisse stattfindet, kann er sich angegriffen fühlen. Eine offene Eskalation von schlechten Ergebnissen ist nur dann hilfreich, wenn allen Beteiligten klar ist, dass Schuldzuweisungen nicht konstruktiv sind. Die Erfahrung zeigt auch, dass die Befürchtung, dass erstaunlich viele Fehler nicht gefunden werden, leider berechtigt ist.
Beispiel aus der Praxis

In einem unter Zeitdruck stehenden Projekt lagen die Nerven beim Auftraggeber schon seit geraumer Zeit blank. Als ich dann noch darauf aufmerksam machte, dass ich dieses Verfahren zur Qualitätssicherung anwende, gab es eine recht heftige Mail mit großem Verteiler, dass ich solche Aktionen, die nur Zeit kosten und der Tarnung von echten Fehlern dienen würden, unterlassen sollte. Die Mail hatte beim IT-Team erheblichen Unterhaltungswert. Der Auftraggeber hatte sich für die Korrektur einer Version der Spezifikation einmal über zwei Monate Zeit gelassen. Der betroffene Fachanwender war schon mehrfach dadurch aufgefallen, dass er Frage- und ToDo-Listen nur oberflächlich abgearbeitet und letztendlich nicht wirklich zur Lösung der anstehenden Aufgaben beigetragen hatte.
Die Fehlerzahl in einem Dokument erhöht sich natürlich durch absichtlich eingebrachte Fehler. Somit kann ein nicht informierter Spezialist zu dem Schluss kommen, dass die Ergebnisse des Business Analysten überdurchschnittlich viele Fehler enthalten. Dem sollte vorgebeugt werden. Ein einfaches Mittel dazu ist, dass die absichtlichen Fehler vor der ersten Übergabe des Dokuments an den Fachanwender dokumentiert und den verantwortlichen Personen im IT-Team und bei der Fachabteilung vorab mitgeteilt werden. Bedingung ist dabei, dass die verantwortlichen Personen nicht am Review des Dokuments beteiligt sind und sicher ist, dass sie die beabsichtigten Fehler für sich behalten.

Inwiefern es gut oder schlecht ist, dass die Fachanwender wissen, dass es versteckte Fehler gibt, konnte ich noch nicht entscheiden. Das Wissen kann zu einer intensiveren Suche animieren, es kann aber auch zu einer ablehnenden Haltung führen, da aus Sicht des Fachanwenders vermeintlich unnötiger Zusatzaufwand verursacht wird. Die Anzahl der absichtlichen Fehler muss auf jeden Fall groß genug sein, dass sich eine Aussage über echte Fehler ableiten lässt, jedoch klein genug, sodass der Fachanwender nicht wirklich mehr Arbeit hat.

Evaluierung von Ergebnisse aus Arbeitspaketen des Fachanwenders

Die Evaluierung von Ergebnissen aus Arbeitspaketen, die der Fachanwender im Rahmen eines Analyseprozesses zu erledigen hat, kann mit Vorsicht als Prognosemodell für die Qualität der Mitarbeit bzw. Kontrolle des Anforderungsdokuments heran gezogen werden. Grundlage der dahinter steckenden Überlegungen ist, dass Aussagen über die Arbeitsweise und die Arbeitsqualität der Fachanwender bezogen auf das laufende IT-Projekt gemacht werden können. Man sollte sich dabei nicht zu der ebenso unsinnigen wie unnötigen Betrachtungsweise verführen lassen, dass sich die Aussagen, die aus dem für den Fachanwender fremden IT-nahen Arbeiten hergeleitet werden, auf sein Hauptbetätigungsfeld übertragen lassen, in dem er zuhause ist. Zu beachten ist, dass diese Arbeitspakete im Rahmen des Erstellungsprozesses der Spezifikation erledigt werden. Das Prognosemodell kann also meist erst nach der Hälfte des Weges zum fertigen Anforderungsdokument angewendet werden und eignet sich auch nur für mittlere oder große Spezifikationen.

Braucht ein Business Analyst eine Information, so kann er zwei Wege wählen:
  1. den direkten, z.B. durch einen Besuch, einen Anruf oder eine EMail.
  2. den kumulierten, z.B. durch eine Fragensammlung oder eine ToDo-Liste.
Eine ToDo-Liste oder ein zu beantwortender Fragenkatalog kann bereits als Arbeitspaket klassifiziert werden, dessen Ergebnis messbar ist. Von der Vorgehensweise bei der Bearbeitung und der gelieferten Qualität lassen sich Rückschlüsse auf die Qualität bei der Bearbeitung des Anforderungsdokuments ziehen. Je ähnlicher die Arbeitspakete der Fehlersuche im Anforderungsdokument bzw. der Vervollständigung von Prozessen ist, um so eher ist ein Schluss erlaubt. Man sollte allerdings auch hier nicht übertreiben: Wenn einmal ein unzureichendes Ergebnis geliefert wird, dann kann es sich um einen Ausrutscher handeln. Eine Tendenz lässt sich jedoch meistens erkennen, wenn das dritte Arbeitspaket auf dieselbe Weise erledigt wurde.
Beispiel aus der Praxis

Der stellvertretende Projektleiter und der Business Analyst, beide auf Auftragnehmerseite arbeitend, hatten einen Fragekatalog mit nicht ganz 50 Fragen ausgearbeitet. Dazu waren fast zwei Tage notwendig gewesen. Der Analytiker ging davon aus, dass nach Beantwortung der erste Schritt zur Abnahme des Konzepts möglich sein sollte und sah drei Arbeitstage für den Rücklauf vor. Der Fachanwender bedankte sich für die Zusendung der Fragen und sicherte zu, sie sofort zu bearbeiten. Etwas später kam der Rücklauf. Der Fachanwender hatte zur Überraschung des Analytikers ca. 1 Minute je Frage aufgewendet. Bei Durchsicht der Antworten stellte sich heraus, dass zwei Drittel der Fragen nicht beantwortet oder dass die Frage nicht verstanden worden war und somit Antworten auf Fragen gegeben worden waren, die nicht gestellt gewesen waren. Etwa ein weiteres sechstel war unvollständig oder mehrdeutig, ins nötige Detail war nirgendwo gegangen worden. - Leider war es nicht möglich, den Fragenkatalog als ungenügend beantwortet abermals zurück zu schicken. Der Analytiker kontaktierte also telefonisch andere Experten beim Auftraggeber und fragte die einzelnen Punkte im Laufe der nächsten zwei Tage stückweise ab, der Mehraufwand wurde dem Kunden in Rechnung gestellt. - Diese Messung ließ sich fast eins zu eins auf die Rückläufe nach der Durchsicht des Anforderungsdokuments übertragen.
Das Beispiel aus der Praxis zeigt recht deutlich, dass korrekte numerische Prognosen für die Qualität des Anforderungsdokuments nicht möglich sind. Jedoch ist eine schlechte Messung noch immer besser als gar keine, so lange die Messung nur die Richtung zeigt.

Ein Rückschluss von rein praktischen (handwerklichen) Fähigkeiten auf die Qualität von Reviews oder informellen Durchsichten des Anforderungsdokuments ist nicht zulässig. Wird z.B. dem Fachanwender der Auftrag gegeben, alle vorhandenen Formblätter zu einem bestimmten Vorgang zusammen zu stellen, so wird er dazu i.d.R. nur in einige Schrankfächer greifen, in denen diese Blätter liegen. Interessant wird es dagegen, wenn er zusätzlich Erklärungen und Beispiele für Vorgänge außerhalb der Norm liefert. Proaktivität ist stets ein gutes Zeichen, wenn es um die Sicherstellung der Vollständigkeit von Vorgängen geht. Genau das Gegenteil ist der Fall, wenn gerade diese Fälle erst nach und nach und auch dann meist nur zufällig oder auf Grund seines gesunden Menschenverstandes vom Analytiker aufgedeckt werden. Ein typisches Beispiel hierfür ist das plötzliche Abbrechen eines Prozessabfolge, weil der Kunde zwischen zwei Prozessen verstorben ist.

Die Evaluierung von Ergebnissen aus Arbeitspaketen des Fachanwenders hat den Nachteil, dass lediglich eine grobe Daumenpeilprognose vorgenommen werden kann. Der Vorteil ist, dass das Verfahren ohne Tricks neben der normalen Arbeit Daten liefert und tatsächlich eine Prognose über die Größenordnung der versteckten Fehler getroffen werden kann.

Reevaluierung der Istaufnahme

Wird der Ablauf der Istaufnahme reevaluiert, so kann nachvollzogen werden, wie häufig bei existierenden Prozessen zunächst fehlerhafte oder unvollständige Angaben gemacht worden sind und wie lange es gedauert hat, sie zu finden. Dazu werden die Review-Protokolle ausgewertet, die idealerweise tabellarisch aufgebaut sind und neben dem gefundenen Fehler auch protokolliert wird, wie schwerwiegend er war. Aus den Protokollen kann für jeden Prozess ermittelt werden, wie viele Fehler gefunden wurden, und wie viele Prüfungen des Prozesses notwendig waren.

Nun ist ein existierender Prozess bei einer Istaufnahme natürlich greifbar, ein geplanter bzw. fiktiver bei der Anforderungsanalyse aber nur vorstellbar. Dadurch, dass weder Analytiker noch Fachanwender am vorhandenen Prozess nachmessen können, sondern nur auf ihre Phantasie und Analysefähigkeit angewiesen sind, kann regelmäßig davon ausgegangen werden, dass im Rahmen der Anforderungsanalyse mehr, meist deutlich mehr Fehler gemacht werden, als bei der Istaufnahme. Da die Mehrheit meiner Projekte mit neuen Produkten zu tun hatte, für die keine Istaufnahme möglich bzw. notwendig war, habe ich keine konkreten Zahlen als Erfahrungswerte zu liefern, die ich hier veröffentlichen will. Sofern Sie hierzu Datenmaterial haben, nehme ich es gerne auf.

Eine Möglichkeit zu einer Hochrechnung zu kommen besteht darin, dieselben Messungen wie bei der Istaufnahme bei der Sollzustandsanalyse im laufenden Projekt zu machen. Hat man einen Teil der Prozesse abgeschlossen und man kann davon ausgehen, dass sich nicht mehr all zu viel an dieser Untermenge des gesamten Anforderungsdokuments tut, dann kann man die vergleichbare Prozess-Untermenge aus der Istaufnahme betrachten und einen Faktor ermitteln, der auf die noch nicht vollständig definierten Prozesse hochgerechnet wird.

Zu beachten ist, dass viele Fachanwender zwar konkrete existierende Prozesse nachvollziehen können, jedoch fiktive bzw. neu zu erfindende Prozesse weder vollständig durchspielen noch selbstständig darstellen können. Ergebnisse einer Hochrechnung einer Organisation können also nicht ohne weiteres auf eine andere Organisation übertragen werden.

Die Reevaluierung der Istaufnahme hat den Vorteil, dass man auf gesichertes Datenmaterial zurück greifen kann und mit großer Sicherheit einen Trend für die zu erwartende Qualität und somit die durch die Fachabteilung zu vertretenden Folgekosten ermitteln kann, die aus mangelhaft überprüften und daher unvollständigen oder falschen Vorgaben im Anforderungsdokument entstehen. Vorteilhaft ist außerdem, dass die Prognose noch vor Beginn der Anforderungsanalyse erarbeitet werden kann. Nachteilig ist, dass nur eine grobe Tendenz festgestellt werden kann.

Messung der Reviewergebnisse

Falls in einem Anforderungsdokument im ersten Review bzw. der ersten informellen Durchsicht keine Fehler gefunden werden, dann ist etwas faul. In der Frühphase einer Analyse kann man davon ausgehen, dass ca. ein Viertel bis ein Drittel der ersten Dokumentenversion korrigiert werden muss. Diese Version ist i.d.R. noch bei weitem nicht fertig. Die Anwendung der Paretoregel kann hier leicht zu Selbstbetrug führen. Die erste Version wird tatsächlich nach ca. 20% der Zeit für eine informelle Durchsicht abgeliefert werden können, aber die vermeintlichen 80% der Arbeit bestehen lediglich in einer sehr oberflächlichen Sicht auf das Gesamtsystem, die vielleicht für eine erste Prozess-Übersicht oder strategische Managemententscheidung reicht, bei weiten aber noch nicht für ein IT-System. Die verbleibenden 80% sind für die eigentliche Detailarbeit notwendig, und diese Arbeit ist die Kernarbeit der IT.

Von der ersten Durchsicht alleine eine Prognose abgeben zu wollen, ist daher nicht sinnvoll, da zunächst die hohe Sicht der insgesamt ablaufenden Prozesse fertig zu stellen ist. Die Anordnung und Schnittstellen der Prozesse wird normalerweise noch recht lange Zeit beweglich sein, obwohl genau das Gegenteil für ein IT-Projekt notwendig ist. Wichtig ist gerade zunächst diese hohe Sicht. Lassen sich jedoch immerhin einige Prozesse identifizieren, deren Schnittstellen statisch erscheinen, kann man dort bereits mit der Detailarbeit beginnen. Gelegentlich wird es aber in der hohen (strategischen) Prozesssicht noch Änderungen geben, die sich in den Details auswirken. Die Folge ist, dass auch diese Prozesse überarbeitet werden müssen, und eine Änderung ist meist aufwendiger, als einen Prozess neu zu definieren. Je tiefer also Prozesse bereits im Detail spezifiziert sind, um so aufwendiger werden die notwendigen Nachbesserungen, wenn die hohe Sicht der Prozesse grundlegend geändert wird. Der Fachanwender selbst hat im Normalfall keine Vorstellung von den Auswirkungen, und er verkennt auch meist, dass das Durchschleifen von Detailänderungen in der Spezifikationsphase ein ernsthafter Kostenfaktor (evtl. doppelt oder dreifach so teuer wie der optimale Ablauf) wird, nur weil er selbst keine verbindliche Festlegung auf eine hohe Prozessablaufsicht findet.

Beobachtet man mehrere hintereinander stattfindende Durchsichten des gerade entstehenden Anforderungsdokuments, so können je Durchsicht einige messbare Informationen gewonnen werden:
Beispiel aus der Praxis

Beim gewünschten Produkt handelte es sich im weiteren Sinne um ein Simulationsprogramm, in dem sinngemäß Käufe und Verkäufe abgewickelt werden konnten. Nachdem sich die Spezifikationsphase schon fast ein halbes Jahr hingezogen hatte und einige Prozesse schon sehr weit ins Detail ausgearbeitet waren, wollte der Kunde noch einen komplett neuen Prozess, der etwa einem Warenkorb in einem Online-Shop entspricht. Dies war um die Zeit der dritten oder vierten Durchsicht des im Detail bei weitem noch nicht vollständigen Dokuments. Wenig später wurde eine komplette schon bis ins letzte Detail spezifizierte Simulations-Komponente gestrichen, die etwa ein Viertel des Gesamtprodukts ausgemacht hätte. Der Analyst war bis dahin davon ausgegangen, dass die Fertigstellung der Spezifikation binnen zwei oder drei weiteren Monaten möglich sein sollte. Auch ohne genaue Messergebnisse aus Reviews bzw. den Durchsichten war unübersehbar, dass die hohe Sicht der Prozessabläufe bis kurz vor Entwicklungsbeginn immer wieder Änderungen erfahren würde und somit Festlegungen im Detail nicht abzusehen waren.  Der Analytiker riet darauf dringend dazu, mit der Entwicklung von Teilkomponenten nach Teilabnahmen schon anzufangen, und sei es nur, um Fakten zu schaffen, denn er befürchtete, dass sonst der Willensfindungsprozess der Fachabteilung alle Terminpläne ad absurdum führen würde. So war es dann auch, die Spezifikation dauerte ein weiteres halbes Jahr und abgenommene Teilprozesse wurden immer wieder modifiziert. Ein Change Request Verfahren nach Teilabnahmen war von der Projektleitung nicht implementiert worden, somit konnte auch nicht vorab mit der Entwicklung begonnen werden, um den Änderungszyklus der Anforderungen einzubremsen. Gegen Ende der Spezifikationsphase ging man IT-seitig etwa vom doppelten Budget aus, als ein Jahr zuvor angesetzt worden war.
So lange die aufgezählten Zahlen Pn, Pg, Ps und Pm noch steigen, kann keine Prognose abgegeben werden, wann die Anforderungsanalyse fertig sein wird. Sichtbar ist hier nur, dass der Willensfindungsprozess des Auftraggebers noch im vollen Gang ist, anstatt, wie bei einem IT-Projekt notwendig, schon im Wesentlichen abgeschlossen ist. Erst, wenn die hohe Sicht, also die Anzahl der Teilprozesse, stabil und die Anordnung der Teilprozesse nicht mehr in Frage gestellt wird, kann man davon ausgehen, dass die Arbeiten am Detail relativ ungestört zielführend voran getrieben werden können. Am einfachsten zeichnet man eine Graphik oder lässt sie von einem Tabellenkalkulatioinssystem zeichnen, in der diese Zahlen nach jeder kompletten Durchsicht des Dokuments eingetragen werden. Erst, wenn eine Kurve steil nach unten zu knicken beginnt, ist ein Ende in Sicht.

Meine Erfahrungen zeigen etwas folgende Ergebnisse:
Beispiel aus der Praxis

Nachdem ein Prozess das dritte Mal komplett modifiziert worden war, fand der Analytiker heraus, dass der verantwortliche Fachanwender bei logischen Widersprüchen, die der Analytiker aufgedeckt hatte, immer wieder bei einer Expertengruppe Rat einholte. Da mal der eine oder der andere gerade in Urlaub, krank oder zu Tisch war, erhielt der Fachanwender von verschiedenen Spezialisten zum Teil sich widersprechende Auskünfte, die er an den Analytiker weiter gab.
Wenn sich über mehrere Reviews bzw. informelle Durchsichten hinweg feststellen lässt, dass von den Fachanwendern immer wieder neue kleinere Features entdeckt werden, und dies vor allem bei Prozessen, die bereits mehrfach von der Fachabteilung durchgesehen wurden, dann kann daraus vorsichtig eine Tendenz hergeleitet werden, dass dies auch bei den noch nicht betrachteten Prozessen der Fall sein wird.

Änderungen von Details in Teilprozessen passieren zwangsläufig, wenn deren Schnittstellen geändert werden. Die hier gewinnbaren Zahlen sind für eine Prognose über versteckte Fehler kaum aussagekräftig.

Aus Reviews und informellen Durchsichten heraus lässt sich nicht schätzen, wie viele versteckte Fehler in einem Anforderungsdokument sind. Jedoch lässt sich ablesen, wie zuverlässig die Anwender zu ihren Entscheidungen stehen und wie weit der Willensfindungsprozess fortgeschritten ist. Die Auswertung von Reviews und informellen Durchsichten lässt am ehesten Schlüsse dahingehend zu, wann eine Spezifikation weit genug ist, um auch bei einem unvollständigen Anforderungsdokument vorzeitig mit der Entwicklung beginnen zu können. Dieses Vorgehen wird häufig gefordert, um Zeit zu sparen, jedoch kann dann der Auftraggeber nicht erwarten, einen konkreten Preis für die Entwicklung genannt zu bekommen. Dass dann jede Schnittstelle inkl. Benutzeroberfläche nur noch über kostenpflichtige Change Requests geändert werden kann, versteht sich von selbst.
HINWEIS: Der früher hier platzierte Abschnitt Arbeitsorganisation wurde auf Grund von Leserwünschen erweitert, teilweise mit Vorlagen ergänzt und in ein eigenes Kapitel verschoben.

home - top - Kontakt - letzter Update 23.4.2004 - © Karl Scharbert