Von der Anforderung zur Spezifikation

Von der Anforderung zur Spezifikation

0:00 Anforderungen kommen selten druckreif an. Meistens sind es ein, zwei Sätze im Vorbeigehen: „Wir brauchen sowas wie eine Warteliste, es beschweren sich Leute." Damit lässt sich nicht bauen — und trotzdem ist das der normale Ausgangspunkt. In diesem Modul geht es um den Weg von diesem Satz zu etwas, mit dem ein Agent und ein Mensch gleichermaßen arbeiten können. Der Weg ist kürzer, als viele befürchten.

0:24 Er führt allerdings über eine Stelle, die man gern überspringt: die Fragen, die man noch nicht beantworten kann.

Von der Anforderung zur Spezifikation

0:31 Vier Kapitel. Zuerst der Intent: Was gehört zu einer guten Zielbeschreibung, und warum sind Ausschlüsse genauso wichtig wie Ziele? Dann die Spezifikation selbst mit ihren fünf Feldern. Danach die Frage, wer eigentlich was entscheiden darf — und wie man das festhält. Zum Schluss prüfen Sie eine bewusst unvollständige Spezifikation und korrigieren sie. Diese letzte Übung ist erfahrungsgemäß die lehrreichste des ganzen Tages.

Intent Engineering

0:58 Beginnen wir mit dem Intent. Das Wort klingt nach Beratersprache, meint aber etwas sehr Konkretes: die Beschreibung des Zustands, der am Ende gelten soll. Interessant ist dabei weniger das Ziel selbst — das haben die meisten im Kopf — als seine Gegenstücke: was unverändert bleiben muss und was ausdrücklich nicht dazugehört.

1:16 Genau dort entstehen die Missverständnisse. Vergleichen wir es mit einem Auftrag an einen Handwerker. „Machen Sie das Bad schön" ist ein Ziel, aber kein Intent. Ein Intent wäre: Die Dusche soll begehbar sein, die Fliesen bleiben, das Fenster darf nicht zugebaut werden, und was mit der Heizung passiert, entscheiden wir später.

1:36 Das ist genau die Struktur: Zielzustand, Unveränderliches, Ausschlüsse, offene Fragen. Der Punkt dabei ist nicht Vollständigkeit. Der Punkt ist, dass jede dieser Angaben eine Entscheidung verhindert, die sonst jemand anderes für Sie trifft — und dieser jemand ist beim agentischen Arbeiten die Maschine. Der erste Punkt ist der schwerste: Problem und Nutzen nennen, nicht die vermutete Lösung. Anfragen kommen fast immer schon als Lösung formuliert, weil das natürlicher ist.

2:04 „Wir brauchen eine Warteliste" ist eine Lösung; das Problem lautet, dass Anfragen verloren gehen. Manchmal stellt sich beim Nachfragen heraus, dass eine andere Lösung besser passt. Der zweite Punkt — beobachtbares Verhalten statt innerer Umbauten — hält die Umsetzung offen. Und der vierte, das offene Benennen von Fragen, ist der, der später die meisten Diskussionen erspart.

2:27 Sie sehen hier links, was ankommt, und rechts, was daraus wird. Der Wortlaut der Anfrage ist echt in dem Sinne, dass er typisch ist — vage, mit einer eingebauten Lösung und einer emotionalen Begründung. Die Übersetzung daneben ist nicht länger, sie ist nur anders sortiert. Achten Sie auf die letzte Zeile, die mit „Offen" beginnt. Sie ist der wertvollste Teil des ganzen Blocks.

2:50 Ohne sie hätte jemand entschieden, wie lange ein Nachrückangebot gilt — vermutlich der Agent, vermutlich plausibel, und ganz sicher, ohne dass jemand gefragt wurde. Diese vier Fallen kommen in genau dieser Häufigkeit vor. Die erste haben wir gerade behandelt: Die Anfrage enthält schon eine Lösung, und niemand fragt nach dem Problem dahinter.

3:10 Die zweite betrifft Qualitätsanforderungen — sie fehlen im Text und werden später trotzdem erwartet, was zu einer unangenehmen Diskussion nach der Umsetzung führt. Die dritte ist der fehlende Ausschluss: Was nicht draußen ist, wächst gern hinein. Und die vierte ist die feinste — offene Fragen werden als Annahmen getarnt und sind damit nicht mehr als offen erkennbar.

Die Spezifikation erarbeiten

3:31 Aus dem Intent wird jetzt die Spezifikation. Wichtig ist mir dabei ein Wort in der Überschrift des Kapitels: erarbeiten. Sie schreiben sie nicht allein am Schreibtisch, und Sie lassen sie auch nicht einfach generieren. Es ist ein Wechselspiel — und das Ergebnis ist deutlich kürzer, als das Wort Spezifikation vermuten lässt.

