Lean Traceability: Spuren legen auf dem Weg vom Stakeholder-Bedarf zur Lösung

Transkript

1 Lean Traceability: Spuren legen auf dem Weg vom Stakeholder-Bedarf zur Lösung 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? Diesen Fragen gehen wir im Folgenden nach. Wir stellen ein leichtgewichtiges Vorgehen vor, das Requirements Traceability auch in agilen Projekten lebbar macht. Inhalt Traceability was ist das genau? Ein paar Definitionen 2 Wozu ist Traceability gut? Ein paar Argumente 4 Die Traceability Matrix ein brauchbares Instrument? Ein paar Erfahrungen 5 Warum tun sich agile Projekte mit der Traceability schwer? Ein paar Vorbehalte 6 Lean Requirements Traceability. Der Lösungsvorschlag 6 Lean Traceability kurz zusammengefasst 10 in-step RED Anforderungen im Team entwickeln und ihre Realisierung agil planen und steuern 10 Requirements Traceability in in-step RED 12 Whitepaper 2016 microtool GmbH, Berlin. Alle Rechte vorbehalten.

2 Traceability was ist das genau? Ein paar Definitionen 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: Bild 1: Begriffsabgrenzung Der erste Begriff 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 und soll hier nicht betrachtet werden. Compliance ist der zweite Begriff: Er hat viele 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. Auch Compliance ist hier nicht das Thema. Hier soll es um Traceability im Sinne des Nachvollziehens von Beziehungen zwischen Artefakten des Entwicklungsprozesses gehen. 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. Whitepaper 2

3 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. Bild 2 zeigt einige davon. Bild 2: Pre-/Post-Requirements Traceability: Beziehungen zwischen Anforderungen und andere Entwicklungsartefakten nachverfolgen 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 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. Bild 3: Inner Traceability: Beziehungen zwischen Anforderungen rückverfolgen Whitepaper 3

4 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. Bild 4: Rückverfolgen der Beziehungen zwischen Anforderungen und Aufgaben in der Projektplanung. Wozu ist Traceability gut? Ein paar Argumente Die unterschiedlichen Formen der Requirements Traceability, die in Bild 2, 3 und 4 dargestellt sind, 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? Kennt man die Auswirkungen beabsichtigter Veränderungen, kann man sicherer planen und Risiken besser erkennen und bewerten. 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. Kann man nachweisen, dass alle Anforderungen in der Lösung berücksichtigt und für alle Anforderungen Tests definiert sind, hat man 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 stellt man Requirements Traceability mit vertretbarem Aufwand her? Whitepaper 4

5 Die Traceability Matrix ein brauchbares Instrument? Ein paar Erfahrungen 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 wie das aus Bild 5. Bild 5: Ein Beispiel für eine klassische Traceability Matrix Wer jemals in einem Projekt versucht hat, eine Traceability Matrix wie diese vom Bedarf der Stakeholder bis zum Test manuell zu pflegen, wird vermutlich die Einschätzung teilen, die im nachfolgenden Zitat auf den Punkt gebracht wird: Requirements Traceability Matrix is probably one of the most valuable things people almost never do 1 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. 1 Whitepaper 5

6 Warum tun sich agile Projekte mit der Traceability schwer? Ein paar Vorbehalte 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 kann das erreicht werden? Zunächst einmal: Traceability ist nicht identisch mit der Traceability Matrix. Traceability ist eine wünschenswerte Eigenschaft, die man auch mit anderen Mitteln herstellen kann. Nachfolgend stellen wir Ihnen eine Lösung vor, die vollständig auf die explizite Dokumentation von Traceability verzichtet, d.h., die ohne Artefakte wie die Traceability Matrix auskommt. Wir bezeichnen diese Lösung auch als Lean Requirements Traceability. Lean Requirements Traceability. Der Lösungsvorschlag Lean Requirements 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? Aus der Praxis 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. Damit haben wir außerdem eine Grundlage, um eine verlässliche Schätzung für den weiteren Projektverlauf mit Hilfe von Earned Value Management abzugeben. Entscheiden Sie, ob Requirement-to-Document also diese spezielle Form der Inner Traceability notwendig ist. Whitepaper 6

