Automatisiertes Requirement Engineering: Anforderungen bewerten mit dem RE Assistant
In der Fahrzeugsoftware-Entwicklung entstehen Anforderungsbestände mit tausenden Einträgen, die manuell geprüft werden. Wir bauen den RE Assistant – ein KI-System, das Anforderungen automatisiert auf Eindeutigkeit, Testbarkeit und Widersprüche prüft, mit Begründung je Befund. Die Entscheidung bleibt beim Ingenieur.
Ausgangslage
In der Fahrzeugsoftware-Entwicklung wachsen Anforderungsbestände auf tausende Einträge, verteilt über DOORS Next, Polarion, codebeamer oder Jama Connect. Jeder Eintrag soll eindeutig, testbar und vollständig formuliert sein – Akteur, Bedingung, Messgröße – und den ASPICE-orientierten Formulierungsregeln des Hauses folgen.
Das manuelle Review dieser Bestände bindet genau die Ingenieure, deren Zeit am knappsten ist. In der Praxis bleibt oft nur die Stichprobe, und Widersprüche zwischen Anforderungen fallen erst spät auf – im Test oder im Feld, wo sie am teuersten sind.
Typische Datengrundlage
Anforderungsbestände aus DOORS Next, Polarion, codebeamer oder Jama Connect, über Export oder API-Anbindung. Lasten- und Pflichtenhefte als Word- und PDF-Dokumente, erschlossen über eine Dokumenten-Pipeline, die Layout, Tabellen und Nummerierung erhält.
Dazu die internen Schreibrichtlinien und Prüfkataloge des Kunden – sie machen aus einem generischen Prüfwerkzeug ein hausspezifisches – und historische Review-Kommentare als Referenz für typische Beanstandungen.
Woran solche Vorhaben scheitern
Fachsprache ohne Kontext. Domänenspezifische Begriffe und Abkürzungen interpretiert ein Sprachmodell ohne Vorbereitung falsch. Ohne Anbindung an die Terminologie des Hauses produziert es Scheinbefunde.
Konflikte zeigen sich erst im Zusammenhang. Anforderungen verweisen über Dokument- und Systemgrenzen hinweg aufeinander. Alle Paare zu prüfen ist bei tausenden Einträgen rechnerisch nicht sinnvoll – die Prüfung muss auf aussichtsreiche Kandidaten eingegrenzt werden.
Blackbox-Urteile. Ein Befund ohne Begründung und Textstelle wird von Requirements-Ingenieuren zu Recht nicht akzeptiert. Jede Bewertung muss nachvollziehbar sein.
Vertrauliche Daten. Anforderungsdaten dürfen die Unternehmensgrenze nicht verlassen. Das System muss vollständig innerhalb der IT-Umgebung des Kunden laufen.
Vorgehen
Regelwerk plus Sprachmodell. Formale Kriterien – Passivkonstruktionen, vage Begriffe, fehlende Messgrößen, verbotene Formulierungen – prüft ein deterministisches Regelwerk zuverlässig und reproduzierbar. Das Sprachmodell bewertet darüber hinaus Verständlichkeit und Testbarkeit und liefert zu jedem Befund eine Begründung mit Textstelle.
Konfliktkandidaten statt aller Paare. Eine hybride Suche aus Stichwortsuche (BM25) und Embeddings findet zu jeder Anforderung die inhaltlich nächsten Nachbarn; ein Cross-Encoder-Reranking sortiert die Kandidaten. Nur diese Paarmenge geht in eine gezielte Widerspruchsprüfung. Ergebnis ist eine Liste von Konfliktkandidaten mit Begründung, die der Reviewer bestätigt oder verwirft.
Ein Agent für Ad-hoc-Fragen. Für Fragen wie „Welche Anforderungen zu dieser Funktion stehen möglicherweise im Konflikt?“ oder „Welche dieser Anforderungen sind nicht testbar formuliert?“ verkettet ein Agent die Prüfschritte.
Betrieb in der Kundengrenze. Das Sprachmodell läuft innerhalb der IT-Umgebung des Kunden – als Open-Weight-Modell wie Mistral oder Llama auf eigener GPU-Infrastruktur über vLLM, oder als vertraglich abgesicherter EU-Dienst wie Azure OpenAI innerhalb der EU Data Boundary. Die Entscheidung trifft die IT des Kunden; die übrige Architektur bleibt davon unberührt.
Was dabei entsteht
Begründete Befunde direkt im Requirements-Management-Tool: je Anforderung die Bewertung von Eindeutigkeit, Testbarkeit und struktureller Vollständigkeit, dazu Konfliktkandidaten mit Begründung. Klassifikation und Zusammenfassung entstehen direkt mit und machen große Anforderungsmengen schneller erfassbar.
Als Erfolgskriterium vereinbaren wir zu Projektbeginn zwei Kennzahlen: die Übernahmequote der vorgeschlagenen Befunde durch die Reviewer und die Falschbefundquote gegen ein gelabeltes Referenzpaket. Beide werden im Pilot gemessen und als Abnahmekriterium festgeschrieben.
Woher unsere Erfahrung kommt
Wir werten seit Jahren technische und wissenschaftliche Textbestände maschinell aus und kennen die Automotive-Entwicklung aus Prognose- und Analyseprojekten mit OEMs und Zulieferern.
Zuletzt aktualisiert: 13. August 2026
