Requirements
Lebensfähigkeit in fünf Pflichten
Requirements sind der Vertrag zwischen dem, was ein System leisten soll, und dem, was es tatsächlich tut. Nicht „Anforderungen schreiben“ — sondern: Was muss beweisbar erfüllt sein? Anforderungen, die nicht messbar sind, sind nicht erfüllbar — sie sind nur nicht widerlegbar.
1Pflicht 1
Adressat & Zweck
Nicht verhandelbar
Jede Anforderung benennt explizit den Empfänger und den Zweck — nicht die Lösung. „Schnell“ ist kein Zweck. „Startzeit < 3 s beim Nutzer“ ist einer.
Typischer Bruch
Anforderung formuliert die Lösung statt den Bedarf. Das System erfüllt die Anforderung — aber nicht den Zweck.
2Pflicht 2
Baseline & Datum
Nicht verhandelbar
Jede Anforderung hat eine versionierte Baseline mit Datum. Ohne Datum ist unklar, ob die Anforderung noch gilt. Anforderungen ohne Datum sind Gerüchte.
Typischer Bruch
Anforderungsdokument ohne Versionskontrolle. Im Review-Meeting haben alle eine andere Version — niemand weiß es.
3Pflicht 3
Verifikation
Nicht verhandelbar
Jede Anforderung hat ein Messmittel und ein Verifikationskriterium. Wenn zwei Prüfer „erfüllt / nicht erfüllt“ unterschiedlich beurteilen, ist die Anforderung defekt.
Typischer Bruch
Anforderung ohne Abnahmekriterium. Im Test stellt sich heraus: niemand kann sagen, ob sie erfüllt ist. Streit statt Abnahme.
4Pflicht 4
Schwächste Anforderung
Was prüfen
Welche Anforderung ist am unsichersten — unklar, unverifizierbar, widersprüchlich? Sortiert nach Risiko. Nicht „98 % sind sauber“ — die fehlenden 2 % reißen das Produkt.
Typischer Bruch
Reife-Mittelwert über alle Anforderungen ist grün. Die eine kritische Sicherheits-Anforderung ist unverifizierbar — verdeckt im Schnitt.
5Pflicht 5
Sync mit der Welt
Was prüfen
Reaktionszeit zwischen Änderung (Norm, Kundenwunsch, Markt) und Anpassung der Anforderung. Aus Versionshistorie messbar. Tote Anforderungen sind die gefährlichsten.
Typischer Bruch
Anforderung wurde 2020 eingefroren, die Norm änderte sich 2023. Niemand hat es nachgezogen. Das Produkt erfüllt eine veraltete Pflicht.
Realer Fall — Medizinprodukt, Heimnutzung statt Klinik
Ausgangslage: Anforderungsbasis von 2015 für Klinik-Setting. Ab 2020 verschiebt sich der Markt zur Heim-Therapie. Pflicht 1 erfüllt: Anforderungen lösungsfrei, deshalb übertragbar. Pflicht 4 deckt auf: Die Anforderung „selbstständige Inbetriebnahme“ ist unverifizierbar. Pflicht 3 löst es: Telemetrie-Ersatzgröße „Anteil Sitzungen ohne Hotline-Anruf“ macht die Anforderung messbar.
Eine Anforderung ohne Verifikationskriterium ist keine Anforderung, sondern eine Hoffnung. Anforderungen, die nicht messbar sind, sind nicht erfüllbar — sie sind nur nicht widerlegbar.
Methode entwickelt von Thomas Arends · OTSM (Organisations-, Technologie- und Service-Management) GmbH.