Kolumne

Req4Arcs: Was Sie (vielleicht) verpasst haben

Peter Hruschka, Gernot Starke

© SuS_Media

In zehn Folgen haben wir Ihnen in dieser Kolumne REQ4ARCS nahegebracht – das, was Architekt*innen über Requirements wissen sollten, wenn sie erfolgreiche Systeme oder Produkte bauen und deployen wollen. In dieser (vorläufig letzten) Folge zeigen wir Ihnen im Überblick nochmals die wichtigsten Themen in Kurzform. Als Ausgangspunkt nutzen wir die sechs Hauptaufgaben aus arc42, die Sie in Ihrer Architektenrolle bearbeiten sollen (Abb. 1) und konzentrieren uns im Folgenden auf das Thema „Anforderungen und Randbedingungen klären“.

Im Idealfall (anders gesagt: in der Traumwelt) erhält Ihr Entwicklungsteam vom Product Owner, Business Analyst oder Requirements Engineer gute Anforderungen. Dann beschränkt sich Ihre Arbeit auf das Lesen und Verstehen dieser Anforderungen und eventuelle Rückfragen bei Unklarheiten.

Abb. 1: Die sechs Hauptaufgaben von Architekten

Abb. 1: Die sechs Hauptaufgaben von Architekten

In der ersten Folge haben wir hingegen die Realität vieler Projekte als Ausgangspunkt genommen: Sie erhalten nur unzureichende, mangel- und lückenhafte Anforderungen. Sie benötigen für erfolgreiche Entwicklungs- und Architekturarbeit zumindest diejenige Teilmenge der Anforderungen, die wir als die „architekturrelevanten Anforderungen“ bezeichnen. Nur mit diesen können Sie die richtigen Entscheidungen für Ihre Architektur treffen. Wenn Sie also im Stich gelassen wurden, haben Sie nur zwei Möglichkeiten: diese Zulieferung aktiv von denjenigen Personen oder Rollen einzufordern, die eigentlich dafür zuständig gewesen wären, oder aber (innerlich knurrend) selbst die Ärmel hochzukrempeln. Was Sie dann alles eventuell machen müssen, ist in Abbildung 2 im Überblick dargestellt. Die Nummern in verweisen auf die jeweilige Folge der Kolumne.

Abb. 2: REQ4ARC-Themen im Überblick

Abb. 2: REQ4ARC-Themen im Überblick

In der zweiten Folge haben wir Ihnen drei Artefakte vorgestellt, ohne die Sie niemals mit Architekturentscheidungen beginnen sollten. Wir nennen das einen „Clean Start“ für Ihre Projekte (Abb. 3). Dazu gehört eine Einigung über die Vision Ihres Vorhabens und die Projektziele (Business Goals), aber auch eine möglichst umfassende Kenntnis über die Stakeholder. Diese Stakeholder (Personen oder Rollen) stellen die wesentliche Quelle für Anforderungen dar – und vergessene Stakeholder bedeuten somit vergessene Anforderungen. Deshalb sollten Sie eine kurze Timebox in ein Brainstorming investieren, wer in Ihrem Umfeld zu welchem Thema Anforderungen, Wünsche und Meinungen hat.

Abb. 3: Clean Start

Abb. 3: Clean Start

Das dritte Artefakt für einen sauberen Projektanfang ist die Festlegung Ihres Scopes: Damit bestimmen Sie, was Ihre „Spielwiese“ ist, d. h. den Bereich, in dem Sie mit Ihrem Team Architekturentscheidungen für Ihr System treffen können. Und Sie legen fest, wen Sie als Nachbarn haben. Gemeint sind alle Personen, IT-Systeme, Sensoren, Aktuatoren etc. die Ihrem System Input liefern oder von Ihnen Output erwarten. In anderen Worten: Alle externen Schnittstellen Ihres Systems. Da Sie diese Kontextabgrenzung sehr ernst nehmen sollten, haben wir Ihnen in Folge 3 dafür zahlreiche Ratschläge aufgezeigt, auch unterschiedliche Notationen vorgeschlagen, wie Sie diese externen Schnittstellen kommunizieren können. Vor allem aber haben wir Ihnen nahegelegt, nicht zu früh auf den Product Scope einzuschränken, sondern eher mit Ihrem Business Scope zu beginnen (Abb. 4). Das gibt Ihnen den Freiheitsgrad, Teile der Funktionalität früher in Ihrem Produkt zu implementieren und andere Teile vielleicht noch eine Weile organisatorisch oder manuell zu erledigen. Wenn Sie zu früh auf den Product Scope einschränken, vergeben Sie die Chancen, über andere Teile Ihres Business nachzudenken, für die sich Automatisierung eventuell lohnt.

