Traceability in agilen Projekten – RTM im Jahr 2018

Ein wichtiges Ergebnis des Requirements Engineering in einem Wasserfallprojekt ist die Traceability Matrix. Sie bildet das Bindeglied zwischen den Anforderungen und der Implementierung. Damit ist sie ein zentrales Arbeitsinstrument für Impact-Analysen und erleichtert zukünftiges Verständnis der Implementierung. In der agilen Welt hat die Traceability Matrix aber an Beliebtheit verloren, weil es schier unmöglich ist, sie in einer Umgebung von sich ständig ändernden User Stories zu unterhalten. Sie deswegen aber ersatzlos fallen zu lassen, reduziert die Traceability, also Nachvollziehbarkeit. Dies führt zu einer gefährlichen Dokumentations-Lücke, die Risiken für Qualität und Betrieb bedeutet und damit schlussendlich einen potentiell großen negativen Einfluss haben kann.

Was ist eine RTM und wozu braucht man das?

Eine RTM ist der einfachste Weg, um Traceability in einem Software-Projekt herzustellen. Es ist eine Tabelle, die alle Anforderung durchnummeriert und mit einer Reihe von Verbindungen versieht. Es werden Links gesetzt zu

  • Software-Artefakten (“Diese Anforderung wird in diesem Modul/Klasse/Funktion umgesetzt”)
  • Tests (“Diese Anforderung wird so getestet”)

Oft werden in der Traceability Matrix auch Hinweise versehen zu

  • Personen, Abteilungen (“Diese Anforderung wurde von X gestellt”)
  • Dokumenten (“Diese Anforderung ist hier dokumentiert”)

Dies erlaubt es, verschiedene Fragen, die im Verlauf des gesamten Lebenszyklus der Software auftauchen können, mit geringem Aufwand zu beantworten:

  • Wenn sich Anforderung X ändert, wo schlägt sich das überall nieder?
  • Wenn Modul Y angefasst wird, welche Anforderungen sind betroffen?
  • Welche Anforderung war der Auslöser für eine bestimmte Implementierung?
  • Aufgrund wessen Anforderung wurde eine Änderung vorgenommen? (Lies: Wer ist schuld?)
  • etc.

Diverse Untersuchungen haben gezeigt, dass Traceability die Softwarequalität verbessert, und zwar praktisch unabhängig von Projektlaufzeit, Teamgröße oder Prozessmodell (siehe bspw[1]).

RTMs existieren in verschiedenen Formen und Farben. In kleineren Projekten können sie in einer einfachen Excel-Tabelle abgebildet werden, für größere Geschichten verlässt man sich meist auf spezielle Requirements Management Software wie bspw. IBM Rational DOORS oder HP Quality Center. Diese können u.a. eine RTM generieren.

Bildnachweis LinkedIn

So sieht eine traditionelle RTM aus [Quelle: https://www.linkedin.com/pulse/what-rtm-software-testing-how-create-gaurang-bajpai/]

Warum gibt es in agilen Projekten oft keine RTM?

Eine RTM zu erstellen bedeutet Aufwand und damit Kosten. Diese Kosten wachsen mit der Menge an Links zwischen Anforderungen, Tests und Software-Artefakten, und mit der Menge an Änderungen, denen diese unterliegen. In einem agilen Umfeld, wo sich User Stories ständig den Gegebenheiten anpassen, neue Anforderungen auftauchen und alte obsolet werden, ist das Aufrechterhalten einer RTM überproportional aufwändig und kostenintensiv und der Return on Investment muss sehr genau abgewogen werden (siehe [2]).

Zudem steht die RTM quer in der agilen Welt und widerspricht der grundsätzlichen Arbeitsweise: Jedes Inkrement ist ein releasebares Produkt, von dem aus Änderungen in Form von User Stories formuliert werden. Diese werden in einem Sprint umgesetzt, worauf das nächste Produkt released wird. Agil zu arbeiten bedeutet u.a., an keinem Punkt im Entwicklungsprozess eine komplette Liste aller Anforderungen zu fixieren.

Dann brauchen wir auch keine Traceability in einem agilen Projekt?

Jein. In der agilen Community wird dieses Thema schon seit einer ganzen Weile diskutiert und man ist sich einig: Eine RTM passt nicht in ein agiles Vorgehen. Trotzdem ist Traceability in vielen Fällen sehr vorteilhaft, denn speziell in großen Projekten kann die Übersicht verloren gehen, wie sich Anforderungen gegenseitig beeinflussen und wie sie implementiert werden.

Speziell Nicht-Funktionelle Anforderungen (NFRs), die nicht auf ein paar bestimmte Zeilen Code runtergebrochen werden können, sind schwer unter Kontrolle zu halten.

Agile Vordenker wie bspw. Chuck Cobb ziehen sich deswegen aus der Affäre, in dem sie darauf verweisen, dass ein zentraler Grundsatz der agilen Vorgehensweise – speziell SCRUM – die ständige Verbesserung des Prozesses ist: Wenn man merkt, dass man eine RTM braucht, soll man eine machen. Aber dass man die Erlaubnis dazu hat, löst nicht die Probleme, die wir oben besprochen haben.

Also, was ist zu tun?

Deswegen ist ein beliebtes Vorgehen, um ein Minimum an Traceability herzustellen, dass jedem Software-Artefakt die dazugehörende User Story als Tag oder Kommentar mitgegeben wird. Das ist ein guter Ansatz und hilft in vielen Fällen. So kann man die Implementierung einer User Story finden und einem Stück Code eine entsprechende Anforderung zuordnen. In TFS bspw. geht das sogar ohne Medienbruch, indem man die Work Items über einen Link mit den versionierten Source Code Files verknüpft.

Wenn man jetzt noch jeder User Story Tests zuweist (z.B. ebenfalls per Link in TFS), dann kann man auch viele Anforderungen über genau diese Tests dokumentieren und so über die User Story zur Implementierung zurückverfolgen. Wichtig hierbei ist die Automatisierung dieser Tests, damit man mit ihnen Regressionstests machen und dadurch sicherstellen kann, dass sie stets aktuell sind.

Problematisch bleiben noch die NFRs und die Anforderungen, die einen großen Umfang haben (bspw. Features). Diese werden oft nicht in einer User Story explizit festgehalten oder durch einen einzelnen Integrations- oder Unittest abgedeckt.

Um hier Traceabilty herstellen zu können, sind wieder die Regressionstests der Schlüssel. Es muss sichergestellt werden, dass die Tests nicht nur informell in explorativen Testsessions gemacht werden, sondern dokumentiert sind und mit User Stories verknüpft. Eine gute Vorgehensweise ist das Test-Backlog, wie es in einem Artikel der Scrum Alliance vorgestellt wurde.

Ein ganz interessanter Ansatz wurde an der 2017er IEEE International Requirements Engineering Conference für Testgetriebene Entwicklung (TDD) vorgeschlagen (siehe [3]): Requirements werden in der Form von Behaviour-Driven-Tests (BDT) festgehalten. Solche BDT testen im Gegensatz zu herkömmlichen Tests nicht isolierte Funktionen und Implementierungen, sondern das Verhalten der Software in ihrem gesamten Verbund. In der reinsten Form wird dies erreicht, indem User-Eingaben über ein Test-Automatisierungs-Framework wie bspw. Selenium oder Robot Framework simuliert werden. So können ganze Businessprozesse und NFRs automatisiert und ganzheitlich getestet werden. Ein Runtime Tracer (wie bspw. Pythons traceback, Environment.StackTrac von .Net oder getStackTrace in Java) zeichnet dabei auf, welcher Code bei welchem Test ausgeführt wird. Werden diese Daten nun geordnet und abgelegt, erreichen wir automatisiert und agile-verträglich eine Traceability, die in vielen Aspekten die einer RTM erreicht oder gar übertrifft: Wir können jede Anforderung seiner Implementierung zuweisen. Dazu können wir sehen, welche anderen Anforderungen betroffen sind, wenn sich ein Software-Artefakt ändert. Und wenn wir diese Tests versionieren und die entsprechenden Links an jeden Commit hängen, sehen wir auch wieder, welche Änderung einer Anforderung einen bestimmten Software-Change verursacht hat.

Fazit

Traceability ist teuer, aber auch sehr nützlich. In der Wasserfall-Welt hatte man mit der RTM ein gutes Mittel geschaffen, um mit (meist) vertretbarem Aufwand eine gute Übersicht über Verbindung zwischen Anforderungen und Implementierung zu bekommen. In die agile Welt passt die RTM nun aber nicht mehr hinein, sowohl vom Prozess wie auch von den Kosten her. Da wir aber immer noch Traceability wollen und brauchen, um Risiken vorzubeugen und die Software-Qualität hoch zu halten, suchen wir nach Alternativen. Wir finden den passenden Ort, um die Links festzuhalten, in den Tests. Verschiedene Automatisierungs-Optionen erlauben uns auch, damit kostentechnisch schlank durchzukommen. Und am Ende winkt wieder eine große Tabelle mit vielen grünen und wenigen roten Punkten, die wir dem Management vorlegen können, um zu zeigen, dass wir alles im Griff haben – und genau darum geht es doch oft.

________________________

  1. Cleland-Huang, J., Zemont,G. and Lukasik,W., 2004, September. A heterogeneous solution for improving the return on investment of requirements traceability. In Requirements Engineering Conference, 2004. Proceedings. 12th IEEE International (pp.230-239). IEEE.
  2. Rempel,P. and Mäder, P., 2017. Preventing defects: The impact of requirements traceability completeness on software quality. IEEE Transactionson Software Engineering, 43(8), pp.777-797.
  3. Lucassen, G., Dalpiaz, F., vanderWerf, J.M.E., Brinkkemper, S. and Zowghi, D., 2017, September. Behavior-Driven Requirements Traceability via Automated Acceptance Tests. In 2017 IEEE 25th International Requirements Engineering Conference Workshops (REW) (pp.431-434). IEEE.

 

Bildnachweise

By |2018-07-04T15:42:04+00:00July 4th, 2018|Allgemein|0 Comments

About the Author:

Senior Business Consultant

Leave a Reply

%d bloggers like this:

novaCapta verwendet Cookies, um die Funktionalität dieser Website zu verbessern. Durch die Nutzung dieser Seite stimmen Sie der Verwendung von Cookies zu. Weiterlesen

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close