KI im Requirements Engineering: Lastenhefte prüfen lassen, ohne die Verantwortung abzugeben

Die Gliederung ist sauber. Jede Anforderung hat eine Nummer. Das Dokument ist freigegeben. Ein paar Monate später streiten trotzdem alle darüber, was mit „zeitnaher Verarbeitung“ gemeint war und warum die Altdaten nirgends vorkommen.

Lastenhefte scheitern selten am Format. Sie scheitern an Lücken, an Widersprüchen und an Begriffen, die jede Abteilung anders versteht. Ich lese sie meist von der anderen Seite des Tisches: als Auftragnehmer, der daraus ein Angebot und einen Plan machen soll. Dort fallen solche Stellen irgendwann auf. Meistens spät.

Beim Aufspüren helfen Sprachmodelle. Sie arbeiten ein langes Dokument in Minuten durch und gehen dabei einen festen Kriterienkatalog Punkt für Punkt ab. Entscheiden können sie nicht. Was an einer gefundenen Stelle gelten soll, legen die Menschen fest, die das Projekt verantworten.

Was KI im Lastenheft-Review leisten kann

Ein Sprachmodell nimmt dem Team einen großen Teil der Sucharbeit ab. Vier Prüfungen bieten sich an:

• Vollständigkeit: Das Modell gleicht den Text mit dem Kriterienkatalog ab. Sind die Schnittstellen benannt, etwa zur Warenwirtschaft oder zum Zahlungsanbieter? Ist die Datenmigration beschrieben? Gibt es nicht-funktionale Anforderungen, also Vorgaben zu Antwortzeiten, Verfügbarkeit und Sicherheit? Wer betreibt die Lösung nach dem Go-live, und woran wird die Abnahme festgemacht?
• Widersprüche und Doppelungen: Abschnitt 3.2 verlangt Single Sign-on für alle Nutzergruppen, Abschnitt 7.4 beschreibt eine eigene Passwortverwaltung für Partnerfirmen. Oder dieselbe Anforderung steht zweimal im Dokument, mit zwei verschiedenen Zahlen.
• Vage Formulierungen: „Schnell“, „benutzerfreundlich“ oder „bei Bedarf“ lesen sich harmlos. In der Abnahme lässt sich nichts davon prüfen. Das Modell markiert solche Stellen und fragt nach dem Maßstab: Wie schnell? Für welche Funktion? Unter welcher Last?
• Begriffe: Was ist nirgends definiert? Und wo heißt dieselbe Sache in einem Abschnitt „Auftrag“ und im nächsten „Bestellung“?

Am Ende aller vier Prüfungen steht eine Liste mit Rückfragen an den Fachbereich.

Der Review-Ablauf in vier Schritten

Schritt 1: Ziel und Kontext festlegen. Wozu wird geprüft? Vor einer Ausschreibung zählt, ob die Angebote vergleichbar werden. Vor einem Angebot zählt, wo Risiken für Aufwand und Preis stecken. Dann kommt der Kontext: Projektziel, Nutzergruppen, bestehende Systeme und, falls vorhanden, das Glossar. Und es wird festgehalten, welche Dokumentversion geprüft wird.

Schritt 2: Prüfauftrag mit klaren Kriterien formulieren. Ein Prüfauftrag wie „Prüfe dieses Lastenheft“ liefert allgemeine Ratschläge. Brauchbar wird das Ergebnis erst, wenn der Prüfauftrag (Prompt) Kriterien und Ausgabeformat vorgibt. Ein Beispiel:

Du bist erfahrener Requirements Engineer und prüfst ein Lastenheft vor der Ausschreibung. Kontext: [Projektziel, Nutzergruppen, bestehende Systeme, Glossar]. Geprüft wird Version [Nr.].

Prüfe das Dokument auf vier Kriterien:

1. Vollständigkeit: Sind Schnittstellen, Datenmigration, nicht-funktionale Anforderungen, Betrieb und Abnahme beschrieben?

2. Widersprüche und Doppelungen zwischen Abschnitten.

3. Vage Formulierungen ohne prüfbaren Maßstab.

4. Begriffe, die nicht definiert sind oder uneinheitlich verwendet werden.

Formuliere nichts um und schlage keine Werte vor; gib jeden Befund als offene Rückfrage aus.

