Verfolgung von Anforderungen

Häufig wird in Projekten den Anforderungen nicht die Aufmerksamkeit gewährt, die sie verdienen. Zweifelsohne werden die Anforderungen als Basis aller Aktivitäten im Projekt gesehen, aber leider werden sie in der Regel zu wenig mit allen anderen Aktivitäten verzahnt und im Zuge des Projektes nicht mehr angepasst.

In welchen Projekten könnte schon an einem Testfall erkannt werden, welche Anforderung damit getestet wird? Üblicherweise hat das Projekt eine Reihe von Anforderungen und noch eine weit längere Liste an Testfällen. Welcher Testfall welche Anforderung abdeckt, ist für Außenstehende nicht erkennbar. Ebenso verhält es sich mit Change Requests im laufenden Projekt. Sie berühren Anforderungen, Fachkonzepte, Software Designs, Testfälle usw.; diese müssen entsprechend geändert werden – und im Anschluss muss alles noch konsistent sein. Es fällt dann oft schwer, zu erkennen, welche Auswirkungen Änderungen auf abhängige Artekfakte haben, und unter Umständen werden bestimmte Artefakte wie Testfälle nicht mehr angepasst und nicht nochmals getestet. Erschwerend kommt hinzu, dass ganz unterschiedliche Mitarbeiter an den Dokumenten arbeiten – fachlich orientierte Mitarbeiter, ausgesprochene Teckies, Tester und einige mehr. In jeder Phase entstehen zudem wieder neue Anforderungen, die in der nächsten Phase durch Lösungen gefüllt werden. Außerdem sind Anforderungen oftmals mit vielen Annahmen und Issues behaftet, die unter Umständen erst später überarbeitet werden. Hier die Übersicht zu behalten, kann eine echte Herausforderung für das Projektteam bedeuten.

Notwendig ist also eine Nachverfolgbarkeit der Anforderungen über den gesamten Softwareentstehungszyklus bis zu Test und Abnahme – eine Traceability.

Banken und Versicherungen sind zudem durch die BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) über die Anforderungen zum Risikomanagement (MaRisk) dazu verpflichtet, Änderungen in der IT durch eine zentrale und vollständige Transparenz sicherzustellen.

Arten von Traceability

Bevor wir tiefer in die Nachvollziehbarkeit von Anforderungen einsteigen, sollten wir die verschiedenen Ausprägungen etwas voneinander abgrenzen.

Es werden drei Arten von Traceability unterschieden:

  • Pre-Requirements-Specification-Traceability: Hier liegt der Fokus auf allen Informationen, die zu der Anforderung führten, z.B. „Unternehmen will Marktführerschaft“ oder „Kunde möchte einfachere Bedienung“ (Geschäftsziele).
     
  • Traceability zwischen den Requirements: Oft entstehen Anforderungen in Konsequenz aus anderen Anforderungen, z.B. könnte eine Anforderung „Navi soll Sprachbefehle auswerten können“ aus der Anforderung „Navi soll Zieleingabe per Sprache ermöglichen“ abgeleitet sein. Bei dieser Art der Traceability würden diese Abhängigkeiten sehr gut aufgezeigt werden.
     
  • Post-Requirements-Traceability: Dies ist, was klassischerweise unter der Nachvollziehbarkeit von Anforderungen verstanden wird: die Nachvollziehbarkeit, angefangen von der Anforderung über die Entwürfe und Implementierungen bis hin zu den Testfällen. Im Vordergrund steht die Frage, wo und wie eine Anforderung in der jeweiligen Projektphase abgebildet wird.

Im Folgenden werden wir uns auf die Post-Requirements-Traceability konzentrieren, da für die meisten Projekte die Nachverfolgbarkeit der Anforderung bis zum Test den größten Mehrwert haben dürfte.

Umgang mit Traceability (Post-Requirements-Specification-Traceability)

