KI für Projektdokumentation: Prompts, Inputs und ein Workflow ohne Spec-Müll
Wie Sie KI für Anforderungs- und Spec-Entwürfe nutzen — Prompts, Workflow, Review. Plus Artefakt-Konsistenz und Impact-Analyse von Anforderungen (keine blinde Testgenerierung).
KI für Projektdokumentation: Prompts, Inputs und ein Workflow ohne Spec-Müll
Vom Smartym Pro Team | Juli 2026
Serie: Discovery & Dokumentation (3 Teile):
- Anforderungspaket — was Artefakte sind und warum sie zählen
- Discovery-Prozess und D1–D11 — wie man dorthin kommt
- KI für Entwürfe (dieser Artikel) — Prompts, Workflow, Konsistenz
Einleitung
Teil 1 beschreibt Discovery-Artefakte — was sie sind und warum. Teil 2 deckt den Prozess und die Phasenschätzung ab. Hier geht es darum, dieses Paket während Discovery schneller zu entwerfen — mit KI, ohne die Spezifikation in eine halluzinierte Textwand zu verwandeln.
KI funktioniert, wenn das Modell strukturierten Kontext und eine enge Ausgabeaufgabe bekommt. Müll entsteht, wenn Sie „eine volle Spec aus zwei Sätzen“ verlangen. Liefern Sie Fakten und Format — validieren Sie Annahmen mit Menschen.
Für CTOs, PMs, BAs und Hands-on-Founder: Discovery läuft oder ist fertig, und Sie brauchen schnellere Verpackung — keine Ersetzung von Workshops und Sign-off.
Serienregel: KI beschleunigt Entwürfe; Product Owner, BAs und Engineers besitzen die Validierung.
Warum KI „Müll“-Anforderungen produziert
| Problem | Was passiert |
|---|---|
| Vager Input | „Baut ein CRM“ ohne Nutzer, Metriken oder Integrationen |
| Anfrage „volle 50-Seiten-Spec“ | Modell erfindet Module, APIs, Integrationen |
| Kein Ausgabeformat | Prosa statt Stories, NFR-Tabellen oder MoSCoW |
| Kein explizites Out of scope | Backlog wächst mit „nur für den Fall“-Features |
| Copy-Paste ohne Review | Konflikte mit Compliance, Legacy, Meeting-Entscheidungen |
| Ein Mega-Prompt | Scope + Stories + NFR + Risiken auf einmal — Qualität fällt |
KI ersetzt keine Workshops, Stakeholder-Alignment oder ein Annahmenregister. Sie nimmt Formatierungsarbeit nach vorhandenen Fakten ab — oder hilft, Lücken über Klärungsfragen sichtbar zu machen.
Input-Checkliste (vor jedem Prompt)
Bereiten Sie ein kurzes Bullet-Doc vor (Notion, Google Doc, Paste in den Chat). Reichhaltigerer Input bedeutet weniger Erfindungen in der Ausgabe.
| # | Was beschreiben |
|---|---|
| I1 | Product One-Liner + Problem, das Sie lösen |
| I2 | Zielnutzer (2–3 Personas, kurz) |
| I3 | Business-Ziele / Erfolgsmetriken |
| I4 | Must-have-Workflows (Liste, auch roh) |
| I5 | Out of scope (explizit) |
| I6 | Constraints: Budgetband, Timeline, Regionen, Stack (falls vorhanden) |
| I7 | Integrationen: bekannt / unbekannt |
| I8 | Compliance-Flags (GDPR, PCI usw.) — keine rechtlichen Schlüsse |
| I9 | Meeting-Notizen oder Transkript (sanitized, keine PII/Prod-Daten) |
| I10 | Referenzprodukte (UX-Erwartungen, kein Scope-Copy) |
Sie brauchen keine Perfektion. Fehlt etwas, ist der nächste Schritt Fragen vom Modell, keine fertige Spec.
Wie Sie KI richtig beauftragen
1. Kontext als Bundle. Paste I1–I8 in einem Block; lassen Sie das Modell Integrationen und NFRs nicht raten.
2. Ein Artefakt nach dem anderen. Zuerst Scope Brief, dann Stories, dann NFR, dann Risiken — nicht alles in einer Antwort.
3. Festes Ausgabeformat. Tabelle, User-Story-Template, MoSCoW-Liste — im Prompt nennen.
4. Keine Erfindungen. Anweisungen wie: „mark unknowns as [ASSUMPTION]“, „do not invent integrations or APIs“.
5. Iterieren. Entwurf → Gap-Fragen → verfeinern → revidierter Entwurf.
6. Human Gate. BA- oder Tech-Lead-Review bevor Kunde oder Schätzer es sehen.
7. Security. Keine Secrets, Prod-Daten oder PII in öffentlichen Modellen; Meeting-Notizen anonymisieren.
Lassen Sie KI zuerst fragen (Reverse Prompt)
Ein guter Workflow startet im Interview-Modus: Das Modell stellt Klärungsfragen, bis genug Kontext für einen engen Entwurf da ist.
Basis-Anweisung:
Before producing any document, ask up to 10 clarifying questions about scope, users, integrations, and NFR priorities. Wait for answers. If information is missing, list ASSUMPTIONS.
Fragekategorien (nicht alle in einem Prompt nötig):
- Wer ist der Primary User und welchen Job „mietet“ er das Produkt für?
- Was ist im MVP vs. späteren Phasen?
- Welche Systeme integrieren am Tag eins?
- Welche Daten sind PII / reguliert?
- Availability- und Performance-Erwartungen (Größenordnung)?
- Wer genehmigt Scope und nimmt Releases ab?
- Was ist explizit Out of scope?
- Was, wenn Timeline oder Budget halbiert werden?
- Legacy: ersetzen oder erweitern?
- Wie sieht Erfolg 90 Tage nach Launch aus?
Antworten festhalten — sie speisen P2–P6.
Prompt-Bibliothek
Die Prompts unten sind ein Startpunkt. An Tool (ChatGPT, Claude, Copilot, Enterprise-LLM) und Policy anpassen. Platzhalter in {{curlies}}. Prompt-Text auf Englisch folgt dem Format oft zuverlässiger; Kontext kann in Ihrer Teamsprache sein.
P1 — Nur Klärungsfragen
You are a senior business analyst for custom software projects.
Context: {{paste I1–I8}}
Do not write a specification yet.
Ask up to 10 clarifying questions grouped by: users, scope, integrations, NFR, risks.
Flag any contradictions you see in the context.
P2 — Scope Brief (in / out / Phasen)
Context: {{answers from P1}}
Produce a Scope Brief with sections: Goals, In scope (MVP), Out of scope, Phase 2 ideas, Assumptions.
Use MoSCoW for MVP features. Max 800 words. Mark every assumption with [ASSUMPTION].
P3 — User Stories aus Workflows
Context: {{scope brief from P2}}
For each MVP workflow, write user stories in format:
As a [role], I want [action], so that [outcome].
Include 3–5 acceptance criteria per story (testable).
Do not add features not listed in MVP scope.
P4 — NFR-Matrix-Entwurf
Context: {{scope brief from P2}}
Create an NFR matrix table: Category | Requirement | Priority (Must/Should/Could) | Notes.
Categories: Security, Performance, Availability, Compliance, Observability, i18n, DR.
Mark items needing client decision with [DECISION NEEDED].
P5 — Integrationskatalog
Known integrations: {{list}}
For each: system, direction (in/out), data objects, protocol (if known), owner, risks.
List [UNKNOWN] where details are missing. Do not invent APIs.
P6 — Risiken und Annahmen für die Schätzung
Based on: {{scope brief, stories, NFR, integrations}}
Output: Risk register (risk, impact, mitigation) and Assumptions list for estimators.
Separate facts from assumptions. Highlight top 5 estimation risks.
P7 — Meeting-Notizen → strukturiertes Backlog
Sanitized meeting notes: {{notes}}
Extract: decisions, action items, open questions, candidate user stories.
Do not invent decisions not present in notes. Quote ambiguous phrases as [UNCLEAR].
Prompts ersetzen keine rechtliche Compliance-Prüfung und keinen Festpreis ohne Human Review.
KI für Konsistenz und Impact von Anforderungen
Nach Entwürfen (P1–P7) ist KI besonders nützlich — nicht für blinde Testfall-Generierung, sondern um das Paket aus Teil 1 konsistent zu halten.
Konsistenz über Artefakte
Das Paket sind mehrere verknüpfte Dateien. Typische Lücken:
| Wo | Beispiel |
|---|---|
| SRS vs. Flows | Schritt-Reihenfolge weicht ab |
| Rollen vs. SRS | Matrix sagt „Manager: alles“; Story begrenzt Zugriff |
| NFR vs. Scope | Must-have Performance ohne Last im MVP-Scope |
| Integrationen vs. SRS | API gelistet, aber keine Story für Error Handling |
Mit vollem Kontext kann das Modell Dokumente vergleichen und Widersprüche sowie Lücken listen — Menschen entscheiden, was geändert wird.
Was eine Anforderung sonst noch betrifft
Wenn sich eine Story, ein NFR oder eine Integration ändert, kann KI betroffene Bereiche vorschlagen: andere Stories, Flows, Rollen, NFRs, Phasenschätzung. Das ist Impact-Analyse über Artefakte — kein Ersatz für Architektur-Review.
Beispiel: neues Profilfeld → GDPR/Consent, Admin Panel, API, Datenmigration, verwandte AC prüfen.
Was nicht funktioniert: „Tests generieren und nicht lesen“
KI zu bitten, aus einer Roh-Spec Testfälle zu schütten ohne Review, ist ein schwacher Pfad: Tests wiederholen Spec-Halluzinationen, und das Team erkennt Scope Drift nicht.
Ein gangbarer Weg:
- Entwürfe und P8 — Konsistenz und Impact.
- Human Review (R1–R8) — Sie lesen und entscheiden.
- Testfälle / AC nach abgestimmtem Scope verfeinern — manuell oder mit KI als Editor, nicht als alleinigem Autor.
P8 — Consistency and impact review
You are a senior BA reviewing discovery artifacts for consistency and cross-impact.
Artifacts: {{paste 2+ documents: scope brief, SRS excerpt, flows, roles, NFR, integrations}}
Do not rewrite documents. Do not generate a full test suite.
Output:
1) Table: Issue | Artifact A | Artifact B | Severity | Suggested fix
2) For each major requirement change area: what other artifacts/stories/NFR/integrations may be affected
3) List: ambiguous phrases, untestable acceptance criteria, flows without matching stories
Mark inferred items as [ASSUMPTION].
Review-Checkliste nach KI
Bevor Sie an Kunde, Schätzer oder Vertrag senden:
| # | Prüfen |
|---|---|
| R1 | Kein Konflikt mit Business-Zielen oder Meeting-Entscheidungen |
| R2 | Keine Features außerhalb des abgestimmten MVP |
| R3 | Keine erfundenen Integrationen / APIs / Protokolle |
| R4 | NFR-Items mit [DECISION NEEDED] haben Owner und Plan |
| R5 | Acceptance Criteria sind testbar, nicht „schnell und bequem“ |
| R6 | Compliance-Aussagen gelten nicht als Rechtsberatung |
| R7 | Keine doppelten Stories; ähnliche zusammenführen |
| R8 | Alle [ASSUMPTION]-Items im Annahmenregister |
Review macht jemand, der die Domain kennt und sagen kann „das haben wir nicht versprochen“ — meist BA, PM oder Tech Lead.
Workflow: von Notizen zur Schätzung
flowchart LR
A[Notes / I1–I10] --> B[P1: questions]
B --> C[Team answers]
C --> D[P2: scope brief]
D --> E[P3: stories]
D --> F[P4: NFR]
D --> G[P5: integrations]
E --> H[P6: risks]
F --> H
G --> H
H --> I[P8: consistency and impact]
I --> J[Human review R1–R8]
J --> K[Package from part 1]
K --> L[Phased estimate — part 2]
P7 nach jedem Meeting parallel laufen lassen. Output aligniert mit dem Paket in Teil 1 und D1–D11 aus Teil 2.
Was weiterhin einen Dev-Partner braucht
KI entfernt nicht:
- Feasibility — kann MVP in Zeit und Budget mit gewähltem Stack shippen;
- Architektur — Optionen, Trade-offs, Integrationsrisiken;
- Schätzung — Spannen, Annahmen, Phasenplan;
- Workshops — Prioritäten, strittige Entscheidungen, Scope-Sign-off.
Entwürfe beschleunigen Gespräche mit Engineers; sie ersetzen sie nicht. Nach der Coding-Phase siehe KI im SDLC und Code-Qualität im SDLC.
Wie wir KI in Discovery nutzen (Smartym Pro)
- P1–P7 innerhalb von Workshops und zwischen Sessions, nicht statt ihrer.
- Engineers validieren Feasibility und nehmen an der Schätzung teil.
- Kunden besitzen Business-Entscheidungen; wir strukturieren Artefakte Richtung Schätzung Phase eins.
Für KI in Produkten und Prozessen — AI Development; für Delivery-Disziplin — unser Ansatz und Web Application Development.
Was nicht versprechen
- Festpreis aus rohem KI-Output ohne Review
- Rechtsverbindliche Compliance-Meinung
- „Ersetzen Sie Ihren BA durch ChatGPT“
- Veröffentlichung interner Kunden-Prompts mit Secrets
FAQ
Können wir KI-Output als finale Spec ausliefern?
Nein. Nur nach Review und abgestimmten Annahmen.
Wie viele Prompts für ein MVP?
Meist P1 → P2 → P3 + P4 + P5 → P6; P7 parallel zu Meetings.
Sollten wir Testfälle mit KI auto-generieren?
Nur als Entwurf nach P8 und Human Review — und Sie müssen sie lesen. Blinde Generierung aus Roh-Spec funktioniert nicht.
Ersetzt das Discovery?
Nein. Siehe Teil 2. KI beschleunigt Entwürfe; Sign-off und das Paket Teil 1 bleiben.
Unternehmens-Policy blockiert Cloud-LLMs?
Gleicher Workflow auf On-Prem / Private Endpoint; Inputs trotzdem anonymisieren.
Fazit
KI für Projektdokumentation funktioniert, wenn Sie strukturierten Input liefern, ein Artefakt nach dem anderen anfordern, P8 und Human Review fahren — und sich dann auf das Paket Teil 1 für die Phasenschätzung stützen. Entwürfe in Stunden, nicht Tagen; Konsistenz mit Lesen — nicht vakuumgenerierte Tests.
Für einen Discovery-Workshop, Validierung von KI-Entwürfen oder SDLC-KI-Adoption — kontaktieren Sie uns.
Allgemeine Orientierung zu Software Delivery und LLM-Nutzung — keine Rechtsberatung. Laden Sie keine vertraulichen Daten in öffentliche Modelle hoch.