Eine Anforderung gilt der Aufgabe, die jemand erledigen will, und dem Ergebnis, das dafür entstehen muss. Die technische Umsetzung ist eine nachgelagerte Entscheidung. Bei KI-Funktionen kehrt sich diese Reihenfolge in Anforderungsdokumenten besonders schnell um; der Beitrag zeigt, warum, und wie Teams sie halten.
Die verbreitete Sicht
Anforderungen an neue Funktionen nennen die Technologie: Das System nutzt ein Sprachmodell, um Anfragen zu klassifizieren. Damit scheint festgelegt, was gebaut wird, und die Entwicklung kann beginnen.
Die Verschiebung
ISO 9241-210 trennt die Nutzungsanforderungen von der Gestaltungslösung. Die Nutzungsanforderung sagt, was Nutzende in ihrem Nutzungskontext erreichen müssen und woran sich das prüfen lässt. Die Gestaltungslösung sagt, wie das System das ermöglicht, und dazu gehört die Technologie. Ein Satz wie „Das System nutzt ein Sprachmodell" ist eine Lösungsentscheidung in der Form einer Anforderung. Er lässt sich nicht prüfen, weil er kein Ergebnis nennt: Ein System, das ein Sprachmodell nutzt und die Anfragen falsch zuordnet, erfüllt ihn.
Bei KI-Funktionen geht die Reihenfolge aus zwei Gründen schneller verloren als sonst. Erstens ist die Technologie der Anlass des Vorhabens: Das Budget ist für „KI" freigegeben, also steht „KI" in der Anforderung. Zweitens ist die Lösung vor der Aufgabe da: Ein Team hat gesehen, was ein Modell kann, und sucht die Aufgabe dazu. In beiden Fällen fehlt die Beobachtung der Menschen, die die Aufgabe heute erledigen.
Die Anforderung, die aus der Beobachtung entsteht, sieht anders aus: Sachbearbeitende der Eingangspost ordnen jede Anfrage innerhalb ihres Arbeitsschritts einer Bearbeitungsgruppe zu; sie erkennen an der Anzeige, welche Merkmale der Anfrage die Zuordnung begründen, und können sie ändern. Dieser Satz nennt Rolle, Aufgabe, Ergebnis und Prüfkriterium. Über die Technologie sagt er nichts. Ob ein Sprachmodell, ein Regelwerk oder eine Kombination die Anforderung erfüllt, entscheidet die Lösungsarchitektur und zeigt die Abnahme.
Was daraus folgt
Teams halten die Reihenfolge mit einer Prüfung, die sich auf jede Anforderung anwenden lässt: Streichen Sie die Technologie aus dem Satz. Bleibt eine Aussage übrig, die Rolle, Aufgabe, Ergebnis und Prüfkriterium enthält? Wenn ja, war die Technologie ein Zusatz und gehört in die Lösungsbeschreibung. Wenn nein, fehlt die Anforderung, und der Satz beschreibt den Wunsch nach einer Technologie.
Die zweite Sicherung ist die Herkunft: Jede Anforderung verweist auf die Erhebung, aus der sie stammt. Steht dort ein Workshop ohne Nutzende, ist die Anforderung eine Annahme und wird als solche geführt.
Ein Beispiel
Ein Landmaschinenhersteller plant eine Funktion, die Fehlercodes der Maschine in Klartext übersetzt, mit einem Sprachmodell als vorgesehener Technik. Die erste Anforderung lautet: Das Terminal erklärt Fehlercodes mithilfe von KI. Bei der Beobachtung auf den Betrieben zeigt sich, was Fahrerinnen und Fahrer mit einem Fehlercode tun: Sie entscheiden, ob sie weiterfahren, anhalten oder den Service rufen. Die Erklärung des Codes ist dafür nachrangig; entscheidend ist die Handlungsempfehlung und ihre Verlässlichkeit bei laufender Maschine.
Die Anforderung nach der Erhebung: Fahrende erhalten zu jedem Fehlercode eine Angabe, ob Weiterfahren zulässig ist, mit dem Grund; die Angabe stammt aus der freigegebenen Servicedokumentation und nennt ihre Quelle. Ob ein Sprachmodell diese Angabe aus der Dokumentation erzeugt oder eine Tabelle sie liefert, ist eine Lösungsfrage. Die Anforderung bleibt in beiden Fällen dieselbe, und sie bleibt es auch beim nächsten Technologiewechsel.