Anforderungsermittlung

Lernziele

Nach diesem Kapitel können Sie: * Methoden zur Anforderungsermittlung anwenden * Interviews, Workshops und User Research durchführen * Die Persona-Methode und das Kano-Modell nutzen * Anforderungen systematisch ermitteln

1. Einführung: Was ist Anforderungsermittlung?

Kernkonzept

Anforderungsermittlung (Requirements Elicitation) ist der Prozess der Identifikation von Anforderungen aus verschiedenen Quellen.

1.1 Warum Anforderungsermittlung kritisch ist

Statistiken:

Problem	Häufigkeit der Ursache
Fehlende Anforderungen	70% → Projektverzögerungen
Falsche Anforderungen	80% → Nicht erfüllte Erwartungen
Unvollständige Anforderungen	60% → Rework

Kosten-Faktor: * Eine fehlende Anforderung im Requirements-Stage kostet 100-mal mehr, wenn sie im Deployment entdeckt wird

1.2 Der Anforderungsermittlungs-Prozess

graph TD
    A[Vorbereitung] --> B[Ermittlung]
    B --> C[Analyse]
    C --> D[Validierung]
    D --> E[Dokumentation]

    style A fill:#4CAF50,stroke:#333,color:white
    style B fill:#2196F3,stroke:#333,color:white
    style C fill:#FF9800,stroke:#333,color:white
    style D fill:#9C27B0,stroke:#333,color:white
    style E fill:#f44336,stroke:#333,color:white

Schritte: 1. Vorbereitung: Stakeholder identifizieren, Methoden wählen 2. Ermittlung: Interviews, Workshops, User Research 3. Analyse: Anforderungen strukturieren, kategorisieren 4. Validierung: Anforderungen mit Stakeholdern bestätigen 5. Dokumentation: Anforderungen dokumentieren (Lastenheft, User Stories)

2. Methoden zur Anforderungsermittlung

Es gibt verschiedene Methoden zur Anforderungsermittlung. Als Berater nutzen Sie eine Kombination dieser Methoden.

2.1 Übersicht der Methoden

Methode	Beschreibung	Einsatz
Interviews	1:1-Gespräche mit Stakeholdern	Tiefe Insights, komplexe Themen
Workshops	Gruppen-Sessions mit mehreren Stakeholdern	Brainstorming, Konsens finden
User Research	Beobachtung von Benutzern bei der Arbeit	Realitäts-Check, UX-Insights
Persona-Methode	Fiktive User-Personas erstellen	User-Zentrierung, Empathie
Kano-Modell	Kundenanforderungen priorisieren	Feature-Priorisierung
Surveys	Umfragen an große Zielgruppen	Quantitative Daten
Competitive Analysis	Wettbewerber analysieren	Benchmarking
Prototyping	Rapid Prototypes erstellen	Feedback erhalten
Use Cases	Szenarien beschreiben	Requirements Engineering

2.2 Auswahlmatrix für Methoden

Szenario	Empfohlene Methoden
Neues System, wenig Vorwissen	Interviews, Workshops, Persona
Komplexes System, viele Stakeholder	Workshops, Use Cases, Traceability Matrix
UX-fokussiertes System	User Research, Persona, Prototyping
Mobile App	User Research, Persona, Prototyping
Enterprise-System	Interviews, Workshops, Use Cases
Konsolidierung von Systemen	Workshops, Competitive Analysis

3. Interviews

3.1 Was sind Interviews?

Interviews sind strukturierte oder unstrukturierte Gespräche mit Stakeholdern.

3.2 Arten von Interviews

Typ	Beschreibung	Vor- / Nachteile
Strukturiert	Fragen sind vorher definiert	✅ Vergleichbar ❌ Weniger flexibel
Halbstrukturiert	Fragen sind definiert, aber Flexibilität	✅ Kompromiss
Unstrukturiert	Keine vorherigen Fragen, offenes Gespräch	✅ Flexibel ❌ Nicht vergleichbar

3.3 Interview-Leitfaden erstellen

Struktur:

Phase	Dauer	Inhalte
Warm-up	5 Min	Begrüßung, Ziel des Interviews
Offene Fragen	10-15 Min	Allgemeine Fragen zum Thema
Gezielte Fragen	15-20 Min	Spezifische Fragen zum System
Follow-up Fragen	5-10 Min	Vertiefungsfragen
Abschluss	5 Min	Zusammenfassung, nächste Schritte

Beispiel-Fragen:

Phase	Fragen
Warm-up	"Können Sie mir kurz Ihre Rolle im Unternehmen beschreiben?"
Offene Fragen	"Wie sieht Ihr aktueller Arbeitsprozess aus?"
Gezielte Fragen	"Welche Probleme erleben Sie bei der Bestellabwicklung?"
Follow-up	"Können Sie mir ein konkretes Beispiel geben?"
Abschluss	"Gibt es noch etwas, das ich vergessen habe zu fragen?"

3.4 Interview-Techniken

Technik	Beschreibung
Offene Fragen	Fragen, die nicht mit Ja/Nein beantwortet werden können ("Wie...", "Warum...", "In welcher Weise...")
Follow-up Fragen	Vertiefungsfragen ("Können Sie mir ein Beispiel geben?", "Was meinen Sie damit?")
Silence nutzen	Pausen einhalten, um den Interviewten zum Sprechen zu bringen
Paraphrasieren	Wiederholen, was gesagt wurde, um Verständnis zu zeigen ("Wenn ich Sie richtig verstehe, ...")
Empathie zeigen	Verständnis für Perspektive zeigen ("Ich verstehe, dass das frustrierend ist")

Häufige Fehler bei Interviews

❌ Ja/Nein-Fragen nutzen ("Mögen Sie das System?")
❌ Suggestive Fragen stellen ("Das System ist langsam, oder?")
❌ Zuhören vs. Vorbereiten der nächsten Frage
❌ Interview dominieren

3.5 Praxis-Beispiel: Interview mit Vertriebler

Szenario: CRM-System

Sie führen ein Interview mit einem Vertriebler.

Warm-up: * "Können Sie mir kurz Ihre Rolle im Unternehmen beschreiben?" * "Was sind Ihre Hauptaufgaben?"

Offene Fragen: * "Wie sieht Ihr aktueller Arbeitsprozess bei der Kundenakquise aus?" * "Welche Tools nutzen Sie täglich?"

Gezielte Fragen: * "Welche Probleme erleben Sie bei der Kundensuche?" * "Was fehlt Ihnen an Ihrem aktuellen CRM-System?" * "Wie sieht Ihr Ideal-Szenario aus?"

Follow-up: * "Können Sie mir ein konkretes Beispiel geben?" * "Was genau meinst du damit?"

Abschluss: * "Gibt es noch etwas, das ich vergessen habe zu fragen?"

4. Workshops

4.1 Was sind Workshops?

Workshops sind Gruppen-Sessions mit mehreren Stakeholdern, um Anforderungen gemeinsam zu ermitteln.

4.2 Workshop-Vorbereitung

Checkliste:

Aspekt	Überlegungen
Ziel	Was ist das Ziel des Workshops?
Teilnehmer	Wer muss teilnehmen? (max. 8-10)
Agenda	Wie sieht der Ablauf aus?
Materialien	Was wird benötigt? (Flipchart, Post-its, Marker)
Ort	Wo findet der Workshop statt? (Räumlich, Virtual)
Dauer	Wie lange dauert der Workshop? (max. 4-6 Stunden)

4.3 Workshop-Ablauf

Phase	Dauer	Aktivität
Intro	15 Min	Begrüßung, Zielsetzung, Regeln
Icebreaker	10 Min	Teilnehmer auflockern
Brainstorming	60-90 Min	Anforderungen brainstormen
Strukturierung	30-60 Min	Anforderungen strukturieren (Methode: 4M, 6M, 8M)
Priorisierung	30-60 Min	Anforderungen priorisieren (Methode: MoSCoW, Kano)
Abschluss	15 Min	Zusammenfassung, next steps

4.4 Workshop-Methoden

4.4.1 Brainstorming

Regeln: 1. Keine Kritik: Ideen sofort akzeptieren 2. Quantität vor Qualität: So viele Ideen wie möglich 3. Freiheit: Alle Ideen sind willkommen 4. Kombination: Ideen anderer aufgreifen und erweitern

Varianten: * Reverse Brainstorming: Statt "Wie lösen wir das Problem?", fragen: "Wie erzeugen wir das Problem?" * Brainwriting: Teilnehmer schreiben Ideen auf Post-its, nicht laut * Mind Mapping: Visuelle Darstellung von Ideen

4.4.2 6-3-5 Methode

Ablauf: 1. 6 Teilnehmer 2. Jeder schreibt 3 Ideen in 5 Minuten 3. Post-its weitergeben 4. Nächster Runde: Teilnehmer erweitern Ideen 5. Wiederholen (3-4 Runden)

4.4.3 Nominal Group Technique

Ablauf: 1. Silent Brainstorming: Jeder schreibt Ideen auf (10 Min) 2. Ideen sammeln: Alle Ideen an Whiteboard hängen 3. Diskussion: Ideen besprechen 4. Ranking: Jeder wählt Top-3 5. Priorisierung: Top-Ideen identifizieren

Workshop: E-Commerce-Shop

Sie leiten einen Workshop zur Entwicklung eines E-Commerce-Shops.

Teilnehmer: Product Owner, UX-Designer, Developer, Marketing-Manager, Sales-Manager, Customer Support

Agenda: 1. Intro (15 Min): Ziel definieren: "Welche Features braucht unser Shop?" 2. Icebreaker (10 Min): "Was ist deine schlechteste Shopping-Erfahrung?" 3. Brainstorming (60 Min): Requirements brainstormen 4. Strukturierung (30 Min): Kategorisierung (FR, NFR, RC) 5. Priorisierung (60 Min): MoSCoW 6. Abschluss (15 Min): Zusammenfassung, next steps

Ergebnisse: * FR-001: Mobile App (Must have) * FR-002: Personalisierung (Must have) * FR-003: KI-Scoring (Should have) * NFR-P001: Performance < 2s (Must have) * NFR-S001: Security (Must have)

5. User Research

5.1 Was ist User Research?

User Research ist die Beobachtung von Benutzern bei der Arbeit, um reale Insights zu erhalten.

5.2 Arten von User Research

Methode	Beschreibung	Einsatz
Go-and-See (Gemba)	Prozesse live vor Ort miterleben	Reale Arbeitsweise verstehen
Shadowing	Benutzer über einen Zeitraum begleiten	Tagesablauf, Pain Points
Contextual Inquiry	Beobachtung + Fragen gleichzeitig	Arbeit im Kontext verstehen
Usability Testing	Benutzer testen das System	UX-Probleme identifizieren
A/B Testing	Zwei Varianten testen	Datengetriebene Entscheidung
Analytics	Usage-Daten analysieren	Quantitative Daten

5.3 Go-and-See (Gemba)

Was ist Gemba? "Gemba" ist japanisch für "Ort des Geschehens". Das bedeutet: Gehen Sie dorthin, wo die Arbeit stattfindet.

Vorgehen: 1. Ziel definieren: Was möchten Sie beobachten? 2. Teilnehmer auswählen: Wen beobachten? 3. Beobachten: Prozesse live miterleben 4. Notizen machen: Was passiert? Was läuft gut/schlecht? 5. Fragen stellen: Warum machen Sie das so?

Go-and-See: Warehouse

Sie beobachten das Personal im Lager.

Beobachtungen: * Mitarbeiter nutzen manuelle Pick-Listen (Papier) Mitarbeiter laufen oft zum Lagerverwalter (Informationen fehlen) Mitarbeiter scannen Artikel manuell mit Handscanner * Fehlerquote bei der Kommissionierung: ~5%

Pain Points: * Manuelle Pick-Lists → Zeitverlust * Fehlende Informationen → Laufwege * Manuelle Scans → Fehleranfälligkeit

Ableitung von Anforderungen: * FR-001: Digitale Pick-Listen auf Tablet * FR-002: Echtzeit-Lagerbestand * FR-003: Barcode-Scanning mit automatischer Validierung

5.4 Shadowing

Was ist Shadowing? Shadowing bedeutet, einen Benutzer über einen Zeitraum zu begleiten.

Vorgehen: 1. Teilnehmer auswählen: Wen begleiten? 2. Zeitraum definieren: Wie lange? (Tage, Wochen) 3. Begleiten: Benutzer beobachten, Fragen stellen 4. Notizen machen: Was passiert? Was läuft gut/schlecht? 5. Analyse: Muster identifizieren

Shadowing: Sales-Representative

Sie begleiten einen Sales-Representative über 2 Tage.

Beobachtungen: * Sales-Rep nutzt CRM-System mobil (Smartphone) * Sales-Rep sucht oft nach Kunden-Daten (Performance-Probleme) * Sales-Rep erstellt Angebote im CRM (langwierig) * Sales-Rep kommuniziert mit Support via E-Mail (langsam)

Pain Points: * Mobile CRM ist langsam → Performance-Probleme * Angebotserstellung ist komplex → UX-Probleme * Support-Kommunikation ist langsam → Integration fehlt

Ableitung von Anforderungen: * NFR-P001: Performance < 2s * FR-001: Vereinfachte Angebotserstellung * FR-002: Integration CRM ↔ Support

6. Die Persona-Methode

6.1 Was sind Personas?

Personas sind fiktive User-Profile, die typische Benutzer repräsentieren.

6.2 Warum Personas wichtig sind

Grund	Erläuterung
Empathie	Entwickler verstehen Benutzer
User-Zentrierung	Anforderungen aus Benutzerperspektive
Konsistenz	Alle arbeiten mit demselben User-Verständnis
Priorisierung	Anforderungen basierend auf User-Zielen priorisieren

6.3 Persona erstellen

Struktur einer Persona:

Element	Beschreibung	Beispiel
Name	Fiktiver Name	"Sarah Müller"
Alter	Alter der Persona	32 Jahre
Rolle	Rolle im Unternehmen	"Vertrieblerin"
Ziele	Was möchte die Persona erreichen?	"Umsatzsteigerung, Zeitersparnis"
Pain Points	Welche Probleme hat die Persona?	"Langsames CRM, komplexes Angebotssystem"
Bedürfnisse	Was braucht die Persona?	"Schnelles CRM, einfaches Angebotssystem"
Kompetenzen	Welche Skills hat die Persona?	"Digitale Kompetenz, CRM-Erfahrung"
Kontext	In welchem Kontext arbeitet die Persona?	"Mobil im Außendienst"
Quote	Zitat der Persona	"Ich brauche ein CRM, das genauso schnell ist wie mein Auto."

6.4 Beispiel-Persona: Sales-Rep

Persona: Sales-Representative

Name: Sarah Müller Alter: 32 Jahre Rolle: Vertrieblerin (Außendienst) Ziele: * Umsatzsteigerung um 15% * Zeitersparnis (mehr Kundenzeit) * Bessere Kundenbindung

Pain Points: * CRM ist langsam (Performance-Probleme) * Angebotserstellung ist komplex (UX-Probleme) * Keine Offline-Funktionalität (Probleme in Kundenbesuchen)

Bedürfnisse: * Schnelles CRM (Performance < 2s) * Einfache Angebotserstellung (< 5 Minuten) * Offline-Funktionalität (Cache)

Kompetenzen: * Digitale Kompetenz: Hoch * CRM-Erfahrung: Mittel * Technisches Verständnis: Mittel

Kontext: * Mobil im Außendienst (Smartphone) * Kundenbesuche (oft ohne Internet) * Reisezeit: ~3 Stunden/Tag

Quote: "Ich brauche ein CRM, das genauso schnell ist wie mein Auto."

6.5 Anforderungen aus Personas ableiten

Persona	Ziel	Anforderungen
Sarah Müller	Umsatzsteigerung	FR-001: Mobile App FR-002: KI-Scoring
	Zeitersparnis	FR-003: Offline-Funktionalität FR-004: Einfache Angebotserstellung
	Performance	NFR-P001: Performance < 2s

7. Das Kano-Modell

7.1 Was ist das Kano-Modell?

Das Kano-Modell ist eine Methode zur Priorisierung von Kundenanforderungen.

7.2 Die 5 Kategorien im Kano-Modell

Kategorie	Beschreibung	Beispiel
Basic Needs (Muss-Anforderungen)	Wird erwartet, aber nicht explizit gefordert	Login funktioniert, System ist verfügbar
Performance Needs (Leistungsanforderungen)	Je mehr, desto besser	Response Time (je schneller, desto besser)
Excitement Needs (Begeisterungs-Features)	Überraschende Features	KI-gestütztes Lead-Scoring
Indifferent (Gleichgültig)	Kein Einfluss auf Kundenzufriedenheit	Admin-Funktionen für IT
Reverse (Negative Features)	Unbeliebte Features	Werbung im System

7.3 Das Kano-Diagramm

graph LR
    A[Customer Satisfaction] --> B[Basic Needs]
    A --> C[Performance Needs]
    A --> D[Excitement Needs]
    A --> E[Indifferent]
    A --> F[Reverse]

    B --> B1[Erwartet, aber nicht gefordert]
    C --> C1[Je mehr, desto besser]
    D --> D1[Überraschende Features]
    E --> E1[Kein Einfluss]
    F --> F1[Unbeliebte Features]

    style A fill:#f96,stroke:#333,stroke-width:3px

7.4 Kano-Fragebogen

Für jedes Feature stellen Sie zwei Fragen:

Funktionsfrage: "Wie ist es, wenn das Feature vorhanden ist?"
Dysfunktionsfrage: "Wie ist es, wenn das Feature nicht vorhanden ist?"

Antworten: * Ich mag es * Ich erwarte es so * Ich bin gleichgültig * Ich kann damit leben * Ich mag es nicht

Auswertung: | Funktionsfrage \ Dysfunktionsfrage | Ich mag es | Ich erwarte es | Gleichgültig | Ich kann damit leben | Ich mag es nicht | |-----------------------------------|-----------|--------------|-------------|---------------------|------------------| | Ich mag es | - | Excitement | Excitement | Performance | - | | Ich erwarte es | Basic | - | Basic | Basic | Reverse | | Gleichgültig | Indifferent | Indifferent | - | Indifferent | Reverse | | Ich kann damit leben | Reverse | Reverse | Reverse | - | - | | Ich mag es nicht | - | - | - | - | - |

7.5 Kano-Analyse durchführen

Schritt 1: Fragebogen erstellen (10-20 Features) Schritt 2: Befragung durchführen (mindestens 10 Kunden) Schritt 3: Auswertung (Tabelle oben) Schritt 4: Kategorien zuordnen Schritt 5: Priorisierung (Basic → Performance → Excitement)

Kano-Analyse: E-Commerce-Shop

Sie führen eine Kano-Analyse für einen E-Commerce-Shop durch.

Fragebogen: 1. Login-Funktion (Basic) 2. Response Time < 2s (Performance) 3. KI-gestützes Lead-Scoring (Excitement) 4. Admin-Funktionen (Indifferent) 5. Werbung im System (Reverse)

Ergebnis: * Basic Needs: Login, Verfügbarkeit, Security * Performance Needs: Response Time, Performance * Excitement Needs: KI-Scoring, Personalisierung * Indifferent: Admin-Funktionen * Reverse: Werbung

Priorisierung: 1. Basic Needs (Muss haben) 2. Performance Needs (sollte haben) 3. Excitement Needs (könnte haben)

8. Zusammenfassung und Checkliste

8.1 Erfolgsfaktoren

Kombination von Methoden: Nicht nur Interviews, sondern Workshops, User Research, Persona, Kano
Stakeholder involvieren: Alle relevanten Rollen befragen
Dokumentation: Alles dokumentieren (Interviews, Workshops, Notizen)
Validierung: Anforderungen mit Stakeholdern validieren
Iterativ: Anforderungen mehrfach prüfen und verbessern

8.2 Checkliste für Ihre Anforderungsermittlung

Vorbereitung

Stakeholder identifiziert: Alle relevanten Rollen?
Methoden gewählt: Interviews, Workshops, User Research, Persona, Kano?
Leitfäden erstellt: Interview-Leitfaden, Workshop-Agenda?
Materialien vorbereitet: Flipchart, Post-its, Recorder?

Durchführung

Interviews geführt: Mit allen Stakeholdern?
Workshops durchgeführt: Requirements brainstormen?
User Research: Go-and-See, Shadowing?
Persona erstellt: User-Personas definiert?
Kano-Analyse durchgeführt: Priorisierung?

Analyse

Anforderungen strukturiert: FR, NFR, RC?
Priorisierung: MoSCoW, Kano?
Traceability: Anforderungen mit Personas verknüpft?

Validierung

Stakeholder involviert: Rückmeldung erhalten?
Anforderungen validiert: Bestätigt?

9. Weiterführende Themen

Anforderungsanalyse: Verifikation, Priorisierung (MoSCoW, Kano)
Anforderungsdokumentation: Lastenheft, User Stories
Anforderungsmanagement: Traceability, Change Management, Versionierung

Nächster Schritt: Lernen Sie Priorisierungsmethoden (Kapitel 04).