Anforderungen dokumentieren: Satzschablonen, Modelle und Glossar

In welchen Formen werden Anforderungen dokumentiert?

Der IREB-Lehrplan unterscheidet natürlichsprachliche, schablonenbasierte und modellbasierte Arbeitsprodukte, ergänzt um andere Darstellungen wie Zeichnungen und Prototypen ^[1]. Jede Form hat Stärken und Schwächen, und in der Praxis werden sie kombiniert: Ein Kontextdiagramm zeigt den Überblick, Use Cases beschreiben Abläufe, einzelne Anforderungen in Satzschablonen legen Details fest, und ein Glossar sichert die Begriffe.

Welche Fallstricke hat natürliche Sprache?

Natürliche Sprache lässt sich oft unterschiedlich interpretieren, und Mehrdeutigkeiten, Auslassungen und Widersprüche sind schwer und teuer zu entdecken. Der Lehrplan empfiehlt kurze, gut strukturierte Sätze, eine einheitliche Terminologie und den Verzicht auf vage Begriffe. Zu vermeiden sind unvollständige Beschreibungen, unspezifische Substantive, unvollständige Bedingungen und unvollständige Vergleiche; mit Vorsicht zu verwenden sind Passiv, Universalquantoren wie «alle» oder «nie» und Nominalisierungen wie «Authentifizierung» ^[1].

Wie funktionieren Satzschablonen?

Satzschablonen geben einem Satz, der eine Anforderung ausdrückt, eine vordefinierte syntaktische Struktur. Der Lehrplan nennt als Quellen unter anderem ISO/IEC/IEEE 29148, das Muster EARS (Easy Approach to Requirements Syntax) von Mavin und anderen sowie die Schablonen von Chris Rupp; für User Stories die Schablone von Mike Cohn und für Use Cases die Formulare von Alistair Cockburn ^[1]. Die Norm ISO/IEC/IEEE 29148 spezifiziert zudem die geforderten Informationsobjekte und deren Inhalte ^[2].

Eine verbreitete Grundform im deutschsprachigen Raum lautet: «Das System muss oder soll oder wird» plus gegebenenfalls «wem die Möglichkeit bieten» plus Objekt plus Prozesswort. Die Wahl des Modalverbs drückt die Verbindlichkeit aus: «muss» für verbindliche Anforderungen, «soll» für dringend empfohlene, «wird» für zukünftige oder absichtserklärende. Das Prozesswort, also das Verb, beschreibt die geforderte Funktion möglichst eindeutig, etwa «exportieren», «berechnen» oder «anzeigen» statt «unterstützen» oder «bearbeiten».

Schablonen haben laut Lehrplan klare Vorteile: Sie schaffen eine wiederverwendbare Struktur, helfen, die wichtigsten Informationen zu erfassen, vereinheitlichen Anforderungen und verbessern die Gesamtqualität. Die Nachteile: Menschen konzentrieren sich oft auf das vollständige Ausfüllen statt auf den Inhalt, und Aspekte, die die Schablone nicht vorsieht, werden eher vergessen ^[1]. Schablonen sind deshalb Hilfsmittel, kein Ersatz für Nachdenken.

Wie sieht eine Use-Case-Schablone aus?

Use Cases beschreiben die Interaktion zwischen einem Akteur und dem System aus Sicht des Akteurs und werden meist mit Formularschablonen oder UML-Aktivitätsdiagrammen dokumentiert. Wann ein Use Case und wann eine User Story besser passt, beschreibt der Beitrag Use Case vs. User Story.

Welche Modelle werden im Requirements Engineering genutzt?

Modelle konzentrieren sich auf einen Aspekt und abstrahieren von den übrigen. Das reduziert die kognitive Last und macht Zusammenhänge sichtbar, die in Texten verborgen bleiben. Der Lehrplan weist aber auch auf Grenzen hin: Die Konsistenz zwischen Modellen verschiedener Aspekte ist schwer zu halten, und die meisten Qualitätsanforderungen und Randbedingungen lassen sich mit vertretbarem Aufwand nicht modellieren ^[1]. Deshalb werden Modelle und natürlichsprachliche Anforderungen meist kombiniert.

Warum braucht es ein Glossar?

