Systematisch zu besseren Anforderungen von Gernot Starke & Peter Hruschka

Sie fühlen sich als Architekt:innen und Designer:innen von Ihren Requirements Engineers, Product Owners oder Produktmanager:innen alleine gelassen, was klare Anforderungen angeht? Sie leiden unter vagen, unklaren oder fehlenden Anforderungen ohne konsistente Prioritäten? Sie werden für falsche Architekturentscheidungen kritisiert, obwohl Sie sie nach bestem Wissen und Gewissen (leider aber ohne Kenntnis der wahren Anforderungen) getroffen haben? Willkommen im Club der „Im-Stich-Gelassenen“.

Peter Hruschka & Gernot Starke

Peter Hruschka (Prinzipal der Atlantic Systems Guild, www.b-agile.de) und Gernot Starke (INNOQ-Fellow, www.gernotstarke.de) haben vor einigen Jahren arc42.de ins Leben gerufen, das freie Portal für Softwarearchitektur, und nun auch req42.de, das freie Portal für agiles Re-quirements Engineering. Sie sind als Gründungsmitglieder sowohl im IREB (www.ireb.org) wie auch im iSAQB (www.isaqb.org) vertreten sowie Autoren mehrerer Bücher rund um Requirements Engineering, Softwarearchitektur und Entwicklungsprozesse.

In diesem Artikel respektive in unserer Selbsthilfegruppe [1] geben wir Tipps und zeigen Good Practices zur Bewältigung dieser frustrierenden Situation. Weil es vielen von uns so geht wie oben beschrieben, hat der iSAQB das Advanced Level Modul REQ4ARC in das Ausbildungsprogramm für Softwarearchitekt:innen aufgenommen [2], [3], um eine Antwort auf die vielfältigen Klagen und Frusterlebnisse von Entwicklungsteams zu geben.

Für Software- und Systemarchitektur stellen „gute“ Anforderungen und Rahmenbedingungen die Basis vieler Entscheidungen dar. Alle Beteiligten geben vor, das Prinzip „garbage-in, garbage-out“ zu kennen, aber die Praxis sieht in dieser Hinsicht oftmals düster aus. Da braucht es konstruktive Abhilfe: Selbst sind die pragmatischen Architekt:innen und Entwicklungsteams.

Nein, wir wollen Sie mit diesem Artikel auf keinen Fall ermutigen, die Rollen von PO, Businessanalysten und Requirements Engineers zu übernehmen. Wir wollen Ihnen lediglich helfen, die architekturrelevanten Anforderungen so weit zu klären, dass Sie auf dieser Basis robuste Architekturentscheidungen treffen können. Wir starten bei grundlegendem Scoping und der Kontextabgrenzung, kümmern uns um Ermittlung (architekturrelevanter) funktionaler Anforderungen und tauchen dann in die kritischen Qualitätsziele und -anforderungen ab. Für diesen Artikel durften wir ein paar grafische Notizen von Lisa Moritz (@teapot4181) als Abbildungen verwenden [4].

Im Schlaraffenland?

Im Idealfall (also im Schlaraffenland) erhält Ihr Entwicklungsteam vom Product Owner, Businessanalysten oder Requirements Engineer gute und verständliche Anforderungen. Dann beschränkt sich Ihre Arbeit auf das Lesen und Verstehen dieser Anforderungen und eventuelle Rückfragen bei Unklarheiten. In der Realität erhalten viele Projekte jedoch nur unzureichende, mangelhafte und lückenhafte Anforderungen, oder sie bekommen Anforderungen viel zu spät.

Entwicklungsteams benötigen für ein erfolgreiches Arbeiten zumindest diejenige Teilmenge der Anforderungen, die wir als die „architekturrelevanten Anforderungen“ bezeichnen. Nur damit können Sie mit Ihren Teams gute Architektur- und Entwicklungsentscheidungen treffen. Wenn Sie also im Stich gelassen wurden, bleiben Ihnen nur zwei Möglichkeiten: diese Zulieferung in der passenden Qualität aktiv von denjenigen Personen einzufordern, die eigentlich dafür zuständig gewesen wären, oder aber selbst die Ärmel hochzukrempeln und die (Requirements-)Dinge selbst in die Hand (bzw. den Kopf) zu nehmen. Was dabei genau ansteht, sehen Sie in Abbildung 1 im Überblick.

Sauber starten

