Business Analyse Beratung, Training und CoachingRufen Sie uns an! +43 2243 23222
Unabhängig davon, mit welcher Methode ein Projekt durchgeführt wird, ein wichtiges Ergebnis einer Business Analyse ist die Kommunikation der Anforderungen an aller Stakeholder – meistens in Form von schriftlicher Dokumentation. Die Verwendung einer guten Vorlage für Anforderungsdokumente ist auf jeden Fall hilfreich.
Aber: Wie schreibt man gute Anforderungen?
In der Literatur gibt es viele Regeln und Tipps, wie gute Anforderungen formuliert sein sollen. Das IEEE definiert beispielsweise im Standard 830 Eigenschaften guter Anforderungs-Dokumente wie beispielsweise „Korrektheit“, „Widerspruchsfreiheit“, „Vollständigkeit“ etc. Neben dieser Definition vom IEEE gibt es noch viele andere Quellen, die davon handeln, wie man gute Anforderungen beschreibt.
In diesem Artikel möchte ich einen anderen Ansatz wählen. 
Die folgenden Fragen sind meiner Meinung nach gut geeignet, um eine Qualitätssicherung der eigenen Anforderungsdokumente durchzuführen. Dabei sind diese Fragen weniger als „Checklist“ zu verstehen (dafür eignen sich beispielsweise die Eigenschaften guter Anforderungsdokumente nach IEEE), sondern als Hilfestellung für den eigenen Denkprozess.
Wenn Sie das nächste Mal im Rahmen einer Business Analyse oder während der Analyse eines Softwareentwicklungsprojekts Anforderungen dokumentieren, stellen Sie sich doch einmal die folgenden vier Fragen:
Diese vier Fragen helfen dabei, sich mit dem selbst erstellten Dokument kritisch auseinanderzusetzen. Sie laden dazu ein, die eigene (vertraute) Sichtweise zu verlassen und durch die Augen einer fremden Personen zu sehen.
Nun zu den Fragen im Detail und deren Interpretation…
Wenn Sie Tage oder gar Wochen an ein und demselben Dokument arbeiten, entsteht eine gewisse Vertrautheit mit Ihrem eigenen Werk. Das ist ganz natürlich und vollkommen in Ordnung! Sie meinen, jede Passage schon eindutzendmal gelesen und bereits jeden Fehler ausgebessert zu haben. Diese Vertrautheit mit Ihrem Werk hat jedoch auch eine Kehrseite: Sie macht Sie leider auch blind für Fehler und ganz besonders für den Blick auf das große Ganze.
Deswegen: Nehmen Sie sich (am besten ausgeruht, z.B. in der Früh) bewusst Zeit und lesen Sie Ihr Dokument einmal von vorne bis hinten durch! Dies wird Ihnen dabei helfen, das Dokument möglichst widerspruchsfrei zu machen und sicherzustellen, dass es einen roten Faden gibt.
Sofern es in Ihrem Unternehmen standardisierte Vorlagen für Anforderungsdokumente gibt, werden diese mit ziemlicher Sicherheit einleitende Kapitel enthalten wie beispielsweise „Zweck des Dokuments“ oder „Stakeholder des Projekts“. Nach meiner Erfahrung werden diese Kapitel zumeist ganz am Schluss kurz vor Abgabe mit der Einstellung „Ach, dieses Kapitel gibt’s ja auch noch“ ausgefüllt. In diesem Fall könnte man diese Kapitel genauso gut auch ganz weglassen.
Der Sinn dieser einleitenden Kapitel ist es einem erstmaligen Leser eine Hilfestellung zu geben, wie das Dokument verstanden werden soll. Wenn Sie sich sich fragen, was hier am Besten beschrieben werden soll, stellen Sie sich folgendes vor: Sie sind Moderator eines Meetings und eine Minute vor Beginn kommt Ihr Vorgesetzter dazu und stellt Ihnen kurz einen neuen Mitarbeiter vor, der ab sofort im Projekt mitarbeiten wird. Und genau das, was Sie diesem Mitarbeiter über das Projekt erzählen, ist der ideale Inhalt für dieses einleitende Kapitel: Kurz und prägnant das Wesentliche, ohne die anderen Leser (oder eben Meeting-Teilnehmer) zu langweilen.
Deswegen: Denken Sie an erstmalige Leser des Dokuments und unterstützen Sie deren schnelle Orientierung. Ihre Leser werden es Ihnen danken! Ein praktischer Nebeneffekt: Ihre Dokumente werden tatsächlich gelesen.
Andere hilfreiche Inhalte, die einem erstmaligen Leser beim Zurechtfinden helfen sind u.a.: Eine Beschreibung der Projekt-Rahmenbedingungen, Auflistungen von Annahmen und Abgrenzungen die für dieses Dokument getroffen wurden oder auch ein Glossar das die wichtigsten Begriffe so definiert, wie sie im Dokument verwendet werden.
Sehr häufig werden Dokumente von den Autoren erst aus der Hand gegeben, wenn sie wirklich „fertig“ sind. Niemand soll ja ein schlechtes Bild bekommen. Und wer zeigt schon gerne einen qualitativ minderwertigen Entwurf her? So verständlich das auch ist, sollten Sie es trotzdem in Betracht ziehen, Ihr Dokument möglichst früh einem größeren Leserkreis zum Review zur Verfügung zu stellen.
Das kann vielerlei Vorteile haben: Beispielsweise können Sie so viel flexibler und effizienter auf Änderungsvorschläge eingehen. Wenn das 100-seitige Werk bereits vollendet ist, führt jede größere Änderung zu hohen Aufwänden. Dadurch werden häufig nur noch kosmetische Anpassungen vorgenommen, wirkliche wichtige Verbesserungen bleiben außen vor. Auch für den Reviewer kann das Lesen eines Entwurfs interessant sein, weil es aufgrund der noch vorhandenen Lücken den meisten viel leichter fällt Änderungsvorschläge zu machen.
Diese Review-Methode erfordert allerdings ein gewisses Maß an Vertrauen und sollte auch im Vorfeld abgestimmt sein, damit es keine Missverständnisse gibt. Bei diesem Vorgehen ist außerdem als Autor hilfreich, das Dokument von Anfang an so zu schreiben, dass es zu jeder Zeit ohne Vorankündigung einem Review unterzogen werden könnte. Überlegen Sie sich von Beginn an die Gliederung und sorgen Sie so für einen roten Faden durch das Dokument. Lassen Sie wichtige aber noch nicht geschriebene Teile nicht aus, sondern markieren Sie diese Lücken und beschreiben kurz den Inhalt. Das hilft nicht nur einem Reviewer, sondern auch Ihnen selbst beim Schreiben.
Deswegen: Lassen Sie bereits frühe Entwürfe Ihres Dokuments von Personen lesen und profitieren Sie von deren kreativen Änderungsvorschlägen!
Das ideale Projektteam in der Business Analyse besteht normalerweise aus Personen, die fachliches Verständnis mitbringen und methodische Experten im Anforderungsmangement sind. Für das Analyse-Team mag dies auch in vielen Fällen zutreffen, in späteren Projektphasen jedoch nur bedingt. Der Projektleiter muss Ziele, Budget und Zeitrahmen im Auge behalten – muss aber kein fachlicher Experte sein. Programmierer sind Experten der Software-Entwicklung – aber nicht in der eindeutigen Beschreibung von Anforderungen. Aber genau diese Menschen, mit ganz unterschiedlichen Stärken, können bei Reviews Verbesserungen einbringen, die auch einem geübten Analysten gar nicht mehr auffallen.
Insbesondere diese Frage lässt sich auch gut ganz alleine im Kopf durchspielen ohne tatsächlich die Projektleiter, Entwickler, Tester oder Auftraggeber zu benötigen.
Deswegen: Überlegen Sie, wie sich Ihr Dokument mit den Augen einer Person liest, die keine Erfahrung mit Anforderungen oder dem Thema an sich hat!
Ich hoffe, dass Ihnen diese Fragen dabei helfen, noch bessere Anforderungsdokumente zu schreiben. Diese Fragen können Sie sich bei jedem Ihrer Ergebnisse während der Analyse selbst stellen. Es spielt keine Rolle, nach welcher Methode Ihre Projekte abgewickelt werden (agil, iterativ, Wasserfall, …). Es geht alleine um die Möglichkeit, die Welt mit anderen Augen zu betrachten.
Wenn Sie nach mehr Tipps für gute Business-Analyse suchen, dann schauen Sie doch auch auf unserer Seite zu Business-Analyse-Trainings vorbei.
Es tut uns leid, aber dieses Kommentar wurde gesperrt.