Kolumne

Req4Arc: Vom Umgang mit funktionalen Anforderungen

Peter Hruschka, Gernot Starke

In der vorigen Folge haben wir uns Scope angesehen. Der saubere Start hat also geklappt. Wir haben uns auf Ziele, Stakeholder und Scope geeinigt. Jetzt wollen wir die Anforderungen verstehen und klären – und zwar sowohl die funktionalen Anforderungen als auch Qualitätsanforderungen und Randbedingungen.

Die letzteren Beiden stellen wir noch etwas zurück und konzentrieren uns in den nächsten Folgen auf die funktionalen Anforderungen. Dabei interessieren uns besonders die für die Architektur relevanten – und weniger eine vollständige Liste aller benötigten Funktionen. Sie müssen wissen, welche funktionalen Anforderungen Ihre Architekturentscheidungen besonders prägen werden.

Woher jedoch können wir diese relevanten von den weniger relevanten unterscheiden? Lassen Sie uns dazu auf die verschiedenen Granularitäten funktionaler Anforderungen schauen.

Granularität von Anforderungen

Ihre Stakeholder werden Ihnen manchmal sehr grobgranulare Anforderungen nennen („das Navisystem soll in der nächsten Version auch einen Spurassistenten haben“) und manchmal sehr feingranulare Anforderungen („die erwartete Ankunftszeit für die aktive Route soll auffällig und gelb unterlegt rechts unten im Kombidisplay dargestellt werden“).

Für Sie als Architekt(in) ist es wichtig, sich einen Überblick über die gewünschte Funktionalität zu verschaffen. Leider können wir unsere Stakeholder nicht davon abhalten, alles, was sie wollen, in beliebiger Reihenfolge und Granularität von sich zu geben. Wenn Sie Details zu hören bekommen, sollten Sie nachfragen, zu welchem größeren Thema diese denn gehören. Sie wollen die unterschiedlichen Granularitäten (funktionaler) Anforderungen in eine Hierarchie bringen, wie in Abbildung 1 aufgezeigt. Für Ihre Architekturarbeit konzentrieren Sie sich dann zuerst auf die oberste Ebene.

Abb. 1: Granularität von Anforderungen – von Zielen zu funktionalen Details

Die grobgranularen Anforderungen hätten Sie gerne vollständig, damit Sie einen Überblick über das Gesamtsystem haben und entscheiden können, welche Teile Sie in der Implementierung vorziehen und welche Sie zurückstellen wollen.

Denken in Prozessen – wenn möglich

Wie kommen wir zu einer grobgranularen Zerlegung des gesamten Systems, die wir möglichst getrennt voneinander analysieren und implementieren können? Nach welchen Kriterien sollen wir gliedern oder zerlegen?

Viele der Analysemethoden der letzten Jahrzehnte schlagen – unter unterschiedlichen Namen – vor, eine Zerlegung in Prozesse vorzunehmen. Diese Prozesse werden aus dem Kontext (d. h. aus der Systemumgebung) getriggert und stellen vergröbert den gesamten Ablauf von den Eingaben bis hin zu den Ergebnissen dar.

Diese Prozesse werden durch Auslöser aus der Umgebung gefunden und sind somit unabhängig von jeder internen Strukturierung Ihres Systems. Außerdem stellen diese externen Trigger sicher, dass es jemanden in der Systemumgebung (im Kontext) gibt, der diesen Prozess haben will. Das sind zwei der INVEST-Kriterien, die Bill Wake für gute Storys aufgestellt hat: unabhängig voneinander und wertvoll.

Abb. 2: Grobgranulare Anforderungen – gliedern nach Prozessen

Für Sie als Architekt(in) ist dieser Überblick einiges wert: Selbst wenn Sie im ersten Release nur einen Teil davon implementieren wollen, wissen Sie doch, wo die Reise hingeht – was bei Designentscheidungen die Kurzsichtigkeit verhindert.

