Requirements Engineer mit AI: Kern und Overload in SWE.1

Der Requirements Engineer mit AI: was am SWE.1-Arbeitsplatz Kern bleibt und was maschinell wird

Die Anforderungs-Analyse, die technische Klärung mit dem Kunden und das Konsistenz-Urteil bleiben Kern der Rolle. Maschinell wird der Ausführungsanteil: ReqIF-Übertragungen, Trace-Link-Logistik, Attribut-Pflege und das Zusammenstellen von Review-Paketen. sensified beschreibt diese Trennung in einer typisierten Rollenkarte für SWE.1, die im Audit gegen die Realität des jeweiligen Projekts geprüft wird.

Wer in einem Steuergeräte-Projekt nach Automotive SPICE (ASPICE) die Software-Anforderungen verantwortet, verbringt einen erheblichen Teil der Woche mit Arbeit, die in keiner Stellenbeschreibung steht: Anforderungen zwischen dem Anforderungsmanagement-Werkzeug (Requirements Management, RM) des Kunden und dem eigenen System übertragen, Trace-Links nachziehen, Attribute pflegen, Review-Pakete zusammenstellen. Dieser Beitrag zerlegt die Rolle entlang unserer Rollenkarte für SWE.1: Was ist Wertbeitrags-Kern, was ist automatisierbarer Ausführungsanteil, und welche Bausteine mit Künstlicher Intelligenz (AI) tragen welchen Teil. Das zugrunde liegende Modell mit den vier Tätigkeitsklassen K1 bis K4 erläutert der Grundlagen-Beitrag zum Wertbeitrags-Prinzip im Automotive Software Engineering. Eine Einordnung vorweg: Die Karte beschreibt eine typisierte Rolle und ihre Tätigkeits-Anteile. Sie ist ein Hypothesen-Startpunkt, der beim Kunden validiert wird, und sie trifft keine Aussage über Personen oder deren Leistung.

Was am SWE.1-Arbeitsplatz Kern bleibt

Der Kern der Rolle liegt in Urteils- und Beziehungsarbeit entlang der Base Practices (BP) von SWE.1. sensified klassifiziert diese Anteile als K1 bis K3: Ergebnis- und Beziehungsarbeit, Entscheidungs- und Lernarbeit sowie Kontroll- und Compliance-Urteile. Keiner dieser Anteile ist ein Automatisierungskandidat; AI liefert hier höchstens Entscheidungsgrundlagen zu.

Technische Klärung mit dem OEM: Beziehungsarbeit

Anforderungen mit dem Original Equipment Manufacturer (OEM), dem System-Team und dem eigenen Team zu klären und zu vereinbaren, ist die K1-Tätigkeit der Rolle (SWE.1.BP6). Klärungsschleifen und Verhandlungen über Interpretationen entscheiden darüber, ob ein Projekt mit einem tragfähigen Anforderungsbestand arbeitet oder monatelang gegen Missverständnisse anläuft. Diese Arbeit bleibt vollständig beim Menschen.

Analyse und Konsistenz-Urteil: Entscheidungsarbeit

Die Entscheidungsarbeit (K2) umfasst das Ableiten und Spezifizieren der Software-Anforderungen aus Systemanforderungen und Systemarchitektur (SWE.1.BP1), das Strukturieren und Priorisieren nach Release-Scopes und Varianten (BP2), die Analyse auf Korrektheit, technische Machbarkeit und Interdependenzen inklusive Zuarbeit zu Projekt-Schätzungen (BP3) sowie die Analyse des Impacts auf die Betriebsumgebung (BP4). Dazu kommt ein K3-Urteil: die inhaltliche Konsistenz-Entscheidung über Anforderungs-Sätze (BP5). Dieses Urteil ist von der Link-Mechanik zu unterscheiden, die im nächsten Abschnitt als Overload auftaucht.

Der Overload: Atomisierung, ReqIF-Brüche, Trace-Logistik

