Anforderungen dokumentieren

Anforderungen zu dokumentieren gehört zu den Kernaufgaben der Business Analyse. Trotzdem zeigt die Praxis: Viele Anforderungen sind zwar gut gemeint, aber nicht eindeutig, nicht vollständig oder nicht überprüfbar formuliert. Details oder wichtige Bestandteile werden oft vergessen, angenommen oder der IT-Entwicklung „überlassen“. Die Folgen reichen von Rückfragen über Fehlentwicklungen bis zu unnötigen Schleifen in Umsetzung und Test.

Wir bündeln hier die Erkenntnisse zur Anforderungsdokumentation und geben konkrete Tipps für Business Analysten, Product Owner, Requirements Engineers und Fachbereiche, die Anforderungen formulieren. Der Fokus liegt nicht auf einzelnen Formaten, sondern auf den inhaltlichen Prinzipien, die tragfähige Anforderungen ermöglichen.

Anforderungen entstehen im Austausch mit Fachbereichen, Stakeholdern und Umsetzungsteams, aber bleiben oft implizit. Aber „darüber sprechen“ reicht nicht aus. Gute Anforderungsdokumentation schafft Verbindlichkeit, entfaltet ihre Wirkung aber erst, wenn sie schriftlich fixiert, strukturiert und überprüfbar vorliegt.

Gut dokumentierte Anforderungen sorgen dafür, dass fachliche Erwartungen so beschrieben sind, dass sie gemeinsam verstanden, technisch umgesetzt und objektiv geprüft werden können.

1. Was ist die Aufgabe oder Funktionalität?

Im Zentrum jeder Anforderung steht eine konkrete fachliche Aufgabe. Entscheidend ist eine klare, aktive Formulierung mit Verb und Objekt.

Beispiel:
Statt „Artikelsuche“ wird „Artikel suchen“ formuliert.

Diese scheinbar kleine sprachliche Präzisierung verhindert Mehrdeutigkeiten. Nominalisierungen lassen offen, was genau passieren soll, während eine Verb-Objekt-Struktur die fachliche Intention eindeutig macht.

Im Requirements Engineering, wird es auch als atomare, handlungsorientierte Formulierung bezeichnet.

2. Wer führt die Aufgabe aus?

Jede Anforderung braucht einen klaren aktiven Aufgabenträger:

• ein Mensch (z. B. Kunde, Sachbearbeiter)
• ein IT-System
• oder einen Menschen der ein IT-System nutzt.

Aktive Formulierungen sind hier essenziell. Ob eine Funktion vom Nutzer ausgelöst oder automatisch vom System ausgeführt wird, hat direkte Auswirkungen auf Benutzeroberflächen, Automatisierungslogik und technische Architektur.

Viele Standards, wie z.B. dem BABOK der IIBA oder IREB / CPRE (Leitlinien zum Requirements Engineering) warnen explizit vor Passivformulierungen , da sie Verantwortlichkeiten verschleiern.

3. Welche Technik oder Sachmittel kommen zum Einsatz?

Anforderungen beziehen sich nicht nur abstrakt auf „das System“. Häufig sind zusätzliche technische oder organisatorische Mittel relevant, etwa:

• mobile Endgeräte
• Authentifizierungsverfahren
• externe Systeme oder Schnittstellen

Diese bewusst zu benennen erhöht die Verständlichkeit und unterstützt eine realistische Umsetzungsplanung.

4. Wie wird die Aufgabe durchgeführt?

Hier geht es um den Grad der Automatisierung. In der Praxis lassen sich drei Grundformen unterscheiden:

• vollautomatisiert (ohne Benutzerinteraktion)
• Mensch–Maschine-Interaktion
• rein manuell außerhalb eines IT-Systems.

Diese Unterscheidung ist besonders wichtig, um falsche Annahmen über Bedienung, Verantwortlichkeit oder technische Machbarkeit zu vermeiden.

5. Unter welchen Voraussetzungen gilt die Anforderung?

Viele Anforderungen gelten nicht jederzeit, sondern nur unter bestimmten Bedingungen. Diese Voraussetzungen explizit zu dokumentieren ist ein zentraler Qualitätsfaktor. Es wird auch häufig von Vorbedingungen oder Triggern gesprochen.

Typische Bedingungen sind:

• logische Bedingungen (z. B. Nutzer ist authentifiziert)
• zeitliche Bedingungen (z. B. Session nicht älter als 15 Minuten).

Fehlen diese Angaben, entstehen Lücken, die in der Umsetzung „gefüllt“ werden müssen – oft ohne fachliche Rückkopplung.

Die beschriebenen Prinzipien guter Anforderungsdokumentation sind formatunabhängig. Sie lassen sich in unterschiedlichen Formaten umsetzen: 

Denn die Erfahrung zeigt: Ohne wiederverwendbare Templates sinkt die Qualität schnell, weil wichtige Aspekte vergessen, verkürzt oder uneinheitlich dokumentiert werden. Templates helfen, die inhaltlichen Anforderungen an gute Dokumentation im Alltag zuverlässig umzusetzen. 

Wer Anforderungen nicht nur dokumentieren, sondern systematisch erheben, strukturieren und absichern möchte, kann die Inhalte im Rahmen einer Weiterbildung zur Business Analyse vertiefen. Dabei geht es unter anderem um: 

• funktionale und nicht-funktionale Anforderungen 

• Qualitätskriterien und typische Fallstricke 

• die Anwendung im Projekt- und Organisationskontext