Ausgabe als Tabelle mit den Spalten: Abschnitt | Zitat | Befundtyp | Rückfrage.

Wenn du dir unsicher bist, kennzeichne den Befund als unsicher.

Schritt 3: Befunde als Fragen ausgeben lassen. Das Verbot von Korrekturen ist für mich der wichtigste Satz im Prüfauftrag. Ein Modell, das umformulieren darf, macht aus „schnell“ einfach „innerhalb von zwei Sekunden“. Damit trifft es eine Entscheidung, die ihm niemand übertragen hat. Eine offene Frage landet dagegen bei jemandem, der die Antwort kennt oder eine Entscheidung herbeiführen muss.

Schritt 4: Entscheiden und dokumentieren. Das Team prüft jeden Befund am Original und verwirft, was nicht stimmt. Den Rest klärt es mit dem Fachbereich und hält fest, wer was entschieden hat. Erst danach wird das Lastenheft geändert. Auf Auftragnehmerseite läuft es ähnlich: Aus den Befunden werden Rückfragen an den Kunden oder klar benannte Annahmen im Angebot.

Ein typisches Bild aus der Praxis: Ein Händler will seinen Onlineshop an die bestehende Warenwirtschaft anbinden. Das Lastenheft wirkt vollständig, doch das Review fördert eine Handvoll Rückfragen zutage. Wie werden Lagerbestände abgeglichen, in Echtzeit oder nachts? Was passiert mit Bestellungen, wenn die Warenwirtschaft nicht erreichbar ist? Und gehören Altkunden ohne E-Mail-Adresse zur Datenmigration? Keine dieser Fragen ist exotisch. Aber jede hätte sich sonst erst im Projekt gestellt, mit Nachtrag und Terminverschiebung.

Von der Anforderung zum Akzeptanzkriterium

Ist eine Rückfrage beantwortet, kann das Modell daraus ein prüfbares Akzeptanzkriterium vorschlagen. Ein Beispiel: Im Lastenheft steht „Die Suche liefert schnell Ergebnisse“. Der Fachbereich ergänzt, dass es um die Artikelsuche zu Stoßzeiten geht. Daraus wird: „Bei [Anzahl] gleichzeitigen Suchanfragen auf dem vollständigen Artikelbestand erscheint die Trefferliste in [Anteil] Prozent der Fälle innerhalb von [Dauer] Sekunden, gemessen vom Absenden bis zur Anzeige.“

Das Gerüst stimmt: Last, Datenbestand, Messpunkt, Grenzwert. Die Werte fehlen, und das ist richtig so. Wer keine Platzhalter verlangt, bekommt Zahlen, die plausibel klingen und die niemand festgelegt hat. Welche Werte zum Geschäft passen, entscheidet der Fachbereich. Was ihre Einhaltung kostet, weiß die Technik.

Jedes vorgeschlagene Kriterium bleibt deshalb ein Entwurf, bis der Fachbereich es bestätigt hat, mit Namen und Datum. Erst dann kommt es ins Lastenheft und wird zum Maßstab der Abnahme. Ein Kriterium, für das sich niemand bewusst entschieden hat, wird spätestens dort zum Streitfall.

Grenzen und Risiken

Datenschutz und vertrauliche Inhalte. In einem Lastenheft steht mehr Vertrauliches, als man beim ersten Lesen denkt: Namen von Ansprechpersonen, Budgetrahmen, Angaben zu laufenden Verträgen und zur Sicherheitsarchitektur, Informationen von Partnerfirmen. In frei zugängliche KI-Dienste ohne vertragliche Regelung gehört davon nichts. Es gibt drei saubere Wege:

• ein vom Unternehmen freigegebener Dienst, dessen Anbieter einen Vertrag zur Auftragsverarbeitung schließt, Vertraulichkeit zusichert und Eingaben nicht zum Training verwendet
• ein Modell in der eigenen Infrastruktur
• eine bereinigte Fassung, in der Namen, Beträge und andere vertrauliche Angaben durch Platzhalter ersetzt sind

Welcher Weg zulässig ist, klären Datenschutz und IT-Sicherheit, bevor das erste Dokument hochgeladen wird. Beim Lastenheft eines Kunden gelten zusätzlich dessen Vertraulichkeitsvorgaben.