Die Basis jeder Traceability sind die Anforderungen. Dazu gehört nicht nur eine gute und ausreichende Beschreibung der Anforderung, sondern auch eine durchdachte Attributierung. Durch Attribute kann jede Anforderung mit weiteren wichtigen Informationen versehen werden. Neben ID, Name und Beschreibung sind dies z.B. verantwortlicher Mitarbeiter, Quelle der Anforderung oder Autor der Anforderungsbeschreibung. Es können auch spezifische Aspekte berücksichtigt werden, wie z.B. Vorgaben seitens des Unternehmens oder Randbedingungen des Entwicklungsprozesses. Soweit es für die Anforderungen keine Einschränkungen durch ein Tool gibt, ist die Zusammenstellung der Attribute völlig frei. Je mehr Informationen eine Anforderung enthält, desto einfacher lassen sich nachher Fragen zu dieser Anforderung klären.

Für die Nachverfolgbarkeit an sich gibt es mehrere Möglichkeiten. Eine wäre es, eine Matrix aufzubauen, in der die Abhängigkeiten der Anforderungen untereinander abgebildet werden. Auch ein Verfolgbarkeitsgraph ist denkbar. Hier würden die Abhängigkeiten durch Pfeile zwischen Anforderungen über die Projektphasen abgebildet werden.

Die beste und einfachste Lösung ist sicher die Anforderungsverfolgung über Anforderungs-IDs, die über alle Dokumente konsequent fortgeführt werden. Wie die Erfahrung zeigt, sollte man allerdings bei der Durchnummerierung der Anforderungen in Zehnerschritten vorgehen, um zwischen den Anforderungen noch genug „Platz“ zu lassen für weitere, sich später ergebende Anforderungen – denn diese werden ganz sicher kommen…

Abb 1: Verfolgbarkeitsgraph von Anforderungen

Vorteile durch Traceability

Der Aufbau eines Fundaments für die Traceability ist ähnlich wie das eines Hauses. Das Fundament ist nicht für die Anforderung an sich bzw. den Keller entscheidend, sondern seine Bedeutung zeigt sich erst im Verlauf des weiteren Projektes bzw. Baus.

Ist das Projekt z.B. bereits im Status der Implementierung und es wird ein Change Request auf eine Anforderung gestellt, zeigt sich das erste Mal der Nutzen einer gut aufgebauten Traceability. Über die Anforderungs-ID kann nun gezielt von der Anforderung ausgehend geprüft werden, an welchen Stellen in welchen Dokumenten zu der Anforderung etwas spezifiziert wurde – und dann dementsprechend angepasst werden.

Der Weg kann aber auch andersherum beschritten werden. Man könnte z.B. bei einem Testfall beginnen, von dem vermutet wird, dass er inhaltlich nicht zum Projektauftrag gehört – also einer Umsetzung, die gar nicht gefordert ist. Der Weg wird einfach rückwärts beschritten und stringent geprüft, ob der Testfall tatsächlich zu einer Anforderung gehört oder ob die Anforderung evtl. irgendwo ergänzt wurde, aber nicht in einer klaren Linie zu einer Anforderung steht. Dies ist übrigens bei der Fehleranalyse ebenfalls sehr hilfreich, da der Testfall auch einer Implementierung zugeordnet werden kann, nach dem Prinzip „Ursache und Auswirkung“.

Ein weiterer Vorteil für Management und Fachbereich ist die bessere Möglichkeit der Zuordnung von Aufwänden zu den Anforderungen über den gesamten Entwicklungsprozess.

Dies steigert die Kostentransparenz pro Anforderung und ermöglicht so eine optimale Verwendung des Budgets, um für den Entscheider den bestmöglichen Output zu erreichen.

Fazit

Softwareentwicklung ist leider nie so planbar, wie wir es gerne hätten. Scheinen die Anforderungen zu Beginn der Entwicklung meist recht eindeutig, werden sie dennoch im Laufe des Softwareentwicklungsprozesses geändert und verbessert, oder es werden Missverständnisse identifiziert. Ein Projekt kommt über seine Laufzeit praktisch nie ohne Change Requests bzw. Änderungen aus, und auch die Wartung wird später bei der Fehleranalyse von einer klaren Traceability profitieren.

Der konsequente Aufbau einer Traceability bringt also viele Vorteile und ist dabei nicht mal ein großer Aufwand.