Vergessen Sie nicht zu entscheiden, „wie viele Sekunden schnell genug sind“ ── Nichtfunktionale Anforderungen mit IPAs Non-Functional Requirements Grade ordnen

„Man hat uns gesagt, die Bildschirmübergänge seien zu langsam, doch weder im Vertrag noch im Lastenheft steht eine Vereinbarung zur Antwortzeit.“

„Der nächtliche Batch-Job war nicht mehr vor dem Morgen fertig, doch niemand hatte je geschätzt, wie stark die Datenmenge über die Jahre wachsen würde.“

„Erst nachdem ein Serverausfall das System für einen halben Tag lahmgelegt hatte, wurde uns klar, dass niemand bei der Bestellung geklärt hatte, innerhalb wie vieler Stunden die Konfiguration tatsächlich wiederherstellen sollte.“

Denkt man an Ärger bei der Systementwicklung, kommt einem meist eine Diskrepanz bei der Funktionalität in den Sinn, doch die Streitigkeiten, die tatsächlich aufflammen, sobald der Betrieb beginnt, sind recht häufig das Ergebnis, dass man vergessen hat, diese nichtfunktionalen Anforderungen festzulegen – die Anforderungen, die überhaupt nichts mit Funktion zu tun haben.

Das öffentliche Werkzeug, das genau solche Versäumnisse verhindern soll, ist der Non-Functional Requirements Grade der IPA (Information-technology Promotion Agency, einer unabhängigen Verwaltungsinstitution). Dieser Artikel legt dar, was tatsächlich darin steht, und einen realistischen Ansatz zur Nutzung für das Geschäftssystem eines KMU, in einer Sprache, der auch ein Auftraggeber folgen kann.

1. Das Wichtigste zuerst

• Nichtfunktionale Anforderungen betreffen nicht „was das System tut“ – sondern „wie gut und unter welchen Bedingungen es arbeitet.“ Sie lassen sich in sechs Bereiche gliedern: Verfügbarkeit, Leistung, Betriebsführung, Migration, Sicherheit und Installationsumgebung.
• Der Non-Functional Requirements Grade ist ein (kostenloses) Werkzeugset der IPA, das die Anforderungspunkte in diesen sechs Bereichen erschöpfend auflistet und es Auftraggebern und Entwicklern ermöglicht, sich auf stufenweisen Niveaus abzustimmen.
• Sie müssen nicht jeden Punkt ausfüllen. Die vorgesehene Nutzung ist, zunächst das dem eigenen System am nächsten liegende „Modellsystem“ zu wählen und dann zuerst die wichtigen Punkte an die realen Umstände anzupassen.
• Je höher Sie ein nichtfunktionales Niveau ansetzen, desto teurer wird es. Wählen Sie das Niveau nicht durch „vage einen hohen Standard fordern“, sondern rückwärts von der Auswirkung auf Ihr Geschäft aus.
• Halten Sie die Entscheidungen im Anforderungsdefinitionsdokument fest. Die dort fixierten Annahmen sind es, die einen fairen Angebotsvergleich ermöglichen und „er-sagte-sie-sagte“-Streitigkeiten im laufenden Betrieb verhindern.

2. Was nichtfunktionale Anforderungen sind – Was zwischen „es läuft“ und „es ist nutzbar“ liegt

Funktionale Anforderungen sind Dinge wie „kann einen Auftrag registrieren“ oder „kann einen Bericht drucken“ – Anforderungen dazu, was das System tut. Entwicklungsbesprechungen neigen naturgemäß zu dieser Art von Diskussion.

Fragen wie die folgenden tauchen dagegen nie auf einer Funktionsliste auf.

• Zu welchen Zeiten muss dieses System verfügbar sein? Wie sieht es am Wochenende aus? Während des nächtlichen Batch-Jobs?
• Fällt es aus, innerhalb wie vieler Stunden muss es wiederhergestellt sein, bevor der Geschäftsbetrieb stillsteht? Wie weit dürfen die wiederhergestellten Daten zurückliegen?
• Wie viele Personen nutzen es gleichzeitig, und wie viele Transaktionen verarbeitet es pro Tag? Um wie viel wird die Datenmenge in fünf Jahren gewachsen sein?
• Wer überwacht es, erstellt Backups und erhält die erste Meldung eines Ausfalls?
• Wie viel der Daten des alten Systems wird ins neue übernommen?

