Teil 2: Die wichtigsten Zutaten für erfolgreiche Projekte

Warum funktionale und nicht-funktionale Requirements den Unterschied machen

Stell dir vor, du willst einen Marmorkuchen backen. Du hast die perfekte Idee im Kopf: saftig, schokoladig, mit der perfekten Marmorierung. Aber dann passiert es – du vergisst wichtige Zutaten oder nimmst die falschen Mengen. Das Ergebnis? Ein trockener, geschmackloser Kuchen, der aussieht wie ein missglücktes Kunstprojekt. Genau so geht es vielen IT-Projekten. 87% aller Software-Projekte scheitern oder überschreiten ihr Budget – und der Hauptgrund liegt oft in unvollständigen oder falschen "Zutaten": den Requirements. Du kennst das bestimmt: Das entwickelte System funktioniert technisch, aber die Nutzer sind unzufrieden, die Performance ist miserabel oder die Bedienung frustriert alle Beteiligten. Das Problem? Die meisten Teams konzentrieren sich nur auf die "Hauptzutaten" (funktionale Requirements) und vergessen die "Geheimzutaten" (nicht-funktionale Requirements), die aus einem guten Kuchen einen großartigen machen.

Das teure Problem unvollständiger Zutaten-Listen

Die Zahlen sprechen eine deutliche Sprache: Unvollständige Requirements kosten deutsche Unternehmen jährlich über 2,1 Milliarden Euro. Das entspricht etwa dem Bruttoinlandsprodukt von Montenegro – verschwendet durch unklare Anforderungen.

Hier ein typisches Szenario aus der Praxis: Ein E-Commerce-Unternehmen beauftragt die Entwicklung einer neuen Produktsuchfunktion. Die funktionalen Requirements sind klar definiert:

• Nutzer sollen nach Produkten suchen können

• Filter für Preis, Kategorie und Marke

• Sortierung nach verschiedenen Kriterien

Sechs Monate später ist die Funktion fertig – technisch perfekt umgesetzt. Aber dann der Schock: Die Suche dauert 8 Sekunden bei 10.000 Produkten. Die mobile Version ist unbenutzbar. Der Server bricht bei mehr als 50 gleichzeitigen Nutzern zusammen. Die Entwicklungskosten verdoppeln sich durch nachträgliche Optimierungen.

Was fehlte? Die nicht-funktionalen Requirements – die "Geheimzutaten" für ein erfolgreiches System:

• Performance: Suchergebnisse in unter 2 Sekunden

• Skalierbarkeit: 500 gleichzeitige Nutzer ohne Performance-Verlust

• Usability: Mobile-optimierte Darstellung

• Verfügbarkeit: 99,9% Uptime während der Geschäftszeiten

Funktionale vs. nicht-funktionale Requirements: Die Marmorkuchen-Metapher

Lass uns das mit unserem Marmorkuchen erklären: Funktionale Requirements = Die Hauptzutaten: Das sind die offensichtlichen Bestandteile, die jeder sofort versteht:

• Mehl = Grundfunktionen (Login, Dateneingabe, Berechnungen)

• Eier = Datenverarbeitung (Speichern, Laden, Transformieren)

• Zucker = User Interface (Buttons, Menüs, Formulare)

• Kakao = Spezialfunktionen (Reports, Export, Integration)

Diese Requirements beschreiben, WAS das System tun soll. Sie sind konkret, messbar und meist leicht zu verstehen. Ein funktionales Requirement könnte lauten: "Das System soll Kundenbestellungen speichern und eine Bestätigungsmail versenden."

Nicht-funktionale Requirements = Die Geheimzutaten

Das sind die subtilen, aber entscheidenden Faktoren:

• Backpulver = Performance (Wie schnell läuft das System?)

• Salz = Sicherheit (Wie werden Daten geschützt?)

• Vanille = Usability (Wie benutzerfreundlich ist es?)

• Backzeit = Verfügbarkeit (Wann muss das System verfügbar sein?)

• Temperatur = Skalierbarkeit (Wie viele Nutzer kann es verkraften?)

Diese Requirements beschreiben, WIE GUT das System funktionieren soll. Sie sind oft schwerer zu messen, aber kritisch für den Erfolg. Ein nicht-funktionales Requirement könnte lauten: "Die Bestätigungsmail soll innerhalb von 30 Sekunden nach der Bestellung versendet werden, auch bei 1.000 gleichzeitigen Bestellungen."

Die verschiedenen Arten von Requirements verstehen

Business Requirements: Die Geschmacksrichtung bestimmen: Business Requirements definieren den grundsätzlichen Zweck deines "Kuchens".

• Warum soll das System entwickelt werden?

• Welche Geschäftsziele soll es erreichen?

• Welchen Nutzen bringt es dem Unternehmen?

Beispiel: "Das neue CRM-System soll die Kundenzufriedenheit um 25% steigern und die Bearbeitungszeit von Anfragen um 40% reduzieren."

User Requirements: Die Gäste verstehen: User Requirements beschreiben, was deine "Gäste" (Endnutzer) vom System erwarten.

• Was möchten die Nutzer erreichen?

• Welche Aufgaben sollen erleichtert werden?

• Welche Erfahrungen sollen sie machen?

Beispiel: "Als Vertriebsmitarbeiter möchte ich alle Kundenkontakte auf einen Blick sehen, damit ich gezielt nachfassen kann."

System Requirements: Das Rezept im Detail: System Requirements sind die genauen "Zubereitungsanweisungen" für die Entwickler.

Funktionale System Requirements:

• Login-Funktion mit Email und Passwort

• Kundendaten anlegen, bearbeiten, löschen

• Export von Kundenlisten als Excel-Datei

• Automatische Erinnerungen bei Follow-ups

Nicht-funktionale System Requirements:

• Performance: Login in unter 3 Sekunden

• Sicherheit: Zwei-Faktor-Authentifizierung

• Usability: Bedienung ohne Schulung möglich

• Kompatibilität: Läuft auf Chrome, Firefox, Safari

• Skalierbarkeit: 200 gleichzeitige Nutzer

• Verfügbarkeit: 99,5% Uptime (Montag-Freitag, 8-18 Uhr)

Häufige Fehler beim "Zutaten sammeln"

Fehler 1: Die Gewürze vergessen	90% der Projekte definieren funktionale Requirements – nur 45% definieren nicht-funktionale Requirements ausreichend. Du würdest niemals einen Kuchen ohne Salz oder Backpulver backen. Trotzdem "vergessen" viele Teams systematisch die nicht-funktionalen Requirements. Das Ergebnis: Ein System, das technisch funktioniert, aber in der Praxis unbrauchbar ist.
Fehler 2: Vage Mengenangaben	Statt "Eine Prise Salz" solltest du "2g Salz" schreiben. Statt "Das System soll schnell sein" solltest du "Antwortzeiten unter 2 Sekunden bei 95% aller Anfragen" definieren. Schlecht: "Das System soll benutzerfreundlich sein." Besser: "Neue Nutzer können ohne Anleitung innerhalb von 5 Minuten eine Bestellung aufgeben."
Fehler 3: Die Gäste nicht fragen	Zu oft werden Requirements im stillen Kämmerlein geschrieben, ohne die tatsächlichen Nutzer zu fragen. Das ist, als würdest du einen Kuchen für eine Diabetiker-Party backen, ohne zu wissen, dass deine Gäste keinen Zucker essen können.

Dein Starter-Kit: Die Requirements-Checkliste

Schritt 1: Business Requirements klären (Die Kuchenidee)	Welches Geschäftsproblem löst das System? Welche messbaren Ziele sollen erreicht werden? Was ist der ROI (Return on Investment)? Bis wann soll das System live gehen?
Schritt 2: User Requirements sammeln (Die Gäste befragen)	Wer sind deine Hauptnutzer? Welche Aufgaben erledigen sie täglich? Was frustriert sie am aktuellen System? Was würde ihren Arbeitsalltag deutlich erleichtern?
Pro-Tipp:	Führe mindestens 5 ausführliche Nutzer-Interviews durch. Eine Stunde Gespräch spart dir später Wochen der Nacharbeit.
Schritt 3: Funktionale Requirements definieren (Die Hauptzutaten)	Alle Hauptfunktionen auflisten Eingabe-/Ausgabe-Daten definieren Geschäftsregeln dokumentieren Integration mit anderen Systemen klären
Schritt 4: Nicht-funktionale Requirements festlegen (Die Geheimzutaten)	Performance: Maximale Antwortzeiten definieren Durchsatz-Anforderungen (Transaktionen/Sekunde) Maximale Systemlast spezifizieren Sicherheit: Authentifizierung und Autorisierung Datenschutz-Anforderungen (DSGVO) Backup und Recovery-Strategien Usability: Lernzeit für neue Nutzer Bedienfreundlichkeit-Standards Barrierefreiheit (falls erforderlich) Skalierbarkeit & Verfügbarkeit: Erwartete Nutzerzahlen (heute und in 3 Jahren) Verfügbarkeitszeiten Wartungsfenster Schritt 5: Requirements priorisieren (Das Wichtigste zuerst) Verwende die MoSCoW-Methode: Must have: Ohne diese Features ist das System wertlos Should have: Wichtig für den Erfolg, aber nicht kritisch Could have: Nice-to-have Features für spätere Versionen Won't have: Bewusst ausgeschlossen (für diese Version)

Ausblick: Next Level Requirements Management

In unserem nächsten Artikel "Wer gehört in die Küche? - Stakeholder identifizieren" lernst du, wie du systematisch alle "Gäste" für dein Projekt findest und ihre unterschiedlichen "Geschmäcker" unter einen Hut bringst. Denn die besten Zutaten helfen nichts, wenn du nicht weißt, für wen du kochst. Wir werden uns ansehen:

• Wie du versteckte Stakeholder aufspürst

• Warum der Geschäftsführer andere Requirements hat als der Endnutzer

• Wie du Interessenskonflikte zwischen verschiedenen Stakeholder-Gruppen löst

• Die Stakeholder-Matrix, die dir nie wieder einen wichtigen "Gast" vergessen lässt

Artefakte und Dokumente

Requirements-Template

Ein praktisches Template mit allen wichtigen Kategorien:

• Business Requirements Checklist

• User Story Template

• Non-functional Requirements Matrix

• Requirements Priorisierung (MoSCoW)

Tools für Requirements Management

• Jira für agile Teams

• Azure DevOps für Microsoft-Umgebungen

• Confluence für Dokumentation

• Miro/Mural für kollaboratives Requirements Engineering

Weiterführende Ressourcen

• IREB (International Requirements Engineering Board) Zertifizierung

• "Software Requirements" von Karl Wiegers

• "Requirements Engineering Fundamentals" von Klaus Pohl

Ausblick: Was kommt als Nächstes?

In den kommenden Artikeln dieser Serie werden wir tiefer in die Kunst des Requirements Engineering eintauchen. Wir lernen:

• Wie Du die "Zutaten" Deines Projekts sammeln kannst (Stakeholder-Analyse)

• Welche Arten von Requirements es gibt (funktionale vs. nicht-funktionale)

• Wie Du das perfekte "Mischverhältnis" findest (Priorisierung)

• Und vieles mehr...

Über die Autorin: Michaela Kühn, Sparringspartnerin zum Thema Requirements Engineeting und Business Analyse in Projekten

Hast Du Fragen oder eigene Erfahrungen mit Requirements Engineering? Teilen Sie sie in den Kommentaren oder diskutieren Sie mit mir auf LinkedIn.

Quellen:

• PMBOK Guide, 7 & 8th Edition, PMI, Themenfeld: Projektmanagement

• Governance of Portfolios, Programs, and Projects: A Practice Guide, PMI, Governance

• Business Analysis for Practitioners: A Practice Guide, 2nd Edition, PMI , Business Analysis

• Requirements Management: A Practice Guide, PMI / Agile Aliance, Agile & Lean

• Band 1: Organisation und Business Analysis – Methoden und Techniken, IBO, Business Analysis Methoden

• Use Case 3.0, Ivar Jacobson et al., Use Cases & Requirements

• Leading AI Transformation: Organizational Strategies for Project Professionals, PMI (2025), KI-Transformation

• Guide to Leading and Managing AI Projects, PMI (2025) , KI-Projektmanagement

(C) Michaela Kühn - www.michaela-kuehn.com - Sparringspartnerin für Anfoderungsmanagement ( Requirements Engineering) und Agile Business Analyse