Link-Coverage 100 %, ASPICE-Assessment trotzdem gefährdet.

Ein zentraler Pfeiler von ASPICE ist das V-Modell, das weit über ein einfaches Phasenmodell hinausgeht: es bildet das methodische Rückgrat für eine durchdachte und nachvollziehbare Produktentwicklung. ASPICE fordert hierbei eine lückenlose, bidirektionale Verknüpfung über alle Entwicklungsstufen hinweg, von den ursprünglichen Stakeholder-Anforderungen über das System- und Software-Design bis hin zur eigentlichen Implementierung und den abschließenden Tests. Und es fordert – seit ASPICE 4.0 durch präzise Definitionen noch strenger in der Bewertung verankert – nicht nur formale Verlinkungen, sondern echte inhaltliche Stimmigkeit. Wie der offizielle Standard (Automotive SPICE PAM v4.0) hierzu unmissverständlich klarstellt: „Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.“ Und in Annex B zur Consistency Evidence: „Evidence that the content of the referenced or mapped information coheres semantically along the traceability chain,…“.

Genau dort liegt der Unterschied, um den es in diesem Artikel geht. Der Mehrwert von Traceability entsteht nicht dadurch, dass Verknüpfungen im Werkzeug existieren, sondern dadurch, dass sie inhaltlich konsistent sind und auf der richtigen Abstraktionsebene greifen. Ist einer dieser beiden Aspekte nicht erfüllt, ist das Prozessziel verfehlt.

Assessoren prüfen bei ihren Stichproben deshalb nie nur, ob ein Verknüpfungsfeld im Tool gefüllt ist. Sie lesen die Texte, durchleuchten den Kontext und entlarven Alibi-Links. Es geht darum nachzuweisen, dass eine Anforderung durch das Design vollständig abgedeckt wird, dass keine ungefragten Zusatzfunktionen im Code landen und dass jedes Artefakt dort entsteht, wo es prozessual hingehört.

Während Traceability auch bisher schon durch klassische Metriken, wie beispielsweise prozentuale Link-Abdeckungsraten oder Allokations-Matrizen, belegt werden konnte, lag der Aufwand für den Nachweis der Konsistenz in der Verantwortung der Entwickler. Large Language Models ermöglichen es jedoch jetzt erstmals, die Ingenieure durch eine automatisierte, semantische Konsistenzprüfung zu unterstützen: sie analysieren den tatsächlichen Bedeutungsgehalt von Anforderungen, Architektur-Spezifikationen und Testfällen, um logische Abweichungen, Parameterfehler oder Kontextbrüche im Text zu erkennen.

Dazu reicht es jedoch nicht aus, dem Sprachmodell Zugriff auf Anforderungsdatenbanken zu geben und es per Prompt um Konsistenzprüfung zu bitten. Vielmehr muss eine systematische Herangehensweise entwickelt werden, die das Sprachverständnis des LLM’s mit einer deterministischen und reproduzierbaren Bewertungsmetrik kombiniert. Im Rahmen der konkreten Umsetzung eines LLM-gestützten ASPICE-Agenten verdeutlicht die nachfolgend skizzierte Vorgehensweise, wie ein automatisierter Consistency Check semantische Fehler systematisch aufdecken kann:

Schritt 1: Der Type Check als Fundament

Der Type Check überprüft automatisiert, ob Entwicklungsartefakte ihrem zugewiesenen ASPICE-Prozess inhaltlich entsprechen, bevor die Konsistenz der Verlinkungen überprüft wird.

Da Sprachmodelle hervorragend im Verstehen von Sprache sind, beim Ziehen von Schlüssen aber zu Varianz neigen (Non-Determinismus), erfolgt die Bewertung in 2 Stufen:

Strukturierte Inhaltsprüfung (LLM)

In der ersten Analysephase bewertet das Sprachmodell jedes Artefakt einzeln anhand eines vorgegebenen Fragenkatalogs:

• Inhaltsprüfung: Existiert überhaupt ein bewertbarer Text? Antwortmöglichkeiten: ja/nein.
• Ebenenprüfung: Verbleibt der Text auf einer einzigen Abstraktionsebene? Antwortmöglichkeiten: ja/nein.
• Abstraktionsprüfung: Nur für Anforderungsartefakte: ist die Formulierung lösungsfrei (was) und enthält keine Implementierungsdetails (wie)? Antwortmöglichkeiten: ja/nein.
• Kategorieprüfung: Welchem ASPICE-Prozess entspricht der Inhalt? Antwortmöglichkeiten: fest vorgegebene Kategorien oder unklar.

Dadurch wird sichergestellt, dass das LLM die Prüfung immer möglichst objektiv anhand derselben Fragen mit denselben Antwortmöglichkeiten durchführt.

Deterministische Klassifizierung und Bewertung (Skript)

Im Anschluss an die Inhaltsprüfung werden die Antworten des LLM über ein vorgegebenes kombinatorisches Schema auf Fehlertypen gemappt:

• Kein Inhalt: Das Artefakt enthält keinen bewertbaren Text.
• Ebenen vermischt: Vermischt mehrere Abstraktions- oder Detaillierungsstufen innerhalb einer Anforderung.
• Abstraktionsdrift: Die Kategorie stimmt grundsätzlich, die Anforderung enthält jedoch bereits konkrete Implementierungsdetails oder interne Signalnamen.
• Kategorie unklar: Der Inhalt lässt sich keiner Kategorie eindeutig zuordnen.
• Falsche Kategorie: Der Inhalt des Textes widerspricht der angegebenen ASPICE-Kategorie.
• Korrekte Kategorie: Werden alle Inhaltsprüfungen bestanden, gilt das Artefakt als vollständig regelkonform (inhaltlich konsistent).

Wichtig: der Type Check dient als Vorfilter. Wenn zu viele fehlerhafte oder unklare Prozesszuweisungen vorliegen, macht ein darauf aufbauender Consistency Check der Traceability keinen Sinn und die Datenbasis muss überprüft werden.

Schritt 2: Der Consistency Check als bewertende Traceability-Instanz

Die Bewertung der Verlinkungen erfolgt ebenfalls zweistufig, um die Stärken des Sprachmodells mit der Eindeutigkeit klassischer Skripte zu verknüpfen.

Paarweise strukturierte Inhaltsprüfung (LLM)

Das LLM beantwortet für jedes verlinkte Paar strikt nacheinander folgende fünf Fragen (Antwortmöglichkeiten: ja/nein):

• Domänenprüfung: Gehören Quell- und Ziel-Artefakt zur selben funktionalen Domäne?
• Eindeutigkeitsprüfung: Adressiert das Ziel genau dieses spezifische Quell-Artefakt (und nicht ein Nachbar-Element)?
• Namensprüfung: Stimmen Signal-, Schnittstellen- oder Test-Namen überein?
• Vollständigkeitsprüfung: Deckt das Ziel alle Aspekte der Quelle ab?
• Konfliktprüfung: Gibt es widersprüchliche Schwellenwerte, Zeiten oder Verhaltensweisen?

Deterministische Klassifizierung und Bewertung (Skript)

Auch hier werden die Antworten aus der Inhaltsprüfung deterministisch auf Fehlertypen gemappt:

• Fehlverknüpfung: Artefakte sind mit dem falschen Partner verknüpft; das korrekte Verknüpfungsziel existiert woanders.
• Falsche Domäne: Quelle und Ziel beziehen sich auf voneinander unabhängige Funktionsbereiche.
• Falsche Entität: Gleiche Domäne, aber das Ziel adressiert eine andere spezifische Entität.
• Wertekonflikt: Widersprüchliche Werte, Schwellenwerte oder Verhaltensweisen zwischen Quelle und Ziel.
• Terminologieabweichung: Gleiches Konzept auf unterschiedlichen Abstraktionsebenen; unterschiedliche Benennungskonventionen.
• Abdeckungslücke: Ziel deckt einige, aber nicht alle Aspekte der Quelle ab.
• Konzeptlücke: Verwandte, aber nicht identische Konzepte.
• Mehrdeutiger Scope: Unklar, ob sich Quelle und Ziel auf exakt dasselbe Subsystem oder denselben Umfang beziehen.
• Übereinstimmung: Keine Probleme gefunden - korrekte semantische Zuordnung.

Schritt 3: Der Consistency Score

Basierend auf den Ergebnissen der vorherigen Analyseschritte wird ein reproduzierbarer Consistency Score berechnet. Er liefert eine Indikation entlang der aus ASPICE bekannten NPLF Skala:

• N (not achieved / nicht erreicht)
• P (partially achieved / teilweise erreicht)
• L (largely achieved / größtenteils erreicht)
• F (fully achieved / vollständig erreicht)

Wichtig ist die Einordnung: Der Score ersetzt kein Assessment und vergibt keine Ratings. Diese vergibt der Assessor auf Basis der Evidenz. Aber er zeigt kontinuierlich und lange vor dem Assessment, wo die Evidenz brüchig ist. Es gilt durchgängig das Prinzip des Conservative Bias: im Zweifelsfall wird ein Fehler gemeldet. Dies ist essentiell, da die Kosten für ein „falsch positiv“, bei dem ein Mensch den Befund prüft und gegebenenfalls verwirft, deutlich geringer sind als die Risiken eines „falsch negativ“, bei dem eine unerkannte Inkonsistenz das Vertrauen in die Validität der automatisierten Prüfung untergräbt.

Praxisbeispiele

Ein System Requirement wird in das Tool eingepflegt.

• Input (Artefakt-Text): „Das System muss den Sensorwert vom Temp_Sensor_01 über die CAN_ID_0x55A empfangen.“
• LLM-Analyse:
  • Abstraktionsprüfung (Lösungsfrei?): Nein. (Das Artefakt enthält spezifische Implementierungsdetails wie Kommunikationsschnittstelle und Signalnamen).
• Skript-Bewertung (Mapping): Abstraktionsdrift
• Begründung: Obwohl das Artefakt inhaltlich zur Kategorie „Systemanforderung“ gehört, verstößt es gegen das Prinzip der Lösungsneutralität. Der Type Check schlägt an, da die Anforderung auf der Abstraktionsebene von Implementierungsdetails operiert, statt nur das „Was“ zu beschreiben.

Ein verlinktes Paar bestehend aus einer Systemanforderung (Quelle) und einer Testfallspezifikation (Ziel) wird überprüft.

• Quelle (System-Requirement): „Das System muss in einem Notfallzustand innerhalb von maximal 100 Millisekunden in den sicheren Modus wechseln.“
• Ziel (Testfall): „Verifiziere, dass der sichere Modus nach Auslösen des Notfall-Events innerhalb von 500 Millisekunden aktiv wird.“
• LLM-Analyse:
  • Konflikt-Prüfung: Ja. (Es liegt ein inhaltlicher Widerspruch bei den Zeitvorgaben vor).
• Skript-Bewertung (Mapping): Wertekonflikt
• Begründung: Die semantische Prüfung erkennt den Widerspruch zwischen der Anforderung (100ms) und dem Testkriterium (500ms). Da die Werte nicht übereinstimmen wird ein „Wertekonflikt“ gemeldet.

Diese Beispiele verdeutlichen: Das System meldet hier jeweils eine Unregelmäßigkeit, die einen Ingenieur dazu zwingt, entweder die Anforderungsebene zu bereinigen (Beispiel 1) oder die Konsistenz zwischen Design/Test und Anforderung zu prüfen (Beispiel 2).

Fazit: Qualität entsteht im Inhalt, nicht im Link

Traceability-Metriken bieten oftmals eine trügerische Sicherheit. Ohne semantische Inhaltsprüfung bleibt die ASPICE-Konformität oberflächlich. Der in diesem Dokument skizzierte Ansatz - die Kombination aus Type Check, deterministischem Consistency Check und einem objektivierbaren Consistency Score - bildet das methodische Fundament zur LLM-basierten, inhaltlichen Qualitätssicherung. Dabei fungiert die KI nicht als Ersatz für den Menschen, sondern als Vorfilter: indem die Automatisierung die Masse an trivialen Konsistenzprüfungen übernimmt, entlastet sie das Engineering-Team massiv. Ingenieure gewinnen so die Freiheit, ihre Expertise gezielt auf die kritischen Abweichungen zu konzentrieren, bei denen menschliches Urteilsvermögen unabdingbar ist.

Requirements Traceability in der Praxis — Wie durchgängige Traceability in regulierten Projekten wirklich funktioniert, welche Werkzeuge sich bewährt haben und wann der RTM-Ansatz an seine Grenzen stößt: Requirements Traceability bei itemis →