Requirements-Qualität mit LLMs prüfen: Praxis-Leitfaden

Requirements-Qualität mit LLMs prüfen: Mehrdeutigkeit, Dubletten, Abnahmekriterien

Ein Large Language Model (LLM) kann die Qualität von Anforderungen vorprüfen: Es markiert mehrdeutige Formulierungen, Lücken gegenüber Vollständigkeits-Heuristiken, Dubletten- und Widerspruchs-Kandidaten über große Bestände sowie fehlende oder schwache Abnahmekriterien. Das Urteil über jede Markierung bleibt beim Requirements Engineer; das System arbeitet rein lesend und verändert keinen Anforderungsstand. Tragfähig wird die Vorprüfung durch einen Feedback-Kanal für Fehlmarkierungen und durch die geordnete Anbindung an das führende Anforderungsmanagement, etwa IBM DOORS oder Polarion. sensified beschreibt in diesem Beitrag die vier Prüfdimensionen einzeln und ordnet den Arbeitsmodus als rein lesende Augmentation ein.

Die Ausgangslage ist in vielen Serienprojekten dieselbe. Ein Lastenheft mit vierstelliger Anforderungszahl kommt vom Kunden, das Review-Fenster vor dem nächsten Meilenstein ist knapp, und die formale Qualitätsprüfung nach den Schreibregeln des Projekts konkurriert mit der inhaltlichen Klärungsarbeit um dieselben Stunden. Wer die Software-Anforderungsanalyse nach Automotive SPICE (ASPICE) im Prozess SWE.1 verantwortet, kennt den Effekt: Unter Termindruck wird aus der systematischen Qualitätsprüfung eine Stichprobe. Genau hier setzt die LLM-Vorprüfung an. Eine Abgrenzung vorweg: Der Beitrag zum Requirements Engineer mit KI in SWE.1 behandelt die Rollen-Sicht, also die Frage, was Kernaufgabe des Requirements Engineers bleibt und was maschinell wird. Der vorliegende Beitrag ist die Werkzeug-Praxis dazu: wie ein LLM Mehrdeutigkeit, Vollständigkeit, Dubletten und Abnahmekriterien-Lücken konkret vorprüft, bevor ein Mensch urteilt. Er gehört zur Werkzeug-Ebene, deren Überblick der Hub-Beitrag zur KI in der Automotive-Softwareentwicklung gibt. Die Eignungsaussagen sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Vier Prüfdimensionen, ein Grundmuster

Die LLM-Vorprüfung von Anforderungen zerfällt in vier Prüfdimensionen, und für alle vier gilt dasselbe Grundmuster: Das System markiert Kandidaten, der Engineer urteilt über jeden Kandidaten, und Fehlmarkierungen fließen über einen definierten Kanal in die Verbesserung des Prüfregelwerks zurück. Eine Markierung ist ein Hinweis mit Begründung, kein Befund. Wer diese Unterscheidung im Werkzeug und im Prozess sauber abbildet, gewinnt Prüfbreite, ohne die Verantwortung zu verwischen.

Die Reihenfolge der Dimensionen ist kein Zufall. Mehrdeutigkeit und Vollständigkeit prüfen die einzelne Anforderung, Dubletten und Widersprüche prüfen den Bestand, Abnahmekriterien schlagen die Brücke zur Verifikation. Die folgenden Abschnitte gehen jede Dimension einzeln durch.

Mehrdeutigkeit: Marker finden, Bedeutung klären

Mehrdeutigkeit ist die Dimension, in der Sprachmodelle ihre Stärke am direktesten ausspielen, denn sie ist ein Sprachproblem. Zugleich ist sie die Dimension mit den meisten Fehlmarkierungen, weil Projektsprache und Allgemeinsprache auseinanderfallen.

Was das System markiert

Der Prüfrahmen ist kein Eigenbau. Die Norm ISO/IEC/IEEE 29148 (Herausgeber: ISO/IEC/IEEE, 2018) beschreibt Merkmale wohlgeformter Einzelanforderungen, darunter eindeutig, singulär, vollständig und verifizierbar. Ein LLM operationalisiert diese Merkmale auf Textebene: Es markiert vage Begriffe wie schnell, robust, angemessen oder benutzerfreundlich, für die kein Messkriterium angegeben ist. Es markiert Passivkonstruktionen ohne erkennbaren Akteur, unklare Pronomen-Bezüge über Satzgrenzen, versteckte Und-Oder-Verknüpfungen sowie Sätze, die mehrere prüfbare Aussagen bündeln und damit das Singularitäts-Merkmal verletzen. Jede Markierung trägt eine kurze Begründung und den Verweis auf die verletzte Schreibregel, damit der Engineer die Prüfung nachvollziehen kann statt ihr glauben zu müssen.

