© Excellent backgrounds/Shutterstock.com
Java Magazin
Was Sie (vielleicht) verpasst haben

Kolumne: Req4Arcs

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 dlen (Abb. 1) und konzentrieren uns im Folgenden auf das Thema „Anforderungen und Randbedingungen klären“.

Peter Hruschka, Gernot Starke


Abb. 1: Die sechs Hauptaufgaben von ArchitektenIn 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.Abb. 2: Req4Arcs-Themen im ÜberblickAbb. 3: Clean StartAbb. 4: Business und Product ScopeAbb. 5: Hierarchie von funktionalen AnforderungenIn der fünften Folge haben wir Ihnen dann DDD (Domain-driven Design) vorgestellt [6], 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 Storytelling“ [7] 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 nichtAbb. 6: ISO-Kategorien für QualitätskritierienAbb. 7: Szenarien zur Präzisierung von QualitätseigenschaftenAbb. 8: Behavior-driven Development – ausführbare SpezifikationenAbb. 9: Discover to deliverWie kommt man an Wissen über gutes Requirements Engineering?Wir haben auch im Rahmen des iSAQB (International Software Architecture Qualification Board) eine Arbeitsgruppe initiiert, die derzeit ein neues Advanced-Modul mit dem Namen „REQ4ARCS“ entwickelt, in dem ...

Java Magazin
Was Sie (vielleicht) verpasst haben

Kolumne: Req4Arcs

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 dlen (Abb. 1) und konzentrieren uns im Folgenden auf das Thema „Anforderungen und Randbedingungen klären“.

Peter Hruschka, Gernot Starke


Abb. 1: Die sechs Hauptaufgaben von ArchitektenIn 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.Abb. 2: Req4Arcs-Themen im ÜberblickAbb. 3: Clean StartAbb. 4: Business und Product ScopeAbb. 5: Hierarchie von funktionalen AnforderungenIn der fünften Folge haben wir Ihnen dann DDD (Domain-driven Design) vorgestellt [6], 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 Storytelling“ [7] 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 nichtAbb. 6: ISO-Kategorien für QualitätskritierienAbb. 7: Szenarien zur Präzisierung von QualitätseigenschaftenAbb. 8: Behavior-driven Development – ausführbare SpezifikationenAbb. 9: Discover to deliverWie kommt man an Wissen über gutes Requirements Engineering?Wir haben auch im Rahmen des iSAQB (International Software Architecture Qualification Board) eine Arbeitsgruppe initiiert, die derzeit ein neues Advanced-Modul mit dem Namen „REQ4ARCS“ entwickelt, in dem ...

Neugierig geworden?


    
Loading...

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