7 Aus der Praxis 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 ganz 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. Sie wurde ursprünglich für das Systems Engineering entwickelt und führt heute leider ein Nischendasein. Ganz zu Unrecht. Denn die SysML enthält hoch interessante Instrumente, die auch für das Requirements Engineering sehr hilfreich sind. 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. Speziell lässt sich der Bezug zum Entwurf der Lösung und zu den Testfällen herstellen. Whitepaper 7

8 Bild 6gibt einen Überblick der Ausdrucksmittel der Requirements Diagramme. Bild 6: Elemente eines Requirements-Diagramms Beziehungen zur Rückverfolgbarkeit nutzbar Was bringt ein Diagramm wie in Bild 6 konkret für die Requirements Traceability? 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. Für Repository- oder Datenbank-basierte ALM- oder Software Engineering Tools sind Diagramme wie das in Bild 6 mehr als Bilder. Die über Modelle eingebrachten Informationen werden bei der Anforderung gesammelt. Diese Art von Tools speichert Informationen über die modellierten Beziehungen persistent und erlaubt 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? Whitepaper 8

9 Hier verlassen wir die Komfortzone der modellbasierten Techniken. Es gibt es leider keine verbreitete Standardnotation vergleichbar mit der UML/SysML zur Modellierung von Business Needs und Stakeholder Goals und den daraus abgeleiteten Anforderungen. Aber es gibt Modellierungstechniken, die hier in Frage kommen: Da ist zum einen das i* Framework. Dabei handelt es sich um eine Modellierungstechnik, die von der Frage ausgeht: Wovon sind Stakeholder bei der Erfüllung ihrer Ziele abhängig? Wir empfehlen hier jedoch eine andere, einfachere 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 sichtbarmachen, aus Zielen konkrete Anforderungen ableiten. Bild 7: Zieldiagramm in Form eines Und/Oder-Graphen Es lassen sich also viele Spuren für die Pre-Requirements Traceability legen, die zu den Quellen einer Anforderung führen. Fragt sich nur: Muss man denn das alles modellieren? Muss man jedes Ziel, jede Anforderung, jedes dazu in Beziehung stehende Artefakt in einem Diagramm abbilden? Bleibt das Vorgehen dabei leichtgewichtig? Nein, man muss nicht alles grafisch abbilden. Damit das Vorgehen leichtgewichtig bleibt, ist ein weiterer Schritt notwendig: Schritt 3: Festlegen, bis zu welchem Detaillierungsniveau Artefakte getraced werden sollen. Aus der Praxis Wir haben 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 Whitepaper 9

10 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 Bei dem beschriebenen Vorgehen kommt man für die Requirements Traceability ohne zusätzlich Artefakte, fast ohne zusätzlichen Aufwand und ohne Verschwendung von Zeit und Energie aus. Voraussetzung ist, dass man einmalig für ein Projekt oder ein Programm oder für die Organisation festlegt, wie viel Traceability wirklich nötig ist. 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. Der Schlüssel dazu ist das Modellieren. Es ist die beste Art bei der Entwicklung Spuren zu legen. Voraussetzung dafür ist ein Tool, das auf einem Repository arbeitet und modellbasiertes Requirements Engineering unterstützt. Ein solches Tool und seinen Einsatz beim Spuren legen und situativen Tracen lernen Sie nachfolgend kennen. in-step RED Anforderungen im Team entwickeln und ihre Realisierung agil planen und steuern Die Überschrift bringt es auf den Punkt: in-step RED ist ein Tool, das Teams beim Erheben, Beschreiben, Modellieren, Dokumentieren und Verwalten von Anforderungen unterstützt beginnend bei der Abgrenzung des Scopes, der Analyse der Stakeholder und ihrer Ziele bis hin zum Generieren der Anforderungsspezifikation z.b. in Form von Lasten- und Pflichtenheften. in-step RED unterstützt ferner das Versions-, Konfigurationsund Variantenmanagement der Ergebnisse des Requirements Engineering. Die Instrumente für das Requirements Engineering, die Sie in in-step RED finden, orientieren sich unter anderem an den Lehrinhalten, die das International Requirements Engineering Board (IREB) für die Zertifizierung zum Certified Professional for Requirements Engineering (CPRE) definiert hat 2. Und: Mit in-step RED kann die Realisierung der Anforderung durch ein oder mehrere Teams agil geplant und gesteuert werden. Als Grundlage für die situationsgerechte agile Steuerung werden unter anderem Release- und Iterationsplanung, Arbeitsfortschritt und Mitarbeiterauslastung in vielfacher Weise ermittelt und sichtbar gemacht. Formulare, Projekttemplates und Muster für Aktivitäten, Artefakte, Ablagestrukturen etc. machen die Arbeit einfacher und schneller. Sie sorgen außerdem dafür, Ergebnisse und Vorgehen organisationsweit anzugleichen. 2 Whitepaper 10

