Antwort.

Funktionale Anforderungen beschreiben, was das System tun soll: Geschäftsoperationen, Prozesse, Benutzerszenarien — also Funktionalität.

Nicht-funktionale Anforderungen definieren, wie das System arbeiten soll: Einschränkungen, Qualitätsparameter, Leistungsfähigkeit, Sicherheit, Benutzerfreundlichkeit usw. Diese Anforderungen beeinflussen oft die Wahl der Technologien, die Skalierbarkeit und die Robustheit der Lösung.

Warum es wichtig ist zu unterscheiden:

• Eine klare Trennung hilft bei der korrekten Formulierung der Aufgaben für Entwickler und Tester.
• Verhindert das Versäumen kritischer Merkmale (z.B. Sicherheit, Skalierbarkeit).
• Nicht berücksichtigte nicht-funktionale Anforderungen werden häufig zur Quelle von Projektfehlern.

Schlüsselfeatures:

• Funktionale Anforderungen — Verhalten des Systems.
• Nicht-funktionale Anforderungen — Qualität und Einschränkungen.
• Beide Arten müssen klar dokumentiert und abgestimmt werden.

Fangfragen.

Fällt „Benutzerfreundlichkeit“ unter die funktionalen Anforderungen?

Nein, das ist ein nicht-funktionaler Parameter (Usability). Eine funktionale Anforderung wäre das Vorhandensein eines Buttons „Speichern“, eine nicht-funktionale Anforderung wäre die Geschwindigkeit seiner Reaktion und die Benutzerfreundlichkeit.

Kann man nicht-funktionale Anforderungen ignorieren, wenn sie vom Auftraggeber nicht ausdrücklich erwähnt werden?

Nein. Der Analyst ist verpflichtet, auch implizite nicht-funktionale Anforderungen zu thematisieren und zu formalieren, andernfalls steigt das Risiko eines Fehlstarts, Nutzerbeschwerden und zusätzlicher Kosten.

„Das System muss in der Lage sein, 1000 Anfragen pro Minute zu bearbeiten“. Ist das eine funktionale Anforderung?

Nein, das ist eine nicht-funktionale Anforderung — ein Leistungsmerkmal.

Typische Fehler und Anti-Patterns

• Einseitige Fokussierung auf Funktionalität („Hauptsache, es funktioniert, die Geschwindigkeit kommt später“).
• Implizite Formulierung nicht-funktionaler Anforderungen — „muss schnell sein“, „zuverlässig“, „sicher“.
• Ignorierung der Tests von Nicht-Funktionalität.

Beispiel aus dem Leben

Negativer Fall: Das System hat die angegebenen Geschäfts-Funktionalitäten vollständig umgesetzt, aber bei hoher Last begann es zu „stocken“, da die Leistungsfähigkeit überhaupt nicht berücksichtigt wurde. Vorteile:

• Schnelle Entwicklung, genaue Umsetzung der angegebenen Szenarien. Nachteile:
• Das System war nicht für den Betrieb unter realer Last geeignet, das Unternehmen musste die Architektur kurzfristig überarbeiten.

Positiver Fall: Der Analyst hat gemeinsam mit dem Architekten und dem Auftraggeber die maximalen Lasten, Reaktionskriterien festgelegt und Lasttests durchgeführt. Vorteile:

• Das Produkt arbeitete stabil und hielt das Wachstum der Nutzer stand.
• Die Entwicklungpläne sahen Skalierung vor. Nachteile:
• Zu Beginn der Planung war es notwendig, mehr Zeit für Diskussionen und zusätzliche Tests aufzuwenden.