3:50 Fünf Felder, mehr braucht es nicht: warum überhaupt, welche Fähigkeiten mit je einer Erfolgsbedingung, welche Randbedingungen gelten, was ausdrücklich draußen bleibt und woran der Erfolg insgesamt erkennbar wird. Das passt auf eine Bildschirmseite. Wenn Sie sich fragen, wo denn die Details bleiben — die stehen im Code, und das ist Absicht.

4:10 Die Spezifikation ist ein Umsetzungsvertrag, kein Pflichtenheft. Sie beschreibt, worauf man sich einigt, nicht, wie es programmiert wird. Die Beispielspalte rechts zeigt, wie knapp das sein darf. „Anfragen gehen verloren" ist ein vollständiges Warum. Wichtiger ist die Fußzeile: Jede Fähigkeit trägt ihre eigene Erfolgsbedingung. Das ist die Stelle, an der sich Spreu von Weizen trennt.

4:34 Solange Sie zu einer Fähigkeit keine Bedingung formulieren können, haben Sie keine Fähigkeit beschrieben, sondern eine Absicht. „Nachrücken" ist eine Absicht. „Wird eine Buchung storniert, erhält genau der erste Eintrag den Platz" ist eine Fähigkeit — prüfbar, testbar, strittig, wenn jemand anderer Meinung ist. Genau das wollen wir.

4:56 Der interessante Schritt ist der vierte: verdichten. Man neigt dazu, eine Spezifikation länger zu machen, weil Länge nach Sorgfalt aussieht. Der Effekt ist das Gegenteil — jede Zeile, die nichts entscheidet, macht die entscheidenden Zeilen unsichtbarer. Streichen Sie deshalb ausdrücklich. Der fünfte Schritt, die Zerlegung in Stories, kommt erst bei größerem Umfang.

5:17 Achten Sie dort auf die Frage nach dem Checkpoint: Für jeden Schnitt wird gefragt, ob ein Mensch davor oder danach draufschauen soll. Diese kleine Frage ist ein sehr wirksames Sicherheitsnetz. Übermäßige Spezifikation ist der häufigste Fehler von Teams, die den Ansatz ernst nehmen. Wer Technik festlegt, die niemand verlangt hat, verbaut Alternativen und altert schneller.

5:39 Der zweite Punkt ist ein Werkzeugthema mit praktischer Folge: Wenn ein Ablauf der Schreiber einer Datei ist und Sie von Hand nachbessern, laufen Datei und Werkzeug auseinander — dann besser den Ablauf noch einmal anstoßen. Der dritte Punkt sind die nicht überprüfbaren Aussagen. Und der vierte: Randfälle fehlen, weil nur der glückliche Pfad beschrieben wurde. Das rächt sich in den Tests.

Menschliche Entscheidungspunkte

6:02 Jetzt zu einer Frage, die Teams selten explizit klären und deshalb immer wieder neu verhandeln: Welche Entscheidungen darf der Agent vorbereiten, und welche müssen von einem Menschen kommen? Die Antwort gehört in die Spezifikation — sonst wird sie in jeder Sitzung neu erfunden. Nicht jede offene Frage ist gleich viel wert, und das ist der Schlüssel zu einem praktikablen Prozess.

6:24 Wenn Sie jede Kleinigkeit zur menschlichen Entscheidung erklären, steht die Arbeit still und die Freigaben werden reflexhaft erteilt. Die Trennlinie verläuft an der Wirkung: Entscheidungen mit fachlicher, rechtlicher oder architektonischer Konsequenz gehören zu einem Menschen. Alles andere darf der Agent vorbereiten und begründet vorschlagen — was übrigens etwas anderes ist als „selbst entscheiden".

6:46 Ein Vorschlag mit Begründung ist eine Vorlage, die jemand annimmt oder verwirft. Die Beispiele in dieser Tabelle sind mit Absicht so gewählt, dass die Grenze sichtbar wird. Feld- und Endpunktnamen darf der Agent vorschlagen — sie sind folgenlos, solange sie konsistent sind. Die Frist eines Nachrückangebots ist eine fachliche Entscheidung, auch wenn sie technisch trivial wäre. Eine zusätzliche Tabelle betrifft die Architektur.

