Eine Anforderung ohne Nutzenbezug ist nur ein Wunsch

„Wir brauchen eine App für Freigaben.“ Der Satz klingt wie eine Anforderung, enthält aber bereits eine Lösung. Unklar bleibt, welche Freigabe heute scheitert, wer davon betroffen ist, welche Wirkung erwartet wird und woran später zu erkennen wäre, dass die App das Problem tatsächlich löst.

Solche Lösungswünsche landen als Tickets, Lastenheftpunkte oder Backlog-Einträge bei der IT. Dort werden sie geschätzt und priorisiert, obwohl ihre geschäftliche Bedeutung nicht ausreichend beschrieben ist. Das Team diskutiert dann über Funktionen, während Problem, Nutzen und Entscheidungsrecht offenbleiben.

Eine belastbare Anforderung beginnt nicht mit dem gewünschten Werkzeug. Sie verbindet eine beobachtbare Ausgangslage mit einer angestrebten Wirkung und macht Bedingungen, Grenzen und Abnahme prüfbar.

Der Lösungswunsch ist ein Hinweis, keine Vorgabe

Wer einen Wunsch äußert, hat häufig bereits über das Problem nachgedacht. Die vorgeschlagene Lösung darf deshalb nicht reflexartig verworfen werden. Sie sollte jedoch als Hypothese behandelt werden.

Aus „Wir brauchen eine App“ werden zunächst Fragen:

• Welcher Arbeitsablauf oder welches Ergebnis ist heute unzureichend?
• Wer erlebt das Problem und in welcher Situation?
• Welche Folgen entstehen durch Fehler, Wartezeit oder fehlende Transparenz?
• Welche Umgehung wird heute genutzt?
• Was soll nach einer Veränderung besser möglich sein?
• Welche Vorgaben oder Abhängigkeiten begrenzen die Lösung?

Der GOV.UK Service Standard zum Verständnis von Nutzerbedürfnissen empfiehlt ebenfalls, das Problem und den Nutzungskontext vor einer konkreten Lösung zu untersuchen und Annahmen früh zu testen. Die Hinweise stammen aus dem öffentlichen Sektor, die Grundlogik ist aber auf interne Services übertragbar.

Nutzen muss als veränderte Wirkung beschrieben werden

„Digitalisieren“, „automatisieren“ oder „moderner arbeiten“ sind keine ausreichenden Wirkungen. Sie benennen ein Mittel oder eine Richtung, aber noch keinen überprüfbaren Zustand.

Ein Nutzenbezug beschreibt, was sich für einen Prozess, eine Rolle oder das Unternehmen verändern soll. Zum Beispiel:

• Freigaben sind innerhalb einer definierten Zeit entscheidbar.
• Pflichtangaben liegen vor, bevor eine Prüfung beginnt.
• Rückfragen und doppelte Erfassung werden reduziert.
• Entscheidungen sind für berechtigte Rollen nachvollziehbar.
• Ein Vorgang kann auch bei Abwesenheit des bisherigen Wissensträgers fortgeführt werden.

Nicht jede Wirkung muss sofort monetarisiert werden. Sie muss jedoch so konkret sein, dass später beobachtet werden kann, ob sie eingetreten ist. Eine Zeitangabe braucht einen Start- und Endpunkt; eine Fehlerreduktion braucht eine bekannte Fehlerart und eine Ausgangsbasis.

Der Beitrag „Ein Business Case endet nicht mit der Budgetfreigabe“ zeigt, wie Nutzenhypothesen nach der Einführung überprüft werden. Diese Prüfung wird erheblich leichter, wenn die erwartete Wirkung bereits in der Anforderung steht.

Nutzer, Auftraggeber und Entscheider sind nicht dieselbe Rolle

Eine Person kann eine Anforderung einreichen, ohne über Priorität, Budget oder Prozessänderung entscheiden zu dürfen. Gleichzeitig kann ein Auftraggeber eine Lösung finanzieren, die operative Arbeit aber nur unvollständig kennen.

