Ein neues Anforderungsmodell

Anforderungen sind sowohl in der Geschäftsarchitektur wie auch in der Servicearchitektur von zentraler Bedeutung für den Erfolg einer Unternehmung. Dennoch verstehen nicht alle unter einer Anforderung dasselbe, und diese Missverständnisse können in der Planung und Ausführung zu Risiken führen. In diesem Beitrag geht es um die Definition der Anforderung an sich, und nur am Rande um die Prozesse des Anforderungsmanagements.

Chris Rupp und Klaus Pohl übernehmen in ihrem Buch Basiswissen Requirements Engineering die Definition der Anforderung, so wie sie von der IEEE im September 1990 beschrieben wurde. Demnach ist eine Anforderung entweder etwas was ein Benutzer benötigt um ein Bedürfnis erfüllen zu können, oder etwas was das System können muss um einen Vertrag zu erfüllen (beispielsweise eine gesetzliche Vorgabe). Für viele Professionals im Software Engineering ist eine Anforderung heute eine Zeile in einem Spreadsheet, die sie inhaltlich leider nicht ganz verstehen. Wie konnte es nur soweit kommen, denn die Definition von 1990 erwähnt doch gar kein Excel?

ieee1990.png
Definition der Anforderung von 1990.

Eine Ursache ist hier die notwendige Kontextualisierung der Methode des Anforderungsmanagements, die nicht durchgeführt wird. Die Masschneiderung der Ermittlung, Dokumentation, Prüfung, Abstimmung und Verwaltung von Anforderungen in der Organisation wird nicht ausreichend im Kontext der Organisation geplant. Häufig kommt ein Spreadsheet zum Einsatz, weil das im Projekt vorher auch so gemacht wurde, und in vielen Fällen ist der physische Austausch per Email der kleinste gemeinsame Nenner der eingesetzten Kollaborationswerkzeuge. Seltener wird nach einem Projekt hinterfragt, wie gut diese Liste am Ende wirklich funktioniert hat.

Ein weiterer Punk ist, dass die Definition von 1990 zwar völlig richtig und umfassend ist, jedoch keine konkreten Aussagen über den Inhalt oder die Struktur einer Anforderung macht. Nach fast dreissig Jahren Praxis im Anforderungsmanagement, zahlreichen Erkenntnissen in der Geschäftsanalyse und der Erfindung der BPMN, die die Best Practices eines gesamten Berufszweigs sprichwörtlich formalisiert, ist es nun vielleicht an der Zeit diese Erkenntnisse in eine neue Definition zu übersetzen, die auch in meinem Buch im August veröffentlicht wird:

Eine Anforderung besteht aus Ereignissen, Prozessen, Regeln und Daten.

Ein identisches Verständnis des Metamodells dieser Definition ist im Projekt genauso zentral wie das Verständnis der Anforderungen an sich, weswegen es im Team besprochen werden sollte. Wie immer ist die Sprache dabei eines der wichtigsten Werkzeuge: wir nutzen unsere natürlichen sprachlichen Fähigkeiten um zu einer guten Lösung zu kommen.

Domänenereignisse

Ereignisse, auch Domänenereignisse oder Geschäftsereignisse genannt, werden von Akteuren ausgelöst und verursachen vielfältigste Reaktionen im System. Ein Ereignis kann ein Timer, ein Signal, eine Anfrage oder irgend eine andere Begebenheit in der Domäne sein, beispielsweise der Wunsch nach einem Versicherungsabschluss. Nicht jedes Ereignis erwartet eine Antwort, einige aber schon, und alle lösen einen Prozess aus. Wenn ein Ereignis keinen Prozess auslöst können wir es ignorieren.

Die erste Iteration zur Ermittlung der Ereignisse ist die Erfassung im Rahmen von User Journeys, eines Kontextdiagramms, oder eines sogenannten Event Storming. Hier treffen sich die wesentlichen Stakeholder zum Brainstorming und dokumentieren im Team mögliche Ereignisse. Wie bei den anderen Methoden der Softwareentwicklung auch, ist die Ermittlung der Ereignisse ein iterativer Prozess. Nach und nach entdeckt das Team weitere Ereignisse und nimmt diese auf. Damit das besonders gut funktionieren kann, ist eine Atmosphäre des Lernens und Entdeckens zu fördern.

Geschäftsprozesse

Die Domänenereignisse lösen Prozesse aus, die in der Unternehmung abgebildet werden und werden häufig als Anwendungsfall dokumentiert. Ein solcher Geschäftsprozess beschreibt das Geschäft einer Organisation als Verknüpfung von Funktionen und kann mithilfe der BPMN formalisiert werden. Die grafische Visualisierung eines Prozesses ist vielen Stakeholdern eine grosse Hilfe beim Verständnis. Das Verständnis von Anforderungen im Team ist wiederum ein Qualitätskriterium unser Anforderungen.

Ein Prozess kann aus einer einzigen Funktion bestehen, aber das ist meiner Erfahrung nach sehr selten. Bei der Modellierung der Prozesse gilt es ausserdem darauf zu achten, dass keine Verallgemeinerungen und Ungenauigkeiten durch Vermischung entstehen. So sollte jeder Prozess sein eigenes BPMN Diagramm haben, und nicht mehrere Prozesse ein Diagramm teilen, selbst wenn die Prozesse in grossen Teilen identisch sind, ist das doch für den Leser schwer zu verstehen. Und die Aufgabe ist nicht, effizient bei der Diagrammerstellung zu sein, sondern Inhalte zu kommunizieren, damit das ganze Team die Anforderungen verstehen kann.

Wird ein und dasselbe Diagramm für mehrerer Prozesse verwendet, so kann dies auch ein Hinweis auf einen falschen Schnitt von Anforderungen sein. Prozesse können in Subprozesse zerlegt werden, damit sie begreifbarer werden, oder um Wiederverwendung zu erlauben.

Geschäftsregeln

Die Funktionen eines Prozesses werden von Regeln bestimmt, die die Berechnung der Funktion steuern. In vielen Fällen sind diese Regeln datenbasiert. So benötigt die Preiskalkulation den Vertrag, den Sie mit Ihrem Kunden geschlossen haben, und einen Mehrwertsteuersatz. In einigen Fällen wird eine Regel durch einen anderen Geschäftsprozess berechnet. Die Regeln binden Ihre Prozesse also zusammen.

Geschäftsregeln und Subprozesse lassen sich wiederverwenden. Beispielsweise wird die Berechnung der Mehrwertsteuer von vielen Prozessen benötigt. So kommt es, dass Geschäftsregeln manchmal zu dedizierten Services in der Organisation werden, die dann von verschiedenen Geschäftsprozessen konsumiert werden können.

Diese Dekomposition ist Teil des domänengetriebenen Entwurfs, der unsere Anforderungen nach Domäne in sogenannte Aggregate strukturiert. Ein Aggregat ist ein technisches Konstrukt, dass Daten und Funktion innerhalb einer Transaktionsgrenze zusammenfasst. Die korrekte Erfassung der Anforderungen sorgt bei diesem Vorgehen also für transaktionale Integrität im System, und ist dem Architekten damit eine grosse Hilfe.

Fazit

Wenn man unter einer Anforderung die Kombination von Ereignissen, Prozessen, Regeln und Daten versteht, so wird schnell klar, dass sie nicht in einem Spreadsheet dokumentiert werden können. Hilfreich bei der Dokumentation von Anforderungen ist demnach ein Wiki, dass eine freie Strukturierung von Prozessen und Regeln nach Domänen erlaubt, sowie ein Service für die Erstellung von Diagrammen. Da wir möchten, dass beide Dienste von möglichst vielen Personen im Team mit Enthusiasmus genutzt werden, wählen wir nur Werkzeuge mit hoher Bedienbarkeit, die möglichst wenig Hürden bei der Benutzung aufbauen (lassen), und die orts- und geräteunabhängig eingesetzt werden können.

Kommentar verfassen