Funktioniert schon – außer wenn’s drauf ankommt

Pragmatisches Projektmanagement

Herzlich willkommen zu einer neuen Ausgabe vom Pragmatischen Projektmanagement, deiner Quelle für Informationen und Inspiration zu alltäglichen Herausforderungen im Management von Softwareentwicklungsprojekten. Dich erwarten Einblicke, Erfahrungen und unsere individuellen Ansichten zu Methoden, Werkzeugen, Vorgehensweisen und Fragen aus dem Leben eines Projektmanagers.

Gern diskutieren wir mit euch auf LinkedIn zu euren Erfahrungen und Ansichten.

Das Feature ist fertig, aber die Ladezeit liegt bei 12 Sekunden.
Wir deployen halt nachts, sonst bricht alles zusammen.
Ach, das mit der Sicherheit machen wir später.

Kommt dir bekannt vor? Willkommen im Niemandsland der Spezifikation – irgendwo zwischen „passt schon“ und „hätte man vorher wissen können“.

Was sind eigentlich nichtfunktionale Anforderungen?

Nichtfunktionale Anforderungen (NFAs) beschreiben nicht, was ein System tun soll – sondern wie gut es das tun soll. Als Referenz kann die ISO IEC 25010:2023 herangezogen werden.

Die Beschreibungen der Merkmale im Schaubild sind perfekt. Für einen Standard. Sie sind das Kondensat all der Dinge, die man versucht, auf generische Weise in einem Standard zu erfassen. Für die praktische Anwendung sind sie zu sperrig. Hier helfen am besten Beispiele. Lasst uns davon ausgehen, dass wir eine IIoT-Plattform zur Anbindung von Edge-Devices umsetzen wollen. Wie könnten dann Anforderungen für die einzelnen Bereiche formuliert sein?

✅ 1. Functional Suitability (Funktionale Eignung)

• Cloud: Die Plattform bietet eine REST-API zur Abfrage von Maschinenstatus.
• Edge: Das Gerät erkennt den Betriebsmodus automatisch (z. B. Produktion, Wartung) und sendet entsprechende Datenpunkte.

🔒 2. Reliability (Zuverlässigkeit)

• Cloud: Das System muss 99,9 % Verfügbarkeit im Monatsmittel gewährleisten. Wiederanlaufzeit bei Systemfehlern liegt bei ≤ 2 Minuten.
• Edge: Bei Stromausfall werden die letzten 10.000 Datenpunkte in einem persistenten Speicher gesichert und nach Neustart übertragen.

👁 3. Interaction Capability (Benutzbarkeit)

• Cloud: Neue Nutzer sollen die Funktion ‘Dashboard erstellen’ ohne Schulung in < 2 Minuten durchführen können (Usability-Test mit 5 Probanden).
• Edge: Die Einbindung von IO-Link Devices erfolgt per Plug-and-Play ohne zusätzliche Interaktion des Nutzers.

🦺 4. Safety (Betriebssicherheit)

• Cloud: Die IoT-Plattform wirkt sich nicht auf sicherheitskritische Funktionen aus, die dem Schutz von Leib und Leben dienen.
• Edge: Die Edge-Software übernimmt keine sicherheitsrelevanten Funktionen. Ihr Ausfall führt zu keinerlei Beeinträchtigung von Leib und Leben.

🔗 5. Compatibility (Kompatibilität)

• Cloud: Die Plattform empfängt Daten via REST und MQTT.
• Edge: Die Edge-Software kann sich mit PLCs verschiedener Hersteller verbinden, z. B. Siemens S7 und Beckhoff.

⚡ 6. Performance Efficiency (Leistungseffizienz)

• Cloud: Die Weboberfläche zeigt Live-Daten mit maximal 3 Sekunden Latenz, auch bei über 10.000 gleichzeitig verbundenen Geräten.
• Edge: Das Gateway verarbeitet bis zu 350 Sensordaten in Echtzeit mit < 100 ms Latenz, ohne dass die CPU-Auslastung über 70 % steigt.

🔃 7. Flexibility (Übertragbarkeit)

• Cloud: Die Plattform kann unter Nutzung eines beliebigen Hyperscalers oder im eigenen Rechenzentrum ausgerollt werden. Dabei ist die notwendige Infrastruktur via IaC zu beschreiben.
• Edge: Die Software läuft auf unterschiedlichen Edge-Geräten (z. B. Raspberry Pi, IPC). Die Geräte müssen Docker-Containerisierung unterstützen.

🛡 8. Security (Informationssicherheit)

• Cloud: Nutzerzugriffe erfolgen über OAuth2 mit Rollenmodell und 2-Faktor-Authentifizierung.
• Edge: Firmware-Updates sind nur digital signiert installierbar; Root-Zugriff auf das System ist gesperrt.

🔄 9. Maintainability (Wartbarkeit)