Overload bezeichnet in unserem Vorgehensmodell den automatisierbaren Ausführungs- und Logistikanteil einer Tätigkeit, ausdrücklich keine unnötige Arbeit. sensified zerlegt dafür jede Tätigkeit in Design- beziehungsweise Urteils-Anteil, Ausführungs-Anteil und Logistik-Anteil. Für den Requirements Engineer sammelt sich der Overload an den Werkzeug-Grenzen und in der Evidenzpflicht.

Konkret heißt das: Trace-Links zwischen Software-Anforderung, Systemanforderung und Architektur werden angelegt und nach jeder Änderung nachgezogen, wobei das Konsistenz-Urteil selbst Kern bleibt. Anforderungen wandern über das Requirements Interchange Format (ReqIF) zwischen dem RM-Werkzeug des Kunden und dem eigenen System, inklusive Format- und Attribut-Mapping. Status, Release-Zuordnung und die Kennzeichnung nach Automotive Safety Integrity Level (ASIL) werden über ganze Anforderungsbestände gepflegt. Und für jedes Review wird ein Paket aus betroffenen Anforderungen, Differenzen und Checklisten zusammengestellt, während das Review-Urteil beim Menschen bleibt.

Warum dieser Anteil strukturell entsteht

Anforderungsarbeit gehört nach unserer Hypothese, die je Kunde zu prüfen ist, zu den änderungsintensivsten Strecken des V-Modells: Jede System-Änderung schlägt auf den Software-Anforderungsbestand durch, und jeder Änderung folgt Trace-, Attribut- und Evidenz-Nacharbeit über mindestens zwei Werkzeug-Grenzen. Der Overload ist damit strukturell, ein Produkt aus Änderungsfrequenz, Evidenzpflicht und Tool-Brüchen. Er ist kein Disziplinproblem der Rolle. Dazu kommt eine externe Abhängigkeit: Qualität und Stabilität der Systemanforderungen aus dem System-Engineering gehören nach unserer Erfahrung zu den größten Aufwandstreibern dieser Karte, auch das eine Hypothese, die im Audit über die Schnittstellen-Betrachtung geprüft wird.

Was AI je Triage-Klasse übernimmt

Unsere Triage unterscheidet vier Klassen: A1 für regelgebundene Hintergrund-Automatisierung, A2 für vorbereitende Automatisierung mit Einzelfall-Prüfung durch den Menschen, B für Augmentation in Form rein lesender Sichten und Analysen, C für autonome Fallabwicklung, die bei sensified grundsätzlich als Prüfkandidat mit Status nicht zulässig startet. Für SWE.1 enthält die Rollenkarte fünf Einträge in den Klassen A1, A2 und B.

A1 und A2: Synchronisation, Formal-Checks, Link-Vorschläge

Zwei Einträge sind regelgebundene Hintergrund-Automatisierung (A1): die RM-Synchronisation zwischen Kunden-System und eigenem System als ReqIF-Roundtrip mit versioniertem Mapping-Regelwerk sowie der Formal-Check vor der Review-Einreichung, der Pflichtattribute, Namenskonventionen und Vollständigkeit gegen ein versioniertes Regelwerk prüft und Sonderfälle an Menschen eskaliert. Beide brauchen dokumentierte Rückholwege und lückenlose Protokollierung, damit die Evidenzkette assessierbar bleibt.

Der dritte Eintrag ist vorbereitende Automatisierung mit Prüfpunkt (A2): Trace-Link-Vorschläge zwischen Anforderungsebenen, bei denen der Engineer jeden einzelnen Link bestätigt, bevor er in den führenden Stand übernommen wird. Der Commit-Punkt bleibt beim Menschen.

B: die Qualitäts-Vorprüfung als abrufbare Sicht