Mindestens vier Perspektiven sollten geklärt werden:

• Nutzer: Wer arbeitet mit dem Ergebnis und unter welchen Bedingungen?
• Process Owner: Wer verantwortet das fachliche Ergebnis und notwendige Prozessänderungen?
• Entscheider: Wer priorisiert gegenüber anderen Vorhaben und akzeptiert Zielkonflikte?
• Umsetzung und Betrieb: Wer kann technische Machbarkeit, Folgekosten und Betriebsfähigkeit beurteilen?

Das bedeutet nicht, dass jede Anforderung einen großen Workshop braucht. Es verhindert aber, dass eine laute Einzelmeinung als abgestimmter Unternehmensbedarf behandelt wird.

Rahmenbedingungen gehören vor die Lösungsauswahl

Eine Anforderung ist mehr als gewünschtes Verhalten. Für die Entscheidung können auch nicht-funktionale und organisatorische Bedingungen ausschlaggebend sein:

• Informationsschutz und zulässige Datenverarbeitung,
• Barrierefreiheit und Bedienbarkeit,
• Verfügbarkeit, Wiederanlauf und Supportzeiten,
• erwartete Mengen und Lastspitzen,
• Integration in führende Systeme,
• Rollen, Trennung von Aufgaben und Freigabegrenzen,
• Aufbewahrung, Löschung und Nachweis,
• Export, Beendigung und Wechselmöglichkeit,
• Fähigkeiten des internen Teams und des Dienstleisters.

Der Standard ISO/IEC/IEEE 29148:2018 ordnet Requirements Engineering als Lebenszyklusaufgabe für Systeme, Software und Services ein. Die Ausgabe wurde 2024 bestätigt und befindet sich seit Februar 2026 in Revision. Für die praktische Arbeit bleibt die entscheidende Aussage robust: Anforderungen müssen über eine einzelne Funktionsbeschreibung hinaus verwaltet und nachvollziehbar gehalten werden.

Abnahmekriterien übersetzen Absicht in Beobachtung

Eine fachliche Abnahme darf nicht erst am Ende klären, was „fertig“ bedeutet. Abnahmekriterien beschreiben vor der Umsetzung die beobachtbaren Bedingungen, unter denen der Auftraggeber das Ergebnis akzeptiert.

Gute Kriterien beziehen sich auf reale Situationen:

• Welche Eingabe oder welches Ereignis startet den Vorgang?
• Welches Ergebnis muss für welche Rolle sichtbar sein?
• Welche Ausnahme muss korrekt behandelt werden?
• Welche Daten dürfen nicht offengelegt oder verändert werden?
• Welche nachgelagerten Buchungen oder Benachrichtigungen müssen entstehen?
• Welcher Nachweis belegt das Ergebnis?

„Die Schaltfläche funktioniert“ ist ein technischer Test. „Eine berechtigte Führungskraft kann einen vollständigen Antrag freigeben, die Entscheidung wird protokolliert und der nachgelagerte Auftrag wird genau einmal erzeugt“ ist ein fachlich prüfbares Ergebnis.

Priorisierung braucht Kosten des Nichttuns und der Umsetzung

Eine gute Beschreibung macht noch nicht jede Anforderung wichtig. Priorität entsteht aus dem Vergleich mit anderen Vorhaben.

Dafür sind mindestens zu betrachten:

• Wirkung und Dringlichkeit des ungelösten Problems,
• Zahl und Kritikalität der betroffenen Vorgänge,
• rechtliche, vertragliche oder sicherheitsbezogene Fristen,
• Umsetzungs- und laufender Betriebsaufwand,
• Abhängigkeiten und gebundene Kapazität,
• Reversibilität und Lernwert eines kleinen Schritts,
• Folgen für bereits zugesagte Vorhaben.

