© GreenFlash/Shutterstock.com
Was Sie (vielleicht) verpasst haben

Kolumne: Req4Arcs


In zehn Folgen haben wir Ihnen in dieser Kolumne Req4­Arcs nahegebracht – das, was Architekt*innen über Requirements wissen sollten, wenn sie erfolgreiche Systeme oder Produkte bauen und deployen wollen. In dlen (Abb. 1) und konzentrieren uns im Folgenden auf das Thema „Anforderungen und Randbedingungen klären“.

hruschka_starke_r4a_11_1.tif_fmt1.jpgAbb. 1: Die sechs Hauptaufgaben von Architekten

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.

In der ersten Folge [2] 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.

hruschka_starke_r4a_11_2.tif_fmt1.jpgAbb. 2: Req4Arcs-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 und [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.

hruschka_starke_r4a_11_3.tif_fmt1.jpgAbb. 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 Si...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang