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.

Der Beitrag Anforderungsaspekte: Was, Wie und Wie lange? erschien zuerst auf INDAL Software-Spezialist.

Es gibt eben nicht nur funktionale Anforderungen, es gibt eine ganze Reihe weiterer Annahmen der Benutzer hinsichtlich von Leistungsmerkmalen des Systems, deren Realisierung unabdingbare Voraussetzung für die erfolgreiche Produktivsetzung einer Lösung ist. Dazu gehören Bedienerfreundlichkeit, Performance, Sicherheitsaspekte und andere.

Schon der Name des Dokumentes, in dem die Anforderungen spezifiziert werden, zeigt, dass in vielen Unternehmen fast ausschließlich funktionale Anforderungen spezifiziert und zur Grundlage von Erstellungsverträgen gemacht werden: von Funktionalen Spezifikationen ist da die Rede oder von Funktionalem Systemdesign.

Dem Anbieter ist dann kein Vorwurf zu machen, wenn er sein Angebot so kalkuliert, dass funktionale Anforderungen umgesetzt werden und andere Aspekte niedrig priorisiert werden.

Um alle Anforderungen zu berücksichtigen,die den Projekterfolg beeinflussen, sollte man sich einen allgemeinen Anforderungskatalog aufbauen. Jedes Unternehmen, welches oft IT-Projekte umsetzt, sollte ein Anforderungsglossar pflegen, in dem die verschiedenen Anforderungsklassen klar definiert und gegeneinander abgegrenzt sind (wenden Sie sich an den Autor dieses Artikels, wenn Sie ein Grundschema für einen solchen Katalog benötigen).

Auf der Basis eines solchen Glossars können dann für ein konkretes Projekt einfach die relevanten Anforderungsklassen abgeleitet und priorisiert werden. Das Dokument, in dem die Anforderungen spezifiziert werden, sollte in seinem Aufbau den Anforderungsklassen entsprechend ihrer Priorität folgen.

Der Beitrag Anforderungen und Akzeptanz erschien zuerst auf INDAL Software-Spezialist.