Die Augmentations-Seite folgt einem Muster, das wir aus einem Entscheider-Cockpit in einem kommunalen Versorgungsprojekt übertragen haben: Das System verdichtet Daten zu einer entscheidungsfertigen Sicht, der Mensch urteilt. Für SWE.1 heißt das erstens eine Qualitäts-Vorprüfung je Anforderung, die Verifizierbarkeit, Eindeutigkeit und Widerspruchs-Kandidaten gegen die Schreibregeln des Projekts markiert. Das System markiert, der Engineer urteilt, und ein Feedback-Kanal fängt Fehlmarkierungen ein. Zweitens ein Klärungs-Dossier je Anforderungskonflikt, das Historie, betroffene Stakeholder und ähnliche frühere Klärungen aus RM- und Ticket-System zusammenführt, als Vorbereitung der K1-Klärungsarbeit mit dem OEM. Beide Sichten arbeiten ausschließlich lesend und erzeugen keinen Arbeitsstand des Work Products.

Nebenwert: Wer Links von Hand zieht, liest die Anforderung

Vor jedem dieser Bausteine steht bei sensified eine Nebenwert-Prüfung, und für SWE.1 ist sie besonders konkret. Manuelle Trace-Pflege erzwingt Anforderungs-Verständnis: Wer Links von Hand zieht, liest die Anforderung. Automatisierte Link-Vorschläge müssen dieses Lesen an anderer Stelle erhalten, in unserem Modell über eine Bestätigungspflicht je Link plus ein Stichproben-Review der inhaltlichen Konsistenz.

„Ohne diese Sicherung steigt die formale Traceability-Quote, während die inhaltliche Konsistenz sinkt. Das ist genau die Lücke, die Assessoren finden.“ Assessoren bewerten die Erreichung der Prozess-Outcomes, Work Products und Trace-Links sind dafür Indikatoren. Wie schwer der Nachweis in der Breite fällt, zeigt eine Selbstauskunfts-Zahl: 46 % der Automotive-Teams fällt der ISO-26262-Nachweis schwer (Quelle: Perforce, 2025). Warum diese Prüfung vor jedem Baustein steht, vertieft der Beitrag zur Nebenwert-Prüfung vor jedem AI-Baustein.

Eine Rollenkarte bewertet Tätigkeiten, keine Personen

Die Rollenkarte SWE.1 von sensified beschreibt einen typisierten Industrie-Rollenschnitt. ASPICE normiert Prozesse und keine Rollen; beim konkreten Kunden können die Schnitte anders liegen, und genau deshalb ist die Karte Interview-Leitfaden und Hypothesen-Startpunkt, der im Audit bestätigt, korrigiert oder verworfen wird.

Ebenso verbindlich ist die zweite Leitplanke: Alle Kennzahlen unseres Vorgehens messen Prozess- und Wertstrom-Größen wie Durchlaufzeiten oder Bestände, niemals Personen. Eine Bewertung einzelner Mitarbeiterinnen und Mitarbeiter findet nicht statt und ist auch kein verstecktes Nebenprodukt. Wie das Karten-Schema über alle zwölf Rollen hinweg funktioniert, zeigt der Überblick zu Rollenkarten und AI-Potenzial je ASPICE-Rolle.

Nächste Schritte

Ob die hier beschriebenen Anteile in Ihrem Projekt so vorliegen, welche Werkzeug-Brüche tatsächlich Aufwand erzeugen und welche Bausteine sich zuerst lohnen, ist keine Frage, die sich am Schreibtisch beantworten lässt. Der Einstieg ist ein strukturiertes Audit entlang der Wertströme und Rollenkarten.