7:12 Und wer fremde Buchungen stornieren darf, ist Fachseite und Security zugleich. Die Fußzeile ist mir wichtig: Wer entscheidet, gehört in die Spec — nicht nur, was entschieden wurde. Sonst klärt man die Zuständigkeit beim nächsten Mal erneut. Nachvollziehbarkeit klingt nach Aktenordner, ist hier aber sehr praktisch gemeint: Jede Fähigkeit sollte sich zu einem Test und zu einem Diff verfolgen lassen.

7:36 Der Nutzen zeigt sich an drei Stellen. Erstens fallen widersprüchliche Anforderungen überhaupt erst auf, wenn man sie verfolgt. Zweitens ersetzt die Verfolgung im Review die Diskussion über Absichten — man schaut nach, statt sich zu erinnern. Und drittens erklärt sie nach Monaten, warum etwas so und nicht anders gebaut wurde. Diese dritte Situation kommt garantiert, meist wenn niemand mehr da ist, der dabei war.

8:00 Der erste Punkt ist der stillste und gefährlichste: Der Agent trifft eine Fachentscheidung, weil niemand widersprochen hat. Widerspruch setzt aber voraus, dass jemand die Entscheidung als solche bemerkt. Der zweite Punkt betrifft mündliche Bestätigungen — sie sind schnell, gelten aber nur, solange sich alle erinnern. Der dritte ist ein Klassiker aus der Praxis: Security wird nach der Umsetzung gefragt und muss dann bremsen, was allen unangenehm ist.

8:26 Und der vierte ist die Gegenrichtung: Zu viele Freigabepunkte lähmen und werden bald übergangen. Beides ist ein Fehler.

Spezifikationen prüfen

8:34 Zum Abschluss die Qualitätssicherung. Eine Spezifikation wird geprüft wie Code — und zwar mit vier Fragen, die man sich merken kann. Danach sind Sie dran: Sie bekommen eine bewusst unvollständige Fassung und bringen sie in Ordnung. Diese Übung ist erfahrungsgemäß die lehrreichste des Tages, weil die typischen Schwächen erst auffallen, wenn man sie an einem fremden Text sucht.

8:55 Vier Fragen decken die meisten Mängel auf. Ist jede Aussage überprüfbar? Fehlt ein Randfall? Steht etwas darin, das niemand verlangt hat? Und legt sie Technik fest, die offen bleiben sollte? Das dauert zehn Minuten und findet erfahrungsgemäß drei bis fünf Stellen. Der Grund, warum das funktioniert: Alle vier Fragen richten sich gegen typische Schreibreflexe.

9:17 Wir formulieren gern freundlich, beschreiben gern den Normalfall und schlagen gern schon eine Lösung vor. Die Fragen zwingen dazu, das jeweils rückgängig zu machen. Jetzt zur Übung. Sie bekommen eine bewusst unvollständige Feature-Anfrage und entwickeln daraus eine Spezifikation — mit den fünf Feldern, die wir besprochen haben.

9:37 Danach prüfen Sie sie mit der Checkliste und korrigieren, was Sie finden. Die Lücken sind gewollt, suchen Sie also nicht nach der einen richtigen Fassung. Was zählt, ist, dass nicht überprüfbare Aussagen verschwinden, fehlende Randfälle auftauchen und erfundene Anforderungen gestrichen werden. Ein Tipp: Fangen Sie mit den Randfällen an. Spielen Sie den leeren Zustand durch — dort steckt fast immer eine fehlende Zeile.

10:02 Beim Prüfen selbst gibt es vier Fallen. Die erste ist die wichtigste und begleitet uns durch das ganze Seminar: Prüfen Sie nicht im selben Kontext, der geschrieben hat. Dieselbe Annahme fällt sich selbst nicht auf. Die zweite ist die Formulierungsdiskussion — sie fühlt sich produktiv an und ändert nichts. Die dritte ist mechanisches Abhaken der Checkliste, ohne den Intent noch einmal zu lesen. Und die vierte ist die banalste: Die Korrekturen landen im Chat statt in der Datei.

10:30 Am nächsten Tag ist die Datei die einzige Wahrheit, die übrig ist. Vier Punkte gehen mit. Ein Intent nennt Zielzustand, Unveränderliches, Ausschlüsse und offene Fragen — vier Angaben, keine Doktorarbeit. Fünf Felder genügen für die Spezifikation. Jede Fähigkeit braucht eine eigene Erfolgsbedingung, sonst ist sie nur eine Absicht. Und: Wer entscheidet, gehört mit in die Spec, nicht nur was entschieden wurde.

10:56 Damit haben wir einen Umsetzungsvertrag. Im nächsten Modul zerlegen wir ihn — in Entscheidungen, die kollidieren könnten, und in Arbeitseinheiten, die ein Agent in einer Sitzung schafft.