Traceability. Beziehungen zwischen Artefakten nachvollziehen.
Was versteht man unter Traceability, wozu ist sie gut und welche Arten von Traceability gibt es?
Was ist Traceability?
Wenn von Traceability – von Rückverfolgbarkeit – die Rede ist, werden oft drei Begriffe miteinander vermengt, die nahe beieinander liegen:
- Die Revisionssicherheit betrifft das Zurückverfolgen der Historie von Artefakten, die im Entwicklungsprozess entstehen. Sie ist fest verankert in Prozessstandards wie zum Beispiel dem V-Modell XT. Die Revisionssicherheit herzustellen ist ein Thema für das Versions- und Konfigurationsmanagement.
- Die Compliance wird unter anderem als die Rückverfolgbarkeit der Einhaltung von Prozessen und Standards verstanden. In regulierten Branchen wie dem Automotive-Sektor ist Compliance ein zentraler Aspekt und eine Voraussetzung zum Beispiel für erfolgreiche Automotive SPICE Assessments.
- Die Traceability bezeichnet das Nachvollziehen von Beziehungen zwischen Artefakten des Entwicklungsprozesses.
Nach ISO/IEC/IEEE 24765:2010 ist Traceability definiert als “Discernable association among two or more logical entities, such as requirements, system elements, verifications and tasks.” Der Guide to Business Analysis Body of Knowledge BABOK v3 konkretisiert diese Definition für den Spezialfall der Requirements Traceability: “The ability for tracking the relationships between sets of requirements and designs from the original stakeholder need to the actual implemented solution.”
Traceability bezeichnet das Nachvollziehen der Beziehungen zwischen Artefakten des Entwicklungsprozesses. Damit unterscheidet sich die Traceability von der Revisionssicherheit und der Compliance.
Stellen Sie die Traceability sicher.
Erfahren Sie hier mehr zu Traceability
mit objectiF RPM oder objectiF RM »
Pre- und Post-Requirements Traceability
Nach BABOK v3 sollen sich die Beziehungen zwischen Anforderungen und ihrer Quelle – den Stakeholdern mit ihrem Bedarf – in beiden Richtungen nachvollziehen lassen. Diese Form der Traceability bezeichnet man als Pre-Requirements Traceability. Ebenso sollen sich die Beziehungen zwischen Anforderungen, dem Entwurf, Code und den Tests in beiden Richtungen verfolgen lassen. Hier spricht man analog von Post-Requirements Traceability. Beide Formen der Requirements Traceability helfen, zahlreiche Fragen im Verlauf des Entwicklungsprozesses zu klären.
- Beispiele für Fragen der Pre-Requirements Traceablity: Wem ist die Anforderung wie wichtig? Wie wird der Bedarf gedeckt?
- Beispiele für Fragen der Post-Requirements Traceability: Wurde eine Anforderung umgesetzt? Was ist alles von Änderungen einer Anforderung betroffen? Fehlen noch Artefakte wie bspw. Testfälle?
Requirements-to-Task Traceability
Pre- und Post-Requirements Traceability sind nicht die einzigen Formen der Traceability, denn Anforderungen können nicht nur mit anderen Artefakten, sondern auch untereinander in Beziehung stehen. So unterscheidet BABOK v3 zum Beispiel zwischen Business-, Stakeholder- und Solution-Requirements, die sich auseinander ableiten. Außerdem kommen Anforderungen in Anforderungs- und Spezifikations-Dokumenten vor wie Lasten-/Pflichtenheften oder der Software Requirements Specification nach IEEE. Die Rückverfolgbarkeit der Beziehungen von Anforderungen untereinander und zu ihrer Dokumentation bezeichnet man als Inner Traceability.
Beispiel für eine Frage der Inner Traceablity: Welche Anforderungen und Anforderungsdokumente sind von Änderungen einer Anforderung betroffen?
Requirements-to-Task Traceability
Anforderungen werden im Verlauf der Entwicklung realisiert. Damit entstehen Beziehungen zwischen Anforderungen und Aufgaben in der Projektplanung. Mit Hilfe dieser Beziehungen wird die Entwicklung von Anforderungen nachvollziehbar. Diese Form der Rückverfolgbarkeit wird als Requirements-to-Task Traceability bezeichnet.
Beispiele für Fragen der Requirements-to-Task Traceability:
- In welchem Zustand ist die Realisierung?
- Wie viel Aufwand steckt in der Realisierung der Anforderung?
- Wer hat die Anforderung realisiert?
Wozu ist Traceability gut?
Die unterschiedlichen Formen der Requirements Traceability unterstützen vier Analyseschritte:
- Auswirkungsanalyse – Welche Anforderungen/Artefakte werden durch Änderungen beeinflusst?
- Herkunftsanalyse – Warum gibt es eine Anforderung/ein Artefakt?
- Abdeckungsanalyse – Wurden alle Anforderungen/Artefakte für eine vollständige Lösung berücksichtigt?
- Leistungswertanalyse – Wie geht die Arbeit voran?
Traceability versetzt Sie in die Lage, unterschiedliche Fragen in Ihrer Entwicklung zu beantworten: Welche Anforderungen werden durch Änderungen beeinflusst? Warum gibt es eine Anforderung? Wurden bereits alle Anforderungen für eine vollständige Lösung berücksichtigt? Und wie geht das Projekt voran? Kennen Sie die Auswirkungen von Änderungen, können Sie sicherer planen und Risiken früher erkennen. Ihr Wartungsaufwand wird besser schätzbar, die Fortschrittskontrolle erleichtert. Die Rückverfolgbarkeit von Anforderungen zu ihrem Stakeholder hilft, Anforderungen zu validieren und zufriedene Stakeholder zu gewinnen. Und die Nachvollziehbarkeit von Entscheidungen und Lösungen ist Voraussetzung für erfolgreiche Audits.
Die Traceablity Matrix
Es gibt verschiedene Möglichkeiten Traceability herzustellen. Eine Möglichkeit ist die explizite Dokumentation der Beziehungen zwischen Anforderungen untereinander und zu anderen Entwicklungsartefakten durch das Anlegen und Pflegen einer Traceability Matrix. Im Internet finden Sie zahlreiche MS Excel Traceablity Matrix Vorlagen. Wer jemals in einem Projekt versucht hat, eine Traceability Matrix – vom Bedarf der Stakeholder bis zum Test – manuell zu pflegen, wird vermutlich folgende Einschätzung teilen: “Requirements Traceability Matrix is probably one of the most valuable things people almost never do!”
Die Pflege der Traceability Matrix ist zeitaufwändig und fehleranfällig. Selbst, wenn die Matrix teilweise maschinell erzeugt wird, bleibt in der Regel ein hoher organisatorischer und operativer Aufwand für ihre schrittweise Vervollständigung, Aktualisierung und Versionierung. In der Praxis hat sich daher der Ansatz des Lean Traceability durchgesetzt. Lean Requirements Traceability bedeutet soviel Traceability wie nötig mit so wenig Aufwand wie möglich. Weitere Information dazu finden Sie im Lean Traceability Whitepaper.
Traceability in Form einer expliziten Dokumentation der Beziehungen von Anforderungen untereinander und zu anderen Artefakten ist aufwändig und führt zu mehr Artefakten. Die Lösung lautet: Lean Traceability.
Per Knopfdruck zur Traceability
Gerade in agilen Projekten gibt es Vorbehalte gegen eine Traceability, denn eine explizite Dokumentation der Beziehungen von Anforderungen untereinander und zu anderen Entwicklungsartefakten führt zu mehr Artefakten. Dies erhöht den Aufwand, zumal die Dokumentation nicht zum eigentlichen Lieferumfang gehört. Agile Projekte werden schwerfälliger. Die Antwort darauf lautet: Lean Traceability.
Verzichten Sie vollständig auf die explizite Dokumentation von Traceability. Verwalten Sie stattdessen alle Artefakte – Stakeholder, Ziele, Anforderungen, Tests, Dokumente, Anforderungs-, Ziel und Kontextdiagramme mit einer einzigen Software: objectiF RPM. Und bei Bedarf generieren Sie sämtliche Informationen der Datenbank in Dokumente. Somit bleibt Ihr Vorgehen leichtgewichtig und gleichzeitig nachvollziehbar.