Dieser Artikel richtet sich an Product Owner, Business Analysten und alle, die Anforderungen zwischen fachlichen und technischen Perspektiven strukturieren.<\/p>\n\n\n\n
Viele glauben, KI hilft beim Schreiben von User Stories.
Das stimmt nur teilweise.<\/p>\n\n\n\n
Im Alltag scheitern Anforderungen selten am Schreiben.
Sie scheitern an fehlender Klarheit.<\/p>\n\n\n\n\n\n\n\n
Stakeholder beschreiben L\u00f6sungen statt Probleme.
Anforderungen werden zu gro\u00df formuliert.
Stories wirken korrekt, sind aber fachlich unklar.
Offene Punkte fallen erst sp\u00e4t auf.<\/p>\n\n\n\n
Ein typisches Beispiel:<\/p>\n\n\n\n
\nStakeholder: \u201eWir brauchen ein Dashboard f\u00fcr Kunden.\u201c
Entwicklung: \u201eWelche Daten?\u201c
Fachbereich: \u201eAlle wichtigen.\u201c<\/p>\n<\/blockquote>\n\n\n\nGenau hier nutze ich die Prompts.
Nicht um Text zu erzeugen, sondern um Denken zu strukturieren.<\/p>\n\n\n\nDie folgenden Prompts sind kein Ablaufplan.
Es sind Werkzeuge f\u00fcr verschiedene Zust\u00e4nde einer Anforderung.<\/p>\n\n\n\nManchmal gibt es nur Gespr\u00e4chsnotizen.
Manchmal existiert bereits eine User Story, aber Kontext oder Verst\u00e4ndnis fehlen.<\/p>\n\n\n\nDie KI dient dabei als Sparringspartner zum Strukturieren und Hinterfragen.<\/p>\n\n\n\n
Einsatz je nach Reifegrad der Anforderung<\/h1>\n\n\n\n
Nicht jede Anforderung beginnt bei null.
Die Werkzeuge helfen beim Erstellen und beim Weiterentwickeln.<\/p>\n\n\n\nVorgehensweise<\/h3>\n\n\n\n
Ich bringe jede Anforderung zuerst mit P1<\/strong> in ein einheitliches Format.
Erst danach nutze ich weitere Prompts.<\/p>\n\n\n\nP1 ist damit die gemeinsame Grundlage f\u00fcr alles Weitere.<\/p>\n\n\n\n
Wenn nur Notizen existieren \u2192 P1<\/h2>\n\n\n\n
Ziel: Aus Fragmenten wird eine verst\u00e4ndliche Anforderung.<\/p>\n\n\n\n
P1 \u2013 Rohbeschreibung \u2192 User Story<\/h3>\n\n\n\n
Rolle: Du bist ein erfahrener Product Owner.\n\nAnweisung:\nWarte auf meine Beschreibung eines konkreten Features, Problems oder Anwendungsfalls.\n\nWenn ich dir eine Beschreibung gebe:\n- stelle bei Unklarheiten gezielte R\u00fcckfragen\n- hilf mir anschlie\u00dfend, eine pr\u00e4gnante User Story zu formulieren\n\nDie User Story soll enthalten:\n- Titel\n- Story\/Ziel (Als \u2026 m\u00f6chte ich \u2026, um \u2026)\n- Problem & Kontext\n- Business Value\n- Out-Of-Scope\n- Akzeptanzkriterien\n\nFormuliere kompakt und in aktiver Sprache.\n<\/code><\/pre>\n\n\n\nDiese Struktur macht sp\u00e4tere Diskussionen vergleichbar.<\/p>\n\n\n\n
Wenn fachliche Einordnung fehlt \u2192 P2<\/h2>\n\n\n\n
Kontext ist optional.
Bei explorativen Themen nutze ich ihn oft nicht.
Bei fachlichen Details hilft er sehr.<\/p>\n\n\n\nP2 \u2013 Kontext gezielt einbeziehen<\/h3>\n\n\n\n
Systemkontext (optional zur Einordnung):\n\n[Dom\u00e4nen- oder Systembeschreibung]\n\nNutze den Kontext nur, um fachliche Annahmen einzuordnen.\nKennzeichne explizit, wo du Annahmen triffst.\n<\/code><\/pre>\n\n\n\nDer Prompt verhindert falsche Ableitungen, ohne Ideen einzuengen.<\/p>\n\n\n\n
Wenn Umsetzung unklar bleibt \u2192 P3<\/h2>\n\n\n\n
Die Story ist verst\u00e4ndlich, aber nicht planbar.<\/p>\n\n\n\n
P3 \u2013 Story zerlegen<\/h3>\n\n\n\n
Bitte mach einen Vorschlag f\u00fcr eine m\u00f6gliche fachliche Zerlegung der User Story.\nListe zuerst die Titel und Story\/Ziel der jeweiligen User Stories auf.\n<\/code><\/pre>\n\n\n\nSo entstehen umsetzbare Einheiten.<\/p>\n\n\n\n
\n\n\n\nWenn Diskussionen sich im Detail verlieren \u2192 P4<\/h2>\n\n\n\n
Hier hilft Abstand statt weiterer Details.<\/p>\n\n\n\n
P4 \u2013 High-Level Ziel ableiten<\/h3>\n\n\n\n
Bitte erstelle aus der User Story ein High-Level Epic.\n\nBeschr\u00e4nke dich auf:\n- Ziel\n- Problem & Kontext\n- Business Value\n- High-Level Akzeptanzkriterien\n<\/code><\/pre>\n\n\n\nDas Gespr\u00e4ch kehrt zur\u00fcck zum Zweck der Anforderung.<\/p>\n\n\n\n
Wenn jeder etwas anderes versteht \u2192 P5<\/h2>\n\n\n\n
Text wird interpretiert.
Abl\u00e4ufe werden beobachtet.<\/p>\n\n\n\nP5 \u2013 Visualisierung erzeugen<\/h3>\n\n\n\n
Erzeuge zur User Story eine Visualisierung in Mermaid:\n\n- UML Sequenzdiagramm\noder\n- ER Diagramm\noder\n- Aktivit\u00e4tsdiagramm\noder\n- User Journey\n<\/code><\/pre>\n\n\n\nJetzt sprechen alle \u00fcber denselben Ablauf.<\/p>\n\n\n\n
Was sich dadurch ver\u00e4ndert<\/h1>\n\n\n\n
Die Zusammenarbeit wird ruhiger.
R\u00fcckfragen entstehen fr\u00fcher.
Annahmen werden sichtbar.
Refinements werden klarer.
Verantwortlichkeiten werden verst\u00e4ndlicher.<\/p>\n\n\n\nDie Kommunikation wird nicht weniger.
Sie wird besser vorbereitet.<\/p>\n\n\n\nFazit<\/h2>\n\n\n\n
Die Prompts sind kein Prozess.
Sie sind Denkwerkzeuge.<\/p>\n\n\n\nMit P1<\/strong> strukturiere ich Anforderungen.
Mit P2 bis P5<\/strong> entwickle ich sie weiter.<\/p>\n\n\n\nTemplates ordnen Text.
Fragen ordnen Verst\u00e4ndnis.
Diese Prompts ordnen Gespr\u00e4che.<\/p>\n\n\n\nDie KI erweitert die Perspektive und macht Annahmen sichtbar.
So werden Anforderungen gemeinsam klarer.<\/p>\n","protected":false},"excerpt":{"rendered":"Wie ich KI als Sparringspartner im Requirements Engineering nutze Dieser Artikel richtet sich an Product Owner, Business Analysten und alle, die Anforderungen zwischen fachlichen und technischen Perspektiven strukturieren. Viele glauben, KI hilft beim Schreiben von User Stories.Das stimmt nur teilweise. Im Alltag scheitern Anforderungen selten am Schreiben.Sie scheitern an fehlender Klarheit.<\/p>\n","protected":false},"author":1,"featured_media":908,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1,34],"tags":[28,36,32,31],"class_list":["post-905","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-analysis","category-product-owner","tag-de","tag-ki","tag-requirements","tag-user-stories"],"_links":{"self":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts\/905","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=905"}],"version-history":[{"count":3,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts\/905\/revisions"}],"predecessor-version":[{"id":909,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/posts\/905\/revisions\/909"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=\/wp\/v2\/media\/908"}],"wp:attachment":[{"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=905"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=905"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.roederconsulting.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=905"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}