Nicht-funktionale Anforderungen: Qualitätsszenarien systematisch spezifizieren in Köln

Tag 1: NFRs verstehen, ermitteln und formulieren

• 1. Warum nicht-funktionale Anforderungen scheitern - und was man dagegen tun kann
  • Die teuersten Fehler in IT-Projekten: Funktionale Fehler werden beim Testing gefunden (Kosten: 1). NFR-Fehler werden erst in Produktion sichtbar (Kosten: 10-100). Performance-Probleme unter Last, Sicherheitslücken beim Audit, Verfügbarkeitsausfälle am Black Friday - alles Folgen fehlender oder vager NFR-Spezifikation.
  • Warum NFRs vage bleiben: Stakeholder denken in Funktionen, nicht in Qualität. Entwickler setzen voraus, dass performant" selbstverständlich ist. Product Owner priorisieren Features über Qualität. Architekten treffen Qualitäts-Entscheidungen ohne explizites Mandat.
  • Die drei NFR-Fehler, die jedes Projekt macht: Zu spät (erst bei der Architektur statt bei den Anforderungen), zu vage (nicht messbar, nicht testbar), zu isoliert (nicht mit Architektur-Entscheidungen verknüpft).
  • Der Paradigmenwechsel: NFRs sind keine Nebenbedingungen - sie sind Architektur-Treiber. Die Entscheidung zwischen Monolith und Microservices, zwischen SQL und NoSQL, zwischen Cloud und On-Premises wird von NFRs getrieben, nicht von Features.

• 2. Qualitätsmodell: ISO 25010 als Checkliste, nicht als Bürokratie
  • Die 8 Hauptmerkmale: Funktionale Eignung, Performance-Effizienz, Kompatibilität, Benutzbarkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit, Portabilität. Jedes Merkmal mit 3-5 Untermerkmalen.
  • Pragmatischer Einsatz: ISO 25010 nicht als Formular ausfüllen, sondern als Checkliste nutzen: Haben wir an Performance gedacht? An Sicherheit? An Wartbarkeit?" Systematisch statt zufällig.
  • Die häufigsten blinden Flecken: Wartbarkeit (wird fast nie spezifiziert, obwohl 60-80 % der Softwarekosten in der Wartung entstehen), Portabilität (Vendor Lock-in erst beim Wechsel bemerkt), Kompatibilität (Schnittstellen-Anforderungen vergessen).
  • Über ISO 25010 hinaus: Anforderungen, die in keinem Modell stehen, aber jedes Projekt betreffen: Compliance (DSGVO, NIS-2, Branchenregulierung), Betreibbarkeit (Deployment, Monitoring, Backup), Ökonomie (Infrastrukturkosten, Lizenzkosten).
  • Praxis-Übung: Teilnehmende nehmen ein eigenes Projekt und prüfen es systematisch gegen alle ISO-25010-Merkmale: Welche Merkmale sind relevant? Welche wurden bisher ignoriert? Ergebnis: NFR-Relevanz-Matrix (MerkmalRelevanzAktueller Spezifikationsgrad).