1. Grundlagen lesen: Das Wertbeitrags-Prinzip im Automotive Software Engineering erklärt Tätigkeitsklassen, Wertströme und Triage im Zusammenhang.
2. Audit prüfen: Das Wertbeitrags-Audit für Automotive Software Engineering beschreibt Ablauf, Ergebnisse und Compliance-Leitplanken des Einstiegs.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Scope und Ausgangslage Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur Rolle des Requirements Engineers unter SWE.1 zusammen. Sie beziehen sich auf typisierte Rollenkarten und Tätigkeits-Anteile; wie die Anteile in einem konkreten Projekt tatsächlich liegen, wird im Audit beim Kunden validiert.

Ersetzt AI den Requirements Engineer in SWE.1?

Nein. Die Klärungs- und Verhandlungsarbeit mit dem OEM, die Anforderungs-Analyse und das Konsistenz-Urteil sind K1- bis K3-Tätigkeiten und bleiben beim Menschen. Automatisiert werden Ausführungs- und Logistikanteile wie ReqIF-Übertragungen, Attribut-Pflege und Review-Paket-Zusammenstellung. Die Rolle verbringt dadurch mehr Zeit mit dem Urteil und weniger mit dem Zusammensuchen der Unterlagen.

Kann AI Trace-Links automatisch anlegen?

Als Vorschlag ja, als eigenmächtige Entscheidung nein. In unserer Triage sind Trace-Link-Vorschläge ein A2-Baustein: Das System schlägt Verknüpfungen zwischen Anforderungsebenen vor, der Engineer bestätigt jeden Link einzeln, bevor er in den führenden Stand übernommen wird. Ergänzend sichert ein Stichproben-Review die inhaltliche Konsistenz, damit die formale Quote das Urteil nicht ersetzt.

Was bedeutet Overload in dieser Rollenkarte?

Overload bezeichnet den automatisierbaren Ausführungs- und Logistikanteil einer Tätigkeit nach ihrer Zerlegung in Urteils-, Ausführungs- und Logistik-Anteil. Der Begriff meint keine unnötige Arbeit: Auch normativ geforderte Tätigkeiten wie Review-Evidenzen sind Prozesswert, klassifiziert wird nur ihr mechanischer Anteil. Für SWE.1 sind das vor allem Trace-Logistik, ReqIF-Handling und Attribut-Pflege.

Wird mit der Rollenkarte die Leistung von Mitarbeitenden bewertet?

Nein. Die Karte beschreibt eine typisierte Rolle und ihre Tätigkeits-Anteile, keine Personen. Im Audit gelten dazu feste Leitplanken: Kennzahlen werden ausschließlich auf Prozess- und Wertstrom-Ebene erhoben, bei kleinen Rollen-Populationen werden Befunde automatisch aggregiert berichtet, und eine Individualbewertung ist vertraglich ausgeschlossen.

Welche Rolle spielt die Qualität der Systemanforderungen?

Eine erhebliche. Die SWE.1-Arbeit beginnt am Übergabepunkt der freigegebenen Systemanforderungen, und deren Qualität und Änderungsfrequenz gehören nach unserer Hypothese zu den größten externen Aufwandstreibern der Rolle. Im Audit wird diese Schnittstelle zum System-Engineering deshalb eigens betrachtet: Übergabeformat, Stabilität je Release und die Latenz der Klärungswege.

Funktionieren die Bausteine mit jedem RM-Werkzeug?

Das ist je Projekt zu prüfen und wird nicht vorausgesetzt. Die A1-Synchronisation braucht API- oder ReqIF-Zugänge beider RM-Systeme, die Qualitäts-Vorprüfung Zugriff auf den Anforderungsbestand und die Schreibregeln des Projekts. Das Audit erhebt dazu nur den Ist-Stand; die technische Prüfung der Schnittstellen leistet die anschließende Backlog-Härtung, bevor ein Baustein beauftragt wird.

Dieser Beitrag nimmt die Rollen-Perspektive ein. Wie der SWE.1-Prozess selbst mit AI arbeitet, von der Klassifizierung bis zur Traceability-Matrix, zeigt der Beitrag Requirements-Engineering mit AI: Klassifizierung, Qualität und Traceability.

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.