Antwort.

Der Business Analyst ist verantwortlich für das vollständige Sammeln, Abstimmen und Dokumentieren von sowohl funktionalen als auch nicht-funktionalen Anforderungen: Systemgeschwindigkeit, Sicherheit, Skalierbarkeit, Verfügbarkeit, Benutzerfreundlichkeit. Dazu arbeitet er eng mit den Stakeholdern (insbesondere mit dem Geschäft und IT) zusammen, verwendet Szenarien und analysiert Standards. Er muss nicht nur die expliziten Erwartungen erfassen, sondern auch verborgene Anforderungen identifizieren (z. B. Datenschutzvorschriften). Letztendlich formalisiert der Analyst die nicht-funktionalen Anforderungen in der Dokumentation, stimmt sie mit dem Projekt- und Technikteam ab und überwacht die Einhaltung dieser Anforderungen während des gesamten Projekts.

Wesentliche Merkmale:

• Identifikation von verborgenen und spezifischen Anforderungen durch Interviews und Analyse von Standards
• Sicherstellung der Dokumentation und Abstimmung nicht-funktionaler Anforderungen
• Überwachung der Übereinstimmung der Umsetzung mit den abgestimmten nicht-funktionalen Kriterien

Fangfragen.

Reicht es aus, nicht-funktionale Anforderungen einfach im Text ohne Metriken und Konkretheit zu beschreiben?

Nein, abstrakte Formulierungen ("schnell", "sicher") sind für die Validierung unbrauchbar. Klare Parameter sind erforderlich: zum Beispiel, eine Antwortzeit von nicht mehr als 2 Sekunden.

Sind nicht-funktionale Anforderungen nur die Sorge der technischen Spezialisten?

Nein, der Analyst muss solche Anforderungen gemeinsam mit dem Geschäft identifizieren und formal gestalten, da deren Nichteinhaltung zu unzufriedenen Schlüsselinteressen des Geschäfts führen kann.

Ist es möglich, die Arbeit mit nicht-funktionalen Anforderungen auf die finalen Phasen des Projekts zu verschieben?

Nein, solche Anforderungen sind oft kritisch für die Architektur der Lösung. Ihre Identifikation in späteren Phasen führt zu Überarbeitungen und hohen Kosten.

Typische Fehler und Anti-Pattern

• Unklare, formal oder zu allgemein gehaltene Beschreibung nicht-funktionaler Merkmale
• Ignorieren von Sicherheitsstandards, SLA, gesetzlichen Anforderungen
• Späte Identifikation nicht-funktionaler Anforderungen mit dem Risiko erheblicher Überarbeitungen

Beispiel aus der Praxis

Negativer Fall: Im Pflichtenheft wurde das erwartete "Benutzerfreundlichkeit" und "Reaktionsgeschwindigkeit" beschrieben, ohne konkrete Metriken festzuhalten. Vorteile: Weniger Aufwand zum Zeitpunkt der Dokumentenerstellung Nachteile: Keine Möglichkeit, Ansprüche an das Team zu stellen, als das Ergebnis den Kunden nicht zufriedenstellte.

Positiver Fall: Vereinbart: "Ladegeschwindigkeit der Seite – bis zu 2 Sekunden bei einer Last von bis zu 1000 Nutzern, SLA-Level – 99,95%". Anforderungen zum Datenschutz wurden formalisiert. Vorteile: Klare Überprüfung des Ergebnisses, Risikominderung für Nacharbeiten, Transparenz für alle Beteiligten. Nachteile: Benötigte Zeit und Abstimmungen mit IT und Juristen.