Sobald mehrere Personen beteiligt sind, besteht das Risiko, dass sie dieselben Begriffe unterschiedlich verstehen. Ein Glossar ist eine zentrale Sammlung von Definitionen für kontextspezifische Begriffe, Alltagsbegriffe mit besonderer Bedeutung, Abkürzungen und Akronyme. Synonyme werden als solche gekennzeichnet, Homonyme vermieden oder markiert. Der Lehrplan nennt Regeln: zentral verwalten, über die gesamte Entwicklung pflegen, eine verantwortliche Person bestimmen, einheitliche Struktur verwenden, Stakeholder einbeziehen, allen zugänglich machen, Nutzung verbindlich machen und Arbeitsprodukte auf korrekte Verwendung prüfen ^[1].

Ein typisches Beispiel: In einer Agentur bedeutet «Projekt» für die Geschäftsleitung einen Kundenauftrag, für das Team eine Kampagne innerhalb eines Auftrags und für die Buchhaltung eine Kostenstelle. Ohne Glossar entstehen Anforderungen, die jeder anders liest. Die Klärung dauert eine Stunde, das Missverständnis kostet Wochen.

Wie werden Anforderungsdokumente strukturiert?

Verbreitete Dokumente sind Stakeholder-, Benutzer-, System- und Geschäftsanforderungsspezifikationen sowie Visionsdokumente; alternative Strukturen sind Product Backlog, Sprint Backlog und Story Map. Die Wahl hängt vom Entwicklungsprozess, der Art des Vorhabens, dem Vertrag und der Grösse ab. Dokumentschablonen finden sich in der Literatur, in Normen wie ISO/IEC/IEEE 29148 und in eigenen Standards von Organisationen. Im DACH-Raum sind Lastenheft und Pflichtenheft verbreitet; Vorlagen bietet flenio.ch unter Anforderungsdokument, Lastenheft und Pflichtenheft.

Anforderungen im Werkzeug dokumentieren

Unabhängig von der Form gelten allgemeine Regeln: den passenden Typ von Arbeitsprodukt wählen, Redundanz durch Verweise vermeiden, Widersprüche zwischen Arbeitsprodukten verhindern, Begriffe gemäss Glossar verwenden und Arbeitsprodukte sinnvoll strukturieren. In Flenio lassen sich Anforderungen als Aufgaben mit eindeutiger Kennung, Beschreibung in Satzschablone, Akzeptanzkriterien als Checkliste und Verweis auf die Quelle führen. Wie Qualitätsanforderungen messbar werden, zeigt der Beitrag Funktionale und nicht-funktionale Anforderungen. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.

Wie werden Abstraktionsebenen auseinandergehalten?

Anforderungen existieren auf vielen Abstraktionsebenen, von groben Anforderungen an einen neuen Geschäftsprozess bis zu sehr detaillierten Anforderungen an die Reaktion einer Softwarekomponente auf ein Ausnahmeereignis. Der IREB-Lehrplan empfiehlt, Anforderungen unterschiedlicher Ebenen nicht zu vermischen. In kleinen und mittleren Arbeitsprodukten sollten Anforderungen etwa auf derselben Ebene liegen; in grossen Spezifikationen werden die Ebenen durch die Gliederung getrennt. Eine Anforderung auf hoher Ebene wird in mehrere detaillierte Anforderungen auf tieferen Ebenen verfeinert.

In HERMES-Projekten der Bundesverwaltung bilden sich diese Ebenen in unterschiedlichen Ergebnissen ab: Stakeholderinteressen und Lösungsanforderungen beschreiben die übergeordnete Sicht, Detailspezifikationen die konkrete Umsetzung ^[3]. Wer diese Trennung konsequent einhält, erleichtert sich die Validierung, weil jede Ebene mit den passenden Stakeholdern geprüft werden kann: Ziele mit dem Auftraggeber, Details mit den Fachspezialisten. Eine Vorlage für eine Detailspezifikation bietet flenio.ch unter HERMES Detailspezifikation.

Ein praktischer Test für jede formulierte Anforderung lautet: Könnte eine Testerin, die das Projekt nicht kennt, allein anhand des Textes einen Testfall schreiben? Wenn nicht, fehlt meist ein Akteur, eine Bedingung, ein Messwert oder eine Definition im Glossar.

Hilfreich ist, solche Prüfungen nicht erst am Ende vorzunehmen, sondern direkt beim Schreiben: Wer jede neue Anforderung kurz gegen die Qualitätskriterien des IREB-Lehrplans prüft, spart später Zeit im Review und reduziert Rückfragen aus Entwicklung und Test erheblich.