Anforderungspaket vor Entwicklungsstart: Was Discovery liefern sollte

Vom Smartym Pro Team | Juli 2026

Serie: Discovery & Dokumentation (3 Teile):

1. Anforderungspaket (dieser Artikel) — was vor Schätzung und Code bereit sein muss
2. Discovery-Prozess und D1–D11-Artefakte — wie man dorthin kommt
3. KI für Dokumentationsentwürfe — Prompts, Workflow, Konsistenz

---

Einleitung

Dieser Artikel erklärt die Dokumenttypen, die typischerweise am Ende von Discovery entstehen — bevor die Entwicklung startet: was jeweils enthalten ist, warum es zählt und wofür es im Gespräch mit dem Team dient. Es ist kein formales Tor „bringen Sie zwölf PDFs mit“. Es ist ein gemeinsames Vokabular, das Unsicherheit zwischen Auftraggeber und Engineering reduziert.

Das Paket entsteht im Discovery-Prozess aus Brief und Workshops. Hier geht es um das Ergebnis und warum diese Artefakte für den Scope der Phase eins und die Schätzung wichtig sind.

---

Wo das Paket im Lifecycle sitzt

Idee / Brief
     ↓
Discovery (Workshops)     ← Teil 2
     ↓
Anforderungspaket (dieser Artikel)
     ↓
Schätzung und Budget (D10)
     ↓
Sign-off → Vertrag
     ↓
Entwicklung

Phase	Paket	Was Sie besprechen
Vor Discovery	Keines	Nur Ballpark
Nach Discovery	Dokumente unten	Schätzung Phase eins
Nach Sign-off	Unterzeichneter Scope	Sprint 0, Delivery

---

Dokumente im Paket: Was, warum, wofür

Dokument	D#	Warum es zählt	Wofür
Project Brief	D2	Ohne „Warum“ bepreisen Teams nur sichtbare Features	Ziele, Nutzer, MVP, Metriken
SRS (nach Modulen)	D1, D4	Ein Bild des funktionalen Scopes	Phasen-Scope, Backlog, Vertrag
Rollenmatrix	D4	Versteckte Admin-/Rechtekomplexität	Security, Kabinett-Schätzungen
User Flows	D4	SRS-Prosa ersetzt den Nutzerpfad nicht	UX-Lücken, Testbarkeit
Wireframes	D11	Reduziert UI-Ambiguität	UI-lastige Produkte ohne Voll-Design
Sitemap / IA	D1	Bildschirmzahl und Navigation	UI-Scope-Grenzen
Datenmodell (lite)	D7	Backend ist oft schwerer als gedacht	API, Migrationen, Admin
Integrationen	D6	Haupttreiber für Zeitplan und Risiko	Realistische Phasenschätzung
NFRs	D5	„Funktioniert“ ≠ schnell / sicher	Architektur, Compliance
MVP-Scope (MoSCoW)	D3	Ohne Prioritäten wird alles bepreist	Phase eins, nicht volle Roadmap
Out of scope	D1	Stoppt Scope Creep	Phasengrenze
Risiken & Annahmen	D8	Macht Unbekanntes explizit	Wann sich Schätzungen ändern
Roadmap / Phasen	D9	Produkte leben in Iterationen	Planung Phase 2, 3…
Technische Constraints	D7	Machbarkeit	Stack, Legacy, Hosting

---

SRS: Struktur und Module

Das SRS ist nach Modulen gruppiert, damit Anforderungen leichter lesbar und abstimmbar sind — das ist Dokumentstruktur, kein Aufruf zum Festpreis pro Modul über die gesamte Produkt-Roadmap.

Empfohlene SRS-Abschnitte:

1. Introduction
2. Product overview
3. User roles
4. Functional requirements (by module)
5. Non-functional requirements
6. Integrations
7. Business rules
8. Data requirements
9. Security
10. Acceptance criteria
11. Constraints and assumptions
12. Out of scope

Beispielmodule: Authentication → User Profile → Dashboard → Admin → Payments → Notifications → Reports → Integrations.

Pro Modul: Beschreibung, Rollen, Anforderungen, Business Rules, Edge Cases, Acceptance Criteria, Abhängigkeiten.

---

Rollenmatrix

Rolle	View	Create	Edit	Delete	Approve
Guest	Öffentliche Seiten	—	—	—	—
User	Eigene Daten	Requests	Eigene Daten	—	—
Manager	Teamdaten	Ja	Teamdaten	Begrenzt	Ja
Admin	Alle Daten	Ja	Ja	Ja	Ja