Scheinvollständigkeit und erfundene Details. Eine Tabelle mit 40 sauber formulierten Befunden wirkt gründlich. Was das Modell übersehen hat, steht aber nicht drin. Wonach niemand gefragt hat, auch nicht. Das Modell kennt weder die ungeschriebenen Regeln der Organisation noch das, was im Workshop besprochen und nie notiert wurde. Und manche Befunde stimmen schlicht nicht: ein Zitat, das so nicht im Dokument steht, ein Widerspruch, der keiner ist, eine angebliche Lücke, die der Anhang füllt.

Dagegen helfen drei Handgriffe. Erstens: jedes Zitat am Original prüfen. Zweitens: jede gemeldete Lücke per Stichwortsuche gegenprüfen. Drittens: bei langen Dokumenten mit einer Kontrollfrage zum Ende des Textes testen, ob das Modell alles gelesen hat, samt Tabellen und Anhängen. Was sich nicht bestätigen lässt, wird verworfen. Ein zweiter Durchlauf zeigt außerdem, welche Befunde stabil sind. Zwei Durchläufe liefern nicht immer dieselbe Liste.

Priorisierung und Zielkonflikte. Das Modell kann zeigen, dass der Vertrieb jede Bestellung sofort freigeben will und die Buchhaltung vorher prüfen möchte. Auflösen kann es den Konflikt nicht. Welche Anforderung Vorrang hat, was auf später verschoben wird und was das Budget hergibt, sind Abwägungen zwischen Interessen. Die treffen die Menschen im Projekt, im Zweifel der Auftraggeber.

Rollen und Verantwortung

Das Lastenheft gehört dem Auftraggeber. Er legt fest, was er haben will, und er verantwortet den Inhalt. Daran ändert sich nichts, wenn ein Modell das Dokument geprüft hat. „KI-geprüft“ ist kein Qualitätssiegel und entlastet niemanden.

Für die Projektleitung kommen zwei Aufgaben dazu. Sie klärt mit Datenschutz und IT-Sicherheit, welche Anwendung für welche Dokumente erlaubt ist. Und sie plant Zeit ein: Das Modell braucht Minuten, das Nachprüfen und die Antworten des Fachbereichs deutlich länger.

Im Requirements Engineering fällt das eigene Lesen nicht weg, es wird gezielter: Mehr Zeit fließt in den Kriterienkatalog, die Bewertung der Befunde und die Gespräche mit dem Fachbereich.

Nachvollziehbar bleibt das Ganze über eine Befundliste. Sie übernimmt die Tabelle des Modells und ergänzt pro Befund vier Angaben: Herkunft (KI oder Mensch), Bewertung, Entscheidung, Name mit Datum. Dazu kommen der verwendete Prüfauftrag, das Modell mit Versionsstand und die geprüfte Dokumentversion. Auch verworfene Befunde bleiben mit kurzer Begründung stehen. So lässt sich später zeigen, dass eine Lücke gesehen und bewusst geschlossen oder hingenommen wurde.

Fazit: Acht Punkte für den Einstieg

Sprachmodelle machen das Review eines Lastenhefts schneller und systematischer. Der Nutzen entsteht aber erst mit den Antworten des Fachbereichs. Das klingt nach mehr Aufwand, und am Anfang ist es das auch. Dafür kommen die Fragen auf den Tisch, bevor sie teuer werden. Für den Einstieg reichen ein einziges Dokument und diese Checkliste:

• Klären, welche KI-Anwendung für Projektdokumente freigegeben ist, welche Inhalte hineindürfen und was vorher raus muss.
• Mit dem Lastenheft eines abgeschlossenen Projekts anfangen. Dort ist bekannt, welche Lücken später Ärger gemacht haben.
• Ziel, Anlass und Kontext des Reviews in wenigen Sätzen festhalten.
• Einen festen Kriterienkatalog nutzen und nach jedem Projekt ergänzen.
• Befunde als offene Rückfragen mit Abschnitt und Zitat anfordern, nicht als Korrekturen.
• Jeden Befund am Original prüfen, auch gemeldete Lücken, und verwerfen, was sich nicht belegen lässt.
• Entscheidungen mit Namen und Datum in der Befundliste festhalten, auch bei verworfenen Befunden.
• Akzeptanzkriterien erst in die Abnahme übernehmen, wenn der Fachbereich sie bestätigt hat.