Vor einigen Tagen hatte ich darüber geschrieben, dass die Trennung von funktionalen und nicht-funktionalen Anforderungen eigentlich problematisch ist. Diesem Gedanken möchte ich noch einmal nachgehen:
Ein Beispiel:
„Berichte in der Anwendung sollen innerhalb von 30 Sekunden bereitgestellt werden“
Ist das eine funktionale oder eine nicht-funktionale Anforderung? Viele werden argumentieren, dass dies eine nicht-funktionale Anforderung ist, da der Satz etwas über das „Wie“ der Leistungserfüllung aussagt. Aber dass die Anwendung „Berichte bereitstellen“ soll, ist eine funktionale Anforderung, und wenn die Berichte typischerweise erst ein Tag nach dem Aufruf des entsprechenden Menüpunktes bereitgestellt werden, dann ist das keine Funktionserfüllung, auch wenn alle Zahlen im Bericht korrekt sind.
Ein neuer Ansatz ist, zu sagen, dass jede Anforderung sowohl Aussagen zu der Frage, was umgesetzt werden soll als auch zu der Frage, wie es umgesetzt werden soll enthält. Anforderungen lassen sich dann generalisieren und spezialisieren, wie wir es aus der objektorientierten Sichtweise kennen.
Können wir damit die Anforderungen, die wir bisher in funktionale und nicht-funktionale unterschieden haben, komplett abbilden? Nicht ganz, ein Aspekt fehlt noch, es ist der der zeitlichen Veränderbarkeit der Anforderung. Ist zu erwarten, dass ein Bericht sich ändert, wenn ja, wie oft? Werden Datenmengen wachsen? Wird die Anforderung auch unter geänderten Bedingungen, z.B. bei neuen Infrastrukturen und Plattformen, bestehen bleiben? Dieser dynamische Aspekt von Anforderungen wird oft vernachlässigt, aber wenn wir ihn mit einbeziehen, dann haben wir quasi alles was wir brauchen, um eine gute Architektur zu entwerfen.
Dazu legen wir uns wie gesagt eine Anforderungs-Hierarchie an, eine Vererbungs-Struktur. Die Basis-Anforderungen sind das Fundament, sowohl für die abgeleiteten Anforderungen als auch für den Architektur-Entwurf der Software. Umso spezieller die Anforderungen werden, desto geringer ist ihr Einfluss auf die Architektur.