Bevor Sie beginnen, Architekturentscheidungen zu treffen, sollten Sie drei Dinge wissen, um einen sauberen Start der Entwicklung sicherzustellen. Wir nennen das den „Clean Start“ für Ihre Projekte (Abb. 2 und [5]). Nummer eins dabei ist die langfristige Vision Ihres Produkts oder Vorhabens, die geschäftlichen/wirtschaftlichen Ziele (Business Goals). Warum entwickeln wir dieses System oder Produkt, was wollen Auftraggeber bzw. Fachbereiche damit überhaupt erreichen?

Nummer zwei beim sauberen Start ist eine Übersicht der betroffenen Stakeholder. Diese Personen oder Rollen stellen die wesentliche Quelle für Anforderungen dar – 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. Gemeinsam mit Ihrem PO und/oder Management finden Sie das in einer Viertelstunde heraus – und halten das bitte explizit (also schriftlich) fest.

Das dritte Artefakt für einen sauberen Projektanfang ist Ihr Scope: Der legt den Bereich fest, in dem Sie mit Ihrem Team Architekturentscheidungen für Ihr System treffen können, und was Sie als Nachbarsysteme haben. Mit den Nachbarn meinen wir sowohl Personen wie auch IT-Systeme, Sensoren, Aktuatoren, Datenquellen und -senken, die Ihrem System Input liefern oder von Ihnen Output erwarten. In anderen Worten: alle externen Schnittstellen Ihres Systems. Sie sollten diese Kontextabgrenzung sehr ernst nehmen! Ein paar Ratschläge dazu finden Sie in [6], zusammen mit einigen Varianten, wie Sie diese externen Schnittstellen kommunizieren können.

Vor allem aber legen wir Ihnen nahe, mit dem Business Scope zu beginnen und sich erst danach auf den Product Scope einzuschränken (Abb. 3). Das gibt Ihnen die Freiheit, Teile der Funktionalität früher in Ihrem Produkt zu implementieren und andere Teile vielleicht noch eine Zeitlang manuell zu erledigen. Wenn Sie sich zu früh auf den Product Scope einschränken, vergeben Sie eventuell Chancen, weitere Teile Ihres Business zu automatisieren.

Kern: Funktionen und Prozesse

Kommen wir jetzt zu den fachlichen Aufgaben oder Verantwortlichkeiten des Systems, einem Kernthema bei Entwicklung und auch Anforderungsklärung. Es geht um die zu implementierenden Funktionen oder Prozesse [7]. Funktionale Anforderungen gibt es auf verschiedenen Abstraktionsebenen: Das beginnt sehr grob mit Use Cases oder Geschäftsprozessen, kann aber auch beliebig feingranular werden, etwa mit detaillierten Aktivitäten bzw. Funktionen. In der agilen Sprechweise hören Sie eher die Begriffe Epics (grob), Features (etwas feiner) und User Stories (ganz klein) (Abb. 4). Für Sie als Architekt:in ist diese Hierarchie deshalb wichtig, weil Sie nur einige der funktionalen Anforderungen in sehr detaillierter Form kennen müssen, beziehungsweise nur die Teile detailliert, die Sie demnächst entwickeln wollen. Die anderen können Sie über die Zeit bei Bedarf genauer erarbeiten (lassen). Dieses „Bei-Bedarf-Verfeinern“ bildet eine wichtige Grundlage iterativ-inkrementeller Entwicklungsprozesse.

Schon frühzeitig sollten Sie die volle Breite der groben funktionalen Anforderungen oder Prozesse kennen, um Art und Umfang Ihrer Gesamtaufgabe besser einschätzen zu können. Das halten wir für notwendig, damit Sie auf Basis von Businessprioritäten und technischen Randbedingungen entscheiden können, was davon Sie früher und was später angehen wollen. Damit legen Sie auch die Grundlage dafür, wo Sie in puncto funktionaler Details in die Tiefe bohren (lassen) wollen.

Falls Sie Domain-driven Design praktizieren oder das demnächst einführen wollen: Dabei liegt ein wesentlicher Fokus auf der Erarbeitung und gemeinsamen Klärung funktionaler Anforderungen: Die im DDD propagierten Bounded Contexts kapseln oftmals High-Level-Funktionalitäten oder Prozesse. Im Event Storming, einem der favorisierten Ansätze zum Start mit DDD, geht es um die zeitliche Abfolge von Ereignissen entlang der wesentlichen Prozesse oder Abläufe – also genau um die Klärung funktionaler Anforderungen.

