Ein international anerkannter Experte auf dem Gebiet des Requirements Engineering wurde vor Kurzem auf einer Veranstaltung gefragt: “Wie sollte man Ihrer Meinung nach mit User Stories – also den Kundenanforderungen in agilen Projekten – umgehen, wenn sie realisiert sind.” Seine Antwort: “Wenn sie fertig und abgenommen sind, weg damit.” Große Unruhe im Saal und die Frage aus dem Publikum: “Wo bleibt da die Traceability?”. Rückfrage des Referenten: “Wozu wollen Sie Traceability?”. Die Reaktion kam prompt. Empörte Zwischenrufe aus dem Publikum: “Dann erreichen wir nie einen höheren CMMI oder SPICE Level!”, “Die ISO-Zertifizierung können wir dann vergessen.” Der Referent blieb gelassen: “Wie viel Traceability haben Sie in ihren Projekten realisiert?”, fragte er zurück. Betretenes Schweigen machte sich breit. Offenbar klafft zwischen dem, was jeder theoretisch für wünschenswert, ja für absolut notwendig hält, und dem, was in Projekten praktiziert wird, eine große Lücke.
Warum laufen Theorie und Praxis beim Thema Traceability so weit auseinander? Warum gibt es gerade in agilen Projekten oft Vorbehalte in Bezug auf Aufwand und Nutzen von Traceability? Und wieviel Traceability braucht man eigentlich?
Traceability – was ist das genau?
Wenn von Traceability – von Rückverfolgbarkeit – die Rede ist, werden oft drei Begriffe miteinander vermengt, die – zugegeben – sehr nahe beieinander liegen. Entwirren wir also das Begriffsknäul:
Compliance ist ein Begriff mit vielen Facetten und 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 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. Revisionssicherheit herzustellen, ist ein Thema für das Versions- und Konfigurationsmanagement.
Die Traceability betrifft 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.”
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.
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 zum Beispiel zwischen Business-, Stakeholder- und Solution-Requirements, die sich auseinander ableiten. Außerdem kommen Anforderungen in Anforderungs- und Spezifikationsdokumenten wie Lasten-/Pflichtenheften vor oder der Software Requirements Specification nach IEEE. Die Rückverfolgbarkeit der Beziehungen von Anforderungen untereinander und zu ihrer Dokumentation bezeichnet man als Inner 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.
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?
Kennen Sie die Auswirkungen beabsichtigter Veränderungen, können Sie sicherer planen und Risiken besser erkennen und bewerten. Ihr Wartungsaufwand wird besser schätzbar. Der transparente Weg von Anforderungen bis zum Test erleichtert die Projektfortschrittskontrolle. Die Rückverfolgbarkeit von Anforderungen bis zu ihrem Ursprung hilft, die Anforderungen zu validieren („Erstellen wir das richtige Produkt?“) und Stakeholder-Zufriedenheit zu schaffen. Die Nachvollziehbarkeit von Entscheidungen und Lösungswegen ist Voraussetzung für erfolgreiche Audits. Können Sie nachweisen, dass alle Anforderungen in der Lösung berücksichtigt und für alle Anforderungen Tests definiert sind, haben Sie einen wesentlichen Schritt zur Verifikation der Lösung und damit zu mehr Qualität gemacht. Kurzum: Requirements Traceability ist für Projekte überaus wertvoll. Stellt sich nur die Frage: Wie stellen Sie Traceability mit vertretbarem Aufwand her?
Die Traceability Matrix – ein brauchbares Instrument?
Eine Möglichkeit, Traceability herzustellen, ist die explizite Dokumentation der Beziehungen zwischen Anforderungen untereinander und zu anderen Entwicklungsartefakten durch das Anlegen und Pflegen einer Traceability Matrix. Dafür findet man im Internet eine große Zahl an Excel-Templates.
Wer jemals in einem Projekt versucht hat, eine Traceability Matrix wie diese – 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. Eine Traceability Matrix ist also kein Instrument für Lean Traceability.
Warum tun sich agile Projekte mit der Traceability schwer?
Gerade in agilen Projekten haben sich Vorbehalte in Bezug auf Aufwand und Nutzen von Traceability aufgebaut. Typische Kritik lautet: Traceability in Form einer expliziten Dokumentation der Beziehungen von Anforderungen untereinander und zu anderen Entwicklungsartefakten:
- führt zu mehr Artefakten, die nicht zum eigentlichen Lieferprodukt gehören, und zu Up-front-Aktivitäten für Erstellung, Pflege und Verwaltung dieser Artefakte,
- macht insbesondere Änderungen – die doch in agilen Projekten immer willkommen sein sollten – schwerfälliger,
- erhöht den Grad an „Waste“, also an unnötiger Arbeit etwa beim „Zusammensuchen” von Informationen
- und bremst damit schließlich die Produktivität des Teams aus.
Um Akzeptanz auch in agilen Projekten zu finden, muss Requirements Traceability lebbar sein. Wie können Sie das erreichen? Zunächst einmal: Traceability ist nicht identisch mit der Traceability Matrix. Traceability ist eine wünschenswerte Eigenschaft, die auch mit anderen Mitteln hergestellt werden kann. Wie verzichten Sie also vollständig auf die explizite Dokumentation von Traceability wie beispielsweise auf eine Traceability Matrix und erzeugen eine Lean Traceability?
Die Schritte zur Lean Traceability
Lean Traceability bedeutet: soviel Traceability wie nötig mit so wenig Aufwand wie möglich. Um dies zu erreichen, sind drei Schritte notwendig:
Schritt 1: Festlegen, welche Arten der Requirements Traceability im Projekt betrachtet werden sollen.
Entscheiden Sie, ob die Requirements-to-Activity Traceability für Ihre Projekte notwendig ist.
Ist Ihnen die Information wichtig, in welchem Release, welcher Projektaktivität oder welcher Iteration eine Anforderung eingeplant ist, wieviel Personalkapazität dafür benötigt wird, wer sie bearbeitet und wie hoch der Planaufwand ist?
Unsere Praxiserfahrung: Wir haben uns in unseren agilen Projekten dafür entschieden, die Beziehung zwischen den Anforderungen (User Stories) und den Projektaktivitäten (Releases und Sprints) mit Toolunterstützung anzulegen und zu pflegen. Diese Beziehungen versetzen uns – wiederum mit entsprechenden Toolfunktionen – in die Lage, den Aufwand für ein Release aus dem Aufwand der Anforderungen abzuleiten und unter anderem den Fortschritt der Release-Entwicklung aus dem Verhältnis der erledigten zu den geplanten Anforderungen sichtbar zu machen im Sinne eines agilen Earned Value Managements.
Entscheiden Sie, ob Requirement-to-Document – also diese spezielle Form der Inner Traceability – notwendig ist.
Unsere Praxiserfahrung: Es mag überraschen, aber wir haben uns dagegen entschieden. Der Grund: Anforderungsdokumentation, die wir veröffentlichen, wird immer aus dem aktuellen Stand der Entwicklung heraus neu generiert und anschließend versioniert. Damit entfällt die Notwendigkeit, festzuhalten, welches Dokument von der Änderung einer Anforderung, einer Stakeholder-Beschreibung, eines Anwendungsfalls oder Testfalls etc. betroffen ist.
Bleibt noch die Pre-/Post-Requirements Traceability.
Bezogen auf die Pre-/Post-Requirements Traceability geht es nicht um die Frage, ob Sie sie in Ihren Projekten brauchen, sondern wie viel Sie davon brauchen und mit welchen Mitteln Sie sie festhalten wollen. Genau das ist Inhalt des zweiten Schrittes der Vorgehensweise.
Schritt 2: Festlegen, welche Pre-/Post Requirements Traces erstellt werden sollen.
Die Frage, wie viel Pre-/Post-Requirements Traceability festgehalten werden soll, läuft auf eine andere Frage hinaus – nämlich: Wie viel Software Engineering soll in Ihren Projekten stattfinden? Was hat Traceability mit Software Engineering zu tun? Ein Blick in die Unified Modeling Language (UML), dem heute gängigsten Software Engineering Verfahren, macht den Zusammenhang deutlich: Die UML kennt zwischen Elementen Dependency Relationships, also Abhängigkeitsbeziehungen. Eine davon ist die Trace-Beziehung. Sie sagt aus, dass Änderungen eines Elements in einem abhängigen Element berücksichtigt werden müssen.
Ganz besonders interessant ist ein Blick in die Systems Modeling Language (SysML), eine Erweiterung der UML. Die SysML kennt
- Satisfy-Beziehungen zwischen Elementen und Anforderungen und
- Verify-Beziehung zwischen Testfällen und Anforderungen.
Einmal modelliert, kann man diese Beziehungen für die Post-Requirements Traceability nutzen.
Die SysML kennt außerdem die:
- Derive- oder Ableitungs-Beziehung zwischen Anforderungen
- Contains- oder Enthält-Beziehung zwischen Anforderungen
- Refine- oder Verfeinerungs-Beziehung zwischen Elementen und Anforderungen.
Alle drei sind für die Inner Traceability von Anforderungen nutzbar.
Hier besteht übrigens eine hohe konzeptuelle Übereinstimmung zwischen der SysML und dem Business Analyse Standard BABOK v3, der ebenfalls die Derive-, Depends-, Satisfy- und Validate-Beziehung als Spezialformen der Trace-Beziehung kennt.
Die SysML enthält einen Diagrammtyp, mit dem Sie beim Modellieren alle diese Spuren legen können: das Requirements-Diagramm. Der Name ist Programm: Gegenstand von Requirements-Diagrammen sind die Anforderungen, ihre Beziehungen zu den Stakeholdern und untereinander sowie zu anderen Entwicklungsartefakten. Wenn Sie eine Anforderung ändern und wissen wollen, welche anderen Anforderungen und Artefakte von der Änderung potenziell betroffen sind, dann können Sie diese Elemente aus der Situation heraus bei der Arbeit mit diesem Modellwissen leicht ermitteln.
Die Antwort auf die Frage, was Traceability mit Software Engineering zu tun hat, liegt damit auf der Hand: Wenn mit den Mitteln der UML/SysML modelliert wird, dann entstehen automatisch Spuren – ganz einfach bei der normalen modellbasierten Entwicklungsarbeit, ohne zusätzliche Artefakte wie die Traceability-Matrix anzulegen und zu pflegen. Repository- oder Datenbank-basierte ALM- oder Software Engineering Tools speichern Informationen über die modellierten Beziehungen persistent und erlauben es, diese Spuren auszuwerten und zurückzuverfolgen.
Halten wir fest: Modelle – speziell das Requirements Diagramm – helfen bei der Inner- & Post-Requirements Traceability. Wie sieht es mit der Pre-Requirements Traceability aus?
Es gibt es leider keine verbreitete Standardnotation zur Modellierung von Business Needs und Stakeholder Goals und den daraus abgeleiteten Anforderungen. Wir empfehlen hier eine einfache, leicht verständliche Technik zur Bedarf-/Zielmodellierung: Goal-Diagramme dargestellt als Und-/Oder-Graphen. Damit können Sie
- den Bedarf/die Ziele eines Stakeholder verfeinern oder in Alternativen zerlegen,
- Zielkonflikte von Stakeholdern sichtbar machen,
- aus Zielen konkrete Anforderungen ableiten.
So lassen sich viele Spuren für die Pre-Requirements Traceability legen, die zu den Quellen einer Anforderung führen. Damit das Vorgehen leichtgewichtig bleibt, ist ein weiterer Schritt notwendig:
Schritt 3: Festlegen, bis zu welchem Detaillierungsniveau Artefakte „getraced“ werden sollen.
Unsere Praxiserfahrung: Wir haben uns entschieden, eine Spur von einer Anforderung zu der Komponente, in der sie realisiert ist, auf Modellniveau zu legen. Auf Traceability bis hinein in den Code verzichten wir. Warum? Die Systemarchitektur beschreiben wir mit Package-Diagrammen der UML. Eine System-Komponente besteht bei uns aus fachlichen Modellen, aus denen wir per Modelltransformationen in großem Umfang Code generieren. Wir entwickeln unsere Software konsequent modellgetrieben. Deshalb ist es für unsere Entwicklungstätigkeit ausreichend, die Beziehung zwischen Anforderung und Komponente sowie gegebenenfalls noch zwischen Anforderung und Modellelement wie z.B. einer Klasse festzuhalten. Diese Beziehungen werden auch nicht mehr grafisch modelliert, sondern durch Setzen von Referenzen hergestellt.
Lean Traceability – kurz zusammengefasst
Lean Traceability bedeutet: soviel Traceability wie nötig mit so wenig Aufwand wie möglich. Voraussetzung ist, dass Sie einmalig für ein Projekt, ein Programm oder für die Organisation festlegen, wie viel Traceability sie benötigen. Ein großes Dokument wie die Traceability Matrix, das alle Abhängigkeiten zeigt, ist – ob generiert oder mit der Hand gepflegt – für die tägliche Arbeit nur eingeschränkt hilfreich. Wirklich hilfreich dagegen ist die Möglichkeit, situativ zu tracen. Denn aus der Situation heraus Beziehungen zwischen Artefakten zu benutzen, um z.B. Auswirkungen von Änderungen zu prüfen, wird nicht als zusätzlicher Aufwand wahrgenommen und schon gar nicht als Zeitverschwendung gewertet. Eine solche Aktion ist Bestandteil der täglichen Entwicklungsarbeit.
Hinweise:
[1] BABOK® ist eine eingetragene Marke des International Institute of Business Analysis. Den BABOK Guide können Sie unter http://www.iiba.org herunterladen.
[2] http://www.metabusinessanalyst.com/3-ways-manage-your-requirements-traceability-matrix/