Das sind die nichtfunktionalen Anforderungen. Was sie tückisch macht, ist, dass das System mehr oder weniger „läuft“, selbst wenn Sie keine davon festlegen. Das Problem zeigt sich erst, sobald der Betrieb beginnt, die Last wächst und tatsächlich ein Ausfall eintritt – und zu diesem Zeitpunkt kostet die Behebung viel, weil sie die Grundlagen der Serverkonfiguration und des Designs berührt.

3. Was der Non-Functional Requirements Grade ist

Der Non-Functional Requirements Grade ist ein Werkzeugset, das die IPA mit dem Ziel veröffentlicht, zu verhindern, dass Auftraggeber und Entwickler bei nichtfunktionalen Anforderungen aneinander vorbeireden. Die erste Version erschien im April 2010, und die aktuelle neueste Version, die Änderungen im Bereich Sicherheit und Virtualisierung (Cloud) berücksichtigt, ist „Non-Functional Requirements Grade 2018“, veröffentlicht im April 2018. Sie liegt inzwischen auf einer archivierten Seite der IPA-Website, ist aber weiterhin das in der Praxis verwendete Standardwerk, um zu prüfen, dass keine nichtfunktionale Anforderung durchs Raster gefallen ist.

Es besteht aus folgendem Werkzeugset.

Jede Kennzahl hat einen definierten Satz stufenweiser Niveaus zur Auswahl, wodurch sich eine Anforderung als Niveauwahl ausdrücken lässt, statt als vages Wort wie „hoch“ oder „niedrig.“

Die drei Modellsysteme

Ein weiteres Merkmal sind die drei Modellsysteme, unterteilt danach, wie groß die gesellschaftliche Auswirkung eines Ausfalls des Systems wäre.

• Systeme mit nahezu keiner gesellschaftlichen Auswirkung
• Systeme mit begrenzter gesellschaftlicher Auswirkung (etwa die Kerngeschäftssysteme eines Unternehmens)
• Systeme mit äußerst großer gesellschaftlicher Auswirkung (etwa gesellschaftliche Infrastruktur)

In der Grade-Tabelle ist für jedes Modell bereits ein Basisniveau eingetragen. Mit anderen Worten: Statt die Diskussion bei null zu beginnen, können Sie zunächst feststellen „wir sind diesem Modell am nächsten“ und die Niveaus dann nach oben oder unten an Ihre eigenen Umstände anpassen.

4. Die sechs Hauptkategorien – In die Sprache des Auftraggebers übersetzt

Umformuliert als Fragen, die ein Auftraggeber tatsächlich beantworten kann, sehen die sechs Hauptkategorien des Non-Functional Requirements Grade so aus.

So betrachtet wird klar, dass die meisten der sechs Hauptkategorien geschäftliche und keine technischen Fragen sind. Wer beantworten kann, „was passiert, wenn der Monatsabschlusslauf um einen halben Tag verzögert wird“, ist der Auftraggeber, nicht das Entwicklungsunternehmen. Die Initiative bei nichtfunktionalen Anforderungen liegt tatsächlich beim Auftraggeber.

5. Ein realistischer Nutzungsansatz – Versuchen Sie nicht, alle 238 Punkte auszufüllen

Die Punkteliste umfasst 238 Kennzahlen, doch jede einzelne zu besprechen ist für ein KMU-Projekt nicht realistisch, und auch der Nutzungsleitfaden geht nicht von dieser Nutzung aus. Der vorgesehene Ablauf sieht so aus.

1. Ein Modellsystem wählen
   (welchem Auswirkungsniveau kommt Ihr System am nächsten?)
        ↓
2. Für die wichtigen Punkte in der Grade-Tabelle
   vom Basisniveau des Modells auf die eigenen Umstände anpassen
        ↓
3. Nur für die Teile, die es brauchen, in die Punkteliste vertiefen

Für die Geschäftsanwendung eines KMU liefert bereits Schritt 2 – die Abstimmung der wichtigen Punkte – erheblichen Nutzen. Nach meiner Erfahrung empfehle ich, während der Anforderungsdefinition mindestens die folgenden Punkte zu dokumentieren.

