Sie entwickeln ein innovatives Produkt und wollen den Markt „erobern“. Ihr Produkt ist komplex und besteht aus mehreren Komponenten wie beispielsweise Hardware, Software und Mechanik. Die letzten Tests der aktuellen Version waren erfolgreich. Die Produktversion wurde freigegeben und an Ihre Kunden ausgeliefert. Da erreicht die erste E-Mail den Kundensupport. Die Anwenderin meldet einen Fehler und erläutert eine für sie scheinbare Unzulänglichkeit. Nach erster Betrachtung handelt es sich wirklich um einen Fehler. Doch wodurch wird er ausgelöst? Ist es ein Defekt, der bei allen Kunden auftreten kann?
Worst Case Szenario – Fehler nach der Produktauslieferung
Dringliche Behebung ist angesagt. Was nun? Welche Teile des Produkts sind betroffen? Welche Szenarien führen zum Fehler? Welche Änderungen des Produkts sind „schuld“ und betrifft das alle Produktversionen?
Viele Fragen, die zeitnah beantwortet werden müssen. Dazu ist eine systematische Arbeitsweise notwendig. Wie gehen Sie also mit Kundenanforderungen und Produktanforderungen um, die zu Erweiterungen und Änderungen des Produkts führen? Wie gestalten Sie den Entwicklungsprozess? Auch wenn die agile Produktentwicklung in der Softwareindustrie gelebte Praxis ist und in vielen anderen Bereichen mehr und mehr eingeführt wird, helfen Kärtchen auf dem Kanban Board nicht wirklich, um Fragen der Nachvollziehbarkeit und der Auswirkungen schnell zu klären.
Zusammenhänge müssen klar ersichtlich sein. Welches Modul des Produkts ist vom Fehler betroffen? In welcher Komponente steckt das Modul mit der zuletzt umgesetzten Anforderung? Zu welchem Teilsystem gehört diese Komponente? Selbst die Frage nach der ursprünglichen Kundenanforderung, die zu Änderungen am Produkt führte, lässt sich schnell beantworten, wenn man die Zusammenhänge wie in der Abbildung 1 dargestellt hierarchisch auswerten kann.
Abb. 1: Von der Kundenanforderung bis zur Modulanforderung
Die altbekannte Weisheit „Je später ein Fehler gefunden wird, umso höher sind die Folgekosten“ motiviert viele, den Entwicklungszyklus zu überdenken. Und da „Qualität nicht in ein Produkt hineingetestet werden kann“ kommt die agile Entwicklung heute an einem ordentlichen Requirements Engineering nicht mehr vorbei.
Wie kombiniert man Theorie und Praxis?
Bei der Analyse, Planung und Umsetzung von Kundenanforderungen/Epics/Stories ist es günstig, die Architektur des Produkts zu prüfen, wenn nötig, zu überarbeiten und die Änderungen für die Teilsysteme, Komponenten und Module zu dokumentieren. Die dahinterliegende Theorie der „gleichzeitigen“ Entwicklung von Anforderungen und Produktarchitektur geht auf den IT-Professor Bashar Nuseibeh der Open University zurück, der einen Lösungsansatz namens „Twin Peaks Modell“ entwickelte. Die Vorteile des Modells sind leicht erkennbar. Wenn eine Kundenanforderung/ein Epic/eine Story umgesetzt werden soll, werden die Auswirkungen auf Teilsysteme, Komponenten und Module des Produkts geprüft. Aus der Kundenanforderung werden Teilsystemanforderungen abgeleitet. Aus den Teilsystemanforderungen werden Komponentenanforderungen und aus Komponentenanforderungen werden Modulanforderungen abgeleitet. Die jeweiligen Anforderungen werden den Elementen der Architektur zugeordnet. So werden bezogen auf die Architektur keine Anforderungen vergessen. Wird festgestellt, dass die bestehende Produktarchitektur zur Anforderungsumsetzung nicht ausreichend ist, erfolgt eine Umstrukturierung bzw. werden neue Teilsysteme/Komponenten/Module definiert. Ein stetiges Refactoring für eine stabile und den Anforderungen angemessene Architektur ist das Ergebnis.
Das Twin Peaks Modell in der Praxis anzuwenden, bedarf heute einer geeigneten Software wie objectiF RM. Zur Darstellung der Architektur sind Blockdiagramme der SysML wie in Abbildung 2 geeignet. Jedes Architekturelement wird als Block abgebildet. Die hierarchische Einordnung erfolgt über Aggregationsbeziehungen (in Rot), sodass auf einen Blick ersichtlich wird, welche Teilsysteme mit welchen Komponenten und Modulen existieren. Anforderungen/Epics/Stories können den Blöcken über satisfy-Beziehungen (in Grün) direkt zugeordnet werden.
Abb. 2: Architekturelemente und deren Anforderungen im Diagramm
Alternativ lassen sich Architekturelemente und Anforderungen sowie deren Beziehungen untereinander auch tabellarisch in konfigurierbaren hierarchischen Abfragen anzeigen. In alter Excel-Manier legen Sie einfach fest, welche Eigenschaften als Spalten angezeigt werden und wie gefiltert und sortiert werden soll.
Abb. 3: Architekturelemente und deren Anforderungen in einer hierarchischen Abfrage
Wie lassen sich nun Teilsystemanforderungen in Komponenten- und Modulanforderungen ableiten? Dazu bietet objectiF RM eine Backlogtechnik. Für jedes Architekturelement gibt es ein Backlog. Wie in Abbildung 3 dargestellt existieren Sichten, um Anforderungen einer höheren Architekturebene in Anforderungen einer untergeordneten Ebene von links nach rechts per Drag & Drop abzuleiten. Zu einer „Teilsystemanforderung 01“ wird so per Klick eine Komponentenanforderung an „Komponente Hardware 01“ abgeleitet, die danach mittels einer derive-Beziehung verbunden sind.
Abb. 4: Mit der Backlog-Technik ganz einfach von Teilsystemanforderungen zu Komponenten- und Modulanforderungen
Agil und trotzdem nachvollziehbar
Im Laufe der Zeit ändern sich die Ziele und Anforderungen der Kunden. Mit Änderungswünschen zeitnah umzugehen, ist Sinn und Zweck einer agilen Entwicklung. Gerade wenn die Zusammenhänge der Architektur und der Anforderungen gut dokumentiert und auswertbar sind, kann die Machbarkeit schnell ermittelt werden. Planerische Aussagen zu Aufwänden werden sicherer und bergen weniger Überraschungen. Mit dem Twin Peaks Modell und objectiF RM gelingt es Ihnen nicht nur, trotz sich wandelnder Anforderungen eine stabile Architektur zu erarbeiten. Sie behalten auch den Überblick, welche Anforderungen wo verbaut sind und welche Abhängigkeiten existieren.
Twin Peaks am konkreten Beispiel – Besuchen Sie unser Webinar
Die Theorie steht, soweit so gut – doch wie sieht das am konkreten Beispiel aus? Hält das Modell, was es verspricht? Das sehen Sie in unserem Webinar „Brücken bauen – mit Twin Peaks und objectiF RM“. Wir zeigen Ihnen, wie Sie übersichtlich und ganz einfach mit der Backlog-Technik von Kundenanforderungen zu Anforderungen auf Teilsystem-, Komponenten-, und Modulebene gelangen. Parallel dazu erweitern wir die Produktarchitektur um weitere Module mit dazugehörigen Anforderungen. Sie werden sehen, welche Möglichkeiten Ihnen objectiF RM bietet, bei Änderungen schnell die betroffene Komponente zu identifizieren und neue Anforderungen mit Testfällen für die Qualitätssicherung abzuleiten. Unsere Webinare sind live und Sie haben die Möglichkeit, Fragen zu stellen und merken schnell, ob dieses Modell mit Toolunterstützung Ihrer Produktentwicklung Mehrwerte bringt.
Melden Sie sich jetzt an unter: https://www.microtool.de/webinare/bruecken-bauen-mit-twin-peaks-und-objectif-rm/