11 Bild 8: Die Client/Server-Architektur von in-step RED für die Arbeit im Team auf einer zentalen Datenbank mit Zugriff über LAN oder Internet einfach per Browser. in-step RED hat einen speziellen Tablet-Mode der Benutzeroberfläche für die Bedienung per Touch auf Tablet PCs. in-step RED bietet eine Vielzahl an Modellen unter anderem aus der UML/SysML für die Entwicklung von Anforderungen an und damit viele Möglichkeiten, um Spuren für die Requirements Traceability zu legen. Alle Informationen über Beziehungen von Anforderungen untereinander und zu anderen Artefakten, die beim Editieren von Zieldiagrammen, Use Case Diagrammen, Requirements-Diagrammen, Architekturmodellen wie Klassen- oder Blockdiagrammen entstehen, werden als Eigenschaften der Anforderungen redundanzfrei in einer Datenbank gespeichert. Bild 9: Wenn Sie z.b. eine Beziehung zwischen einer Anforderung und einem Testfall in einem Requirements-Diagramm anlegen, finden Sie diese Beziehung ohne weiteres Zutun unter den Eigenschaften der Anforderung im Anforderungsformular und (hier nicht dargestellt) unter den Eigenenschaften des Testfalls im Testfallformular wieder. Whitepaper 11

12 Wichtig dabei: Sie müssen keineswegs mit Diagrammen arbeiten, um Informationen über die Beziehungen von Artefakten festzuhalten. Nachfolgendes Bild zeigt, wie Sie Beziehungen zwischen Artefakten beim formularbasierten Arbeiten herstellen. Wenn Sie sich nachträglich dafür entscheiden, ein Diagramm zu erstellen, können Sie diese Beziehungen per Mausklick in eine grafische Darstellung übernehmen. Bild 10: Wo immer Sie das grüne Icon mit dem Plus-zeichen sehen, können Sie einer Anforderung Elemente zuordnen, ohne dass diese Elemente in einem Diagramm vorkommen müssen. Wie Sie die Informationen über die Beziehungen der Artefakte des Requirements Engineering für die Traceability festhalten, wo Sie diese Informationen finden und wie Sie sie zum situativen Tracen benutzen, das erfahren Sie jetzt. Requirements Traceability in in-step RED Nehmen wir an, im Projektverlauf stellt sich heraus, dass eine Anforderung, so wie sie anfänglich definiert wurde, nicht mehr sinnvoll ist und geändert werden muss. Für Sie in der Rolle des Requirements Engineer ergeben sich daraus folgende Fragen: Wo kommt die Anforderung her? Wem ist die Anforderung wie wichtig? Welcher Stakeholder muss ggf. kontaktiert werden? Welche Businessziele sollten ursprünglich mit der Anforderung erreicht werden? Trägt die geänderte Anforderung nach wie vor dazu bei? Welche anderen damit in Beziehung stehenden Anforderungen sind von Änderungen ggf. betroffen? Whitepaper 12

13 Sind nach der Änderung der Anforderung die Testfälle noch richtig, fehlen Testfälle oder sind manche sogar überflüssig geworden? Welchen Einfluss hat die Änderung auf die Realisierung bzw. auf bereits realisierte Funktionen? Gibt es Lösungsartefakte, die von der Änderung betroffen ist? Alle Informationen zur Pre- und Post-Requirements Traceability einer Anforderung sowie zur Requirement-to-Task Traceability finden Sie im Anforderungsformular. Die Bilder 11 bis 14 veranschaulichen die Zusammenhänge: Bild 11: Die Quellen der Anforderung: Eine Anforderung kann direkt auf einen Stakeholder zurückgehen und/oder aus einem (Business-) Ziel abgeleitet sein. Whitepaper 13