Typische Fehlmarkierungen

Drei Muster kehren wieder. Erstens etablierte Fachbegriffe: Ein Wort wie Entprellzeit ist für das Modell ohne Glossar-Anbindung ein Kandidat für Vagheit, im Projekt aber präzise definiert. Zweitens referenzierte Präzisierung: Die Anforderung wirkt isoliert unvollständig, der quantitative Wert steht jedoch im verlinkten Schnittstellendokument. Drittens bewusste Freiheitsgrade: Manche Lastenheft-Formulierung lässt dem Lieferanten absichtlich Lösungsraum, und eine Schärfung wäre fachlich falsch. In allen drei Fällen entscheidet der Engineer, und genau diese Entscheidungen gehören in den Feedback-Kanal, damit das Prüfregelwerk projektspezifisch nachschärft.

Vollständigkeit und Abnahmekriterien: Heuristik und Entwurf

Die zweite und die vierte Prüfdimension hängen zusammen: Beide fragen, ob eine Anforderung genug Substanz für die Verifikation trägt. Der Unterschied liegt im Ergebnis. Die Vollständigkeitsprüfung markiert Lücken, die Abnahmekriterien-Prüfung liefert zusätzlich einen Entwurf.

Vollständigkeits-Heuristiken

Vollständigkeit ist formal nicht beweisbar; prüfbar sind Heuristiken. Ein LLM gleicht Anforderungen gegen wiederkehrende Muster ab: Ist der Fehlerfall zum Gutfall beschrieben, tragen Zahlenwerte Einheiten und Toleranzen, sind Betriebszustände wie Klemmenwechsel oder Degradationsmodi benannt, existieren Zeit- und Randbedingungen für zeitkritisches Verhalten, ist das Verhalten an den Bereichsgrenzen definiert. Jeder Treffer ist ein Lücken-Kandidat. Der Engineer beurteilt, ob die Lücke real ist, ob sie bewusst offen bleibt oder ob die Information an anderer Stelle des Anforderungsbestands steht. Die typische Fehlmarkierung dieser Dimension ist die dritte Variante: Das System kennt die Dokumentenlandschaft nicht vollständig und meldet Lücken, die auf Systemebene längst geschlossen sind.

Abnahmekriterien-Entwürfe

Bei Anforderungen ohne prüfbares Abnahmekriterium kann das System über die Markierung hinausgehen und einen Kriteriums-Entwurf vorschlagen: Vorbedingung, Stimulus, erwartetes Verhalten, Messgröße. Solche Entwürfe sparen Schreibarbeit und machen Diskussionen konkret, sie sind aber Vorschläge mit begrenzter Einsicht in die Testrealität. Der Engineer prüft dreierlei: ob das Kriterium die fachliche Absicht trifft, ob es in der vorhandenen Testumgebung überhaupt prüfbar ist und ob es Design-Entscheidungen vorwegnimmt, die in die Anforderung nicht hineingehören. Warum sich diese Sorgfalt lohnt, zeigt der Druck auf der Nachweisstrecke: 46 % der Automotive-Teams fällt der Nachweis der ISO-26262-Konformität schwer (Quelle: Perforce, 2025). Anforderungen, die mit belastbaren Abnahmekriterien in die Umsetzung gehen, entlasten genau diese Strecke, weil die Verifikationsargumentation früh angelegt wird.

Dubletten und Widersprüche über große Bestände

Die dritte Prüfdimension wechselt die Flughöhe: von der einzelnen Anforderung zum Bestand. Hier liegt der Fall, den kein Mensch nebenbei leistet, denn der paarweise Vergleich von einigen tausend Anforderungen über mehrere Dokumentengenerationen übersteigt jedes Review-Fenster.

Wie Kandidaten entstehen

Technisch beruht die Prüfung auf semantischer Ähnlichkeit: Anforderungstexte werden als Vektoren repräsentiert, ähnliche Paare und Cluster werden unabhängig vom Wortlaut gefunden. Das deckt die Fälle auf, die eine reine Textsuche verfehlt, etwa dieselbe Forderung in zwei Formulierungen aus zwei Lastenheft-Versionen oder zwei Anforderungen, die dieselbe Größe mit unterschiedlichen Grenzwerten belegen. Widerspruchs-Kandidaten entstehen aus demselben Verfahren mit umgekehrtem Vorzeichen: hohe Ähnlichkeit im Gegenstand, Abweichung in Wert, Bedingung oder Modalität.

