Ich werde immer wieder gefragt, wie das ideale Anforderungsdokument aussieht. Tja, das ideale Anforderungsdokument gibt es nicht, weil es von der konkreten Aufgabenstellung und der Organisation abhängt, aber ich möchte hier trotzdem eine Grundstruktur anbieten, die sich sicherlich auch gut als Vorlage für Ihr Anforderungsdokument eignet.
In diesem Video erkläre ich außerdem im Detail, wie die Vorlage am besten verwendet wird. Viel Erfolg!
Wozu überhaupt dokumentieren?
Wofür wird ein Anforderungsdokument überhaupt erstellt? Der eigentliche Zweck besteht darin, z.B. im Rahmen der Entwicklungs eines neuen IT-Systems, die Gesamtheit aller Anforderungen auf effiziente Art und Weise zu dokumentieren – mit dem Zweck, die Kommunikation zu erleichtern. Ein Dokument ist also nur Mittel (Dokument) zum Zweck (Kommunikation). Manchmal ist es auch besser, Anforderungen mündlich oder grafisch zu kommunizieren.
Das hier vorgestellte Template eignet sich grundsätzlich für alle Arten der Kommunikation, da es schließlich vor allem den Inhalt beschreibt und strukturiert – und eine strukturierte Kommunikation ist immer gut, weil sie dafür sorgt, das unsere Gegenüber auch versteht, was wir sagen wollen.
Template Anforderungsdokument
1. Management Summary
Das ist eine kurze Beschreibung mit einer Länge von maximal 1 Seite, bei der ich die wesentlichen Punkte des gesamten Dokuments zusammenfasse. Die Management Summary richtet sich natürlich nicht nur an das Management, sondern an jede Person, die sich schnell einen Überblick über das Dokument verschaffen will. Alle relevanten Fakten sollten auf das Wesentliche reduziert sein, damit jeder für sich selbst entscheiden kann, ob und wo ein tieferes Eintauchen sinnvoll ist.
2. Einführung
In der Einführung wird klargestellt, was die Ziele und der Umfang der Anforderungen (an das IT-System) sind. Diesen Abschnitt strukturiere ich gerne wie folgt:
- Ausgangslage: Wo stehen wir heute und wie sind wir hierher gekommen?
- Ziele und Abgrenzungen: Wo wollen wir hin, was wollen wir erreichen – und was nicht?
- Annahmen: Von welchen Dingen nehmen wir an, dass sie zutreffen (wissen es aber zum aktuellen Zeitpunkt nicht sicher)
- Stakeholder: Wer sind die relevanten Stakeholder (Namen oder Gruppen von Stakeholdern, Abteilungen, externe Stakeholder, je nach Relevanz). Mehr zum Thema Stakeholder-Analyse in unserem Podcast.
- Glossar: Ein kurzes Glossar mit den wesentlichen Begriffen, die im Dokument verwendet werden. Dieses Glossar kann auch am Ende stehen, wird dann aber leider häufig nicht gelesen…
- Referenzen: Welche anderen Dokumente sind sonst noch relevant? Beispielsweise ein Business Case, der den zu erwarteten Nutzen der Investition beschreibt.
3. Geschäftsprozesse
Die Einführung oder Adaption eines IT-Systems betrifft immer auch die Geschäftsprozesse einer Organisation. Entweder geben die Prozesse vor, wo eine Automatisierung oder IT-Unterstützung notwendig ist – oder neue Technologien verändern die Prozesse auf eine disruptive Art und Weise. In beiden Fällen sind die Geschäftsprozesse relevant und sollten hier beschreiben werden, beispielsweise in der Form von:
- Prozesslandkarten oder Value Chains
- Prozessmodellen
Wer hier mehr wissen möchte, dem empfehle ich unseren Kurs Modellierung von Geschäftsprozessen.
4. Systemumfang und -funktionalität
An dieser Stelle beschreibe ich den Umfang des einzuführenden oder zu adaptierenden IT-Systems. Dabei geht es darum, einen schnellen Einblick in die Grenzen und den Umfang des Systems zu bekommen. Hier stimmt der Spruch: Ein Bild sagt mehr als tausend Worte. Ich empfehlen dazu eine der folgenden Techniken:
- Big Picture: Also eine einfache Skizze – ohne spezielle Notation. Denken Sie einfach an die letzte, auf Flipchart verewigte Skizze, von der auch nach Monaten immer noch gesprochen wird!
- Kontextdiagramm
- Anwendungsfalldiagramm: Damit meine ich ein Übersichtsdiagramm nach der Unified Modeling Language (UML), die alle Anwendungsfälle (Use Cases) übersichtlich zusammenfasst.
5. Funktionale Anforderungen
Das ist der Kern des Dokuments, das alle (bis zum aktuellen Zeitpunkt bekannten) Anforderungen beschreibt.
Die wichtigste Regel: Bitte hier keine Tabellenkalkulation benutzen oder auf externe Listen verweisen. Denn nicht vergessen: Das Ziel ist, Anforderungen zu kommunizieren. Und das funktioniert nicht mit einer Excel-Tabelle, die 25 Spalten breit und 148 Zeilen lang ist. Das liest niemand.
Bewährt haben sich:
- Use Cases: Auch Anwendungsfälle genannt und zwar nach dem bewährten Schema (Name, ID, Auslöser, Standardablauf, etc.). Diese lassen sich übrigens auch wunderbar iterativ erstellen und verfeinern und auch in Rahmen von agiler Softwarentwicklung realisieren (Stichwort Use Case 2.0).
- Datenmodelle: Nur hier sind Tabellen empfohlen, wenn sich Anforderungen speziell auf Datenhaltung beziehen.
Wer hier mehr wissen möchte, dem empfehle ich unseren Kurs Requirements-Engineering.
6. Nicht-funktionale Anforderungen
Damit sind die Eigenschaften gemeint, die eine Lösung sonst noch erfüllen muss. Dieser Teil wird leider häufig vergessen oder an „die ITler“ abgetreten.
Damit Sie an dieser Stelle keine Anforderungen vergessen, prüfen Sie anhand von bewährten Kategorien, wie hier aus dem BABOK© Guide:
- Verfügbarkeit
- Kompatibilität
- Wartbarkeit
- Geschwindigkeit
- Verlässlichkeit
- Sicherheit
- Usability
- u.v.m
7. Offene Punkte
Anforderungen zu verschriftlichen, hat nicht nur den Zweck, diese für Andere aufzuschreiben, sondern hilft auch dem Verfasser Klarheit zu bekommen und das eigene Denken anzuregen. Genau die Zwischenergebnisse des Denkprozesses sollten bereits während dem Erstellen des Anforderungsdokuments festgehalten werden: Was ist noch offen? Wo fehlt noch etwas? Was ist noch nicht konsistent?
Der Weg ist das Ziel
Bitte beachten Sie beim Anwenden dieser Vorlage, dass ein Anforderungsdokument immer nur ein Weg zum Ziel ist – nicht das Ziel selbst. Ein Anforderungsdokument ist nur sinnvoll, wenn es dabei unterstützt, bessere IT-Systeme einzuführen.
Wenn Sie weitere Tipps rund um Anforderungsdokumente lesen wollen, empfehle ich Ihnen unser Buch Basiswissen Business-Analyse, in dem Sie auch diese Struktur mit weiterführenden Informationen finden.
Wenn Sie irgendwelche Fragen haben oder ein maßgeschneidertes Template für Ihre Organisation erstellen wollen, zögern Sie bitte nicht mich zu kontaktieren!
