Requirement Elicitation
Eine strukturierte Methode zur systematischen Erfassung von Stakeholder-Bedürfnissen, Annahmen und Akzeptanzkriterien zur Definition von Produkt- und Lösungsumfang.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypOrganisation
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Unvollständige Stakeholder-Analyse führt zu fehlenden Anforderungen.
- Missverstandene Anforderungen erzeugen teure Korrekturen später im Projekt.
- Überdokumentation verzögert Umsetzung und reduziert Agilität.
- Kleine, fokussierte Workshops statt großer Sammelsessions.
- Explizite Aufnahme von Annahmen und offenen Fragen.
- Routinemäßige Validierung der Anforderungen in Iterationen.
I/O & Ressourcen
- Stakeholder-Register und Kontaktinformationen
- Vorhandene Prozess- und Systemdokumentation
- Geschäftsziele und Produktvision
- Abgestimmte und priorisierte Anforderungen
- Akzeptanzkriterien und Testgrundlagen
- Risiko- und Annahmenprotokoll
Beschreibung
Requirement Elicitation ist eine strukturierte Methode zur Erfassung von Stakeholder-Bedürfnissen, Randbedingungen und Akzeptanzkriterien zur Gestaltung von Produktumfang und Lösung. Sie kombiniert Interviews, Workshops, Beobachtung und Dokumentenanalyse, um ein gemeinsames Verständnis zu schaffen. Fokus liegt auf Abstimmung, Rückverfolgbarkeit und früher Validierung zur Reduktion von Nacharbeit.
✔Vorteile
- Reduktion von Nacharbeit durch frühere Klärung von Erwartungen.
- Bessere Abstimmung zwischen Fach- und Technikteams.
- Nachvollziehbare Anforderungen mit klaren Akzeptanzkriterien.
✖Limitationen
- Erfolgt ohne gute Moderation, kann es zu dominanten Stimmen kommen.
- Zeitintensiv bei hoher Stakeholder-Anzahl.
- Nur so gut wie die repräsentierten Stakeholder und Datenquellen.
Trade-offs
Metriken
- Anzahl der Rückfragen während der Implementierung
Misst, wie oft Anforderungen während der Umsetzung unklar sind.
- Änderungsrate der Anforderungen
Anteil der Anforderungen, die nach Planung noch geändert werden.
- Stakeholder-Zufriedenheit mit erfassten Anforderungen
Subjektive Bewertung der Stakeholder zur Vollständigkeit und Korrektheit.
Beispiele & Implementierungen
Bank: Erhebung regulatorischer Reporting-Anforderungen
Workshops mit Compliance, IT und Fachbereichen führten zu einer standardisierten Berichtsspezifikation und klarem Umsetzungsplan.
E-Commerce: MVP-Anforderungen definieren
Interviews und Priorisierungsworkshops reduzierten Umfang und ermöglichten schnelle Markteinführung des Kernfeatures.
IoT-Integration: Partneranforderungen abstimmen
Technische Workshops mit Partnern klärten Schnittstellen und Testkriterien und vermieden spätere Integrationsfehler.
Implementierungsschritte
Stakeholder identifizieren und einladen.
Ziele, Annahmen und Scope gemeinsam definieren.
Kombination aus Interviews, Workshops und Beobachtung durchführen.
Ergebnisse konsolidieren, priorisieren und dokumentieren.
Anforderungen mit Stakeholdern validieren und freigeben.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unklare Anforderungen, die zu wiederholten Nachbesserungen führen.
- Fehlende Traceability zwischen Anforderungen und Tests.
- Veraltete Spezifikationen ohne Pflegeprozess.
Bekannte Engpässe
Beispiele für Missbrauch
- Nur Management interviewen und Endnutzer ignorieren.
- Formale Dokumente erstellen, ohne Stakeholder-Feedback einzuholen.
- Annahmen nicht dokumentieren und später überraschen lassen.
Typische Fallen
- Zu früh zu viel Detail einfordern (Paralyse durch Analyse).
- Stakeholder als homogene Gruppe behandeln.
- Ergebnisse nicht versionieren und nachverfolgbar halten.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Zeitliche Begrenzung vor Releases
- • Vertraulichkeitsanforderungen bei sensiblen Daten
- • Begrenzte Ressourcen für Moderation und Analyse