Ohne diese Matrix werden Admin-Panel und Rechtearbeit fast immer unterschätzt.

---

User Flows

Beschreiben Sie zentrale Journeys Schritt für Schritt, z. B. Registrierung:

1. Nutzer öffnet die Registrierungsseite
2. Gibt E-Mail und Passwort ein
3. System validiert die Eingabe
4. Bestätigungs-E-Mail wird gesendet
5. Nutzer bestätigt die E-Mail
6. Nutzer vervollständigt das Profil
7. Zugriff auf das Dashboard

Mindest-Flows: Registrierung/Login, Kernprozess, Zahlung (falls vorhanden), Freigabe, Admin, Benachrichtigungen, Fehler-/Ablehnungspfade.

---

Integrationen

Dokumentieren Sie je Integration:

• Name und Zweck
• Richtung (in / out / both)
• ausgetauschte Daten
• Authentifizierungsmethode
• API-Docs / Sandbox-Link
• Frequenz, Webhooks, Retry
• Owner auf Kundenseite
• [UNKNOWN], wo Details fehlen — nichts erfinden

---

NFRs (Kurzüberblick)

Kategorie	Beispiele
Performance	Seitenladezeit, API-Latenz, gleichzeitige Nutzer
Availability	Uptime-Ziel, Backup/DR
Security	HTTPS, RBAC, Audit-Log, OWASP-Baseline
Compliance	GDPR, Consent, Retention — Flag „Legal Review nötig“
Scale	Nutzer, RPS, Dateivolumen, Datenwachstum

Priorisieren Sie Must / Should / Could wie in Teil 2.

---

Mindest- vs. Vollpaket

Minimum für eine aussagekräftige Schätzung:

1. Project Brief
2. SRS (mindestens Top-MVP-Module)
3. Rollen und Rechte
4. User Flows
5. Wireframes oder Figma (Low-Fi)
6. Integrationsliste
7. MVP-Scope (MoSCoW)
8. Out of scope
9. NFR-Prioritäten
10. Format der Schätzungsanfrage

Für eine engere Schätzung ergänzen: detaillierte AC, Datenmodell, UI-Zustände, Edge Cases, Legacy-Migration, Deployment, SLA, Dokumentationsanforderungen.

---

Beispiel Ordnerstruktur

/project-docs
  01-project-brief.md
  02-srs.md
  03-user-roles-permissions.md
  04-user-flows.md
  05-sitemap.md
  06-data-model.md
  07-integrations.md
  08-non-functional-requirements.md
  09-acceptance-criteria.md
  10-mvp-scope.md
  11-out-of-scope.md
  12-estimation-request.md
/design
  figma-link.txt
  wireframes.pdf
/assets
  logo, brandbook, screenshots
/legal
  privacy-policy.md, terms.md

KI kann Entwürfe beschleunigen und Artefakte über Dateien hinweg konsistent halten — siehe Teil 3.

---

Phasenschätzung, nicht Festpreis für das gesamte Produkt

Diese Artefakte helfen allen, zu verstehen, worüber gesprochen wird. Die kommerzielle Zahl gilt meist für Phase eins (MVP), nicht für eine mehrjährige Roadmap als Einmalpreis.

Prinzip	Praxis
MoSCoW Must	Grenze der aktuellen Phase für die Schätzung
Iterationen	Nach Release Phase eins — verfeinerter Scope und neue Schätzung für Phase zwei
Kein Festpreis für alles erwarten	Festpreis passt zu einer unterzeichneten Phase bei niedriger Unsicherheit
Sonst	Spanne, T&M mit Cap oder Hybrid

Siehe Engagement-Modelle: Vor- und Nachteile. Zu Discovery-Prozess und Ballpark → Fixed Phase siehe Teil 2.

Sinnvolle Anfrage nach dem Paket: Annahmen, offene Fragen, Schätzung Phase eins, Optionen für spätere Phasen, Risiken, Out of scope, empfohlenes Engagement-Modell — nicht eine Zahl „für das gesamte SRS“.

---

Weiter in der Serie

• Teil 2 — Discovery als Prozess: RACI, D1–D11, MVP/Ausschreibungen, Ballpark vs. Fixed Phase
• Teil 3 — KI: Entwürfe, Prompts, Konsistenz und Impact-Review

Brauchen Sie einen Discovery-Workshop oder Hilfe, einen Brief in dieses Paket zu überführen? Siehe unseren Ansatz oder schreiben Sie uns.

---

Allgemeine Orientierung zur Delivery-Praxis — keine Rechts- oder Beschaffungsberatung.