Was der Engineer entscheidet

Die Kandidatenliste ist der Anfang der Arbeit. Der Engineer unterscheidet echte Dubletten von zulässigen Verfeinerungen über Ebenen, denn eine Systemanforderung und ihre Software-Ableitung sind sich absichtlich ähnlich. Er unterscheidet echte Widersprüche von Varianten- und Betriebszustands-Logik, denn zwei abweichende Grenzwerte können zu zwei Fahrzeugkonfigurationen gehören. Genau diese beiden Verwechslungen sind auch die typischen Fehlmarkierungen der Dimension. Das Konsistenz-Urteil über den Bestand bleibt damit eine menschliche Entscheidung; das System liefert die Kandidaten in einer Breite, die manuell nicht erreichbar ist.

Arbeitsmodus: rein lesende Vorprüfung mit Feedback-Kanal

Alle vier Dimensionen laufen im selben Arbeitsmodus, und dieser Modus ist der Grund, warum die Vorprüfung ohne Umbau der Freigabeprozesse einsetzbar ist. In unserem Vorgehensmodell ist das die Triage-Klasse B: rein lesende Augmentation, ohne Schreibrechte auf Arbeitsprodukte und ohne eigenen Arbeitsstand. Die vollständige Klassen-Logik beschreibt der Beitrag zur Triage zwischen Automatisierung und Augmentation im Engineering.

Warum rein lesend

Eine Vorprüfung, die Anforderungen direkt ändert, würde einen zweiten Autor in den Bestand einführen und jede Baseline-Argumentation belasten. Die rein lesende Auslegung vermeidet das: Der Anforderungsbestand hat weiterhin genau einen Änderungsweg, nämlich den bestehenden über den Requirements Engineer und das Änderungsmanagement. Damit bleibt auch die Assessment-Argumentation einfach, denn die Prüfleistung des Systems ist eine zusätzliche Sicht, kein neues Arbeitsprodukt. Der rote Faden der gesamten Werkzeug-Ebene gilt hier wörtlich: KI assistiert, der Mensch verantwortet.

Der Feedback-Kanal

Ohne Feedback-Kanal kippt jede Vorprüfung. Wenn Fehlmarkierungen kommentarlos verworfen werden, bleibt ihre Quote konstant, das Vertrauen sinkt, und nach einigen Wochen liest niemand mehr die Markierungsliste. Tragfähig ist ein einfacher Mechanismus: Jede verworfene Markierung erhält einen Ablehnungsgrund aus einer kurzen Liste, etwa Glossar-Begriff, referenzierte Präzisierung, bewusster Freiheitsgrad oder Varianten-Logik. Diese Gründe fließen periodisch in das versionierte Prüfregelwerk zurück, zum Beispiel in projektspezifische Glossare und Ausnahmelisten. So sinkt die Fehlmarkierungsquote nachvollziehbar, und der Stand des Regelwerks ist je Prüflauf dokumentiert.

Integration in DOORS- und Polarion-Workflows

Die Vorprüfung entfaltet ihren Wert erst im führenden Werkzeug, denn dort finden Review und Klärung statt. Für die Anbindung an IBM DOORS, Polarion oder vergleichbare Systeme gilt dieselbe Richtung wie für den Arbeitsmodus: lesender Zugriff auf einen definierten Baseline-Stand, etwa über ReqIF-Exporte oder die Schnittstellen des Werkzeugs, und Rückgabe der Markierungen als Review-Liste oder als Vorschlags-Attribute, die ein Mensch übernimmt oder verwirft. Ein direktes Schreiben des Systems in Attribute des führenden Bestands ist in dieser Klasse nicht vorgesehen. Wichtig ist die Versionsbindung: Jede Markierung referenziert die Anforderungs-ID und den geprüften Stand, sonst laufen Prüfergebnis und Bestand auseinander. Wer über die Anforderungsprüfung hinaus die gesamte Entwicklungsdokumentation abfragbar machen will, findet die Architektur dafür im Beitrag zur RAG-Anbindung von DOORS, Polarion und Confluence.

Nächste Schritte