BDD - Verhalten spezifizieren

Das Behavior-driven Development (BDD) entstand vor einigen Jahren mit der Zielsetzung, die Vorteile automatisierter (Unit-)Tests mit der Anforderungsklärung zu verbinden. Auf der Basis der Idee „Specification by Example“ entstehen bei BDD ausführbare Spezifikationen, im Idealfall durch die Kooperation zwischen Fachbereichen und Entwicklungsteams. Mittlerweile haben entsprechende Sprachen (etwa Gherkin [8]) und Frameworks (etwa Cucumber [9]) eine für die Praxis angemessene Reife erreicht. Unserer Ansicht nach fristen sie leider immer noch eine Außenseiterrolle – unter anderem fehlt es an durchgängigen Beispielen jenseits der Hello-World-Kategorie.

Jedes Mal, wenn wir (insbesondere Gernot) Hand an ausführbare BDD Specifications anlegen, keimt wieder die Hoffnung auf, dass diese vielversprechende und nützliche Kombination aus Methodik und Werkzeugen doch mehr Verbreitung in der Realität finden möge … (Ja, wir werden bestimmt demnächst an dieser Stelle einmal einen einführenden Artikel dazu schreiben!)

Qualität: Oft vergessen

Das Thema „Qualitätsanforderungen“ wird in der Praxis leider oft vernachlässigt. Uns ist das völlig unverständlich, macht doch gerade Qualität den Unterschied zwischen Akzeptanz und Ablehnung aus. Aber wir haben auch eine gute Nachricht: Es gibt einige standardisierte Schemata, die Ihnen bei der Klärung oder Definition von Qualitätsanforderungen helfen können, beispielsweise die ISO-Norm 25010, von der wir in Abbildung 5 nur die oberste Ebene darstellen.

Mit Hilfe 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. Ein möglicher (und weit verbreiteter) Ansatz besteht darin, Qualitätsanforderungen durch konkrete Szenarien (Ablaufszenarien oder Änderungsszenarien) zu präzisieren. Vermutlich werden Sie für hinreichend große Systeme davon relativ viele bekommen, in solchen Fällen hilft ein hierarchischer Qualitätsbaum, den Überblick zu behalten (Abb. 6).

Wir persönlich ersetzen diese grafische Baumdarstellung in der Praxis meistens durch Tabellen, aber das ist reine Geschmackssache. Allerdings können Sie Tabellen mit jedem Editor, Wiki oder Textverarbeitungsprogramm bearbeiten, das halten wir für etwas einfacher als Baumdiagramme zu zeichnen. In grafischen Überblick von Abbildung 7 finden Sie ein paar weitere Tipps zum Umgang mit Qualitätsanforderungen (Danke für diese Zusammenfassung, Lisa!).

Mehr über Requirements lernen?

Seit vielen Jahren arbeitet der IREB (International Requirements Engineering Board) e. V. daran, rund um die Welt solide Kenntnisse und Fähigkeiten zu Business Analysis und Requirements Engineering zu vermitteln. Mehr als 70 000 Personen haben dieses Ausbildungsprogramm durchlaufen. Der iSAQB (International Software Architecture Qualification Board) hat ein speziell auf die Bedürfnisse von Entwicklungsteams ausgerichtetes Curriculum entwickeln, in dem Sie in drei Tagen die notwendigen Skills lernen und üben, die wir hier skizziert haben (siehe [2] für Details). Wir selbst haben das dazu passende kompakte Lehrbuch verfasst [3].

Fazit

In unserer Projektarbeit stellen wir immer wieder fest, dass Entwicklungsteams unter relativ schlechten Anforderungen leiden. Für solide und tragfähige Architekturentscheidungen sind diese allerdings unbedingt notwendig. Entwicklungsteams können sich jedoch selbst helfen: In diesem Artikel haben Sie ein paar Anregungen erhalten, wie Sie schlechte Anforderungen mit überschaubarem Aufwand in den Griff bekommen können. Involvieren Sie die relevanten Stakeholder, klären Sie die übergreifenden Ziele und Qualitätsanforderungen und verschaffen Sie sich einen Überblick über die funktionalen Anforderungen und notwendigen Prozesse. Das Ganze praktizieren Sie iterativ und verfeinern Anforderungen erst on-demand, und keinesfalls up-front.