Anforderungsanalyse Software: Prozess, Methoden & typische Fehler (Awareness-Phase)

    In der Awareness-Phase geht es nicht um die Frage nach dem richtigen Tool, sondern um: Welches Problem lösen wir, welche Prozesse sind betroffen, und wie messen wir Erfolg? Dieser Ratgeber zeigt eine pragmatische Anforderungsanalyse, die Systemauswahl und Umsetzung vorbereitet – ohne Requirements-Theater und ohne Vendor-Pitch.

    Zum VorgehenMethodenAnforderungskatalog VorlageErstberatung

    Worum es bei Anforderungsanalyse wirklich geht

    Was Sie nach diesem Artikel können

    • 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.

    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ürden Sie Verbesserung messen?

    Ergebnisse
    • 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)
    Typische Fehler
    • Wir brauchen Tool X – statt Problemdefinition
    • Ziele ohne Messbarkeit (‘besser’, ‘schneller’)
    Praxis-Tipp

    Wenn Sie hier nicht weiterkommen: setzen Sie eine Zeitbox und entscheiden Sie 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. Sie brauchen Ownership: wer definiert Prozesse, wer entscheidet Trade-offs, wer betreibt später?

    Ergebnisse
    • Stakeholder-Map (Fachbereiche, IT, Finance, Compliance)
    • Rollen: Product Owner, Key User, Data Owner, Process Owner
    • Entscheidungsgremium + Terminplan (nicht ‘ad hoc’)
    Typische Fehler
    • Fachbereich ist Zuschauer, IT trägt alles
    • Key User haben keine Kapazität (alles nebenbei)
    Praxis-Tipp

    Wenn Sie hier nicht weiterkommen: setzen Sie eine Zeitbox und entscheiden Sie 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)

    Sie brauchen kein perfektes BPMN-Museum. Sie brauchen klare Prozessketten und reale Engpässe: Medienbrüche, manuelle Schritte, Doppelpflege, Fehlerquellen.

    Ergebnisse
    • 3–7 Kernprozesse (Swimlane oder einfaches Flussdiagramm)
    • Pain Points je Prozess (Ursache, Impact, Häufigkeit)
    • Datenobjekte je Prozess (z.B. Kunde, Artikel, Preis, Bestellung)
    Typische Fehler
    • Zu viel Dokumentation, zu wenig Entscheidung
    • Happy Path only – Grenzfälle fehlen
    Praxis-Tipp

    Wenn Sie hier nicht weiterkommen: setzen Sie eine Zeitbox und entscheiden Sie 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.

    Ergebnisse
    • Use-Case Backlog (10–25 Fälle) inkl. Akzeptanzkriterien
    • Priorisierung (Impact × Häufigkeit × Risiko)
    • No-Go Fälle (was MUSS gehen – sonst raus)
    Typische Fehler
    • Feature-Liste ohne Kontext
    • Keine echten Beispieldaten / keine Grenzfälle
    Praxis-Tipp

    Wenn Sie hier nicht weiterkommen: setzen Sie eine Zeitbox und entscheiden Sie 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.

    Ergebnisse
    • Datenobjekte & Felder (Minimum Dataset für MVP)
    • Ownership je Feld (führendes System / editierbar / read-only)
    • Datenqualitätsregeln (Validierungen, Dublettenlogik, Pflichtfelder)
    Typische Fehler
    • Daten machen wir später
    • Mehrere Systeme sind gleichzeitig führend
    Praxis-Tipp

    Wenn Sie hier nicht weiterkommen: setzen Sie eine Zeitbox und entscheiden Sie 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.

    Ergebnisse
    • Rollen/Rechte (wer sieht was?)
    • Reporting/KPIs (Definitionen, Aktualität, Dimensionen)
    • Schnittstellen/Integration (Monitoring, Reprocessing, SLA/SLO Bedarf)
    Typische Fehler
    • NFRs werden als später abgetan
    • Keine Betriebssicht für Integrationen
    Praxis-Tipp

    Wenn Sie hier nicht weiterkommen: setzen Sie eine Zeitbox und entscheiden Sie 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.

    Ergebnisse
    • MVP-Scope (Prozesse, Teams, Standorte) + Roadmap v2/v3
    • Abnahmekriterien pro Use Case (testbar, messbar)
    • Risikoliste + Annahmen (was muss im PoC geprüft werden?)
    Typische Fehler
    • MVP wird nie entschieden
    • Abnahme bleibt Gefühl
    Praxis-Tipp

    Wenn Sie hier nicht weiterkommen: setzen Sie eine Zeitbox und entscheiden Sie 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 Sie diese vermeiden)

    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: Legen Sie pro Feld fest, welches System führend ist. Ohne Ownership entsteht doppelte Pflege und Sie automatisieren Inkonsistenz.

    Fehler 3: Kein MVP / Scope zu groß

    Fix: Definieren Sie die erste stabile Wertkette (MVP) und planen Sie 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 Sie aus der Analyse ableiten

    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 Ihren Use Cases ableiten
    • Bewertungsmatrix mit Gewichtung (nicht nur ungewichtete Summen)

    Wenn Sie möchten, ist der nächste Schritt ein strukturierter Vergleich: Demo-Skripte, gewichtete Matrix, Mini-PoC. Dazu passt der Methodik-Artikel: IT Systemauswahl Methodik →

    Weiterführende Artikel

    Vorlage

    Anforderungskatalog erstellen

    Excel-Vorlage und Leitfaden für die strukturierte Erfassung aller Anforderungen.

    Zum Artikel
    RFP

    Software Ausschreibung (RFP)

    Aus Anforderungen eine vergleichbare Ausschreibung machen – Schritt für Schritt.

    Zum Artikel
    Praxis

    Change Management

    Stakeholder frühzeitig einbinden – vom Anforderungsprozess bis zum Go-Live.

    Zum Artikel
    ← Zurück zu: Blog

    Erstberatung: Anforderungsanalyse good enough für Auswahl & Umsetzung

    Wir unterstützen systemunabhängig dabei, Ihre 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.

    Erstberatung anfragenAnforderungskatalog VorlageSystemauswahl MethodikiPaaS Hub

    Tipp: Bringen Sie 10 Kernprozesse/Use Cases, Stakeholderliste und Ihre Integrationspunkte mit.

    FAQ