Worum es bei Anforderungsanalyse wirklich geht
Was du nach diesem Artikel kannst
- Anforderungen als Use Cases statt Feature-Liste formulieren
- Stakeholder, Prozesse und Datenobjekte strukturiert erfassen
- Priorisieren (Impact, Häufigkeit, Risiko) und MVP definieren
- Abnahmekriterien definieren, damit Demos/PoCs vergleichbar werden
Was dieser Artikel bewusst NICHT ist
- Keine Tool-Empfehlung (das ist die nächste Phase: Systemauswahl)
- Keine 200-seitige Methodik – sondern ein praxisnaher Prozess
- Kein "Requirements Theater": Fokus auf Entscheidung und Umsetzung
Beraterregel: Eine Anforderungsanalyse ist dann gut, wenn sie Entscheidungen ermöglicht: MVP, Prioritäten, No-Gos und testbare Abnahmekriterien. Nicht, wenn sie besonders viele Seiten hat.
Weiterführend
Systemauswahl Methodik
Framework vom Zielbild bis PoC, TCO und Vertragsdesign.
Zum Framework →Anforderungskatalog (Lead-Magnet)
Excel-Template als Startpunkt für Use Cases und Priorisierung.
Zum Download →ERP Fehler vermeiden
Viele Prinzipien gelten 1:1 für Anforderungen und Auswahl.
Zum Listicle →Schritt-für-Schritt: Anforderungsanalyse für Software
Das folgende Vorgehen ist bewusst pragmatisch. Es funktioniert für viele Systemklassen (ERP, PIM, CRM, MDM, iPaaS), weil es vom Problem über Prozesse zu testbaren Use Cases führt.
1) Problem-Statement (1 Seite) – warum überhaupt Software?
Eine Anforderungsanalyse startet nicht mit Features, sondern mit einem klaren Problem: Was läuft heute schief – und woran würdet ihr Verbesserung messen?
- Problem-Statement (Kontext, Symptome, Auswirkungen, Zielgröße)
- Business-Ziele (z.B. Durchlaufzeit, Datenqualität, Skalierung, Compliance)
- In/Out of Scope (was gehört bewusst NICHT dazu)
- ‘Wir brauchen Tool X’ statt Problemdefinition
- Ziele ohne Messbarkeit (‘besser’, ‘schneller’)
Wenn du hier stecken bleibst: setze eine Zeitbox und entscheide bewusst, was für MVP reicht. Perfektion ist selten wirtschaftlich.
2) Stakeholder & Entscheidungslogik (wer muss was entscheiden?)
Ohne klare Rollen wird die Analyse zur Sammelstelle. Du brauchst Ownership: wer definiert Prozesse, wer entscheidet Trade-offs, wer betreibt später?
- Stakeholder-Map (Fachbereiche, IT, Finance, Compliance)
- Rollen: Product Owner, Key User, Data Owner, Process Owner
- Entscheidungsgremium + Terminplan (nicht ‘ad hoc’)
- Fachbereich ist Zuschauer, IT trägt alles
- Key User haben keine Kapazität (alles nebenbei)
Wenn du hier stecken bleibst: setze eine Zeitbox und entscheide bewusst, was für MVP reicht. Perfektion ist selten wirtschaftlich.
3) Ist-Prozesse & Pain Points (so wenig wie nötig, so klar wie möglich)
Du brauchst kein perfektes BPMN-Museum. Du brauchst klare Prozessketten und reale Engpässe: Medienbrüche, manuelle Schritte, Doppelpflege, Fehlerquellen.
- 3–7 Kernprozesse (Swimlane oder einfaches Flussdiagramm)
- Pain Points je Prozess (Ursache, Impact, Häufigkeit)
- Datenobjekte je Prozess (z.B. Kunde, Artikel, Preis, Bestellung)
- Zu viel Dokumentation, zu wenig Entscheidung
- ‘Happy Path only’ – Grenzfälle fehlen
Wenn du hier stecken bleibst: setze eine Zeitbox und entscheide bewusst, was für MVP reicht. Perfektion ist selten wirtschaftlich.
4) Soll-Prozesse als Use Cases (der wichtigste Schritt)
Use Cases machen Anforderungen testbar. Sie sind die Basis für Demos, PoCs und später UAT. Eine gute Anforderungsanalyse endet nicht mit Features, sondern mit Prozessfällen.
- Use-Case Backlog (10–25 Fälle) inkl. Akzeptanzkriterien
- Priorisierung (Impact × Häufigkeit × Risiko)
- No-Go Fälle (was MUSS gehen – sonst raus)
- Feature-Liste ohne Kontext
- Keine echten Beispieldaten / keine Grenzfälle
Wenn du hier stecken bleibst: setze eine Zeitbox und entscheide bewusst, was für MVP reicht. Perfektion ist selten wirtschaftlich.
5) Datenanforderungen & Ownership (Golden Source pro Feld)
Viele Software-Projekte scheitern nicht an Modulen, sondern an Daten: Dubletten, fehlende Pflichtfelder, unklare Quellen. Kläre Datenhoheit früh.
- Datenobjekte & Felder (Minimum Dataset für MVP)
- Ownership je Feld (führendes System / editierbar / read-only)
- Datenqualitätsregeln (Validierungen, Dublettenlogik, Pflichtfelder)
- ‘Daten machen wir später’
- Mehrere Systeme sind gleichzeitig ‘führend’
Wenn du hier stecken bleibst: setze eine Zeitbox und entscheide bewusst, was für MVP reicht. Perfektion ist selten wirtschaftlich.
6) Nicht-funktionale Anforderungen (NFRs) – oft der Dealbreaker
Performance, Rechte, Audit, Reporting, Verfügbarkeit – das sind typische No-Go Kriterien. NFRs müssen in die Analyse, sonst brechen sie später als Überraschung auf.
- Rollen/Rechte (wer sieht was?)
- Reporting/KPIs (Definitionen, Aktualität, Dimensionen)
- Schnittstellen/Integration (Monitoring, Reprocessing, SLA/SLO Bedarf)
- NFRs werden als ‘später’ abgetan
- Keine Betriebssicht für Integrationen
Wenn du hier stecken bleibst: setze eine Zeitbox und entscheide bewusst, was für MVP reicht. Perfektion ist selten wirtschaftlich.
7) MVP, Roadmap & Abnahmekriterien (Definition of Done)
Die Analyse ist erst dann ‘fertig’, wenn sie Entscheidungen ermöglicht: MVP-Scope, Prioritäten und klare Abnahmekriterien.
- MVP-Scope (Prozesse, Teams, Standorte) + Roadmap v2/v3
- Abnahmekriterien pro Use Case (testbar, messbar)
- Risikoliste + Annahmen (was muss im PoC geprüft werden?)
- MVP wird nie entschieden
- Abnahme bleibt ‘Gefühl’
Wenn du hier stecken bleibst: setze eine Zeitbox und entscheide bewusst, was für MVP reicht. Perfektion ist selten wirtschaftlich.
Methoden & Formate (leichtgewichtig, aber robust)
Methoden: Was in der Praxis gut funktioniert
- Workshops mit Zeitbox (90–120 Min) pro Prozess, danach Konsolidierung
- Use Cases mit Akzeptanzkriterien (Given/When/Then oder klarer Bullet-Check)
- Priorisierung über Impact/Häufigkeit/Risiko statt lauteste Stimme
- Echte Beispieldaten (20 Datensätze) + Grenzfälle bewusst einbauen
Formate: User Stories vs Use Cases
- User Stories sind gut für Backlog & Umsetzung, aber oft zu klein für Systemauswahl
- Use Cases eignen sich besser, um Demos/PoCs vergleichbar zu machen
- Empfehlung: Use Cases als Auswahlbasis, Stories später für Implementierung
Prozessmodellierung: leichtgewichtig
- Swimlane-Diagramm reicht häufig (wer macht was?)
- BPMN nur dort, wo Compliance/Audit es verlangt
- Entscheidend: Grenzfälle (Teillieferung, Retoure, Sonderpreis, Dublette)
Typische Fehler (und wie du sie vermeidest)
Fehler 1: Anforderungsanalyse = Feature-Sammeln
Fix: Schreibe Anforderungen als Prozessfälle (Use Cases) und definiere Akzeptanzkriterien. Features sind abgeleitete Mittel, nicht das Ziel.
Fehler 2: Keine Datenhoheit
Fix: Lege pro Feld fest, welches System führend ist. Ohne Ownership entsteht doppelte Pflege und ihr automatisiert Inkonsistenz.
Fehler 3: Kein MVP / Scope zu groß
Fix: Definiere die erste stabile Wertkette (MVP) und plane v2/v3. Big Bang ist fast immer der teuerste Weg.
Fehler 4: NFRs vergessen (Rechte, Audit, Reporting, Betrieb)
Fix: NFRs als No-Go Kriterien aufnehmen und früh prüfen. Besonders Integrationsbetrieb (Monitoring/Reprocessing) gehört in die Analyse.
Übergang zur Systemauswahl: Was du aus der Analyse ableitest
Wann ist die Anforderungsanalyse ‘gut genug’ für Systemauswahl?
- 10–25 priorisierte Use Cases inkl. Akzeptanzkriterien
- MVP-Scope definiert (Teams/Prozesse/Standorte) + Roadmap v2/v3
- No-Go Kriterien und NFRs dokumentiert
- Datenobjekte + Ownership + Integrationslandkarte
Nächster Schritt: Systemklasse & Vergleichbarkeit
- Systemklasse bestätigen (ERP, PIM, CRM, MDM, iPaaS) – Problemtyp matchen
- Demo-Skripte aus euren Use Cases ableiten
- Bewertungsmatrix mit Gewichtung (nicht nur ungewichtete Summen)
Wenn du willst, ist der nächste Schritt ein strukturierter Vergleich: Demo-Skripte, gewichtete Matrix, Mini-PoC. Dazu passt der Methodik-Artikel: IT Systemauswahl Methodik →
Erstberatung: Anforderungsanalyse "good enough" für Auswahl & Umsetzung
Ich unterstütze systemunabhängig dabei, eure Anforderungen so zu strukturieren, dass sie eine belastbare Entscheidung ermöglichen: Use Cases, MVP, No-Gos/NFRs, Datenhoheit und Demo-Vergleichbarkeit. Ergebnis: weniger Überraschungen im PoC und im Go-Live.
Tipp: Bring 10 Kernprozesse/Use Cases, Stakeholderliste und eure Integrationspunkte mit.