Handeln statt jammern:

In vielen Beratungs­pro­jekten der letzten Jahre haben wir erlebt, dass sich Entwick­lungs­teams über zwei Dinge beschweren: dass sie unter einem Mangel an guten Anfor­de­rungen leiden bzw. dass sie wichtige Anfor­de­rungen nicht oder viel zu spät erhalten haben. Sie schieben die Schuld dann auf Requirements Engineers, Business Analysts oder Product Owner, die „ihren Job nicht gut gemacht haben“. Daraus resul­tieren dann Archi­tektur- und Entwurfs­ent­schei­dungen auf der Basis impli­ziter Annahmen oder Vermu­tungen – ganz schlecht für‘s System oder Produkt.

Dem Advanced-Modul „REQ4ARC“ (Requirements for Archi­tects) des iSAQB liegt die Idee zugrunde, dass sich Entwick­lungs­teams in puncto Anfor­de­rungen selbst helfen sollen, statt weiterhin über schlechte Anfor­de­rungen zu jammern. Mit anderen Worten: Als Architekt:in oder Entwickler:in sollten Sie so viel über Anfor­de­rungen lernen, dass Sie Projekte und Produkte erfolg­reich gestalten können.

Falls Sie übrigens mehr für Grafiken als für Fließtext übrig­haben, können Sie ganz ans Ende dieses Beitrags springen und eine visuelle Zusam­men­fassung (der großar­tigen Lisa Moritz, siehe [teapot418]) genießen. Wir freuen uns natürlich, wenn Sie danach wieder hier zum Text zurückkehren…

Architek­tur­rele­vante Anforderungen

Bereits mit sehr wenig Zeitaufwand können Entwick­lungs­teams die entschei­denden (sprich: archi­tek­tur­rele­vanten) Anfor­de­rungen klären. Starten wir beim Fundament:

Drei Punkte sollten jedem Team explizit klar sein: Die Projekt­ziele, die Stake­holder und der Scope des Projekts. Mit anderen Worten: „Wo wollen wir hin?“, „Wer darf (oder muss) mitspielen?“, und „Ist das unser Thema oder nicht?“ (siehe Abbildung 1).

Abbildung 1: Sauber starten (verwendet mit Geneh­migung von req42)

Wenn die richtigen Personen zusam­men­kommen und sich die Politik aus der Diskussion heraushält, genügen dafür wenige Stunden oder – bei sehr großen Projekten – wenige Tage, um in diesen drei Kernpunkten Klarheit zu gewinnen.

Zusätzlich gehört ein Überblick über die gewünschte Funktio­na­lität (keine Details!) dazu, sowie die wesent­lichen (und wir meinen tatsächlich nur 3 – 5) Quali­täts­an­for­de­rungen sowie die härtesten Randbe­din­gungen. Unserer Erfahrung nach können Sie das in 1 – 2 Prozent des Projekt­auf­wands ermitteln. Bei einem typischen Scrum-Team von 5 – 9 Personen und einer Laufzeit von einem Jahr (also 1000 bis 1800 Perso­nentage), um ein Produkt iterativ, inkre­mentell zu entwi­ckeln, macht das 10 – 18 Perso­nentage. Schon mit diesem sehr überschau­baren Zeitaufwand können Sie das Risiko von Fehlent­wick­lungen deutlich abmildern.

Kern der Sache: Prozesse und Funktionen

Funktionale Anfor­de­rungen bilden ein Kernthema der gesamten Anfor­de­rungs­analyse: Es geht darum, was genau das System erledigen soll, welche Geschäfts- oder Arbeits­pro­zesse es unter­stützen muss.

Dabei genügt es zu Beginn der Entwicklung, einen groben Überblick zu besitzen und erst on-demand im Laufe von Entwick­lungs­i­te­ra­tionen funktionale Details zu klären. In der agilen Sprech­weise beginnt diese Hierarchie bei den Epics und geht in den Stories dann ins Detail. Für Sie als Architekt:in ist diese Hierarchie deshalb wichtig, weil Sie lediglich dieje­nigen Teile der funktio­nalen Anfor­de­rungen in detail­lierter Form kennen müssen, die Sie demnächst entwi­ckeln wollen. Für andere Teile reicht Ihnen der Überblick. Das vermeidet Up-Front Arbeits­aufwand und erlaubt es, auf geänderte fachliche Rahmen­be­din­gungen kurzfristig eingehen zu können.

