Warum müssen Anforderungen validiert werden?
Am Ende muss das eingesetzte System die Wünsche und Bedürfnisse der Stakeholder erfüllen. Um das Risiko der Unzufriedenheit früh zu kontrollieren, beginnt die Validierung laut IREB-Lehrplan bereits im Requirements Engineering. Zu prüfen ist, ob unter den Stakeholdern Einigkeit über die Anforderungen besteht, ob ihre Wünsche und Bedürfnisse angemessen abgedeckt sind und ob die Kontextannahmen vernünftig sind [1]. Das sechste Prinzip des Lehrplans fasst das knapp zusammen: Nicht validierte Anforderungen sind nutzlos.
Der wirtschaftliche Grund ist einfach: Fehler in Anforderungen werden umso teurer, je später sie entdeckt werden. Ein Missverständnis, das im Review auffällt, kostet eine Korrektur im Dokument. Dasselbe Missverständnis, das erst bei der Abnahme auffällt, kostet Umbau, Nachtests und oft Verzögerungen. Der Lehrplan betont, dass die frühe Sicherung der Qualität von Anforderungen spätere Verschwendung reduziert.
Was ist der Unterschied zwischen Validierung und Verifikation?
Die beiden Begriffe werden oft verwechselt. Validierung fragt: Bauen wir das Richtige? Sie prüft, ob die Anforderungen und das entstehende System die tatsächlichen Bedürfnisse der Stakeholder erfüllen. Verifikation fragt: Bauen wir es richtig? Sie prüft, ob das umgesetzte System die spezifizierten Anforderungen erfüllt. Eine Anforderung kann perfekt verifiziert werden, also exakt wie beschrieben umgesetzt sein, und trotzdem am Bedarf vorbeigehen, wenn sie nie validiert wurde. Die Norm ISO/IEC/IEEE 29148 behandelt beide Aktivitäten als Teil der Anforderungsprozesse über den Lebenszyklus [2].
Welche Grundsätze gelten für die Validierung?
| Grundsatz | Bedeutung | Praxis |
|---|---|---|
| Richtige Stakeholder beteiligen | diejenigen prüfen lassen, die Bedarf und Kontext kennen | Fachbereich für fachliche Anforderungen, Betrieb für Betriebsanforderungen |
| Fehlerfinden und Fehlerbeheben trennen | zuerst Mängel sammeln, dann beheben | im Review nur notieren, Korrektur danach durch die Autorin |
| Aus verschiedenen Sichten prüfen | Nutzende, Entwicklung, Test, Betrieb sehen unterschiedliche Mängel | Prüfende mit unterschiedlichen Rollen einladen |
| Validierung wiederholen | Anforderungen ändern sich, Validierung ist kein einmaliger Akt | nach Änderungen und vor Meilensteinen erneut prüfen |
Diese vier Grundsätze stammen aus dem IREB-Lehrplan [1]. Der zweite wird in der Praxis häufig verletzt: Wenn im Review jeder gefundene Mangel sofort diskutiert und gelöst wird, geht die Zeit für die eigentliche Prüfung verloren, und viele Mängel bleiben unentdeckt. Wirksamer ist, im Review nur zu sammeln und die Korrektur danach gezielt vorzunehmen.
Welche Validierungstechniken gibt es?
| Technik | Kategorie | Vorgehen | Geeignet für |
|---|---|---|---|
| Walkthrough | Review | Autorin führt Prüfende durch das Dokument, Fragen und Hinweise werden gesammelt | gemeinsames Verständnis, frühe Entwürfe |
| Inspektion | Review | formales Verfahren mit Vorbereitung, Rollen, Checklisten und Protokoll | kritische Anforderungen, Verträge |
| Prototyp | explorativ | Stakeholder erleben eine Darstellung der Lösung | Benutzeroberflächen, unklare Vorstellungen |
| Alpha- und Betatest | explorativ | frühe Versionen werden von ausgewählten Nutzenden erprobt | Produkte, neue Abläufe |
| A/B-Test | explorativ | zwei Varianten werden mit echten Nutzenden verglichen | Produkte mit vielen Nutzenden |
| Minimum Viable Product | explorativ | kleinste nutzbare Version wird am Markt geprüft | neue Produkte mit unsicherem Bedarf |
| Musterentwicklung | explorativ | ein Ausschnitt wird beispielhaft umgesetzt | technisch riskante Anforderungen |
Der Lehrplan ordnet die Techniken in Reviews, etwa Walkthroughs und Inspektionen, und explorative Techniken, etwa Prototypen, Alpha- und Betatests, A/B-Tests und Minimum Viable Products, ergänzt um die Musterentwicklung [1]. Die Techniken unterscheiden sich in Formalität und Aufwand. Die Wahl hängt vom Entwicklungsmodell, der Reife des Entwicklungsprozesses, der Komplexität und dem Risiko des Systems, rechtlichen oder regulatorischen Vorgaben und dem Bedarf an Nachweisen ab.
Prüfliste: Woran wird eine Anforderung gemessen?
| Kriterium | Prüffrage |
|---|---|
| Adäquat | Beschreibt die Anforderung tatsächliche und abgestimmte Bedürfnisse? |
| Notwendig | Würde etwas Wichtiges fehlen, wenn sie gestrichen wird? |
| Eindeutig | Verstehen alle Prüfenden dasselbe darunter? |
| Vollständig | Enthält sie alle nötigen Angaben, etwa Akteur, Bedingung, Messwert? |
| Verständlich | Ist sie für die Zielgruppe ohne Rückfrage lesbar? |
| Prüfbar | Lässt sich ein Testfall oder Abnahmekriterium ableiten? |
| Konsistent (Dokument) | Widerspricht sie keiner anderen Anforderung? |
| Verfolgbar (Dokument) | Sind Quelle und Verknüpfungen nachvollziehbar? |
Eine solche Prüfliste macht Reviews effizienter und vergleichbar. Sie wird den Prüfenden vorab gegeben, damit sie sich vorbereiten können. Für umfangreiche Dokumente hat es sich bewährt, die Prüfung nach Sichten aufzuteilen: Eine Person prüft die fachliche Adäquatheit, eine andere die Prüfbarkeit aus Testsicht, eine dritte die Konsistenz mit Schnittstellen. Eine Checkliste für Anforderungsreviews bietet flenio.ch unter Anforderungsreview.
Wie läuft eine Inspektion ab?
- 1Planung: Prüfgegenstand, Prüfende, Rollen und Termine festlegen.
- 2Einführung: Autorin erklärt Ziel und Kontext des Dokuments.
- 3Vorbereitung: Prüfende lesen das Dokument einzeln anhand der Prüfliste und notieren Mängel.
- 4Sitzung: gefundene Mängel werden gesammelt, bewertet und protokolliert, nicht gelöst.
- 5Überarbeitung: Autorin behebt die Mängel.
- 6Nachprüfung: Moderation prüft, ob alle Mängel behandelt wurden, und entscheidet über die Freigabe.
Inspektionen sind aufwendig, finden aber erfahrungsgemäss viele Mängel, die in informellen Reviews übersehen werden. Sie lohnen sich besonders für Anforderungen mit hohem Risiko oder vertraglicher Bedeutung. Für Entwürfe und weniger kritische Inhalte genügen Walkthroughs oder kurze Reviews im Team. Die Wertorientierung des IREB-Lehrplans gilt auch hier: Der Aufwand der Validierung soll dem Wert und dem Risiko der Anforderungen entsprechen.
Wie hängen Validierung und Abnahme zusammen?
Die Abnahme ist der formale Schritt, mit dem Auftraggeber bestätigen, dass ein Ergebnis den vereinbarten Anforderungen entspricht. Sie kann nur gelingen, wenn die Anforderungen zuvor validiert und prüfbar formuliert wurden. Abnahmekriterien werden deshalb nicht erst am Ende festgelegt, sondern zusammen mit den Anforderungen. In HERMES-Projekten sind Freigaben an Meilensteine gebunden, und die Ergebnisse zu Lösungsanforderungen bilden die Grundlage für spätere Prüfungen [3]. Wie Abnahme und Übergabe im Projektabschluss organisiert werden, beschreibt der Beitrag Projektabschluss.
Beispiel: Validierung einer Spezifikation vor der Ausschreibung
Eine Verwaltung will eine Zeiterfassungslösung ausschreiben. Vor der Publikation wird die Spezifikation in drei Schritten validiert. Zuerst führt die Requirements Engineerin den Fachbereich in einem Walkthrough durch die Use Cases; dabei zeigt sich, dass Teilzeitpensen mit wechselnden Arbeitstagen fehlen. Danach prüft eine Inspektion mit Vertretern von Informatik, Datenschutz und Beschaffung die Qualitätsanforderungen und Randbedingungen; gefunden werden zwei widersprüchliche Angaben zur Aufbewahrungsdauer und eine nicht prüfbare Leistungsanforderung. Schliesslich wird ein klickbarer Prototyp der Erfassungsmaske mit fünf Mitarbeitenden getestet; drei von ihnen erwarten eine Wochenansicht statt einer Tagesansicht.
Alle Mängel werden gesammelt, behoben und in einer Nachprüfung bestätigt. Die Spezifikation geht mit deutlich weniger Unklarheiten in die Ausschreibung, und die Zahl der Rückfragen von Anbietenden sinkt. Jeder gefundene Mangel hätte nach dem Zuschlag einen Nachtrag oder einen Streit über den Leistungsumfang ausgelöst.
Typische Fehler bei der Validierung
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Validierung erst bei der Abnahme | teure Korrekturen, Verzögerungen | früh und wiederholt validieren |
| Falsche Prüfende | fachliche Mängel bleiben unentdeckt | Prüfende nach Sichten auswählen |
| Lösen statt Sammeln im Review | wenige Mängel gefunden, Sitzungen ufern aus | Fehlerfinden und Fehlerbeheben trennen |
| Nur Dokumente prüfen | Erwartungen an Bedienung bleiben verborgen | Prototypen für Benutzeroberflächen einsetzen |
| Kontextannahmen nicht prüfen | System scheitert an äusseren Bedingungen | Annahmen ausdrücklich validieren |
Validierung im Werkzeug abbilden
Im Projekttool lassen sich Reviews als Aufgaben mit Prüfenden, Fristen und Checklisten planen, gefundene Mängel als Kommentare oder eigene Einträge erfassen und der Status einer Anforderung nach erfolgreicher Validierung auf «geprüft» setzen. In Flenio können Anforderungen mit Status, Checklisten und Kommentaren geführt und mit Meilensteinen wie Freigaben verbunden werden. Wie Anforderungen nach der Validierung verwaltet werden, beschreibt der Beitrag Requirements Management; wie sie prüfbar formuliert werden, der Beitrag Anforderungen formulieren. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.
Validierung in agilen Vorhaben
In agilen Vorhaben findet Validierung laufend statt. Im Refinement prüfen Product Owner und Team, ob Einträge verständlich und prüfbar sind; im Sprint Review prüfen Stakeholder das entstandene Increment und geben Rückmeldung, ob es ihre Bedürfnisse trifft. Die kurzen Rückkopplungsschleifen sind laut IREB-Lehrplan die wichtigste Praxis, um die Auswirkungen von Missverständnissen gering zu halten. Explorative Techniken wie Prototypen, Betatests oder Minimum Viable Products sind hier besonders verbreitet, weil sie Rückmeldung am konkreten Ergebnis ermöglichen.
Trotzdem lohnt sich auch in agilen Teams ein bewusster Blick auf die Qualität einzelner Einträge, bevor sie in einen Sprint gehen. Eine kurze Prüfung gegen die Qualitätskriterien im Refinement verhindert, dass unklare Einträge erst während der Umsetzung auffallen. Viele Teams nutzen dafür eine Definition of Ready, die festlegt, wann ein Eintrag ausreichend geklärt ist.
Wie werden Kontextannahmen validiert?
Kontextannahmen sind Bedingungen ausserhalb des Systems, die gelten müssen, damit es funktioniert, etwa aktuelle Stammdaten in einem Nachbarsystem oder eine bestimmte Netzwerkverfügbarkeit. Sie werden validiert, indem die Verantwortlichen der betroffenen Systeme oder Prozesse bestätigen, dass die Annahme zutrifft und weiterhin zutreffen wird. Wo das nicht gesichert ist, entstehen neue Anforderungen, etwa an Plausibilitätsprüfungen oder Fehlermeldungen, oder ein Risiko, das im Projekt geführt wird. Mehr zur Abgrenzung und zu Annahmen im Beitrag Systemkontext und Abgrenzung.