Requirements-Engineering mit AI: Klassifizierung, Qualität und Traceability (SWE.1)

Requirements-Engineering mit AI: von der Kundenanforderung zur traceable Requirement

Requirements sind der Ursprung jeder Evidenzkette. Genau hier hat AI den größten Hebel. Und das größte Risiko, wenn Traceability verloren geht. Wer tausende Anforderungen von Hand klassifiziert, verliert Zeit. Wer es unkontrolliert automatisiert, verliert die Spur.

Der Schlüssel ist ein assistierendes Vorgehen. Jede Ableitung bleibt nachvollziehbar. AI strukturiert und schlägt vor. Der Engineer verantwortet und gibt frei. Das ALM bleibt System-of-Record.

AI strukturiert. Der Engineer verantwortet.

Damit stehen für Sie als Verantwortliche im Engineering konkrete Fragen im Raum:

• Wie ordnen und klassifizieren wir große Mengen an Anforderungen zuverlässig?
• Wie leiten wir System-Requirements ab, ohne Traceability zu verlieren?
• Wie erkennen wir Lücken, Inkonsistenzen und Mehrdeutigkeiten früh?
• Wie bleibt die RFQ-Abdeckung nachvollziehbar und belegbar?

Dieser Beitrag zeigt, welche Aufgaben AI im Sinne von SWE.1 übernimmt. Und welche Größenordnung im realen Serienprogramm belegt ist.

Requirements sind der Ursprung der Evidenzkette

Alles, was später belegt werden muss, beginnt bei den Anforderungen. Sie sind der Ursprung der Kette. Sie zieht sich über Design, Implementierung und Test. Ein Fehler hier pflanzt sich durch den ganzen Prozess fort. Und er wird teurer, je später er auffällt.

Deshalb ist das Requirements-Engineering der Ort mit dem größten Hebel. Und mit dem größten Risiko. Der Hebel ist klar. Tausende Anforderungen zu sichten und abzuleiten, ist mechanisch und fehleranfällig. Das Risiko ist ebenso klar. Wird das unkontrolliert automatisiert, entsteht eine Menge plausibler Anforderungen ohne belastbare Spur. Der Anspruch lautet deshalb: Tempo gewinnen, ohne die Spur zu verlieren.

Wo AI im Requirements-Engineering trägt

Der Hebel liegt in der Zuarbeit entlang von SWE.1. Jeder Schritt bleibt vorschlagsbasiert und freigabepflichtig.

• Klassifizierung. Automatische Zuordnung von Anforderungen zu Kategorien und Verantwortlichkeiten, mit menschlicher Freigabe.
• Ableitung. Vorschläge für System-Requirements aus Stakeholder-Anforderungen, inklusive Traceability-Vorschlag.
• Qualität. Erkennen von Lücken, Inkonsistenzen und Mehrdeutigkeiten. Dazu Change- und Impact-Reports.
• Abdeckung. RFQ-Abdeckungsanalysen als Entscheidungsvorlage für das Angebot.

Traceability ist nicht verhandelbar

Vom Vorschlag zur Wahrheit

Jeder Vorschlag bleibt ein Derivat, bis ein Engineer ihn freigibt. Das ALM, etwa Polarion, bleibt System-of-Record. AI schreibt nicht zurück. Sie liefert Vorschläge über ein read-only Overlay. So entsteht keine zweite Wahrheit. Es entsteht eine kontrollierte Zuarbeit zur bestehenden.

Eine prüfbare Matrix

Das Ergebnis ist eine belastbare Traceability-Matrix. Sie führt von der Anforderung zu Design, Unit und Test. Sie ist die Grundlage jeder ASPICE-Argumentation. Sie bleibt konsistent, weil AI die Spuren mitzieht. Die Bewertung verantwortet der Mensch.

Belegte Größenordnung

Dieses Vorgehen war in einem realen, anonymisierten Tier-1-Telematik-ECU-Serienprogramm produktiv im Einsatz. Die Zahlen sind ein Capability-Nachweis. Sie sind kein garantiertes Kundenergebnis.

• Über 27.000 verarbeitete Requirements aus dem ALM.
• Über 70 Engineering-Funktionen als Edge-Functions über Requirements, Test und Prozess.
• SWE.1 bis SWE.6 und MAN.3 als V-Modell-Abdeckung mit ASPICE L2 als Zielreife.

Diese Zahlen zeigen nicht, was Ihr Programm erreichen wird. Sie zeigen, dass das Vorgehen in einem echten Serienkontext trägt.

Prüfbare Artefakte statt Chat-Antworten

Der Wert entsteht nicht in einem Chatfenster. Er entsteht in prüfbaren Artefakten, die in den Prozess passen. Dazu gehört ein Requirements-Quality-Report. Dazu gehört eine Traceability-Matrix von Anforderung bis Test. Und ein Tracker zur Schließung von SWE-Lücken. Das sind Dokumente, die ein Assessor lesen kann. Kein flüchtiger Dialog.

Häufige Fehler im AI-gestützten Requirements-Engineering

• Write-back ins ALM. AI direkt in das System-of-Record schreiben lassen.
• Freigabe überspringen. Vorschläge ungeprüft übernehmen.
• Chat statt Artefakt. Ergebnisse im Dialog belassen, statt sie prüfbar zu machen.

Der rote Faden bleibt gleich. AI beschleunigt die Zuarbeit. Die Freigabe bleibt beim Engineer.

So gehen wir vor: Build, Operate, Transfer

AI-gestütztes Requirements-Engineering nach SWE.1 bauen wir nicht als Folienkonzept. Wir bauen es als produktive Fähigkeit. Das folgt dem Prinzip Build, Operate, Transfer. Unsere Beteiligung nimmt über die Phasen ab. Ihre Capability wächst ins eigene Haus. Der Wissenstransfer ist vertragliches Erfolgskriterium, kein Zusatz. Sonst entsteht genau der Lock-in, den wir vermeiden wollen.

1. Build. Setup, Guardrails und erste Workflows entlang Ihres realen Prozesses.
2. Operate. Betrieb mit KPI-Verantwortung auf Wertstrom-Ebene. Nie auf Personen-Telemetrie.
3. Transfer. Dokumentierte Übergabe. Ihr Team übernimmt Tooling, Wissen und Betrieb.

Getragen wird das von drei Modulen. Erstens ein Strategic Engineering Lead. Das ist ein Senior-Embedded-Architekt zusammen mit einem Strategic AI Lead. Zweitens die auditierbare Tooling-Plane sensified AI-OS. Drittens die Automotive-Playbooks. Sie beschreiben die Methodik für AI in Embedded-, ASIL-, ASPICE- und AUTOSAR-Kontexten. Die Leitplanke, was AI nicht entscheidet, ist darin fest verankert.

Die vier Mandat-Typen sind kombinierbar. Sie passen sich Ihrem Reifegrad an. Es gibt den Strategic Engineering Lead für den breiten Aufbau. Es gibt die BOT Engineering-Capability als Programm-Paket je Domäne. Es gibt den ASPICE- oder ASIL-Workflow-Pilot zur Validierung vor dem Mandat. Und es gibt das Modul Tooling, MCP und AI-Governance mit Schlüssel-Isolation und Kosten-Transparenz. Der Einstieg ist bewusst risikoarm. Zuerst ein Qualifying-Call zum Fit-Check. Dann NDA und Discovery-Workshop. Danach der Workflow-Pilot. Erst dann das BOT-Mandat mit Governance-Plane. Kommerzielle Details klären wir im Discovery-Workshop, nicht über öffentliche Preislisten.

Gemessen wird auf Wertstrom-Ebene, nie an Personen. Wir messen Kosten je Wertstrom, den Produktivitäts-Zuwachs und die reale Nutzung. So bleibt jederzeit belegbar, ob sich die Fähigkeit rechnet. Das entscheidet über den nächsten Ausbauschritt. Der Betrieb erzeugt keine Chat-Historie als Ergebnis. Er erzeugt prüfbare Artefakte, die in Ihren Prozess passen. Dazu gehören Reports, Traceability-Matrizen und ausführbare Testsuiten.

Der Pilot ist bewusst klein gehalten. Er dauert wenige Wochen. Er nimmt sich einen realen Ausschnitt Ihres Prozesses vor, nicht ein Laborbeispiel. Am Ende steht ein belastbarer Beleg. Sie sehen, ob die Kette hält und ob sich der Aufwand lohnt. Erst auf dieser Basis entscheiden wir gemeinsam über das volle Mandat. So bleibt jedes Investment an ein sichtbares Ergebnis gebunden.

Dieser Beitrag betrachtet den Prozess und die Traceability. Die Rollen-Perspektive, also was den Kern der Requirements-Arbeit ausmacht und was Overload ist, vertieft der Beitrag Requirements Engineer mit AI: Kern und Overload in SWE.1.

Wie die AI-Sichten technisch andocken, ohne das ALM zu ersetzen, zeigt der Beitrag zum Read-only Overlay für Polarion und Jira.

Fazit

Es gibt einen Unterschied zwischen zwei Sätzen. Der erste lautet: Wir nutzen AI-Tools. Der zweite lautet: Wir besitzen eine beherrschte, auditierbare AI-Engineering-Capability. Dieser Unterschied entscheidet, ob AI im Serienprogramm trägt oder im Pilot versandet. Genau diese Entscheidungen hat sensified für den eigenen Betrieb getroffen. Sie sind in einem realen ASPICE-Serienprogramm gebaut. Deshalb kommt sensified mit einer Position, nicht mit Fragen.

Drei Dinge unterscheiden diesen Ansatz. Es gibt einen klaren Plan, belegt durch eigenes, produktives IP. Wir bauen es mit, bis es ASPICE-konform in Produktion läuft. Und es gibt keinen Vendor-Lock-in, abgesichert durch modell-agnostische Architektur und Transfer als Erfolgskriterium. Zwei Tiefen treffen dabei in einem Partner zusammen. Das ist etabliertes Automotive- und SDV-Wissen. Und es ist AI-Engineering-Tiefe aus eigener Plattform.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema. Der nächste Schritt ist ein Discovery-Workshop. Dort ordnen wir Ihren Prozess, Ihre Compliance-Lage und den ersten sinnvollen Use-Case gemeinsam ein.

Das Wichtigste in Kürze

• AI klassifiziert, leitet ab und prüft. Der Engineer gibt frei.
• Das ALM bleibt System-of-Record. AI arbeitet read-only zu.
• Das Ergebnis ist eine prüfbare Traceability-Matrix, kein Chatverlauf.
• Über 27.000 Requirements sind ein Capability-Beleg, kein garantiertes Ergebnis.