Nonfunktionale Anforderungen
Nonfunktionale Anforderungen an ein IT-System sind die Anforderungen, die sich nicht direkt auf die Funktionalität beziehen. Während eine funktionale Anforderung zum Beispiel besagt, dass man Artikel in einem Online Shop verkaufen möchte, können nonfunktionale Anforderungen bei gleicher Funktionalität zu komplett unterschiedlichen Systemen führen: Ein Online Shop mit 100 Artikeln für monatlich 1000 Nutzer ist ein komplett anderes System als ein Online Shop mit 100.000 Artikeln für monatlich 10 Millionen Nutzer. Aus diesem Grund ist es für die Erstellung einer Architektur immer enorm wichtig, die nonfunktionalen Anforderungen an ein System zu kennen.
Arten
Nonfunktionale Anforderungen können sich auf organisatorische Dinge beziehen, wie zum Beispiel: Die Erreichbarkeit einer Support-Hotline zu dem System muss werktäglich von 8-18 Uhr gesichert sein. Es kann sich um regulatorische Anforderungen handeln, wie: Alle Datenspeicher müssen physikalisch entsprechend der DSGVO vollständig in Deutschland liegen. Oder es können technische Anforderungen, bzw. Qualitätsmerkmale sein, wie: Der Online Shop muss mit 100.000 Artikeln und 10 Millionen monatlichen Nutzern umgehen können.
Während es für organisatorische oder regulatorische Anforderungen kein Rahmenwerk gibt, sind die Qualitätsmerkmale in den beiden Normen ISO9126 (alt) und ISO25010 (neu) standardisiert. Die Normen sind ein guter Ausgangspunkt um die nonfunktionalen Anforderungen für die eigenen Systeme zu spezifizieren.
ISO 9126
Wie im obigen Bild gezeigt, definiert die Norm folgende Qualitätsmerkmale:
| Wartbarkeit | Benutzbarkeit | Effizienz |
|---|---|---|
| Analysierbarkeit | Attraktivität | Zeitverhalten |
| Modifizierbarkeit | Bedienbarkeit | Verbrauchsverhalten |
| Stabilität | Erlernbarkeit | |
| Testbarkeit | Verständlichkeit |
| Funktionalität | Übertragbarkeit | Zuverlässigkeit |
|---|---|---|
| Angemessenheit | Anpassbarkeit | Fehlertoleranz |
| Sicherheit | Austauschbarkeit | Reife |
| Interoperabilität | Installierbarkeit | Wiederherstellbarkeit |
| Ordnungsmäßigkeit | Koexistenz | |
| Richtigkeit |
Diese Qualitätskriterien können herangezogen werden, um einen eigenen Katalog von Kriterien für das eigene Projekt aufzustellen. Dabei spielen oftmals nicht alle Qualitätskriterien eine Rolle. Wenn zum Beispiel eine Software explizit für eine besondere Hardware erstellt wird, dann ist die Übertragbarkeit unwichtig. Andererseits können auch Kriterien eine Rolle spielen, die man nicht sofort im Sinn hat: Für eine Kommandozeilenanwendung kann auch die Benutzbarkeit und Attraktivität eine Rolle spielen, denn auch eine CLI kann deutlich benutzbarer sein, wenn sie gut gestaltet ist.
ISO 25010
Die ISO 25010 ist die Weiterentwicklung der ISO 9126. Sie sagt im Großen und Ganzen dasselbe aus, ordnet die Qualitätskriterien aber in 8 statt 6 Hauptkriterien.
| Wartbarkeit | Benutzbarkeit | Leistungsfähigkeit | Austauschbarkeit |
|---|---|---|---|
| Modularität | Erlernbarkeit | Zeitverhalten | Ko-Existenz |
| Wiederverwendbarkeit | Wiedererkennbarkeit | Ressourcennutzung | Interoperabilität |
| Analysierbarkeit | Betreibbarkeit | Kapazität | |
| Änderbarkeit | Fehlertoleranz | ||
| Testbarkeit | Attraktivität | ||
| Zugänglichkeit |
| Funktionalität | Übertragbarkeit | Zuverlässigkeit | Sicherheit |
|---|---|---|---|
| Vollständigkeit | Installierbarkeit | Reifegrad | Vertraulichkeit |
| Richtigkeit | Ersetzbarkeit | Verfügbarkeit | Integrität |
| Angemessenheit | Anpassbarkeit | Wiederherstellbarkeit | Manipulationschutz |
| Fehlertoleranz | Nachvollziehbarkeit | ||
| Authentizität |
In der neueren ISO 25010 ist die Austauschbarkeit als Teilkriterium der Übertragbarkeit zu einem Hauptkriterium geworden. Die Effizienz heißt jetzt Leistungsfähigkeit (engl. Performance) und ist um die Ressourcennutzung erweitert worden. Die Sicherheit ist aus der reinen Funktionalität herausgewandert und bildet jetzt ebenfalls ein eigenes Hauptkriterium.
Ausprägungen und Metriken
Es genügt in keinem Projekt, einfach nur die Qualitätsmerkmale als Anforderung zu definieren, also zum Beispiel:
- Das System muss eine hohe Kapazität haben
Die Qualitätsmerkmale müssen ausgeprägt und mit Metriken spezifiziert werden, ansonsten sind sie bedeutungslos. Die Merkmalsausprägungen definieren, was ein Qualitätsmerkmal im konkreten Projektkontext bedeutet und die Metriken machen das Merkmal messbar. Für jedes Qualitätsmerkmal, das in den Anforderungen für ein System oder Projekt gesetzt wird, müssen diese Metriken ausgeprägt werden. Dabei ist zu beachten, dass die Metriken jederzeit mess- und/oder überprüfbar sind.
In der Praxis bietet sich dafür eine Tabelle mit den Qualitätsmerkmalen, ihren Ausprägungen und den zugehörigen Metriken an. Zum Beispiel:
| Qualitätsmerkmal | Ausprägung | Metrik |
|---|---|---|
| Funktionalität: Vollständigkeit | Alle Anforderungen sind im System umgesetzt | Es existiert eine Dokumentation, die zeigt, welche Anforderung von welchem Modul umgesetzt ist. |
| Wartbarkeit: Testbarkeit | Das System muss vollständig per Unittests getestet sein | Für jedes Modul existiert ein geeigneter, automatisch ausführbarer Unittest. Die Testabdeckung des Codes muss bei 100% liegen. |
| Zuverlässigkeit: Verfügbarkeit | Die Anwendung muss hochverfügbar sein | Für die Gesamtanwendung muss eine Verfügbarkeit von 99,95% im Jahresmittel bei einer Betriebszeit von 24 Stunden pro Tag einschließlich Wartungsfenstern gewährleistet sein. |
| … | … | … |
Für das eigene Unternehmen oder den eigenen Bereich bietet es sich an, einen Standardsatz von Qualitätsmerkmalen mit entsprechenden Metriken zu definieren, die dann übergreifend für alle Projekte gelten und dort nicht immer neu definiert werden müssen, z.B.:
- Kapazität: Alle Systeme müssen für 10 Millionen Nutzeranmeldungen pro Monat ausgelegt sein
- Zeitverhalten: Die Zeit für einen Anmeldevorgang darf in 99% der Fälle 50ms nicht überschreiten
- Verfügbarkeit: Die Verfügbarkeit einer Anwendung muss 99,95% im Jahresmittel einschließlich geplanter Downtimes betragen
Fazit
Die nonfunktionalen Anforderungen, egal ob es sich um organisatorische, regulatorische oder technische Anforderungen handelt, müssen in jedem Projekt beachtet werden. Auch in agilen Projekten spielen sie eine große Rolle - gleichwohl sie hier nicht zu Projektbeginn vollständig definiert sein müssen. Sie entwickeln sich genau wie die Funktionalitäten einer Anwendung mit jeder Iteration weiter. Erfahrene Architekten sollten ein Gespür dafür entwickeln, welche Anforderungen sich im Nachhinein als schwer revidierbar herausstellen und eben diese so früh wie möglich im Projekt festzurren.