Ob die LLM-Vorprüfung in Ihrem Projekt zuerst bei Mehrdeutigkeit, bei Dubletten oder bei Abnahmekriterien ansetzt, hängt von Bestandsgröße, Lastenheft-Qualität und Toolchain ab und lässt sich nicht pauschal entscheiden. Der geordnete Einstieg sieht so aus:

1. Überblick lesen: Der Hub-Beitrag zur KI in der Automotive-Softwareentwicklung ordnet die Requirements-Vorprüfung neben Code-Assistenz, Doku-RAG und Testunterstützung ein.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Werkzeug-Bausteinen ein geführtes Transformationsvorhaben wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Anforderungsbestand, Toolchain und Ausgangslage Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur LLM-gestützten Qualitätsprüfung von Anforderungen zusammen. Sie beschreiben typisierte Prüfdimensionen und Arbeitsmodi; wie die Vorprüfung in einem konkreten Projekt liegt, wird je Kunde und Toolchain geprüft.

Kann ein LLM die Qualität von Anforderungen prüfen?

Ja, als rein lesende Vorprüfung in vier Dimensionen: Mehrdeutigkeit, Vollständigkeit, Dubletten und Widersprüche sowie Abnahmekriterien. Das System markiert Kandidaten mit Begründung, der Requirements Engineer urteilt über jede Markierung. Das Qualitäts- und Konsistenz-Urteil über den Anforderungsbestand bleibt eine menschliche Entscheidung.

Ersetzt die LLM-Vorprüfung das Review durch den Requirements Engineer?

Nein. Die Vorprüfung übernimmt die Breite, also das systematische Durchkämmen großer Bestände gegen Schreibregeln und Ähnlichkeitsmuster. Urteil, Klärungsarbeit mit dem Kunden und die Freigabe bleiben beim Engineer. Was das für den Zuschnitt der Rolle bedeutet, beschreibt der Rollen-Beitrag zum Requirements Engineer mit KI in SWE.1.

Welche Mehrdeutigkeits-Marker erkennt ein LLM zuverlässig?

Belastbar sind sprachliche Muster: vage Begriffe ohne Messkriterium, Passiv ohne Akteur, unklare Bezüge, versteckte Verknüpfungen und Sätze mit mehreren prüfbaren Aussagen. Grundlage sind die Merkmale wohlgeformter Anforderungen, wie sie ISO/IEC/IEEE 29148 beschreibt. Projektspezifische Fachbegriffe braucht das System als Glossar, sonst steigt die Fehlmarkierungsquote.

Wie findet ein LLM Dubletten und Widersprüche in großen Anforderungsbeständen?

Über semantische Ähnlichkeit: Anforderungstexte werden als Vektoren verglichen, ähnliche Paare und Cluster erscheinen als Kandidatenliste, auch wenn der Wortlaut abweicht. Widerspruchs-Kandidaten sind Paare mit gleichem Gegenstand und abweichendem Wert oder abweichender Bedingung. Der Engineer trennt anschließend echte Befunde von Verfeinerungen über Ebenen und von Varianten-Logik.

Kann ein LLM Abnahmekriterien schreiben?

Es kann Entwürfe liefern: Vorbedingung, Stimulus, erwartetes Verhalten und Messgröße als Vorschlag zu einer Anforderung ohne prüfbares Kriterium. Der Engineer prüft jeden Entwurf auf fachliche Richtigkeit, Testbarkeit in der vorhandenen Testumgebung und unzulässige Design-Vorwegnahmen. Übernommen wird ein Kriterium erst durch diese menschliche Entscheidung.

Darf das System direkt in DOORS oder Polarion schreiben?

In der hier beschriebenen Triage-Klasse B nicht. Das System liest einen definierten Baseline-Stand und gibt Markierungen als Review-Liste oder Vorschlags-Attribute zurück; die Übernahme in den führenden Bestand erfolgt durch einen Menschen über den bestehenden Änderungsweg. So bleibt der Anforderungsbestand bei genau einem Änderungspfad, und die Baseline-Argumentation für Assessments bleibt einfach.

Wie geht man mit Fehlmarkierungen um?

Über einen definierten Feedback-Kanal: Jede verworfene Markierung erhält einen Ablehnungsgrund, etwa Glossar-Begriff, referenzierte Präzisierung oder bewusster Freiheitsgrad. Diese Gründe fließen periodisch in das versionierte Prüfregelwerk zurück, zum Beispiel in Glossare und Ausnahmelisten. Damit sinkt die Fehlmarkierungsquote nachvollziehbar, und der Regelwerks-Stand ist je Prüflauf dokumentiert.