Wenn KI aus unklaren Anforderungen Produktentscheidungen macht

Generative KI hält zunehmend Einzug in die Softwareentwicklung und eröffnet auch im Requirements Engineering neue Möglichkeiten. Sie kann Anforderungen analysieren, weiterverarbeiten und daraus in kurzer Zeit konkrete Artefakte für Entwicklung und Test ableiten. Damit gewinnt jedoch die Qualität der zugrunde liegenden Anforderungen zusätzlich an Bedeutung: Wo Informationen fehlen oder Produktentscheidungen noch offen sind, kann aus einer hilfreichen Automatisierung schnell ein Risiko werden.

Generative KI kann aus Anforderungen innerhalb weniger Sekunden Akzeptanzkriterien und Testfälle ableiten. Fehlen wichtige Informationen, können dabei Annahmen zu vermeintlich feststehenden Produkteigenschaften werden. „Das System soll den Nutzer rechtzeitig warnen, wenn ein kritischer Zustand eintritt.“ Auf den ersten Blick klingt das nach einer brauchbaren Anforderung. Das gewünschte Verhalten ist beschrieben, ein Nutzer kommt vor und mit dem kritischen Zustand gibt es einen Auslöser. Für Entwicklung und Test reicht das trotzdem nicht. Wer genau ist „der Nutzer“? Was bedeutet „rechtzeitig“? Wann ist ein Zustand kritisch? Wie soll die Warnung aussehen? Hinter diesen Fragen stecken keine sprachlichen Feinheiten. Es fehlen Produktentscheidungen.

01 — Beobachtung

Wenn aus einer Lücke eine Entscheidung wird

Das wird besonders sichtbar, wenn wir generative KI auf eine solche Anforderung anwenden. Fordern wir sie auf, testbare Akzeptanzkriterien zu formulieren und fehlende Informationen durch sinnvolle Annahmen zu ergänzen, muss sie Entscheidungen treffen.

Sie kann zum Beispiel festlegen, was „kritisch“ bedeutet, wie schnell eine Warnung erfolgen muss, wie die Warnung ausgegeben wird oder ob sie bestätigt und protokolliert werden muss. Das Ergebnis kann vollständig und schlüssig aussehen. Die zusätzlichen Festlegungen stammen trotzdem nicht aus der ursprünglichen Anforderung.

02 — Vergleich

Gute Requirements minimieren Interpretationsraum

Wie stark die Qualität des Inputs das Ergebnis beeinflusst, zeigt ein einfaches Beispiel.

Variante A

Variante B

Bei Variante A bleiben zentrale Begriffe offen. Was ist eine große Datei? Was bedeutet schnell? Wann gilt ein Download als erfolgreich? Eine KI kann daraus Testfälle generieren. Dafür muss sie aber selbst festlegen, mit welcher Dateigröße getestet wird, welche Downloadzeit akzeptabel ist und was überhaupt als erfolgreicher Test gilt.

Variante B schränkt diesen Spielraum ein. Dateigröße und Zeitgrenze sind definiert. Auch für eine Unterbrechung wird ein erwartetes Verhalten beschrieben. Vollständig ist auch diese Anforderung nicht. Welche Netzwerkbedingungen gelten? Wann ist eine Fehlermeldung verständlich?

03 — Risiko

Test bestanden. Aber haben wir das Richtige getestet?

Je weiter eine Annahme durch den Entwicklungsprozess wandert, desto schwieriger wird es, ihren Ursprung zu erkennen.

Eine typische Kette kann so aussehen:

Am Ende steht möglicherweise ein bestandener Test. Dieser Test zeigt, dass die Implementierung die zugrunde liegende Spezifikation erfüllt. Er zeigt nicht automatisch, dass diese Spezifikation die ursprüngliche fachliche Absicht korrekt wiedergibt.

Auch eine vollständige Traceability löst dieses Problem nicht. Sie macht nachvollziehbar, welche Anforderung mit welchem Test verbunden ist. Sie beantwortet aber noch nicht die Frage, woher jede einzelne Festlegung stammt. Für den Einsatz generativer KI wird deshalb eine zusätzliche Frage wichtig:

04 — Methode

KI zuerst als Reviewer einsetzen

Für das Requirements Engineering ergibt sich daraus ein anderer Ansatz. Die erste Aufgabe für die KI muss nicht lauten: „Erzeuge Akzeptanzkriterien für diese Anforderung.“

Eine bessere erste Frage kann sein: „Welche Entscheidung fehlt?“ Damit ändert sich die Rolle der KI. Statt Informationslücken selbstständig zu schließen, soll sie diese zunächst sichtbar machen. Ein sinnvoller Ablauf besteht aus vier Schritten:

1. Analysieren

Welche Begriffe sind mehrdeutig? Welche Informationen fehlen, damit aus der Anforderung eindeutige Tests entstehen können?

2. Rückfragen formulieren

Welche offenen Punkte müssen Product Owner sowie Fachexpertinnen und Fachexperten entscheiden?

3. Generieren

Erst wenn die relevanten Entscheidungen getroffen wurden, entstehen daraus Akzeptanzkriterien, Testfälle und Dokumentation.

4. Prüfen

Zum Schluss werden die Ergebnisse fachlich geprüft. Dazu gehört insbesondere die Frage, ob neue Annahmen hinzugekommen sind und welchen Einfluss sie auf Produktverhalten, Risiken und Nachweisführung haben.

05 — Praxis

Ein Prompt für den Requirement Review

Für einen solchen Review reicht bereits eine kurze Vorlage:

Generiere noch keine Akzeptanzkriterien.

Welche Begriffe sind mehrdeutig?
Welche Informationen fehlen für deterministische Tests?
Welche Annahmen müsstest du treffen?
Welche Annahmen könnten Produkt- oder Sicherheitsverhalten verändern?
Formuliere priorisierte Rückfragen an den Product Owner.

Trenne zwischen Textbefund, Annahme und Rückfrage.

Damit entsteht zunächst kein weiterer Spezifikationstext. Stattdessen werden die Stellen sichtbar, an denen Menschen eine fachliche Entscheidung treffen müssen.

06 — Abgrenzung

Was sollten wir der KI überlassen?

Requirements formulieren, Akzeptanzkriterien erzeugen und Testfälle schreiben sind naheliegende Einsatzmöglichkeiten für generative KI.

Mindestens genauso relevant ist eine andere Aufgabe: Requirements hinterfragen. KI kann mehrdeutige Formulierungen identifizieren. Sie kann auf fehlende Informationen hinweisen. Und sie kann zeigen, welche Annahmen sie treffen müsste, um aus einer Anforderung einen konkreten Testfall abzuleiten. Die fachliche Entscheidung bleibt bei den Menschen, die Produkt und Kontext kennen.

Autoren

Lisa Liu