NFA statt NSA – die geheimen Anforderungen des RE

Der wohl größte Konsens im Requirements Engineering liegt wahrscheinlich im einstimmigen Bekenntnis zur Existenz funktionaler Anforderungen. Auch wenn sich hinsichtlich Definition und Auslegung leichte Unterschiede auftun, scheint ein relativ geeintes Verständnis von der Bedeutung einer funktionalen Anforderung zu existieren. Eine solche wird allgemein als Beschreibung eines fachlichen, oft domänenspezifischen Ablaufs verstanden. Darunter fallen, vereinfacht gesagt, alle Aktivitäten, bei denen ein zu entwickelndes System etwas tun bzw. handeln muss. Am Schluss dieser Aktivität wird für gewöhnlich ein Zustand erreicht, der sich vom Ausgangszustand der Aktivität unterscheidet (z.B. hat sich konkret ein bestimmter Wert erhöht oder ein Nutzer hat vom System eine Nachricht erhalten).

Weit weniger einheitlich verhält es sich mit den restlichen Anforderungen, die nicht zur Kategorie der funktionalen Anforderungen zählen. Der Begriff „nichtfunktionale Anforderung“, häufig einfach NfA abgekürzt, stellt eine eher still getroffene Übereinkunft dar, als einen gültigen Standard. So enthält die ISO/IEC25010 des verbreiteten SquaRE-Standards gar keine nichtfunktionalen Anforderungen und der IREB (International Requirements Engineering Board) erwähnt sie offiziell auch nicht.

Obwohl im Grunde jeder den Begriff verwendet und ihn auch zu deuten weiß, bedeutet der offizielle Umgang in der Realität eine Zergliederung der eigentlichen Kategorie „NfA“ in Stellvertreterkategorien, anstatt sie auf gleicher Höhe mit den funktionalen Anforderungen zu stellen. Die Kategorienbildung erfolgt dabei einer durchaus sinnvollen Logik: IREB unterteilt neben den funktionalen Anforderungen in Qualitätsanforderungen und Randbedingungen. SQuaRE handelt auf gleicher Ebene etwas detailverliebter und entwirft neben der Kategorie der Qualitätsanforderungen zusätzliche Kategorien für Prozessanforderungen und organisatorische Anforderungen. Die anfängliche Oberflächlichkeit in der Systematik des IREB kann man allerdings verschmerzen, denn über die Bildung von Subkategorien eine Ebene darunter ist man bequem in der Lage, noch fehlende Kategorien von Anforderungen in tiefere „Schubladen“ zu packen.

Am Ende bleibt bei nahezu allen Standardisierungen, ob nun ISO, IREB, IEEE oder anderen Quellen, eine mehrstöckige aber überschaubare Taxonomie von Anforderungskategorien. Die Suche nach den mysteriösen nichtfunktionalen Anforderungen endet also direkt vor den Schubladensystemen diverser Requirements Engineering Standards, denn dann hat man sie bereits gefunden. Ein großer Teil der dort gelisteten Kategorien findet sich übergreifend in anderen Standards wieder. Da jeder solcher Standards dennoch seinen individuellen Schwerpunkt hat, lohnt sich der Blick in Dokumente anderer Standards durchaus.

Sind die NfAs gefunden und die notwendigen Kategorien identifiziert, wartet die eigentliche Schwierigkeit erst im Projektalltag. Eine sinnvolle Abgrenzung zwischen einer funktionalen und einer nichtfunktionalen Anforderungen ist je nach Situation und Kontext nicht immer einfach. Eine bewährte und einfache Unterscheidungshilfe ist die Betrachtung einer nichtfunktionalen Anforderung als Eigenschaft eines zu entwickelnden Systems. Während funktionale Anforderungen, wie oben dargestellt, klar definierte Abläufe beschreiben (z.B. hat jeder Ablauf einen klaren Anfang und ein eindeutiges Ende), bei dem meist ein Nutzer von Außen mit dem System interagiert, bleiben die Eigenschaften des Systems normalerweise unverändert. Ähnlich wie Charaktereigenschaften eines Menschen sind Systemeigenschaften beständig und zeitlich nicht eingeschränkt.

Die Unterscheidung liegt also vor allem auf den Aspekten Dynamik und Statik: NfAs beschreiben die überdauernden, strukturellen Eigenschaften eines Systems, funktionale Anforderungen kapseln die dynamischen Aspekte wie Funktionen, Abläufe, Zustandswechsel etc., bei denen am Ende ein definiertes Ziel erreicht wird. Auf diese Weise können wir allein über die Auswahl des Anforderungstyps zwei unterschiedliche Perspektiven auf ein und dasselbe System einnehmen und die Systemfeatures getrennt von seiner Struktur bzw. Architektur behandeln.

Diesen Blogbeitrag hat Christian Wünsch für HOOD geschrieben.