• Cloud: Die Codebasis ist modular aufgebaut, sodass einzelne Services unabhängig gewartet und ausgerollt werden können.
• Edge: Das Logging lässt sich in den Stufen Debug, Information, Warning, Error konfigurieren und zur Laufzeit ohne Neustart umstellen. Loggingdaten können sowohl lokal als auch remote abgerufen werden.

Das alles klingt trocken? Mag sein. Aber das hier entscheidet, ob dein Produkt am Ende glänzt oder strauchelt – besonders unter Last, unter Angriff oder unter realen Nutzungsbedingungen. Es stellt sich also die Frage, warum, wenn es doch so wichtig ist, NFAs so oft ignoriert oder nur am Rande behandelt werden.

Warum werden NFAs so oft ignoriert?

Aus meiner Sicht gibt es mindestens fünf einfache Gründe:

1. Sie sind nicht sexy. Kein Kunde ruft begeistert: „Wow, die Antwortzeit liegt unter 300 ms!“. Aber wehe, sie liegt drüber.

2. Sie sind schwer greifbar. Schnell, sicher, intuitiv – klingt gut, ist aber inhaltlich leer. Ohne konkrete Kriterien weiß niemand, was gemeint ist.

3. Sie zeigen sich erst spät. Performanceprobleme, Sicherheitslücken oder Wartungshöllen tauchen selten beim ersten Test auf – sondern im Live-Betrieb. Und dann ist es zu spät.

4. Sie werden implizit erwartet. Eure Nutzer nutzen auch andere Lösungen, vom Smartphone über Laptop bis zu Home Automation oder Car Infotainment. Und daraus ergeben sich Erwartungshaltungen, wie gut/schnell/stabil/intuitiv etwas funktionieren muss.

5. Sie machen Stories initial teurer. Jede Prüfung auf NFAs ist zusätzlicher Aufwand. Aufwand, der sich meist nicht als zusätzlicher Nutzwert sondern als Risiko-Minimierung darstellt. Und an der Stelle sind wir meist geizig. Es wird schon nichts passieren.

Das Problem: Wir behandeln NFAs wie nice-to-haves

Funktionale Anforderungen haben in jedem Backlog ihren Platz: „Als Benutzer möchte ich mich einloggen können …“. Aber wo steht: „Die Login-Seite muss unter 200 ms antworten – auch bei 1.000 gleichzeitigen Nutzern“?

NFAs landen meist am Ende der Spezifikation, wenn überhaupt. Oft werden sie isoliert von den funktionalen Anforderungen betrachtet. Und beim Umsetzen werden sie dann elegant ignoriert, weil sie eben nicht direkt an einer Stelle sichtbar sind.

Die bittere Wahrheit: Wenn du sie nicht spezifizierst, bekommst du sie nicht.

Der Trick: Mach sie konkret. Und testbar. Und so früh wie möglich

NFAs sind wie Ziele, die du mit deiner Lösung erreichen willst. Und ebenso wie bei Zielen hilft dir das SMART-Prinzip (spezifisch, messbar, akzeptiert, realistisch, terminiert). Nutze Kennzahlen, um deine Zielerreichung zu beschreiben. Und wenn du die NFAs dann noch, wie in Scrum in a nutshell beschrieben, in deine Definition of Ready aufnimmst, kannst du sie fast nicht mehr ignorieren oder vergessen. Unsere PBI-Checkliste kann dir zusätzlich dabei helfen, NFAs nie wieder zu vergessen oder zu spät zu adressieren.

Erst mal die Funktionalität, die Performance machen wir später!

Sicher? Performance entsteht nicht durch optimieren am Schluss. Sie ist eine Architekturentscheidung. Wer von Anfang an REST, SQL, Azure, Web und Cloud sagt, aber kein Wort über Lastverhalten verliert, baut auf Sand. Typischer Fehler: NFAs erst messen, wenn’s zu spät ist – also im Live-Betrieb. Dann ist es aber zu spät für Lasttests, Penetration Tests u.v.m. Dann hilft nur noch Feuerlöschen. Wer also kein Feuerwehrmann ist, sollte lieber den Brandschutz schon bei Baubeginn berücksichtigen.

Fazit: NFA = Not-Fucking-Around-Anforderungen

Wer nichtfunktionale Anforderungen ignoriert, zahlt später die Zeche – sei es durch Downtime, kostspielige Rewrites oder beschädigtes Vertrauen. Darum: Klärt früh, was „gut genug“ in eurem Kontext wirklich bedeutet – und dokumentiert es so eindeutig, dass hinterher niemand behaupten kann: „Das stand so aber nie im Raum.“ Wenn ihr das ernst nehmt und NFAs von Anfang an berücksichtigt, klingen Sätze wie „Funktional ist zwar alles geliefert – aber benutzen kann man’s trotzdem nicht“ bald wie Relikte aus der Steinzeit der Softwareentwicklung.

👉 Was sind eure schlimmsten „Hätte man vorher wissen können“-Erfahrungen mit nichtfunktionalen Anforderungen? Erzählt es uns auf LinkedIn.