Abb. 4: Business und Product Scope

Abb. 4: Business und Product Scope

Ab Folge 4 haben wir ein Kernthema der Anforderungsanalyse aufgegriffen, den „Umgang mit funktionalen Anforderungen“. Zunächst haben wir darauf hingewiesen, dass funktionale Anforderungen auf verschiedenen Abstraktionsebenen existieren, z. B. ganz grobe Use Cases (oder Geschäftsprozesse) gegen komplexe Aktivitäten (Prozessschritte) und Teilaktivitäten (bzw. detaillierte Funktionen), oder in der agilen Sprechweise (wie in Abb. 5 dargestellt) grobe Epics, feinere Features und ganz kleine User Stories. Für Sie als Architekt*in ist diese Hierarchie deshalb wichtig, weil Sie nicht alle funktionalen Anforderungen in sehr detaillierter Form kennen müssen. Genauer wollen Sie nur die Teile kennen, die Sie demnächst entwickeln wollen. Die anderen können Sie über die Zeit bei Bedarf genauer erarbeiten (lassen).

Abb. 5: Hierarchie von funktionalen Anforderungen

Abb. 5: Hierarchie von funktionalen Anforderungen

Die volle Breite grober Anforderungen sollten Sie jedoch frühzeitig kennen, um den Umfang Ihrer Gesamtaufgabe besser abschätzen zu können – nach Businessprioritäten zu entscheiden, was Sie davon früher und was später angehen wollen und damit die Grundlage dafür zu legen, wo Sie in die Tiefe bohren (lassen) möchten.

In der fünften Folge haben wir Ihnen dann DDD (Domain-driven Design) vorgestellt, einen Ansatz, der trotz seines Namens mehr mit fachlichen Anforderungen als mit Design zu tun hat. Er beruht vor allem auf der Idee, ein gemeinsames fachliches Vokabular zwischen Nutzern, Analytikern, Architekten und Entwicklern aufzubauen, eine Ubiquitous Language (wie Eric Evans das nennt), und somit Fachlichkeit und Architektur in Einklang zu bringen. Wir empfehlen diesen Ansatz allen praktizierenden Entwicklungsteams nicht nur, um die Fachlichkeit (die Domäne) besser zu verstehen, sondern auch, um die Architektur an diesen Domänenstrukturen auszurichten.

Abschließend zu den funktionalen Anforderungen haben wir in Folge 6 dann unter dem Titel „BDD und/oder Domain Story Telling“ noch Specification by Example aufgegriffen – die Idee, dass einige gute Beispiele (in Form von konkreten Szenarien ausgedrückt) manchmal besser sind als schlechte Abstraktionen.

Funktionale Anforderungen alleine reichen nicht

In den Folgen 7 und 8 haben wir uns anschließend mit dem weit unterschätzten Thema „Qualitätsanforderungen“ auseinandergesetzt [1], [2]. Zunächst die gute Nachricht: Es gibt einige standardisierte Kategorisierungsschemata, z. B. die ISO-Norm 25010, von der wir in Abbildung 6 nur die oberste Ebene darstellen.

Abb. 6: ISO-Kategorien für Qualitätskritierien

Abb. 6: ISO-Kategorien für Qualitätskritierien