Die IT-Roadmap mit Entscheidungslogik hilft, Anforderungen nicht einzeln nach Lautstärke zu betrachten. Eine neue Priorität verdrängt Kapazität an anderer Stelle; diese Folge gehört in die Entscheidung.

Konstruiertes Beispiel: Die App löst nur den sichtbaren Übergabepunkt

Das folgende Beispiel ist konstruiert.

Ein Fachbereich fordert eine mobile App für Investitionsfreigaben. Bei der Analyse zeigt sich, dass nicht der Zugriff das Hauptproblem ist. Anträge erreichen die Führungskräfte ohne Kostenstelle, Vergleichsangebot oder klare Budgetgrenze. Deshalb beginnen Rückfragen, und niemand weiß, wann ein Vorgang entscheidungsreif ist.

Die erste Verbesserung besteht aus verbindlichen Pflichtangaben, eindeutigen Freigabegrenzen und einer Vertretungsregel im bestehenden System. Erst danach wird geprüft, ob eine mobile Oberfläche zusätzlichen Nutzen bringt.

Der Lösungswunsch war nicht unsinnig. Er zeigte auf eine sichtbare Stelle im Ablauf. Die belastbare Anforderung entstand aber erst, als Entscheidungsreife und Durchlaufzeit statt „App vorhanden“ zum Ziel wurden.

Die Anforderungskarte

Für viele mittelständische Vorhaben genügt eine kompakte Karte, bevor ein detailliertes Fachkonzept entsteht.

Feld	Zu klärende Aussage
Auslöser	Welche Situation oder Beobachtung führt zur Anforderung?
Problem	Was gelingt heute nicht zuverlässig oder nur mit unverhältnismäßigem Aufwand?
Nutzer	Welche Rollen sind in welchem Kontext betroffen?
Wirkung	Was soll sich für Prozess, Qualität, Zeit, Risiko oder Kosten verändern?
Ausgangsbasis	Welche Beobachtung oder Messung beschreibt den heutigen Zustand?
Umfang	Was gehört zur Anforderung – und was ausdrücklich nicht?
Bedingungen	Welche fachlichen, technischen und organisatorischen Grenzen gelten?
Abnahme	Welche beobachtbaren Kriterien belegen das Ergebnis?
Verantwortung	Wer entscheidet Priorität, Zielkonflikte und fachliche Abnahme?
Betrieb	Wer trägt Support, Pflege, Datenqualität und laufende Kosten?
nächster Beleg	Welche kleine Untersuchung oder Erprobung reduziert die größte Unsicherheit?

Die Karte ersetzt kein Lastenheft für ein komplexes Vorhaben. Sie verhindert, dass ein solches Dokument zu früh eine Lösung detailliert, deren Zweck noch nicht belastbar ist.

Wann eine kurze User Story genügt

Für eine kleine, reversible Änderung in einem bekannten Produkt kann eine User Story mit klaren Akzeptanzkriterien ausreichen. Voraussetzung ist, dass Nutzer, Prozess, Daten und Verantwortung bereits verstanden sind.

Mehr Klärung ist notwendig, wenn mehrere Bereiche betroffen sind, hohe Folgekosten entstehen, sensible Daten verarbeitet werden, ein schwer reversibler Vertrag bevorsteht oder die Beteiligten das Problem unterschiedlich beschreiben.

Das IREB CPRE Foundation Level Handbook behandelt Requirements Engineering unabhängig davon, ob ein Vorgehen planorientiert oder agil organisiert ist. Ein Backlog beseitigt die Aufgabe also nicht. Es verändert nur die Form, in der Anforderungen dokumentiert und weiterentwickelt werden.

Eine Anforderung wird belastbar, wenn sie eine Entscheidung ermöglicht: Welches Problem ist relevant, welche Wirkung wird angestrebt, welche Grenzen gelten und welcher Nachweis reicht für die Abnahme? Erst dann lohnt es sich, über App, Workflow, Standardsoftware oder Individualentwicklung zu sprechen.