Wie arbeite ich mit KI an Anforderungen, ohne in generischen „KI-Stories“ zu enden? In dieser Artikelreihe zeige ich meine komplette Requirements-Engineering-Pipeline aus der Praxis – von der rohen Idee bis zum Ticket, das im Entwicklungsteam ankommt.
Der rote Faden: Der Mensch besitzt die Absicht, die Agenten besitzen die Prüfung. Die KI schreibt keine User Stories – sie prüft, gleicht ab und hinterfragt. Jeder Teil steht für sich; zusammen ergeben sie das ganze Vorgehen mit Obsidian, Claude Code und Jira. Das komplette System gibt es als offenes Starter-Kit auf GitHub. Am besten startest du bei Teil 1.
Ich hatte eine wirklich gute Story. Sauber abgegrenzt und vorher geprüft. Dann lege ich sie einem Team vor und ernte … More Jira-Tickets an das Team anpassen: Warum die Story die Sprache des Teams sprechen muss
Ich war verliebt in eine Idee. Eine Funktion, die ich unbedingt bauen wollte, ich hatte sie mir schon in allen … More Multi-Agent-Review: Sechs Perspektiven auf eine Story – und ein Advocatus Diaboli
„Was soll damit ausdrücklich nicht passieren?“ Diese eine Frage hat mich neulich ausgebremst. Ich hatte eine Idee, von der ich … More Anforderungen mit KI erheben: ein Interview statt eines Fragebogens
Bei spielmit.eu, einem meiner privaten Projekte, habe ich der KI am Anfang einfach freien Lauf gelassen. „Bau mir das“ – … More Guidelines-First: Warum eine KI ohne Wissensbasis am Jenga-Turm baut
Neulich wollte ich eine neue User Story anlegen. Kleine Sache, dachte ich, eine Funktion, die alte Daten automatisch aufräumt. Ich … More Warum ich keine KI-generierten User Stories schreibe – und KI trotzdem überall einsetze