• Betriebszeiten und die geschäftliche Auswirkung, falls das System ausfällt (Verfügbarkeit)
• Das Backup-Intervall sowie im Fehlerfall „bis zu welchem Zeitpunkt Daten wiederhergestellt werden“ und „innerhalb wie vieler Stunden“ (Verfügbarkeit / Betriebsführung)
• Die aktuelle Datenmenge/Datensatzanzahl und die Prognose für einige Jahre voraus (Leistung / Skalierbarkeit)
• Zielwerte für Antwortzeit und Batch-Verarbeitungszeit. Selbst „mindestens so schnell wie das aktuelle System“ ist in Ordnung, solange eine Basis gesetzt wird (Leistung)
• Wer für Überwachung, Backups und Erstreaktion bei einem Ausfall zuständig ist (Betriebsführung / Wartbarkeit)

Was hier nicht vergessen werden darf, ist der Zielkonflikt zwischen Niveau und Kosten. Streben Sie beispielsweise „ein System, das absolut niemals ausfällt“ an, steigen die Kosten durch Server-Redundanz und Überwachungsinfrastruktur sprunghaft. Können Sie stattdessen beurteilen, dass „solange das Geschäft bis zum nächsten Morgen warten kann, eine Wiederherstellung bis Tagesende ausreicht“, können Sie dieses Budget anderswo einsetzen. Die richtige Art, die Niveaus des Non-Functional Requirements Grade zu handhaben, ist nicht als Werkzeug, um mehr zu fordern – sondern als gemeinsame Sprache, um die Balance zwischen geschäftlicher Auswirkung und Kosten zu diskutieren.

6. Das Verhältnis zu Verträgen und Angeboten

Nichtfunktionale Anforderungen verbinden sich auch unmittelbar mit dem Vertrag.

Zunächst der Angebotsvergleich. Holen Sie Angebote mehrerer Unternehmen ein, ohne sich über nichtfunktionale Annahmen abzustimmen, kalkuliert Unternehmen A möglicherweise eine redundante Konfiguration, während Unternehmen B einen einzelnen Server kalkuliert. Der Auftraggeber verliert die Fähigkeit zu unterscheiden, ob ein Preisunterschied eine unterschiedliche Konfiguration widerspiegelt oder nur eine allzu optimistische Kalkulation.

Als Nächstes kommen Abnahmetest und das Leben nach dem Livegang. Sind Antwortzeit und Backup-Regelungen schriftlich festgehalten, verwandelt sich ein Hin und Her aus „es ist langsam“ gegen „damit haben wir nicht gerechnet“ schlicht in eine Prüfung der Fakten gegen einen vereinbarten Standard.

Auch IPAs Musterhandelsgeschäft und -vertrag für Informationssysteme geht davon aus, dass nichtfunktionale Anforderungen als Ergebnis der Anforderungsdefinitionsphase dokumentiert werden. Der Non-Functional Requirements Grade fügt sich natürlich in einen mehrstufigen Vertragsablauf ein, bei dem die Anforderungsdefinition unter einer Geschäftsbesorgung erfolgt und die Entwicklung, sobald der Inhalt feststeht, unter einem Werkvertrag fortgesetzt wird. Mehr zu dieser Vertragsstruktur finden Sie in unserem Artikel zu IPAs Mustervertrag.

Zusammenfassung

Hier eine Rekapitulation der wichtigsten Punkte zu IPAs Non-Functional Requirements Grade.

• Nichtfunktionale Anforderungen betreffen, wie gut und unter welchen Bedingungen ein System arbeitet. Es läuft auch ohne diese festzulegen, doch die Lücken zeigen sich als Streitigkeiten, sobald es in Betrieb ist
• Der Non-Functional Requirements Grade ist IPAs kostenloses Werkzeugset zur stufenweisen Abstimmung von sechs Hauptkategorien – Verfügbarkeit, Leistung/Skalierbarkeit, Betriebsführung/Wartbarkeit, Migrierbarkeit, Sicherheit und Systemumgebung – über 238 Kennzahlen hinweg
• Beginnen Sie bei den Basisniveaus der drei Modellsysteme und passen Sie zuerst die wichtigen Punkte an. Sie müssen nicht jeden Punkt ausfüllen
• Der Inhalt der sechs Hauptkategorien besteht größtenteils aus geschäftlichen Fragen. Der Auftraggeber ist derjenige, der die Antworten hat
• Je höher das Niveau, desto höher die Kosten. Wählen Sie die Balance rückwärts von der geschäftlichen Auswirkung aus, und halten Sie das Ergebnis im Anforderungsdefinitionsdokument fest

