Katalog
concept#Architektur#Softwaretechnik#Zuverlässigkeit#Sicherheit

Nicht Funktionale Anforderungen

Nicht funktionale Anforderungen beschreiben die Qualitätsmerkmale eines Systems (z. B. Performance, Sicherheit, Wartbarkeit) und ergänzen funktionale Anforderungen. Sie bilden Entscheidungsgrundlagen für Architektur, Betrieb und Test.

Nicht funktionale Anforderungen beschreiben Qualitätsmerkmale eines Systems wie Performance, Sicherheit, Skalierbarkeit und Wartbarkeit.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Monitoring- und Observability-Tools (z. B. Prometheus)CI/CD-Pipeline zur automatisierten Performance-ValidierungIncident-Management- und SLA-Reporting-Systeme

Prinzipien & Ziele

Formulierung in messbaren Kriterien (z. B. Metriken, Schwellenwerte).Priorisierung nach Geschäftsauswirkung und Risiko.Frühzeitige Validation durch Tests und Monitoring planen.
Erkundung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Übermäßige Perfektionierung führt zu Kostenüberschreitung.
  • Unklare oder widersprüchliche Anforderungen schaffen Implementationsrisiken.
  • Fehlende Messbarkeit verhindert Nachweis und Betriebskontrolle.
  • Anforderungen in S.M.A.R.T.-Metriken formulieren.
  • Frühe Validierung durch automatisierte Tests und Load-Tests.
  • Regelmäßige Review- und Priorisierungszyklen einführen.

I/O & Ressourcen

  • Stakeholder-Ziele und Geschäftsanforderungen
  • Messbare Leistungs- und Sicherheitsziele
  • Bestehende Systemarchitektur und Monitoring-Daten
  • Katalog nicht funktionaler Anforderungen mit Metriken
  • Priorisierte Qualitätsattribute und Akzeptanzkriterien
  • Test- und Monitoring-Plan zur Validierung

Beschreibung

Nicht funktionale Anforderungen beschreiben Qualitätsmerkmale eines Systems wie Performance, Sicherheit, Skalierbarkeit und Wartbarkeit. Sie ergänzen funktionale Anforderungen und prägen Architektur, Design sowie organisatorische Entscheidungen. Ein systematischer Umgang erleichtert Priorisierung, Testbarkeit und Erfüllung von Stakeholder-Erwartungen. Die Formulierung in messbaren Kriterien ist entscheidend für Nachweis und Vertrag.

✔

  • Bessere Planbarkeit und Nachweisbarkeit von Qualitätszielen.
  • Klare Grundlage für Architektur- und Betriebsentscheidungen.
  • Verringertes Risiko von Fehlannahmen und Nacharbeiten.

✖

  • Nicht alle Qualitätsattribute sind gleichzeitig vollständig erfüllbar.
  • Messbarkeit kann in frühen Phasen eingeschränkt sein.
  • Erhöhter Aufwand zur Spezifikation und Validierung.

  • Mittlere Antwortzeit (P95)

    Messung der Antwortzeit unter Last zur Bewertung der Performance.

  • Verfügbarkeit (Uptime %)

    Prozentualer Anteil der Betriebszeit innerhalb definierter Zeitfenster.

  • Mean Time To Recovery (MTTR)

    Durchschnittliche Zeit zur Wiederherstellung nach Ausfall.

SLA für Verfügbarkeit eines Payment-Services

Definition messbarer Verfügbarkeitsziele (z. B. 99,95 %) und Wiederherstellungszeiten.

Performance-Definition für API-Endpunkte

Konkrete Latenz- und Durchsatzziele pro Endpoint mit Testfällen.

Sicherheitsanforderungen für personenbezogene Daten

Verschlüsselung, Zugriffskontrollen und Audit-Logs zur Einhaltung von Datenschutzvorgaben.

1

Stakeholder identifizieren und Qualitätsziele erheben.

2

Metriken und Akzeptanzkriterien für jedes Attribut definieren.

3

Tests, Monitoring und Verantwortlichkeiten in den Delivery-Prozess integrieren.

⚠️ Technische Schulden & Engpässe

  • Fehlende Observability erschwert spätere Validierung.
  • Harte Kopplung reduziert Fähigkeit zur Skalierung.
  • Unzureichende Testabdeckung für Last- und Sicherheitsfälle.
Monolithische KomponentenFehlende ObservabilityEngpass in Datenbankperformance
  • Spezifikation von ‚hoher Sicherheit‘ ohne konkrete Maßnahmen.
  • Festlegen unrealistischer Performance-Ziele ohne Testgrundlage.
  • Ignorieren betriebsspezifischer Anforderungen bei Cloud-Migration.
  • Konflikte zwischen Qualitätszielen nicht früh genug erkennen.
  • Metriken ohne Messinfrastruktur definieren.
  • Übermäßige Detailtiefe in frühen Phasen erzwingen.
Architektur- und QualitätsmodellkenntnisTestautomatisierung und Performance-TestingSicherheits- und Compliance-Verständnis
Verfügbarkeit und Recovery-ZeitzieleSkalierbarkeit unter LastSicherheits- und Datenschutzanforderungen
  • • Budget- und Betriebsrestriktionen
  • • Regulatorische Vorgaben (z. B. Datenschutz)
  • • Vorhandene Legacy-Systeme