Vom Bedarf zum konkreten Verhalten
Im Lastenheft steht möglicherweise, dass Kunden eine Buchung ändern können sollen. Das Pflichtenheft erklärt, welche Buchungen geändert werden dürfen, wer das tun kann und welche Folgen es für freie Plätze und Bestätigungen gibt. Es verbindet damit ein fachliches Anliegen mit Entscheidungen, die sich tatsächlich umsetzen lassen.
Der Auftraggeber soll die vorgeschlagene Lösung verstehen, während das umsetzende Team eine verlässliche Arbeitsgrundlage braucht. Trenne deshalb verständliche Abläufe von tieferen technischen Verweisen. Ein Text voller interner Bauteilnamen kann Entwicklern helfen, während die fachlich verantwortliche Person darin ein wesentliches Missverständnis nicht mehr erkennt. Beide Perspektiven müssen zusammenpassen, ohne denselben Detaillierungsgrad zu benötigen.
Abläufe vor einzelnen Masken beschreiben
Beginne mit beteiligten Personen, Ausgangslage, Handlung und Ergebnis. Was sieht der Nutzer? Was wird gespeichert? Welche Regel erlaubt oder verhindert den nächsten Schritt? Beschreibe anschließend Sonderfälle wie fehlende Angaben, doppelte Eingaben, abgebrochene Vorgänge oder ausgefallene Verbindungen. Bildschirmbilder können diese Aussagen ergänzen, erklären aber nicht automatisch das Verhalten dahinter.
Verweise bei wichtigen Entscheidungen auf die zugehörige Anforderung. Dadurch fallen unnötige Funktionen und nicht abgedeckte Bedürfnisse leichter auf. Bei einer späteren Änderung findet das Team außerdem die betroffenen Regeln gezielt wieder. Ohne diese Verbindung muss es aus ähnlichen Formulierungen erraten, welche Teile des Dokuments mit dem geänderten Bedarf zusammenhängen.
Ein Beispiel aus einem Cateringbetrieb
Ein fiktiver Cateringbetrieb plant ein Formular für Veranstaltungsanfragen. Die Anforderung lautet, dass Interessenten ihre Anfrage online stellen und eine Eingangsbestätigung erhalten können. Im Pflichtenheft wird diese Nachricht klar von einer verbindlichen Auftragsbestätigung im betrieblichen Ablauf unterschieden. Zuerst muss das Team Kapazität und Einzelheiten prüfen und mit dem Interessenten besprechen.
Das Dokument erläutert, welche Angaben zum Termin benötigt werden, wie fehlende Informationen angezeigt werden und wo die Anfrage anschließend erscheint. Es legt auch fest, wie Beschäftigte mögliche Doppeleingänge erkennen. Ohne diese Entscheidungen könnte ein hübscher Bestätigungsbildschirm Erwartungen auslösen, die der Betrieb noch gar nicht erfüllen kann. Das Beispiel dient ausschließlich zur Veranschaulichung.
Übergänge zwischen Systemen klären
Soll die Anfrage in ein CRM gelangen, beschreibe die übertragenen Informationen, ihre Bedeutung und die führende Datenquelle. Lege fest, wie eine Ergänzung der vorhandenen Anfrage zugeordnet wird. Auch der Fehlerfall gehört dazu: Was sehen Nutzer bei einem Ausfall, wer wird informiert und wie verhindert das Team Verlust oder doppelte Bearbeitung?
Dafür muss nicht jede Zeile Programmcode vorgegeben werden. Die Aussage „beide Systeme sind verbunden“ ist trotzdem zu ungenau. Eine Verbindung kann technisch bestehen, während wichtige Angaben fehlen oder Fehler niemandem auffallen. Ein brauchbares Pflichtenheft beschreibt deshalb den erwarteten fachlichen Effekt so, dass er besprochen und später gezielt überprüft werden kann.
Prüffälle aus den Abläufen ableiten
Ein Prüffall enthält einen Ausgangszustand, eine konkrete Handlung und ein erwartetes Ergebnis. Beim Cateringbetrieb wird eine vollständige Anfrage abgeschickt. Der Interessent erhält eine Eingangsbestätigung, und intern erscheint eine noch zu prüfende Anfrage. Anschließend betrachtet ihr fehlende Angaben und eine Unterbrechung. Für jeden Fall wird festgelegt, welches Verhalten gewünscht ist.
Ein Prototyp kann die Bedienung vorab anschaulich machen. Nutze die Beobachtungen zur Verbesserung des Pflichtenhefts. Sie beweisen jedoch nicht, dass der gesamte Dienst zuverlässig funktioniert. Ein klickbares Modell sagt beispielsweise wenig darüber aus, ob Nachrichten ankommen, Rechte korrekt greifen oder ein unterbrochener Datenaustausch ohne doppelte Einträge wieder aufgenommen werden kann.
Den passenden Umfang finden
Dokumentiere Entscheidungen, die andere sonst erraten müssten: Regeln, Zustände, Zugriffsrechte, Datenwege, betriebliche Aufgaben und Erwartungen an die Abnahme. Verweise auf detaillierte Entwürfe, wenn sie gebraucht werden. Kopiere dieselbe Regel möglichst nicht in mehrere Kapitel. Bei Änderungen entstehen sonst widersprüchliche Fassungen, von denen jede auf den ersten Blick gültig erscheint.
In kleinen Projekten können Bedarf und Lösungsvorschlag in einem gemeinsamen Dokument stehen. Getrennte Abschnitte oder klar benannte Felder erhalten den Unterschied. Der Nutzen liegt in nachvollziehbaren Entscheidungen und gemeinsamem Verständnis. Zwei formale Dateien, die denselben Inhalt wiederholen, verursachen zusätzliche Pflege, ohne genauer zu erklären, was die umsetzende Seite tatsächlich liefern wird.
Vereinbarungen und Änderungen verbinden
Ein Pflichtenheft ist ein gemeinsamer Entscheidungsstand und keine Zusage, dass später niemand mehr etwas lernen darf. Vergib Version und Verantwortung. Führe offene Entscheidungen mit ihren möglichen Folgen für die Umsetzung separat auf. Bevor ein Entwurf als abgestimmt gilt, sollten die richtigen fachlichen und technischen Personen ihre jeweiligen Teile tatsächlich geprüft haben.
Verfolge bei Änderungswünschen die Auswirkungen auf Regeln, Daten, Prüffälle und Anleitungen. Eine neue Frist für Buchungsänderungen kann auch Nachrichten, bestehende Reservierungen und Arbeitsabläufe betreffen. Prüft diese Folgen, bevor ihr eine neue Zusage gebt. Wie förmlich ihr dabei vorgeht, hängt vom Vorhaben ab. Die Klarheit der Vereinbarung sollte darunter nicht leiden.
Einen wichtigen Vorgang vollständig durchgehen
Wähle eine zentrale Aufgabe und spiele sie nur anhand des Dokuments durch. Kann eine andere Person die nötigen Ausgangsdaten, jede Entscheidung, den Endzustand und den Umgang mit einer Unterbrechung erklären? Lass markieren, wo der Text Wissen voraussetzt, das bisher nur die Autorin oder der Autor besitzt und nicht aufgeschrieben hat.
Vergleiche den beschriebenen Ablauf anschließend wieder mit der Anforderung. Eine Lösung kann vollständig und in sich schlüssig sein und trotzdem am eigentlichen Problem vorbeigehen. Der Rückgriff auf den gewünschten Nutzen verhindert das. Beendet die Prüfung mit konkreten Entscheidungen oder benannten offenen Fragen, statt lediglich festzuhalten, dass der Entwurf insgesamt gut aussieht.
Häufige Fragen
Ist ein Pflichtenheft dasselbe wie technische Dokumentation?
Nein. Technische Entscheidungen können darin vorkommen, doch im Mittelpunkt stehen die vereinbarte Lösung und ihr Verhalten. Eine detaillierte Beschreibung des Programmcodes erfüllt einen anderen Zweck und entwickelt sich mit der Umsetzung weiter. Wo Entscheidungen zusammenhängen, helfen klare Verweise zwischen beiden Ebenen.
Passt ein Pflichtenheft zu agilem Arbeiten?
Ja. Entscheidungen können schrittweise dokumentiert und vor der jeweiligen Umsetzung genauer ausgearbeitet werden. Wichtig bleibt, was bereits vereinbart ist, welche Fragen offen sind und wie Änderungen behandelt werden. Ein agiles Vorgehen macht verständliche Absprachen über das gewünschte Verhalten nicht überflüssig.