Lastenhefte per KI prüfen
Ein Engineering-Dienstleister im Anforderungsmanagement prüft Lastenhefte mit hunderten Seiten von Hand, gegen eine feste Mängelliste. Wir haben in rund sechs Wochen ein MVP gebaut, das diese Prüfung je Anforderung durchläuft, und es an einem realen Lastenheft mit 432 Seiten getestet.
- Branche
- Automotive-Engineering-Dienstleister, Anforderungsmanagement
- Zeitraum
- Konzept ab März 2025, MVP in rund sechs Wochen zum Festpreis
- Stand
- In Test seit dem 6. August 2025, letzter belegter Vorgang 30. September 2025
- Prüfobjekt
- Reales Lastenheft eines Automobilherstellers, 432 Seiten, über 100.000 extrahierte Zeichen, PDF-Export aus einem Requirements-Management-System
- Gebaut
- Multiagenten-System mit Supervisor: Extraktion von Glossar und nummerierten Anforderungen, neun Befundfelder je Anforderung, dazu ein Formulierungsvorschlag
- Technik
- Python, FastAPI, LangChain, vLLM, LiteLLM, PostgreSQL mit SQLAlchemy, Gradio, Docker
- Ausgabe
- Befunde je Requirement-ID in der Oberfläche, Export als Excel, später als PDF
Ausgangslage
Ein Lastenheft aus dem Automotive-Umfeld hat schnell mehrere hundert Seiten und besteht aus tausenden einzeln nummerierten Anforderungen. Geprüft wird von Hand, gegen immer dieselbe Mängelliste.
Wie die Mängel aussehen, zeigt das Dokument, an dem wir getestet haben: ein reales Lastenheft eines Automobilherstellers mit 432 Seiten, als PDF aus einem Requirements-Management-System exportiert, über 100.000 Zeichen im extrahierten Text. Im Glossar stehen Einträge wie „AQO, Beschreibung offen“ und ein Eintrag, den das Dokument selbst als Tippfehler vermerkt. Drei aufeinanderfolgende Anforderungen sind wortgleich. In einer Anforderung steht noch die Frage des Autors: „woher bekommen wir den Trigger? aus der Funktion? HMI?“
Die Zeichnung daneben hält beides nebeneinander: den Stapel von 432 Seiten und die eine Zeile, in der ein einzelnes Wort den Mangel ausmacht.
Wonach von Hand gesucht wird
- nicht aufgelöste Abkürzungen
- Duplikate
- unklare oder unvollständige Formulierungen
- Passivkonstruktionen
- überlange Anforderungen
- mehrere Sätze in einer Anforderung
- Universalquantoren wie „alle“
- fehlende Verbindlichkeit in der Sprache
- stehengebliebene Platzhalter
Was wir gebaut haben
Ein MVP in rund sechs Wochen zum Festpreis, angelegt als Multiagenten-System mit einem Supervisor. Für den Nutzer hat der Durchlauf vier Schritte: Dokument hochladen, Prüffall wählen, Befunde in der Oberfläche ansehen und anpassen, Ergebnis als Excel exportieren, später zusätzlich als PDF. Das System nimmt das PDF, wie es aus dem Requirements-Management-System kommt. Wie wir solche Vorhaben aufsetzen, steht unter KI-Implementierung.
Dahinter liegt die Verarbeitungskette. Erst werden das Glossar und die einzeln nummerierten Anforderungen aus dem PDF extrahiert, dann läuft je Anforderung eine Prüfung mit neun Befundfeldern. Dazu kommt ein zehntes Feld mit einem Formulierungsvorschlag.
Abkürzungen werden gegen das Glossar geprüft und müssen bei der ersten Nennung ausgeschrieben sein. Eine einmal gemeldete Abkürzung wird danach nicht erneut gemeldet, einzelne lassen sich auf eine Ignorierliste setzen. Die Ansicht lässt sich auf die Fundstellen allein umschalten, die Ausgabe ist je Requirement-ID gegliedert. Die drei wortgleichen Anforderungen aus dem Testdokument markiert das System gegenseitig als Duplikate, mit einem Ähnlichkeitswert von 99,5 Prozent.
Das Raster daneben ist der Kern: Jede Anforderung läuft durch dieselben neun Felder, und was rot ist, sieht sich jemand an.
Im Raster daneben steht jede Zeile für eine Anforderung, jede Spalte für eines der neun Felder, und markiert ist allein die Zelle mit dem Befund.
Die neun Befundfelder je Anforderung
- Abkürzungen, gegen das Glossar des Dokuments
- Länge
- Duplikate, mit Ähnlichkeitswert je Fundstelle
- Platzhalter
- Unvollständigkeit
- Verbindlichkeit der Sprache
- mehrere Sätze in einer Anforderung
- Passiv
- Universalquantoren
| Baustein | Wofür |
|---|---|
| Python und FastAPI | Anwendung und Schnittstelle |
| LangChain | Orchestrierung der Agenten |
| vLLM, davor LiteLLM | Inferenz für selbst gehostete Sprachmodelle, mit Lastverteiler |
| PostgreSQL und SQLAlchemy | Sitzungen und Befunde |
| Gradio | Oberfläche |
| Docker | Container für den Betrieb |
Was heute läuft
In Test seit dem 6. August 2025, begonnen mit einem Kickoff beim Kunden und zwei seiner Partnerbetriebe. Getestet wird an realen Lastenheften aus dem eigenen Haus. Die Befunde halten die Tester in einer Excel-Vorlage fest, nach dem Muster Ist-Zustand, Soll-Zustand, Verbesserungsvorschlag, Kommentar.
Geprüft hat das System dabei ein reales Lastenheft mit 432 Seiten, über 100.000 Zeichen im extrahierten Text. Jede Anforderung darin läuft durch dieselben neun Prüffelder, die Befunde stehen je Requirement-ID in der Oberfläche und gehen als Excel aus dem System.
Das beweist
Eine Prüfung, die sonst im Kopf erfahrener Ingenieure stattfindet, lässt sich in benannte Regeln zerlegen und auf selbst gehosteten Modellen durchlaufen, ohne dass die Dokumente das Haus verlassen. Warum das bei technischen Unterlagen den Ausschlag gibt, steht im Wissensblog unter DSGVO-konforme KI. Wenn bei Ihnen Dokumente dieser Größe von Hand gegen eine feste Mängelliste laufen, ist der Weg derselbe.
Die Zeichnung daneben zieht die Linie, auf die es dabei ankommt: Dokument und Modell stehen im selben Haus, und nach draußen führt keine Verbindung.