Die zweitbeste Möglichkeit zur Grobgliederung von Anforderungen – wenn Sie ein bestehendes System ergänzen oder erweitern – ist die Gliederung nach der bekannten Struktur dieses Vorgängersystems. Sie können dann neue Anforderungen zu spezifischen Subsystemen oder bestehenden Komponenten erfassen. Diese Anforderungsgliederung erschwert jedoch innovative Ideen zum Produkt, weil Sie die gegebene architekturelle Struktur wahrscheinlich nicht hinterfragen oder anzweifeln werden, sondern nur lokale Ergänzungen oder Änderungen spezifizieren.

Schreiben oder zeichnen?

Wenn Sie in Prozessen denken, können Sie nach Lust und Laune wählen, ob Sie Umgangssprache zur Darstellung dieser Prozesse bevorzugen oder lieber grafische Darstellungen.
Umgangssprachlich bewährt sich die Formel, die Mike Cohn für Storys vorgeschlagen hat [1]: Als <Nutzer> möchte ich <Funktion>, sodass <Vorteil>. Dazu zwei konkrete Beispiele:

  • „Als Fahrer möchte ich auf Wartungsintervalle hingewiesen werden, damit mein Fahrzeug immer fahrtüchtig bleibt.“
  • „Als Fahrer möchte ich das Tempo mit dem Tempomat konstant halten, um nicht selbst das Gaspedal bedienen zu müssen und in geschwindigkeitsbeschränkten Bereichen die Höchstgeschwindigkeit nicht zu überschreiten.“

Diese sprachliche Formel gewährleistet, dass es erstens jemanden gibt (den Nutzer), der die Funktion wirklich haben will und sie erklärt zweitens auch den Grund dafür (den Vorteil). Als Entwicklerteam erlaubt Ihnen dieser Vorteil, Ihren Nutzern bei Bedarf Alternativen zu der Funktion vorzuschlagen und vermeidet somit die zu frühe Festlegung auf Lösungsdetails.

Das Gleiche kann man gemäß Ivar Jacobson natürlich auch Form von Use Cases darstellen, mit einem Strichmännchen als Auslöser (Actor) und der Prozessbezeichnung in der Ellipse, die diesen Use Case repräsentiert (Abb. 3).

Abb. 3: Use-Case-Diagramm als Überblick über funktionale Anforderungen

Mehr Details zu den Prozessen

Viele gefundene Prozesse sind sicherlich noch zu vage, zu abstrakt, um schon Klarheit über die funktionalen Anforderungen zu haben. Wenn Sie entschieden haben, was zuerst implementiert werden soll, stehen Ihnen viele Ausdruckmöglichkeiten zur Verfügung, um die funktionalen Details zu spezifizieren. Sie können den Prozess mit Aktivitätsdiagrammen, Datenflussdiagrammen, BPMN, Ereignisprozessketten, Szenarien, kleiner geschnittenen Storys u. v. a. m. weiter präzisieren. Beispiele zu vielen Notationen finden Sie in [2].

Empfehlungen

  • Nutzen Sie „große Prozesse“ als Ansatz zur Strukturierung der Requirements Ihres Systems. Diese sind unabhängig voneinander, wegen der externen Trigger für irgendjemanden in der Systemumgebung wertvoll und können somit unabhängig voneinander implementiert werden.
  • Warten Sie noch ein oder zwei Folgen der Kolumne ab – weil wir Ihnen aus dem Domain-driven Design noch einige Patterns zum besseren Verständnis funktionaler Anforderungen vorstellen werden (und Sie dann die so genannten Bounded Contexts zur Strukturierung Ihres Systems heranziehen können).
  • Streben Sie anfangs mehr nach Überblick über die Gesamtfunktionalität als nach zu vielen Details – auch wenn die Nutzer versucht sind, Ihnen viele Details zu erzählen.

Fazit

Mit dem sauberen Start (Scope und Kontext) haben wir für unser System die Außenschnittstellen klar definiert. Jetzt kommen die wesentlichen funktionalen Anforderungen hinzu – wobei Sie in dieser Folge die Ende-zu-Ende-Prozesse und einige Möglichkeiten zur Beschreibung von Funktionen (Stories und Use Cases) kennen gelernt haben. Im Grunde können Sie jetzt mit Architekturarbeit loslegen. In der nächsten Folge stellen wir die anforderungsbezogenen Teile von Domain-driven Design vor, die uns bei komplexer Fachlichkeit sehr helfen können. Bis dahin alles Gute.

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: