Anforderungsanalyse und -definition
In dieser Lerneinheit erwirbst du grundlegende Kompetenzen zur systematischen Erfassung und Definition von Softwareanforderungen. Du lernst, wie du Stakeholder identifizierst, deren Anforderungen strukturiert erhebst und diese in konkrete Systemanforderungen übersetzt. Diese Fähigkeiten sind essentiell für die erfolgreiche Planung und Umsetzung von Softwareprojekten in der Praxis.
Einführung
Ein Software-Projekt startet nicht mit Code. Es beginnt mit Fragen: Was soll die Software können? Wer wird sie nutzen? Welche Probleme löst sie? Ohne klare Antworten auf diese Fragen drohen Missverständnisse, Fehlentwicklungen und teure Nachbesserungen.
Wie können wir sicherstellen, dass alle Beteiligten dasselbe verstehen und die Software am Ende wirklich das tut, was sie soll?
Die Anforderungsanalyse und -definition ist die Antwort. Sie bildet die Analyse-Phase des SDLC (Software Development Life Cycle) und schafft eine klare, dokumentierte Grundlage für Entwicklung und Qualitätssicherung.
In dieser Lerneinheit lernst du, wie du Anforderungen systematisch erfasst, strukturierst und dokumentierst – die Basis für den Erfolg jedes Software-Projekts.
Lernziele
Nach dieser Lerneinheit kannst du:
- Stakeholder identifizieren und priorisieren
- Funktionale und nicht-funktionale Anforderungen unterscheiden und formulieren
- Anforderungen mit der MoSCoW-Methode priorisieren
- Use Cases, User Stories und Akzeptanzkriterien erstellen
- Anforderungen validieren und dokumentieren
Überleitung
Um zu verstehen, wie wir Anforderungen systematisch erfassen, beginnen wir mit der wichtigsten Frage: Wer sind die Stakeholder und wie identifizieren wir ihre Bedürfnisse?
Danach lernst du, wie du diese Anforderungen strukturiert erhebst, dokumentierst und priorisierst.
Stakeholder identifizieren und kategorisieren
Stakeholder sind alle Personen oder Gruppen, die ein Interesse am Projekt haben. Ihre Anforderungen zu verstehen ist entscheidend für den Projekterfolg.
Stakeholder-Kategorien:
| Kategorie | Beispiele |
|---|---|
| Direkte Stakeholder (arbeiten direkt mit dem System) | Endnutzer, Administratoren |
| Indirekte Stakeholder (von Entscheidungen betroffen) | Management, Support-Teams |
| Entscheider (Finanzierung, Strategie) | Geschäftsleitung, Projektsponsoren |
| Projektteam (Entwicklung, Design) | Entwickler, Designer, Tester |
| Externe (Partner, Behörden) | API-Anbieter, Datenschutzbeauftragte |
Stakeholder priorisieren: Power/Interest Matrix
Nicht alle Stakeholder haben dieselbe Bedeutung. Die Power/Interest Matrix hilft dir, Stakeholder nach ihrem Einfluss (Power) und Interesse am Projekt zu priorisieren.
| Power/Interest | Hohes Interesse | Geringes Interesse |
|---|---|---|
| Hohe Power | Key Players (eng einbinden, regelmäßig informieren) | Keep Satisfied (zufriedenstellen, aber nicht übermäßig einbeziehen) |
| Geringe Power | Keep Informed (auf dem Laufenden halten) | Monitor (beobachten, minimaler Aufwand) |
Nutzen: Du erkennst, welche Stakeholder intensiv eingebunden werden müssen (Key Players) und welche nur informiert werden sollten (Keep Informed).
Methoden zur Anforderungserhebung
Es gibt verschiedene Methoden, um Anforderungen von Stakeholdern zu erheben:
| Methode | Wann einsetzen? |
|---|---|
| Interviews | Detaillierte Anforderungen, komplexe Bedürfnisse |
| Fragebögen | Große Anzahl von Stakeholdern |
| Workshops | Gemeinsames Verständnis entwickeln, Gruppendiskussion |
| Beobachtung | Verstehen der tatsächlichen Arbeitsweise |
Tipp: Kombiniere mehrere Methoden, um ein vollständiges Bild zu erhalten.
Anforderungen dokumentieren
Nach der Erhebung ist eine strukturierte Dokumentation entscheidend. Jede Anforderung sollte folgende Elemente umfassen:
Dokumentationsstruktur:
- Anforderungs-ID: Eindeutige Kennung (z.B. REQ-001)
- Beschreibung: Klare, verständliche Beschreibung der Anforderung
- Quelle: Stakeholder oder Dokument als Ursprung
- Priorität: Dringlichkeit (Hoch, Mittel, Niedrig)
- Verifizierung: Kriterien zur Überprüfung der Erfüllung
Beispiel:
ID: REQ-001
Beschreibung: Nutzer können Kontakte als CSV exportieren
Quelle: Endnutzer
Priorität: Hoch
Verifizierung: Export-Funktion liefert valide CSV-Datei
Funktionale vs. nicht-funktionale Anforderungen
Wie du in der Lerneinheit Einführung und Überblick gelernt hast, beschreiben funktionale Anforderungen die Funktionen des Systems (WAS), während nicht-funktionale Anforderungen Qualitätsmerkmale festlegen (WIE GUT).
| Typ | Fokus | Beispiel |
|---|---|---|
| Funktional | Was das System tun soll | ”Nutzer kann sich anmelden” |
| Nicht-funktional | Wie gut das System arbeitet | ”Anmeldezeit < 3 Sekunden” |
Wichtig: Nicht-funktionale Anforderungen müssen messbar sein. Statt “Das System soll schnell sein” schreibst du “Das System antwortet in < 2 Sekunden”.
Nicht-funktionale Anforderungen quantifizieren
Nicht-funktionale Anforderungen müssen präzise und messbar formuliert werden. Nutze diese Formel:
[Messgröße] [Operator] [Zielwert] [Bedingung]
Beispiele:
| Vage Formulierung | Quantifiziert |
|---|---|
| ”System soll schnell sein" | "Antwortzeit ≤ 2 Sekunden bei 1.000 gleichzeitigen Nutzern" |
| "Hohe Verfügbarkeit" | "Verfügbarkeit ≥ 99,9% pro Monat" |
| "Sicher" | "Alle Passwörter mit SHA-256 verschlüsselt” |
Nutzen: Quantifizierte Anforderungen sind testbar und schaffen klare Erwartungen.
Anforderungen priorisieren: MoSCoW-Methode
Die MoSCoW-Methode hilft dir, Anforderungen nach Wichtigkeit zu kategorisieren:
| Kategorie | Bedeutung | Beispiel |
|---|---|---|
| Must have | Unverzichtbar für Projekterfolg | Login-System für Nutzer |
| Should have | Wichtig, aber nicht kritisch | Suchfunktion für Produkte |
| Could have | Nice-to-have, wenn Zeit/Budget da ist | Benachrichtigungen über neue Produkte |
| Won’t have | Nicht in dieser Version | Integration sozialer Medien |
Vorteil: Du erkennst sofort, welche Anforderungen für den Projekterfolg kritisch sind und wo du bei Zeitdruck Kompromisse eingehen kannst.
Die 60/20-Regel für MoSCoW
Bei der Priorisierung mit MoSCoW solltest du eine wichtige Best Practice beachten:
Faustregel: Maximal 60% der Anforderungen sollten “Must have” sein, maximal 20% “Could have”.
Warum diese Regel?
- Zu viele Must-haves machen das Projekt unflexibel und riskant (keine Puffer).
- Zu viele Could-haves signalisieren fehlende Priorisierung und Fokus.
In der Praxis: Wenn mehr als 60% deiner Anforderungen “Must have” sind, überprüfe kritisch, ob sie wirklich alle unverzichtbar sind. Oft lassen sich einige in “Should have” verschieben.
Use Cases: Anwendungsfälle beschreiben
Ein Use Case (Anwendungsfall) beschreibt, wie ein Nutzer mit dem System interagiert, um ein bestimmtes Ziel zu erreichen. Use Cases fokussieren auf das WAS, nicht das WIE.
Struktur eines Use Cases:
- Titel: Kurz und prägnant (z.B. “Geld am Automaten abheben”)
- Akteure: Nutzer oder Systeme, die interagieren (z.B. Bankkunde)
- Vorbedingungen: Was muss erfüllt sein? (z.B. gültige Karte und PIN)
- Hauptszenario: Schritt-für-Schritt-Ablauf unter idealen Bedingungen
- Alternativszenarien: Abweichende Flows (z.B. falsche PIN)
- Nachbedingungen: Zustand nach Abschluss (z.B. Geld ausgegeben)
Use Case Beispiel
Beispiel: Geld am Automaten abheben
Akteure: Bankkunde, Bankensystem
Vorbedingungen: Kunde hat gültige Karte und PIN
Hauptszenario:
- Kunde führt Karte ein
- System validiert Karte und fordert PIN an
- Kunde gibt PIN ein
- System zeigt verfügbare Aktionen
- Kunde wählt “Geld abheben” und gibt Betrag ein
- System gibt Geld aus und druckt Beleg
- Kunde nimmt Geld und Karte
Alternativszenario: Falsche PIN
- Bei dreimaliger falscher Eingabe wird Transaktion abgebrochen und Karte eingezogen
User Stories und Akzeptanzkriterien
User Stories beschreiben Funktionen aus Nutzersicht. Format:
Als [Rolle] möchte ich [Funktion], sodass [Nutzen].
Beispiel: “Als Bankkunde möchte ich am Geldautomaten Geld abheben können, sodass ich Bargeld erhalte.”
Akzeptanzkriterien definieren, wann eine User Story als erfüllt gilt:
| Kriterium | Beschreibung |
|---|---|
| Konkret | Eindeutig formuliert |
| Messbar | Testbar und überprüfbar |
| Nutzersicht | Aus Perspektive des Nutzers |
Beispiel-Kriterien:
- Kunde erhält gewünschten Betrag in lokaler Währung
- Beleg wird nur auf Wunsch gedruckt
- Transaktion wird nach 3 falschen PIN-Versuchen abgebrochen
Anforderungen validieren
Die Validierung stellt sicher, dass Anforderungen korrekt, vollständig und durchführbar sind.
Validierungstechniken:
| Technik | Beschreibung | Nutzen |
|---|---|---|
| Reviews | Stakeholder prüfen Anforderungsdokumente | Fehler und Unklarheiten finden |
| Prototyping | Frühes Feedback durch funktionsfähige Demos | Korrektheit und Vollständigkeit bestätigen |
| Testfälle | Testfälle vor Entwicklung erstellen | Testbarkeit und Klarheit sichern |
| ATDD/BDD | Acceptance Test-Driven Development, Behavior-Driven Development | Anforderungen automatisiert testen |
Hinweis: Mehr zur Validierung von Spezifikationen erfährst du in der Lerneinheit Qualitätssicherung und Validierung.
Zusammenfassung und Ausblick
Zusammenfassung
Die Anforderungsanalyse bildet die Analyse-Phase des SDLC und schafft die Grundlage für erfolgreiche Software-Projekte.
Stakeholder-Identifikation: Du hast gelernt, Stakeholder zu kategorisieren (direkte, indirekte, Entscheider, Projektteam, Externe) und mit der Power/Interest Matrix zu priorisieren. Key Players (hohe Power, hohes Interesse) werden eng eingebunden, während andere nur informiert oder beobachtet werden.
Anforderungserhebung: Verschiedene Methoden (Interviews, Fragebögen, Workshops, Beobachtung) helfen, Anforderungen zu sammeln. Die strukturierte Dokumentation umfasst: Anforderungs-ID, Beschreibung, Quelle, Priorität und Verifizierung.
Funktionale vs. nicht-funktionale Anforderungen: Funktionale Anforderungen beschreiben WAS das System tun soll (z.B. “Nutzer kann sich anmelden”). Nicht-funktionale Anforderungen legen fest, WIE GUT es arbeitet (z.B. “Anmeldezeit < 3 Sekunden”). NFRs müssen messbar sein: [Messgröße] [Operator] [Zielwert] [Bedingung].
Priorisierung: Die MoSCoW-Methode kategorisiert Anforderungen in Must have, Should have, Could have und Won’t have. Best Practice: Maximal 60% Must-haves, maximal 20% Could-haves.
Use Cases und User Stories: Use Cases beschreiben Interaktionen (Titel, Akteure, Vorbedingungen, Hauptszenario, Alternativszenarien). User Stories folgen dem Format: “Als [Rolle] möchte ich [Funktion], sodass [Nutzen]“. Akzeptanzkriterien definieren, wann eine Story erfüllt ist (konkret, messbar, aus Nutzersicht).
Validierung: Reviews, Prototyping, Testfälle und moderne Ansätze (ATDD, BDD) stellen sicher, dass Anforderungen korrekt, vollständig und durchführbar sind.
Ausblick
In der nächsten Lerneinheit lernst du, wie du aus den analysierten Anforderungen Datenmodelle und Strukturen ableitest. Du erfährst, wie Entitäten, Beziehungen und Attribute modelliert werden und wie du konzeptionelle Modelle in technische Spezifikationen überführst.