• 3. Qualitätsszenarien: Das Spezifikationsformat für NFRs
  • Das Problem mit Das System soll schnell sein": Nicht messbar, nicht testbar, nicht verhandelbar. Jeder Stakeholder hat eine andere Vorstellung von schnell". Architekten können damit nicht arbeiten, Tester können es nicht prüfen.
  • Qualitätsszenario-Schema: Jedes Qualitätsszenario besteht aus sechs Elementen: 
    • Quelle (wer/was löst das Szenario aus?): Endnutzer, Administrator, externer Service, Angreifer, Zeitgeber
    • Stimulus (was passiert?): Anfrage, Fehler, Angriff, Lastspitze, Konfigurationsänderung
    • Artefakt (was ist betroffen?): System, Komponente, Datenbank, API, UI
    • Umgebung (unter welchen Bedingungen?): Normalbetrieb, Spitzenlast, Wartungsfenster, Degraded Mode
    • Reaktion (was soll das System tun?): Antworten, Protokollieren, Ablehnen, Failover, Benachrichtigen
    • Maß (wie messen wir Erfolg?): LatenzQualitätsszenarien gemeinsam brainstormen -> Szenarien priorisieren -> Refinement.
    • KI-gestützte Ermittlung: ChatGPT/Claude als Sparringspartner: Welche nicht-funktionalen Anforderungen sind für ein E-Commerce-System mit 50.000 täglichen Nutzern typischerweise relevant?" -> KI liefert eine Checkliste, die der RE-Professional mit Stakeholdern validiert.
    • Praxis-Übung: Mini-QAW in Kleingruppen (20 Min) - ein Teilnehmer präsentiert sein Projekt, die Gruppe stellt NFR-Fragen, gemeinsam werden 5 Qualitätsszenarien formuliert.

  Tag 2: Priorisieren, Zielkonflikte lösen und in Architektur/Testing überführen
  • 5. Qualitätsbaum: NFRs priorisieren und verhandelbar machen
    • Das Problem der Priorisierung: Alles ist wichtig" - Performance UND Sicherheit UND Verfügbarkeit UND Wartbarkeit UND Benutzbarkeit. Ohne Priorisierung trifft der Architekt implizite Entscheidungen, die niemand hinterfragt.
    • Utility Tree / Qualitätsbaum: Hierarchische Darstellung: Wurzel = Systemqualität -> Äste = Qualitätsmerkmale (Performance, Sicherheit, ...) -> Blätter = konkrete Qualitätsszenarien. Jedes Szenario wird bewertet nach: Geschäftswert (H/M/L)technisches Risiko (H/M/L). Szenarien mit H/H sind die Architektur-Treiber.
    • Stakeholder-Priorisierung: Verschiedene Stakeholder bewerten denselben Qualitätsbaum unterschiedlich - der CTO priorisiert Skalierbarkeit, der CISO Sicherheit, der CFO Kosten, der Endnutzer Benutzbarkeit. Die Priorisierung macht diese Konflikte sichtbar und verhandelbar.
    • Good Enough"-Prinzip: Nicht jede NFR muss auf 99,99 % Verfügbarkeit oder99,99 % Verfügbarkeit kostet 10 mehr Infrastruktur. Lohnt sich das?
    • Praxis-Übung: Teilnehmende erstellen einen Qualitätsbaum für ihr eigenes Projekt mit den 5 Szenarien aus Topic 3. Priorisierung nach Geschäftswerttechnischem Risiko. Ergebnis: die 3 wichtigsten Architektur-Treiber sind identifiziert.

  • 6. Zielkonflikte: Die versteckten Trade-offs sichtbar machen
    • Warum Qualitätsmerkmale sich widersprechen: Nicht alle NFRs sind gleichzeitig maximierbar. Jede Architektur-Entscheidung ist ein Trade-off.
    • Die klassischen Konflikte:
      • Performance vs. Sicherheit: Verschlüsselung kostet Rechenzeit. Input-Validierung verlangsamt die Verarbeitung. Logging erzeugt I/O-Last.
      • Verfügbarkeit vs. Konsistenz: CAP-Theorem - in verteilten Systemen kann man nur zwei von drei haben (Consistency, Availability, Partition Tolerance). Eventual Consistency als Kompromiss.
      • Flexibilität vs. Performance: Abstraktion und Konfigurierbarkeit kosten Laufzeit. Ein hochflexibles Plugin-System ist langsamer als hardcodierte Logik.
      • Benutzbarkeit vs. Sicherheit: Zwei-Faktor-Authentifizierung verbessert die Sicherheit, verschlechtert die Benutzbarkeit. Passwort-Komplexitätsregeln frustrieren Nutzer.
      • Wartbarkeit vs. Performance: Clean Architecture mit vielen Abstraktionsschichten ist wartbarer, aber langsamer. Optimierter Code ist schneller, aber schwerer zu ändern.
      • Skalierbarkeit vs. Kosten: Auto-Scaling löst Lastprobleme, aber die Cloud-Rechnung kann explodieren.

    • Zielkonflikte dokumentieren: Jeder Trade-off wird explizit dokumentiert: Wir haben uns für Eventual Consistency entschieden (zulasten von Strong Consistency), weil Verfügbarkeit für unser E-Commerce-System wichtiger ist als konsistente Lagerbestände in Echtzeit. Risiko: kurzzeitig können Nutzer ein ausverkauftes Produkt bestellen."
    • Entscheidungsmatrix: QualitätsmerkmalQualitätsmerkmal -> Konflikte markieren, Priorität festlegen, Entscheidung dokumentieren.
    • Praxis-Übung: Teilnehmende identifizieren 3 Zielkonflikte in ihrem eigenen Projekt. Für jeden Konflikt: Welches Merkmal hat Vorrang? Warum? Was ist das akzeptierte Risiko? Dokumentation als Architektur-Entscheidung (Architecture Decision Record).
  • 7. NFRs in Architektur-Entscheidungen überführen
    • NFRs als Architektur-Treiber: Architektur-Entscheidungen folgen nicht aus Features, sondern aus NFRs. Wir brauchen einen Warenkorb" (funktional) -> kann jede Architektur. Der Warenkorb muss bei 100.000 gleichzeitigen Nutzern unter 100ms antworten" (NFR) -> erfordert Caching, CDN, horizontale Skalierung.
    • Von der NFR zur Architektur-Taktik: Für jedes Qualitätsmerkmal existieren erprobte Architektur-Taktiken: 
      • Performance: Caching, Connection Pooling, Lazy Loading, CDN, Asynchrone Verarbeitung
      • Verfügbarkeit: Redundanz, Failover, Health Checks, Circuit Breaker, Graceful Degradation
      • Sicherheit: Defense in Depth, Least Privilege, Input Validation, Encryption at Rest/in Transit
      • Wartbarkeit: Modularisierung, Dependency Injection, API-Versionierung, Feature Toggles
      • Skalierbarkeit: Horizontale Skalierung, Stateless Design, Event-Driven Architecture, Sharding

    • Architecture Decision Records (ADRs): Jede NFR-getriebene Entscheidung in einem ADR dokumentieren: Kontext -> Entscheidung -> Konsequenzen -> Status. Brücke zu arc42, C4-Modell (S6794) und Softwarearchitektur-Seminaren.
    • NFRs in der Backlog-Praxis: Wie kommen NFRs ins Sprint Backlog? Drei Patterns: als Akzeptanzkriterium einer funktionalen Story (implizit), als eigenständige technische Story (explizit), als Definition of Done-Kriterium (global).
    • Praxis-Übung: Für die Top-3-Qualitätsszenarien aus Topic 5 jeweils eine Architektur-Taktik auswählen und als ADR dokumentieren: Weil NFR, entscheiden wir uns für Taktik, mit der Konsequenz Trade-off."
  • 8. NFRs testbar machen: Von der Spezifikation zur Verifikation
    • Testbarkeit als Qualitätskriterium einer NFR: Eine NFR, die nicht testbar ist, ist keine Anforderung - sie ist ein Wunsch. Jedes Qualitätsszenario muss eine klare Aussage enthalten, wie es verifiziert wird.
    • Teststrategien pro Qualitätsmerkmal:
      • Performance: Lasttests (k6, JMeter, Gatling - S6509 als Brücke), Benchmarks, Profiling. TestumgebungProduktion: Skalierungsfaktoren definieren.
      • Verfügbarkeit: Chaos Engineering (S6490 als Brücke), Failover-Tests, Disaster-Recovery-Übungen, SLO-Monitoring (SRE S4124 als Brücke).
      • Sicherheit: Penetrationstests (12 im GFU-Portfolio), Security Scans (OWASP, Vulnerability Management S6781), Code Reviews, Threat Modeling.
      • Benutzbarkeit: Usability Tests (S6643), A/B-Tests (S6266), Accessibility Tests (BFSG-Seminare).
      • Wartbarkeit: Code-Metriken (Cyclomatic Complexity, Coupling, Cohesion), Architektur-Fitness-Functions, Time-to-Change messen.

    • Automatisierte NFR-Validierung in CI/CD: Performance-Budgets (Lighthouse CI), Security Gates (SAST/DAST in Pipeline), Architektur-Fitness-Functions (ArchUnit, NetArchTest), Dependency Checks. NFR-Verletzungen brechen den Build - genauso wie funktionale Fehler.
    • SLOs als lebende NFRs: Service Level Objectives (SLOs) sind NFRs, die in Produktion kontinuierlich gemessen werden. Aus dem Qualitätsszenario wird ein SLI (Service Level Indicator) + SLO (Zielwert) + Error Budget (Toleranz). Brücke zu SRE (S4124).
    • Praxis-Übung: Für jedes der 5 Qualitätsszenarien eine Teststrategie definieren: Wie wird verifiziert? Welches Werkzeug? Wann im Entwicklungsprozess? Automatisierbar?
  • 9. NFR-Dokumentation: Pragmatische Formate für verschiedene Stakeholder
    • Für Stakeholder und Management: Qualitätsbaum (1 Seite) mit Priorisierung - Das sind unsere 3 wichtigsten Qualitätsziele und was sie kosten."
    • Für Architekten und Entwickler: Qualitätsszenarien im Vollformat (Quelle-Stimulus-Artefakt-Umgebung-Reaktion-Maß) + Architektur-Taktik + ADR.
    • Für Tester: Qualitätsszenarien mit Teststrategie, Testumgebung, Werkzeug und Erwartungswerten.
    • Für den Product Owner / Backlog: NFR als Akzeptanzkriterium: Diese Story ist nur Done, wenn die Response Time unter 200ms bei 500 concurrent Users liegt (verifiziert durch k6-Lasttest)."
    • NFR-Register: Zentrale Tabelle aller NFRs mit ID, Qualitätsmerkmal, Szenario, Priorität, Architektur-Taktik, Teststrategie, Status. In Confluence, Wiki oder Jira Custom Fields.
    • Versionierung und Evolution: NFRs ändern sich - Lastprognosen steigen, Compliance-Anforderungen verschärfen sich, Geschäftsmodelle wandeln sich. NFRs regelmäßig reviewen (quartalsweise), nicht als statisches Dokument behandeln.

  • 10. Praxis-Workshop: Ihre NFRs - systematisch spezifiziert"
  • Phase 1 - NFR-Ermittlung (20 Min):
    • ISO-25010-Checkliste auf das eigene Projekt anwenden.
    • 3 relevante Qualitätsmerkmale identifizieren, die bisher nicht oder vage spezifiziert sind.

  • Phase 2 - Qualitätsszenarien formulieren (25 Min):
    • Für jedes Merkmal ein vollständiges Qualitätsszenario im 6-Elemente-Schema formulieren.
    • Peer-Review: Ist es messbar? Testbar? Für alle Stakeholder verständlich?

  • Phase 3 - Qualitätsbaum und Zielkonflikte (20 Min):
    • Qualitätsbaum erstellen und nach GeschäftswertRisiko priorisieren.
    • Einen Zielkonflikt identifizieren und als ADR dokumentieren.

  • Phase 4 - Teststrategie und Dokumentation (15 Min):
    • Für die Top-3-Szenarien die Teststrategie festlegen.
    • NFR-Register als Tabelle anlegen (ID, Szenario, Priorität, Taktik, Test, Status).

  LernzieleJede teilnehmende Person verlässt das Seminar mit 3-5 vollständig spezifizierten Qualitätsszenarien für das eigene Projekt, einem priorisierten Qualitätsbaum, dokumentierten Zielkonflikten als Architecture Decision Records, einer Teststrategie pro NFR und einem NFR-Register als Vorlage für die eigene Organisation.Zielgruppen
  • Requirements Engineers und Business-Analysten: Die nicht-funktionale Anforderungen genauso systematisch spezifizieren wie funktionale.
  • Software-Architekten: Die Qualitätsanforderungen als Treiber für Architektur-Entscheidungen nutzen und nachvollziehbar dokumentieren.
  • Product Owner und Produktmanager: Die Qualitätserwartungen der Stakeholder in testbare Kriterien übersetzen - statt das System soll schnell sein" im Backlog stehen zu lassen.
  • Testmanager und QA-Verantwortliche: Die aus nicht-funktionalen Anforderungen systematisch Teststrategien und Testfälle ableiten.
  • DevOps- und SRE-Teams: Die SLOs, SLIs und Error Budgets aus Geschäftsanforderungen ableiten statt aus technischen Vermutungen.

  Voraussetzungen: Grundkenntnisse in Requirements Engineering (was sind Anforderungen, wie werden sie dokumentiert?). Grundverständnis von Software-Architektur (Client-Server, APIs, Datenbanken). Keine tiefgehenden technischen Vorkenntnisse nötig - das Seminar ist methodisch, nicht tool-spezifisch.