Abbildung 2: Hierarchie funktio­naler Anforderungen

REQ4ARC stellt hierzu einige Mecha­nismen zur Hierar­chi­sierung von Anfor­de­rungen vor, um syste­ma­tisch vom „Großen“ in die notwen­digen Details abtauchen zu können. In manchen Fällen tragen Techniken wie behaviour-driven develo­pment (BDD) oder speci­fi­cation-by-example (siehe [bdd] und [spec-by-example]) dazu bei, solche detail­lierten Anfor­de­rungen mitsamt passender Abnah­me­kri­terien entwick­lungsnah und pragma­tisch zu erarbeiten.

Baustelle Qualität

Die unserer Ansicht nach größte Baustelle bezüglich Anfor­de­rungen bilden mangelnde oder fehlende Qualitätsanforderungen:

Alle erwarten vom Team quali­tativ gute Lösungen, aber niemand sagt explizit, was genau an Performanz, Sicherheit, Robustheit, Erwei­ter­barkeit etc. benötigt wird.

Obwohl unter der Aufsicht des Inter­na­tional Requirements Engineering Board (IREB, https://ireb.org) in den letzten 15 Jahren über 70.000 Personen (!!) in mehr als 80 Ländern als Requirements Engineers ausge­bildet und zerti­fi­ziert wurden und auch die Scrum-Organi­sa­tionen jährlich Tausende Product Owner ausbilden, bleiben Quali­täts­an­for­de­rungen in der Praxis meist unsäglich schlecht formu­liert bezie­hungs­weise implizit.

Dabei bilden doch gerade die Quali­täts­an­for­de­rungen unsere wesent­lichen Archi­tek­tur­treiber. Ohne wirklich zu verstehen, welcher Grad an Sicherheit gebraucht wird, wie sehr das System skalieren muss, welche recht­lichen Auflagen erfüllt werden müssen, bleiben zentrale Entwurfs­ent­schei­dungen oft Glückssache.

Deshalb widmet REQ4ARC diesem Thema sehr viel Aufmerk­samkeit: Wir basieren die Diskussion beispiels­weise auf dem bewährten ISO-Standard 25010 (siehe Abbildung 3) und gehen ausführlich auf Möglich­keiten zur Konkre­ti­sierung einzelner Quali­täts­an­for­de­rungen ein, etwa mit Hilfe von Quali­täts­sze­narien oder vergleich­baren metho­di­schen Ansätzen.

Abbildung 3: Standar­di­siertes Schema für Qualitätseigenschaften

Entwick­lungs­teams sollten hierbei beson­deren Wert auf die explizite Prüfbarkeit der gestellten Quali­täts­an­for­de­rungen legen, etwa durch konkrete und messbare Abnah­me­kri­terien. REQ4ARC-Trainings enthalten zu diesem Thema intensive Übungsanteile.

Enge Koope­ration

Finden Sie den Fehler in folgender Aussage:

„Kund:innen und Nutzer:innen wissen genau, was sie wollen.“

Klar, ein Klassiker: Menschen (hier: unsere Fachseite) wissen eben in vielen Fällen nicht genau, was sie wollen oder benötigen. Daher sollten Sie für eine möglichst enge Zusam­men­arbeit zwischen Entwick­lungsteam und den produkt­ver­ant­wort­lichen Stake­holdern (etwa: Requirements Engineering oder Product Owner) sorgen. Uns gefällt das Motto „discover to deliver“ der Produkt­ex­pertin Ellen Gottes­diener (siehe [gottes­diener]). Sie verknüpft die beiden Themen Requirements Analyse (Discover) und Architektur/Entwicklung/Deployment (Deliver) eng mitein­ander, statt sie sequen­ziell hinter­ein­ander auszu­führen, siehe Abbildung 4.

Abbildung 4: Discover to deliver

Im Rahmen dieser konti­nu­ier­lichen Zusam­men­arbeit entwi­ckeln (deliver) Sie Teile des Produktes, und auf dieser Basis entdecken (discover) die fachlichen Stake­holder geänderte oder neue Anfor­de­rungen. So bekommen beide Seiten schnelles Feedback und können gemeinsam das passende System gestalten.

Alter­nativ dazu stellen auch Ansätze wie Three Amigo Sessions, Design Thinking oder Lean Develo­pment die Teams so auf, dass beide Fähig­keiten intensiv zusam­men­ar­beiten und in kurzen Zyklen den Produkt­erfolg sicherstellen.

Zusam­men­fassung

In unserer pragma­ti­schen Projekt­arbeit stellen wir immer wieder fest, dass Architekt:innen und Entwick­lungs­teams leider nur selten adäquat mit hinrei­chend guten Anfor­de­rungen versorgt werden. Die brauchen sie aber dringend, um Entschei­dungen über die Archi­tektur von Produkten zielge­richtet und zukunfts­sicher treffen zu können.

In Kurzform:

1. Klären Sie gemeinsam mit den maßgeb­lichen Stake­holdern Ziele, Scope und Kontext.
2. Verschaffen Sie sich einen Überblick der wichtigen High-Level-Abläufe, Prozesse oder Geschäfts­funk­tionen (in agiler Sprech­weise: Epics).
3. Klären Sie die 3 – 5 wichtigsten Quali­täts­an­for­de­rungen, am besten mess- oder entscheidbar.
4. Im Laufe der Entwicklung verfeinern Sie (oder bitten Fachseite oder Product-Owner darum) die High-Level-Prozesse on-demand in Stories oder Features.
5. Koope­rieren Sie dabei mit den für das Produkt oder System verant­wort­lichen Personen (z. B. Fachseite, Business, PO).

Als Hilfe zur Selbst­hilfe gibt es mit dem praxis­nahen REQ4ARC-Modul eine effektive Abhilfe, die Ihnen Anregungen und konkrete Hilfe­stellung gibt, wie Sie diese Situation in den Griff bekommen. Möge die Macht guter Requirements mit Ihnen sein.

Req4Arc als Sketchnotes

Wie in der Einleitung angekündigt, finden Sie hier eine grafische Zusam­men­fassung des Themas, erstellt von Lisa Moritz ([teapot418]). Lisa hat an einem unserer REQ4ARC-Trainings teilge­nommen – die folgenden Abbil­dungen stellen ihre Mitschrift dar (falls Sie davon auch so begeistert sind wie wir, schauen Sie auf ihre Website https://www.sketchnotes.tech).

Zum Vergrößern die folgenden Bilder anklicken.

Abbildung 5: Sketchnote 1 [teapot4181]

Abbildung 6: Sketchnote 2 [teapot4181]

Abbildung 7: Sketchnote 3 [teapot4181]

Quellen

[REQ4ARC Lehrplan] (Inter­na­tionale Version) https://isaqb-org.github.io/curriculum-req4arc/

[REQ4ARC Buch] P. Hruschka & G. Starke: Requirements Skills erfolg­reicher Software­teams. Das Buch zum REQ4ARC-Lehrplan. Für Leser:innen des iSAQB-Blogs 50% Ermäßigung: https://leanpub.com/requirements-skills/c/isaqb-blog-coupon

[bdd] Behaviour Driven Develo­pment, siehe etwa https://cucumber.io/docs/bdd/

[spec-by-example] Gojko Adzic: Speci­fi­cation by Example, How Successful Teams Deliver the Right Software. Manning, 2011

[gottes­diener] Ellen Gottes­diener, Discover to Deliver. https://www.ebgconsulting.com/agile-resources/agile-books/

[teapot4181] Lisa Moritz, https://www.sketchnotes.tech/about/