Legen Sie vorab fest, „mit welcher Qualität es weiterlaufen muss“, ebenso wie „was gebaut werden soll.“ Das ist der günstigste Weg, sowohl ein System zu verhindern, das läuft, aber nicht nutzbar ist, als auch die daraus folgenden Streitigkeiten.

Wenn Sie Schwierigkeiten haben, die Anforderungen für ein Geschäftssystem zu ordnen

Nichtfunktionale Anforderungen abzustimmen erfordert ein Hin und Her zwischen der geschäftlichen Realität (Spitzenzeiten, Datenmenge, Auswirkung von Ausfallzeiten) und der Systemkonfiguration, die dies leisten muss.

Die Komura Software LLC arbeitet bei der Beratung zu Auftragsentwicklung oder Anpassung von Windows-Geschäftsanwendungen und Websystemen gemeinsam mit Auftraggebern daran, Leistung, Betrieb und Verhalten im Fehlerfall bereits in der Anforderungsphase zu ordnen, nach dem in diesem Artikel vorgestellten Gedanken. Wir sprechen gerne auch schon im Stadium von „unser aktuelles System wird allmählich langsamer“ oder „wir möchten unsere Betriebsabläufe im Zuge der Aktualisierung überdenken.“

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was sind nichtfunktionale Anforderungen?

Es sind Anforderungen dazu, wie gut und unter welchen Bedingungen ein System arbeitet, im Gegensatz zu funktionalen Anforderungen, die abdecken, was das System tut. Beispiele sind, wann das System verfügbar sein muss (Verfügbarkeit), wie viele gleichzeitige Nutzer es unterstützen muss und wie schnell es reagieren muss (Leistung und Skalierbarkeit), wer es wie betreibt und wartet (Betriebsführung und Wartbarkeit), wie Daten aus dem alten System übernommen werden (Migrierbarkeit), welchen Schutz es benötigt (Sicherheit) und in welcher Umgebung es installiert wird (Systemumgebung). Vergisst man, diese festzulegen, entsteht tendenziell ein System, das zwar läuft, aber nicht wirklich nutzbar ist.

Kann ich den Non-Functional Requirements Grade kostenlos nutzen? Wo bekomme ich ihn?

Ja, Sie können ihn kostenlos von der Website der IPA herunterladen. Er kommt als Set: eine Grade-Tabelle, eine Punkteliste, ein Baumdiagramm, ein Arbeitsblatt und ein Nutzungsleitfaden (in Erklärungs-, Nutzungs- und Anwendungsbänden). Die aktuelle Version ist „Non-Functional Requirements Grade 2018“, veröffentlicht im April 2018. Sie liegt inzwischen auf einer archivierten Seite der IPA-Website, wird in der Praxis aber weiterhin breit als Standard genutzt, um zu prüfen, dass keine nichtfunktionale Anforderung übersehen wurde.

Muss ich alle 238 Punkte festlegen?

Nein. Selbst der Nutzungsleitfaden geht nicht davon aus, dass Sie jede Kennzahl einzeln besprechen. Der dort dargelegte stufenweise Ansatz lautet: wählen Sie zunächst das Ihrem eigenen System am nächsten liegende Modellsystem, um eine Gesamtbasis festzulegen, passen Sie dann die wichtigen Punkte in der Grade-Tabelle an Ihre tatsächlichen Umstände an, und vertiefen Sie sich nur für die Teile, die es brauchen, in die Punkteliste. Für das Geschäftssystem eines KMU genügt bereits der Abgleich der wichtigen Punkte, um die meisten Streitigkeiten zu verhindern, die daraus entstehen, dass man etwas zu entscheiden vergessen hat.

Wann sollten nichtfunktionale Anforderungen festgelegt werden?

In der Phase der Anforderungsdefinition. Verfügbarkeits- und Leistungsziele berühren die Grundlagen der Serverkonfiguration und des Designs, weshalb eine Änderung, sobald die Entwicklung läuft, erhebliche Auswirkungen auf Kosten und Zeitplan hat. Auch IPAs Musterhandelsgeschäft und -vertrag für Informationssysteme geht davon aus, dass nicht nur funktionale, sondern auch nichtfunktionale Anforderungen als Ergebnis der Anforderungsdefinitionsphase dokumentiert werden. Stimmen Sie sich vor dem Angebotsvergleich nicht über nichtfunktionale Annahmen ab, können Sie nicht mehr unterscheiden, ob ein Preisunterschied eine unterschiedliche Konfiguration widerspiegelt oder nur eine allzu optimistische Kalkulation.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.