Mithilfe einer solchen Checkliste können Sie systematisch Ihre Stakeholder befragen, in welchem Bereich sie welche Qualitätsanforderungen haben. Achten Sie darauf, dass auch Qualitätsanforderungen überprüfbar sein müssen und Sie daher Abnahmekriterien dafür festlegen müssen. Konkrete Beispiele dafür haben wir dann in Folge 8 gezeigt, wiederum wie bei den funktionalen Anforderungen hauptsächlich durch die Idee, Qualitäten durch Szenarien zu präzisieren und diese z. B. als Qualitätsbäume darzustellen (Abb. 7).

Abb. 7: Szenarien zur Präzisierung von Qualitätseigenschafen

Abb. 7: Szenarien zur Präzisierung von Qualitätseigenschafen

In Folge 9 gingen wir noch einen Schritt weiter in der Zusammenarbeit zwischen Requirements Engineers und Architekten. Am Beispiel Gherkin und Cucumber (Abb. 8) haben wir Ihnen aufgezeigt, wie man von vagen Anforderungen über konkrete Szenarien zu ausführbaren Spezifikationen kommen kann [3]. Das ist sicherlich (noch) nicht der Entwicklungsalltag in vielen Projekten, bestätigt aber den Trend zur immer engeren Verknüpfung zwischen Problemraum und Lösungsraum.

Abb. 8: Behavior-driven Development – ausführbare Spezifikationen

Abb. 8: Behavior-driven Development – ausführbare Spezifikationen

Diesen Trend zu „miteinander statt gegeneinander“ haben wir schließlich in Folge 10 weiter vertieft [4]. Mit dem von Ellen Gottesdiener geprägten Motto „Discover to deliver“ haben wir Ihnen eindringlich nahegelegt, dass heute jeder erfolgreiche Entwicklungsprozess iterativ die beiden Themen Requirements-Analyse (discover) und Architektur/Entwicklung/Deployment (deliver) eng miteinander verknüpft, statt sie sequenziell hintereinander auszuführen (Abb. 9).

Abb. 9: Discover to deliver

Abb. 9: Discover to deliver

In Ansätzen wie Three Amigo Sessions, Design Thinking oder Lean Development werden die Teams so aufgestellt, dass beide Fähigkeiten vertreten sind und in intensiver, gemeinsamer Arbeit in kurzen

Zyklen zum Produkterfolg kommen.

Wie kommt man zu dem Wissen über gutes Requirements Engineering?
Seit vielen Jahren arbeitet IREB e. V. (International Requirements Engineering Board) daran, vielen Personen rund um die Welt solide Business-Analysis- und Requirements-Engineering-Kenntnisse zu vermitteln. Fast 50 000 Personen haben dieses Ausbildungsprogramm durchlaufen und durch die Zertifizierungsprüfung ihre Fähigkeiten nachgewiesen. Seit einem Jahr steht auch ein speziell auf agile, iterative, inkrementelle Projekte zugeschnittenes Programm zur Verfügung.

Wir haben auch im Rahmen des iSAQB (International Software Architecture Qualification Board) eine Arbeitsgruppe initiiert, die derzeit ein neues Advanced-Modul mit dem Titel „REQ4ARCS“ entwickelt, in dem Sie speziell in der Rolle als Architekt(in) in drei Tagen die Skills, die wir in dieser Zusammenfassung unserer Kolumne skizziert haben, ausführlich lernen können. Mehr dazu finden Sie demnächst auf der iSAQB-Homepage.

Fazit

Als Realisten und Pragmatiker stellen wir immer wieder fest, dass Architekt*innen und Entwicklungsteams leider oft nicht (oder zumindest nicht gut genug) mit den Anforderungen versorgt werden, die sie dringend brauchen, um Entscheidungen über die Architektur von Produkten zielgerichtet und zukunftssicher zu treffen. Als Hilfe zur Selbsthilfe haben wir über die letzten zehn Monate hinweg diese Kolumne geschrieben, die Ihnen Anregungen geben soll, wie Sie diese oft unerträgliche Situation in den Griff bekommen. Möge die Macht guter Requirements weiter mit Ihnen sein.

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: