Zum Hauptinhalt springen

TIM (Traceability Information Model)

Ein Traceability Information Model (TIM) definiert, welche Artefakttypen eines Entwicklungsprozesses durch welche Beziehungstypen verbunden sein müssen — der verbindliche Bauplan für Requirements Traceability. TIMs sind versioniert, damit Trace-Links auditierbar gegen eine definierte Modellversion validiert werden können.

Was legt ein TIM fest?

Ein TIM beantwortet drei Fragen, bevor der erste Trace-Link gesetzt wird:

FrageBeispiel
Welche Artefakttypen gibt es?Stakeholder-Anforderung, Systemanforderung, Architekturelement, Implementierung, Testfall, Testergebnis
Welche Beziehungstypen verbinden sie?wird verfeinert durch, wird erfüllt durch, wird verifiziert durch
Welche Verbindungen sind verpflichtend?Jede Systemanforderung braucht mindestens einen verifizierenden Testfall

Erst diese Festlegung macht Lücken-Analysen möglich: Ohne Modell lässt sich nicht entscheiden, ob ein fehlender Link eine echte Lücke ist oder schlicht nie gefordert war. Coverage-Analysen prüfen immer gegen das TIM.

Warum versioniert und mit Provenienz?

Entwicklungsprozesse ändern sich — neue Artefakttypen kommen hinzu, Beziehungstypen werden verfeinert. Damit Nachweise belastbar bleiben, tragen Verknüpfungen (Assertions) im Traceability-Graph eine Provenienz zur TIM-Version, gegen die sie validiert wurden. So bleibt für Auditoren nachvollziehbar, nach welchem Regelwerk ein Nachweis entstanden ist — und die strukturierte, maschinenlesbare Form macht den Traceability-Graphen zugleich auswertbar für KI-gestützte Analysen.

TIM und Normen: Tailoring statt Übernahme

Normen wie ISO 26262, IEC 62443 oder Automotive SPICE fordern nachvollziehbare Beziehungen zwischen Artefakten, liefern aber kein fertiges Modell für die konkrete Organisation. Das TIM entsteht durch Tailoring: Aus den regulatorischen Anforderungen, der realen Tool-Landschaft und den Prozessen des Unternehmens wird festgelegt, welche Artefakte verbunden sein müssen, welche Beziehungstypen relevant sind und wie Änderungen dokumentiert werden.

TIM in der Praxis

Das TIM ist der Punkt, an dem Traceability vom guten Vorsatz zur prüfbaren Methodik wird: Es macht aus einer Sammlung von Links ein validierbares Modell. In Projekten mit fragmentierten Tool-Landschaften (Anforderungen in DOORS oder Polarion, Modelle in MBSE-Werkzeugen, Code in GitLab) definiert das TIM zugleich, welche Werkzeuggrenzen die Traceability-Schicht überbrücken muss.

Häufige Fragen

Was ist der Unterschied zwischen TIM und Traceability-Matrix?
Das TIM ist das Modell, die Matrix eine Instanz: Das TIM legt fest, welche Artefakttypen durch welche Beziehungstypen verbunden sein müssen (z. B. „jede Anforderung wird durch mindestens einen Testfall verifiziert“). Eine Traceability-Matrix zeigt, welche konkreten Artefakte eines Projekts tatsächlich verknüpft sind.
Wer definiert das TIM in einem Projekt?
Typischerweise gemeinsam Prozessverantwortliche, Safety-/Security-Verantwortliche und Tool-Owner: Normen wie ISO 26262 oder ASPICE liefern die regulatorischen Anforderungen, aber kein passgenaues Modell — welche Artefakte, Beziehungstypen und Verbindlichkeiten gelten, muss pro Organisation und Projekt zugeschnitten (tailored) werden.
Warum müssen TIMs versioniert sein?
Weil sich Prozesse ändern: Kommt ein neuer Artefakttyp oder Beziehungstyp hinzu, müssen bestehende Trace-Links nachvollziehbar bleiben. Versionierte TIMs erlauben es, jede Verknüpfung der Modellversion zuzuordnen, gegen die sie validiert wurde — die Grundlage für auditierbare Nachweise.

Verwandte Begriffe

Fachlich geprüft von Florian Antony, Principal Software Engineer & IT Consultant am 20. Juli 2026