14 Bild 12: Die Beziehungen zu anderen Anforderungen werden jeweils auf einem eigenen Tab im Anforderungsformular festgehalten: Verfeinerungen (im Diagramm Contains-Beziehung), Ableitungen (Derive-Beziehungen) und Abhängigkeiten (Depend-Beziehung) Whitepaper 14

15 Bild 13: Requirements-to-Task Traceability und Beziehungen zu bereits realisierten Systemelementen. Bild 14: Beziehungen zu Anwendungsfällen und Testfällen. Whitepaper 15

16 Wenn Sie Elemente gefunden haben, die von der zu ändernden Anforderung betroffen sind, wie geht es dann weiter? Sicher wollen Sie die Definitionen der betroffenen Elemente genauer ansehen, um zu entscheiden, ob auch diese Elemente geändert werden müssen. Das Navigieren zu diesen Elementen ist denkbar einfach: Auf den Elementen stehen Kontextmenüfunktionen zur Verfügung, die Sie entweder direkt zur Definition oder zum grafischen Kontext der Elemente führen. Nachfolgendes Bild zeigt ein Beispiel dafür: Bild 15: Der Spur folgen zu der ggf. von der Änderung betroffenenen Verfeinerung der Anforderung. Darüber hinaus stehen Ihnen in in-step RED zahlreiche konfigurierbare Abfragen zur Verfügung, die unter anderem Anforderungen mit ihren Stakeholdern, alle Anwendungsfälle mit abgeleiteten Anforderungen, Anforderungen mit ihren Verfeinerungen, Anforderungen mit abgeleiteten Anforderungen (Anforderungshierarchie) und Anforderungen mit ihren Testfällen etc. auf einen Blick zeigen. Diese Listen können Sie in Word-Dokumente hinein generieren oder nach Excel exportieren. Bild 16 zeigt ein Beispiel für eine solche Abfrage. Whitepaper 16

17 Bild 16: Eine vordefinierte, konfigurierbare Abfrage: Anforderungen mit ihen Stakeholdern. Einen Aspekt, nämlich den der Evolution von Anforderungen, haben wir in der obigen Betrachtung weitgehend ausgeklammert. Das bedeutet jedoch nicht, dass in-step RED Sie nicht bei der Versionierung der Artefakte des Requirements Engineering unterstützt. Sie können sich jederzeit die Historie der Artefakte, also ihre Revisionen, ansehen und nach Bedarf auch zu einen früheren Entwicklungsstand zurückkehren. In Hinsicht auf die Requirements Traceability können Sie sich, wann immer Sie wollen, einen Überblick über die Entwicklungsschritte verschaffen, die eine Anforderung erlebt hat. Eine entsprechende Sicht zeigt Bild 17. Bild 17: Durch Auflistung der erzeugten Revisionen wird die Evolution der Anforderungen transparent gemacht. Auch diese Sicht ist übrigens konfigurierbar. Whitepaper 17

18 Auf den vorangegangenen Seiten haben Sie in-step RED unter dem Aspekt der Traceability kennengelernt. Das Tool kann aber noch mehr für Sie tun, speziell wenn Sie ganz oder teilweise agil vorgehen. So bietet es: Unterstützung für die agile Projekt-, Release- und Sprint-Planung einschließlich Backlog-Organisation und Metriken Funktionen für das Vorgehen nach Use Case 2.0 3, einer agilen Erweiterung des klassischen Use Case Konzepts. Das sind nur zwei Beispiele für viele interessante Features, die es zu entdecken gibt. Und genau dazu laden wir Sie ein: Testen Sie in-step RED live online Installation einfach im Browser. Das und noch viele nützliche Informationen zur Projektplanung unter projektplanung-mit-in-step-red/ Copyrights und Warenzeichen in-step RED sowie microtool making IT better sind eingetragene Marken der microtool GmbH. UML und SysML sind eingetragene Marken der Object Management Group, Inc. 3 Whitepaper 18