Anforderungsmanagement und -analyse
In dieser Lerneinheit tauchst du in das professionelle Anforderungsmanagement ein und lernst, wie du Qualitätsanforderungen systematisch erhebst und dokumentierst. Du verstehst die wichtigsten Methoden und Werkzeuge zur strukturierten Erfassung von Anforderungen und kannst diese direkt in deinen Entwicklungsprojekten anwenden. Diese Grundlagen sind entscheidend für den Projekterfolg, da gut dokumentierte Anforderungen die Basis für qualitativ hochwertige Softwareentwicklung bilden.
Einführung
Stell dir vor: Ein Entwicklerteam arbeitet monatelang an einer neuen Software. Kurz vor dem Launch stellt sich heraus, dass wichtige Funktionen fehlen, weil niemand die Anforderungen richtig verstanden hat. Das Projekt scheitert.
Das ist kein Einzelfall:
- Über 50% aller Projektprobleme gehen auf unklare Anforderungen zurück
- Die Kosten für Anforderungsfehler steigen exponentiell, je später sie entdeckt werden
- Ein Fehler, der in der Anforderungsphase 1€ kostet, kostet in der Wartung bis zu 100€
In dieser Lerneinheit erfährst du, wie du Anforderungen systematisch erhebst, dokumentierst und verfolgst, damit deine Projekte von Anfang an auf solidem Fundament stehen.
Lernziele
Nach dieser Lerneinheit kannst du:
- Funktionale und nicht-funktionale Anforderungen unterscheiden und klassifizieren
- Anforderungen mit MoSCoW und dem Kano-Modell priorisieren
- Use Cases und User Stories formulieren und voneinander abgrenzen
- Traceability herstellen und eine Impact-Analyse durchführen
- Die 8 Qualitätsmerkmale der ISO 25010 benennen und anwenden
Überleitung
Wie gehen wir vor?
Bevor wir Anforderungen dokumentieren können, müssen wir sie erst einmal erheben. Dazu schauen wir uns zunächst an:
- Welche Arten von Anforderungen es gibt
- Wie wir sie von den richtigen Stakeholdern bekommen
- Welche Erhebungstechniken sich bewährt haben
Anforderungstypen verstehen
Im Anforderungsmanagement unterscheiden wir drei Hauptkategorien:
- Funktionale Anforderungen: Was das System tun soll (z.B. “Benutzer kann sich anmelden”)
- Qualitätsanforderungen: Wie gut das System Funktionen ausführen soll (z.B. “Antwortzeit unter 500ms”)
- Randbedingungen: Technische, organisatorische und rechtliche Vorgaben (z.B. “Muss DSGVO-konform sein”)
Nach aktueller IREB-Terminologie wird “nicht-funktionale Anforderungen” zunehmend durch “Qualitätsanforderungen” ersetzt. Beide Begriffe meinen dasselbe.
Stakeholder identifizieren
Stakeholder sind alle Personen oder Organisationen, die ein Interesse am Projekt haben oder davon betroffen sind.
Typische Stakeholder in Softwareprojekten:
- Endnutzer: Verwenden die Software täglich
- Auftraggeber: Finanzieren das Projekt, definieren Geschäftsziele
- Entwicklerteam: Setzen die Anforderungen technisch um
- Testteam: Verifizieren die Umsetzung
- Betrieb/Operations: Betreiben die Software nach dem Go-Live
Jeder Stakeholder bringt unterschiedliche Perspektiven und Anforderungen ein.
Erhebungstechniken
Um Anforderungen von Stakeholdern zu erhalten, nutzen wir verschiedene Techniken:
- Interviews: Einzelgespräche mit Stakeholdern. Gut für detaillierte Informationen und sensible Themen.
- Workshops: Mehrere Stakeholder arbeiten gemeinsam. Fördert Konsens und deckt Widersprüche früh auf.
- Beobachtung: Nutzer bei ihrer Arbeit beobachten. Zeigt reale Arbeitsabläufe und unausgesprochene Bedürfnisse.
- Dokumentenanalyse: Bestehende Dokumente, Altanwendungen oder Prozessbeschreibungen auswerten.
- Prototyping: Frühe Visualisierung, um Feedback zu sammeln und Anforderungen zu konkretisieren.
In der Praxis kombiniert man oft mehrere Techniken, um ein vollständiges Bild zu erhalten.
Use Cases vs. User Stories
Beide beschreiben Anforderungen aus Nutzersicht, unterscheiden sich aber deutlich:
| Aspekt | User Story | Use Case |
|---|---|---|
| Länge | 1-2 Sätze | Mehrere Absätze |
| Perspektive | Nutzersicht (“Als… möchte ich…“) | Systemsicht (Akteur, System, Szenarien) |
| Detailgrad | Grob, Platzhalter für Gespräch | Detailliert mit Vor-/Nachbedingungen |
| Ideal für | Agile Sprints, schnelle Iterationen | Komplexe Systeme, Dokumentationspflicht |
In der Praxis werden oft beide kombiniert: User Stories für die Planung, Use Cases für die Spezifikation.
Use Case Beispiel
Ein Use Case beschreibt eine vollständige Interaktion zwischen Akteur und System:
Use Case: Bestellhistorie anzeigen
Akteur: Registrierter Kunde
Vorbedingung: Kunde ist eingeloggt
Hauptszenario:
1. Kunde öffnet "Meine Bestellungen"
2. System lädt alle Bestellungen des Kunden
3. System zeigt Bestellungen chronologisch sortiert
4. Kunde wählt eine Bestellung aus
5. System zeigt Bestelldetails an
Alternativszenario:
3a. Keine Bestellungen vorhanden
→ System zeigt Hinweis "Noch keine Bestellungen"
Nachbedingung: Kunde sieht gewünschte Bestellinformationen
Der Use Case zeigt die komplette Interaktion mit Vor- und Nachbedingungen sowie einem Alternativszenario. Diese Struktur macht Use Cases besonders wertvoll für komplexe Systeme mit vielen Sonderfällen.
User Story und INVEST
Eine User Story folgt dem Format: “Als [Rolle] möchte ich [Funktion], um [Nutzen] zu erreichen.”
Als registrierter Kunde möchte ich meine Bestellhistorie einsehen,
um frühere Käufe nachvollziehen zu können.
Gute User Stories erfüllen die INVEST-Kriterien:
- Independent: Unabhängig von anderen Stories
- Negotiable: Verhandelbar, nicht in Stein gemeißelt
- Valuable: Liefert Mehrwert für den Nutzer
- Estimable: Aufwand ist schätzbar
- Small: Klein genug für einen Sprint
- Testable: Akzeptanzkriterien sind prüfbar
Funktionale Anforderungen
Funktionale Anforderungen beschreiben, was ein System tun soll. Sie definieren konkrete Verhaltensweisen und Funktionen.
Beispiele:
- “Das System muss Benutzer per Benutzername und Passwort authentifizieren.”
- “Benutzer können nach Produkten suchen und diese filtern.”
- “Das System ermöglicht den Export von Berichten als PDF.”
Funktionale Anforderungen lassen sich direkt testen: Entweder funktioniert das Login oder nicht. Sie sind meist direkt mit Geschäftszielen verbunden und werden oft aus User Stories oder Use Cases abgeleitet.
Nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen (Qualitätsanforderungen) beschreiben, wie gut ein System seine Funktionen ausführen soll.
Beispiele:
- Performance: “Die Suchergebnisse müssen innerhalb von 500ms angezeigt werden.”
- Sicherheit: “Passwörter müssen mit bcrypt gehasht gespeichert werden.”
- Verfügbarkeit: “Das System muss 99,9% der Zeit erreichbar sein.”
- Usability: “Neue Benutzer sollen die Grundfunktionen ohne Schulung nutzen können.”
Diese Anforderungen sind oft schwieriger zu testen und erfordern spezielle Testmethoden wie Lasttests oder Sicherheitsaudits.
ISO 25010 Qualitätsmerkmale
Die ISO/IEC 25010 definiert 8 Qualitätsmerkmale für Softwareprodukte:
| Merkmal | Beschreibung | Beispiel |
|---|---|---|
| Funktionale Eignung | Erfüllt die Software ihre Aufgaben? | Login funktioniert zuverlässig |
| Leistungseffizienz | Wie schnell und ressourcenschonend? | Antwortzeit < 500ms |
| Kompatibilität | Zusammenarbeit mit anderen Systemen | REST-API-Schnittstellen |
| Benutzbarkeit | Wie einfach zu bedienen? | Intuitive Navigation |
| Zuverlässigkeit | Wie stabil und fehlertolerant? | 99,9% Verfügbarkeit |
| Sicherheit | Schutz vor unbefugtem Zugriff | Verschlüsselte Passwörter |
| Wartbarkeit | Wie einfach zu ändern und testen? | Modularer Code |
| Portabilität | Auf verschiedenen Plattformen nutzbar? | Läuft auf Windows/Linux |
Diese Merkmale helfen, Qualitätsanforderungen systematisch zu definieren und zu prüfen.
Praxisbeispiele
Die Unterscheidung zwischen funktionalen und nicht-funktionalen Anforderungen wird an diesen Beispielen deutlich:
| System | Funktional | Nicht-funktional |
|---|---|---|
| Online-Shop | Produkte suchen, in Warenkorb legen, bezahlen | Seite lädt in < 2 Sekunden, SSL-Verschlüsselung |
| Banking-App | Kontostand prüfen, Überweisungen tätigen | Zwei-Faktor-Authentifizierung, Audit-Logging |
| Lernplattform | Kurse anzeigen, Fortschritt speichern | Offline-Modus, barrierefrei nach WCAG 2.1 |
Bei der Anforderungserhebung solltest du beide Typen aktiv erfragen, da Stakeholder oft nur funktionale Anforderungen nennen.
Dokumentation von Anforderungen
Eine gute Anforderungsdokumentation ist die Grundlage für erfolgreiche Projekte. Wichtige Prinzipien:
- Eindeutigkeit: Jede Anforderung hat genau eine Interpretation
- Nachverfolgbarkeit: Eindeutige IDs ermöglichen Rückverfolgung (z.B. REQ-001)
- Testbarkeit: Klare Akzeptanzkriterien definieren
- Versionierung: Änderungen nachvollziehbar dokumentieren
- Priorisierung: Wichtigkeit und Dringlichkeit festlegen
Moderne Anforderungsdokumente enthalten neben der Beschreibung auch Quelle, Priorität, Verknüpfungen und Akzeptanzkriterien.
Anforderungsbeispiel REQ-001
Ein vollständiges Anforderungsdokument enthält alle relevanten Informationen:
Anforderungs-ID: REQ-001
Titel: Benutzeranmeldung mit Sicherheit
Typ: Funktionale Anforderung
Quelle: Stakeholder-Workshop, Security Audit SA-12
Priorität: Must Have (MoSCoW)
Kano-Kategorie: Basisanforderung
Beschreibung:
Das System muss Benutzern die Anmeldung per Benutzername/Passwort
ermöglichen. Nach drei Fehlversuchen wird das Konto 15 Min. gesperrt.
Akzeptanzkriterien:
- Eingabefelder für Benutzername und Passwort vorhanden
- Nach drei Fehlversuchen: Kontosperrung für 15 Minuten
Verknüpfte Qualitätsanforderungen:
- REQ-SEC-001: Passwörter verschlüsselt speichern
- REQ-PERF-001: Login innerhalb 500ms
Traceability:
- Upstream: Business Requirement BR-005
- Downstream: Design DD-Auth, Tests TC-001 bis TC-005
Dieses Beispiel zeigt eine vollständige Anforderung mit Metadaten, Akzeptanzkriterien und Traceability-Links. Die Verknüpfung zu anderen Anforderungen macht Abhängigkeiten sichtbar und erleichtert die Impact-Analyse bei Änderungen.
MoSCoW-Methode
Die MoSCoW-Methode priorisiert Anforderungen in vier Kategorien:
| Kategorie | Bedeutung | Anteil |
|---|---|---|
| Must Have | Unverzichtbar, Projekt scheitert ohne | ~60% |
| Should Have | Wichtig, aber nicht kritisch | ~20% |
| Could Have | Wünschenswert, wenn Zeit bleibt | ~20% |
| Won’t Have | Nicht in diesem Release | Backlog |
Tipp: Die Verteilung 60/20/20 hilft, realistisch zu planen. Wenn alles “Must Have” ist, ist nichts priorisiert.
Beispiel: Für einen MVP eines Online-Shops wäre “Warenkorb” Must Have, “Wunschliste” Could Have.
Kano-Modell
Das Kano-Modell kategorisiert Anforderungen nach ihrer Wirkung auf die Kundenzufriedenheit:
Basisanforderungen (Must-be):
- Werden als selbstverständlich erwartet
- Fehlen sie, ist der Kunde unzufrieden
- Ihre Erfüllung macht aber nicht zufriedener
- Beispiel: Ein Auto muss fahren können
Leistungsanforderungen (One-dimensional):
- Je besser erfüllt, desto zufriedener der Kunde
- Klassische “mehr ist besser” Anforderungen
- Beispiel: Kraftstoffverbrauch des Autos
Begeisterungsmerkmale (Attractive):
- Nicht erwartet, aber wenn vorhanden, begeistert
- Fehlen verursacht keine Unzufriedenheit
- Beispiel: Sitzheizung, die sich an Außentemperatur anpasst
Das Kano-Modell hilft, Ressourcen auf Features zu konzentrieren, die echten Mehrwert bieten.
Traceability verstehen
Traceability (Rückverfolgbarkeit) ist die Fähigkeit, den Weg jeder Anforderung durch den gesamten Entwicklungsprozess zu verfolgen.
Warum ist das wichtig?
- Vollständigkeitsprüfung: Ist jede Anforderung implementiert und getestet?
- Änderungsmanagement: Was ist betroffen, wenn sich eine Anforderung ändert?
- Compliance: Nachweis der Umsetzung für Audits und Zertifizierungen
- Wartung: Schnelles Auffinden betroffener Komponenten bei Fehlern
Traceability verbindet Anforderungen mit Design-Dokumenten, Code, Tests und Benutzerhandbüchern zu einem nachvollziehbaren Netzwerk.
Vorwärts- und Rückwärtstraceability
Es gibt zwei Richtungen der Rückverfolgbarkeit:
Vorwärtstraceability (Forward): Von der Anforderung zur Implementierung. Zeigt, wie jede Anforderung durch Design, Code und Tests realisiert wird. Frage: “Welcher Code implementiert REQ-001?”
Rückwärtstraceability (Backward): Von der Implementierung zurück zur Anforderung. Zeigt, welche Anforderung eine Komponente rechtfertigt. Frage: “Warum gibt es diese Funktion im Code?”
Beide Richtungen zusammen ermöglichen:
- Lückenanalyse: Gibt es nicht implementierte Anforderungen?
- Goldplating-Erkennung: Gibt es Code ohne zugehörige Anforderung?
Rückverfolgbarkeitsmatrix
Eine Traceability-Matrix visualisiert die Verbindungen zwischen Artefakten. Sie zeigt, wie Anforderungen durch den gesamten Entwicklungsprozess verfolgt werden können:
Beispiel einer Traceability-Kette:
| Ebene | Artefakt | Beschreibung |
|---|---|---|
| Business | BR-005 | Sichere Benutzerverwaltung |
| Anforderung | REQ-001 | Benutzeranmeldung mit Sicherheit |
| Qualität | REQ-SEC-001 | Passwort-Verschlüsselung |
| Design | DD-Auth | Authentication Design Document |
| Code | AuthService | AuthenticationService Klasse |
| Test | TC-001 | Login-Testfall |
Was zeigt diese Matrix?
- Von der Geschäftsanforderung (BR-005) zur technischen Anforderung (REQ-001)
- Vom Design (DD-Auth) zum Code (AuthenticationService)
- Vom Code zum Test (TC-001)
Jedes Element ist mit seinen Vorgängern und Nachfolgern verbunden. So lässt sich jederzeit nachvollziehen, warum eine Komponente existiert und welche Tests sie abdecken.
Werkzeuge für Anforderungsmanagement
Je nach Projektgröße eignen sich unterschiedliche Werkzeuge:
Für kleinere Teams und agile Projekte:
| Tool | Stärke |
|---|---|
| Jira | Issue-Tracking mit Requirements-Verwaltung |
| Azure DevOps | Integrierte Boards und Pipelines |
| GitHub Issues/Projects | Für DevOps-orientierte Teams |
| Trello | Einfaches Kanban (für initiale Sammlung) |
Für große Projekte und regulierte Industrien:
| Tool | Stärke |
|---|---|
| Jama Connect | Spezialisiert auf Traceability und Compliance |
| Helix ALM | Automatische Traceability Matrix |
| Polarion | ALM-Plattform für komplexe Systeme |
Die Wahl des richtigen Werkzeugs hängt von Teamgröße, Budget und regulatorischen Anforderungen ab. Für den Einstieg reichen oft einfache Tools wie Jira oder GitHub Issues. Spezialisierte ALM-Plattformen lohnen sich erst bei komplexen Projekten mit hohen Compliance-Anforderungen.
Impact-Analyse verstehen
Die Impact-Analyse bewertet die Auswirkungen von Änderungen auf das gesamte System, bevor sie umgesetzt werden.
Hauptziele:
- Betroffene Komponenten identifizieren: Was muss alles geändert werden?
- Aufwand schätzen: Wie viel Arbeit verursacht die Änderung?
- Risiken bewerten: Welche Nebenwirkungen könnten auftreten?
- Entscheidungsgrundlage: Lohnt sich die Änderung?
Ohne Impact-Analyse werden Änderungen oft unterschätzt. Eine kleine Anforderungsänderung kann Auswirkungen auf Design, Code, Tests und Dokumentation haben.
Impact-Analyse Beispiel
Szenario: Neue Anforderung “SMS-Verifizierung bei Registrierung”
Schritte der Impact-Analyse:
- Betroffene Anforderungen identifizieren: REQ-001 (Registrierung), REQ-SEC-002 (Datenschutz)
- Betroffene Komponenten finden: RegistrationService, UserDatabase, NotificationService (neu)
- Tests prüfen: TC-001 bis TC-010 müssen angepasst werden, neue Tests TC-011 bis TC-015
- Aufwand schätzen: Siehe Tabelle unten
| Komponente | Aufwand | Risiko |
|---|---|---|
| SMS Service (neu) | 40h | Hoch |
| RegistrationService | 16h | Mittel |
| User Database | 8h | Hoch |
| Gesamt | 64h |
Diese Analyse zeigt: Eine scheinbar kleine Änderung kann erheblichen Aufwand verursachen. Besonders kritisch sind die hohen Risiken bei SMS Service und Datenbank, da externe Abhängigkeiten (SMS-Provider) und sensible Daten (Telefonnummern) betroffen sind. Ohne Impact-Analyse hätte das Team den Aufwand vermutlich unterschätzt.
Risikobewertung bei Änderungen
Schritt 5: Risikobewertung mit Ampelsystem
Nach der Aufwandsschätzung werden Risiken bewertet:
🔴 Hohes Risiko:
- SMS-Provider Abhängigkeit (externer Dienst)
- Datenbankschema-Änderung (Migration erforderlich)
🟡 Mittleres Risiko:
- DSGVO-Konformität prüfen (Telefonnummern sind personenbezogene Daten)
- Internationale Nummern unterstützen
🟢 Niedriges Risiko:
- UI-Änderungen (isoliert, gut testbar)
- E-Mail-Benachrichtigungen anpassen
Entscheidung: Die Analyse zeigt 64h Aufwand und hohe Risiken. Das Team entscheidet nun informiert, ob die Änderung umgesetzt wird oder alternative Lösungen geprüft werden.
Zusammenfassung und Ausblick
Zusammenfassung
Anforderungsmanagement ist das Fundament erfolgreicher Softwareprojekte. Gut dokumentierte Anforderungen reduzieren Missverständnisse, vermeiden teure Nacharbeiten und schaffen eine gemeinsame Basis für alle Projektbeteiligten.
Die wichtigsten Erkenntnisse dieser Lerneinheit:
-
Funktionale vs. Qualitätsanforderungen: Funktionale Anforderungen beschreiben, WAS das System tun soll. Qualitätsanforderungen (nach ISO 25010) definieren, WIE GUT diese Funktionen ausgeführt werden sollen. Beide Typen müssen von Anfang an erfasst werden.
-
Erhebungstechniken: Interviews, Workshops, Beobachtung und Dokumentenanalyse liefern unterschiedliche Perspektiven. Die Kombination mehrerer Techniken führt zu vollständigeren Anforderungen.
-
Use Cases und User Stories: Use Cases eignen sich für komplexe Systeme mit vielen Sonderfällen. User Stories mit INVEST-Kriterien passen besser zu agilen Projekten. Beide Formate haben ihre Berechtigung.
-
Priorisierung: MoSCoW (Must/Should/Could/Won’t) hilft bei der Ressourcenplanung. Das Kano-Modell zeigt, welche Features Begeisterung auslösen und welche nur Grunderwartungen erfüllen.
-
Traceability: Die Verknüpfung von Anforderungen zu Design, Code und Tests macht Änderungen nachvollziehbar und vereinfacht die Impact-Analyse erheblich.
| Konzept | Kernaussage |
|---|---|
| Anforderungstypen | Funktional (Was?) vs. Qualität (Wie gut?) vs. Randbedingungen |
| ISO 25010 | 8 Qualitätsmerkmale als Checkliste für NFRs |
| Priorisierung | MoSCoW oder Kano je nach Projektkontext |
| Traceability | Vorwärts- und Rückwärtsverfolgung aller Artefakte |
Ausblick
In der nächsten Lerneinheit Entwurf und Architektur erfährst du, wie aus gut dokumentierten Anforderungen ein tragfähiges Software-Design entsteht. Du lernst Architekturmuster kennen und verstehst, wie Qualitätsanforderungen die Architekturentscheidungen beeinflussen.