„Schreib User Stories für ein Bestellportal.“ So sehen die meisten Prompts für Anforderungen aus. Die Antwort wirkt plausibel, liest sich gut, und niemand kann sagen, ob sie gut ist. Die nächste Person fragt dasselbe mit anderen Worten und bekommt eine andere Antwort. Das ist kein Requirements Engineering. Das ist ein Chat.

Die IREB-Fachgruppe #AIREB hat den AI4RE Prompt Guide veröffentlicht: kostenlose Prompt-Vorlagen für typische Aufgaben im Requirements Engineering. Dieser Beitrag zeigt, was drinsteht, wie eine gute Vorlage aussieht und warum für mich der nächste Schritt nach einer Prompt-Vorlage ein Skill im Repository ist.

23 Prompts entlang der RE-Aktivitäten

Der Guide folgt den vier Aktivitäten des Requirements Engineering. Zum Zeitpunkt dieses Beitrags enthält er 23 Prompts:

  • Erhebung: eine neue Domäne kennenlernen, Stakeholder identifizieren, ein Interview vorbereiten, einen Workshop planen, ein Transkript überarbeiten, Whiteboard-Bilder transkribieren, Anforderungen identifizieren
  • Dokumentation: eine Anforderung spezifizieren, eine Synonymtabelle erstellen, eine Anforderung zerlegen, ein Modell aus Text und Text aus einem Modell erzeugen, Anforderungen in einfacher Sprache erklären, eine Persona erstellen, Testfälle erzeugen, Anforderungen aus Quellcode ableiten
  • Validierung: eine Spezifikation mit dem Quellcode vergleichen, die Konsistenz von Anforderungen analysieren, die Konsistenz von Modellen prüfen, ein Wireframe erzeugen
  • Management: die Auswirkungen eines Change Requests analysieren, Anforderungen taggen, Anforderungen verfolgen (Tracing)

Jeder Prompt hat eine eigene Seite mit derselben Struktur: die RE-Aufgabe, der KI-Ansatz und ein kurzes Fazit, dann die Prompt-Vorlage mit Variablen zum Konfigurieren, Fallstricke und Tipps sowie ein ausgefülltes Beispiel mit Ausgabe. Der Guide sagt klar, dass er den Stand eines Gebiets zeigt, das sich schnell bewegt, und zur Inspiration und Diskussion gedacht ist, nicht als Standard. Und er beginnt mit zwei Regeln, die jedes Team an die Wand hängen sollte: Gib nie sensible Daten in einen Prompt, und prüfe die Ausgabe immer, bevor du sie verwendest.

Aufbau einer Prompt-Vorlage

Die Vorlage für Specify Requirement zeigt die Struktur gut. Gekürzt, im englischen Original:

AI's role: Requirements specification expert
My role:   Requirements engineer
Purpose:   Requirement formulated in an optimized way to increase
           readability and comprehensibility.
Task:      Optimize the formulation of the following requirement.
Formulation standard: [FORMULATION]
Quality standard:     [QUALITY]
Step 1: Identify the standard used for the input requirement.
Step 2: If there are more appropriate standards, stop, suggest
        alternatives and ask which one should be used.
Step 3: Formulate the requirement according to the chosen standard.
Step 4: Validate the requirement according to the quality standard.
        Request missing information and repeat step 3.
Format: [FORMAT]
Input:  [REQUIREMENT]

Fünf Bausteine machen den Unterschied zu einem Chat-Prompt:

  • Rollen. Wer die KI ist und wer du bist. Das legt das Vokabular und das Niveau der Antwort fest.
  • Zweck und Aufgabe. Wie eine gute Ausgabe aussieht, nicht nur, was zu tun ist.
  • Variablen. [FORMULATION] kann eine User Story, ein Use Case, IEEE oder die SOPHIST-Schablone sein. [QUALITY] kann INVEST, ISO/IEC/IEEE 29148 oder IREB CPRE sein. Die Vorlage bleibt gleich, der Standard ist deine Entscheidung.
  • Ein Checkpoint. Schritt 2 sagt dem Modell, dass es anhalten und fragen soll, statt selbst ein Format zu wählen. Das ist die meistunterschätzte Zeile der Vorlage. Ein Modell, das still rät, liefert selbstbewusste Ausgaben in der falschen Form.
  • Ein Format. Die Vorlage Identify Requirements verlangt eine Tabelle mit der Anforderung in der einen Spalte und einem Zitat aus der Stakeholder-Aussage in der anderen. Diese eine Spalte liefert die Nachverfolgbarkeit gratis: Du kannst jede Anforderung mit dem vergleichen, was der Stakeholder wirklich gesagt hat.

Die Fallstricke sind das Beste daran

Vorlagen sind leicht zu kopieren. In den Abschnitten über Fallstricke steckt die Erfahrung. Für Specify Requirement nennt der Guide unter anderem:

  • Mehrdeutige Eingaben. Eine vage Anforderung führt zu falschen Annahmen. Gib Kontext mit: Systemgrenze, Stakeholder, beabsichtigtes Verhalten.
  • Überanpassung an Muster. Das Modell greift auf Vorlagen aus dem Training zurück, auch wenn sie nicht zu deiner Domäne passen. Ergänze Beispiele und Randbedingungen aus der Domäne.
  • Fehlendes Domänenwissen. Regulatorische und technische Details werden vereinfacht. Nutze das Modell für den ersten Wurf und lass eine Fachperson prüfen.
  • Grenzen der Qualitätsprüfung. Das Modell setzt nicht jedes Kriterium von ISO/IEC/IEEE 29148 durch, vor allem nicht Prüfbarkeit und Nachverfolgbarkeit. Verwende eine Checkliste.

Nichts davon ist neu für Requirements Engineers. Genau darum geht es. Der Guide ersetzt kein RE-Wissen, er zeigt, wo man es anwendet, wenn eine KI den ersten Entwurf schreibt.

Von der Prompt-Vorlage zum Skill

Eine Prompt-Vorlage, die man in einen Chat kopiert, hat eine Schwäche: Sie lebt in der Zwischenablage von jemandem. Jeder passt sie ein wenig an, niemand weiss, welche Version welches Dokument erzeugt hat, und das Ergebnis bleibt im Chatverlauf.

Ein Skill für einen Coding-Agenten ist dieselbe Idee, einen Schritt weiter. Er hat dieselben Bausteine: eine Rolle, Schritte, Checkpoints, eine Vorlage und ein Ausgabeformat. Aber er lebt im Repository. Er ist versioniert, wird wie Code reviewt und läuft für alle im Team gleich. Und das Ergebnis ist keine Chat-Antwort, sondern eine Datei in docs/, neben dem Code, der sie umsetzt.

Viele Prompts des Guides haben ein direktes Gegenstück in den Skills des AI Unified Process:

AI4RE Prompt GuideSkill im AI Unified Process
Identify requirements/requirements
Generate model from text/entity-model, /use-case-diagram
Specify requirement/use-case-spec
Analyze requirements consistency/spec-review
Generate test cases/test-case
Compare specification with source code/coverage-check
Generate requirements from source code/reverse-engineer

Der Guide und die Skills kommen aus verschiedenen Richtungen und landen bei derselben Struktur. Das nehme ich als gutes Zeichen für beide.

So nutzt du den Guide

  • Wenn du im Chat arbeitest: Schreib Prompts für Anforderungen nicht mehr jedes Mal neu. Kopiere die Vorlage, setze die Variablen und behalte den Checkpoint.
  • Wenn du mit einem Agenten und Skills arbeitest: Lies die Fallstricke und vergleiche sie mit deinen Skills. Hält dein Skill an und fragt, wenn die Eingabe mehrdeutig ist? Verweist die Ausgabe auf die Quelle?
  • Wenn du Leute ausbildest: Die ausgefüllten Beispiele sind gutes Material für Diskussionen. Wo ist die Ausgabe gut, wo würdest du widersprechen?

In meinem Spec-Driven Development Workshop schliesse ich den ersten Tag mit dem Guide ab. Nach einem Nachmittag, an dem die Teilnehmenden mit Skills Anforderungen, Use Cases und Reviews erstellt haben, sehen sie dieselben Bausteine in einer werkzeugunabhängigen Form.

Fazit

Der AI4RE Prompt Guide macht aus Prompts für Anforderungen Handwerk statt Improvisation: Rollen, Variablen, ein Checkpoint und ein Ausgabeformat, das man prüfen kann. Die Abschnitte über Fallstricke lohnen sich, auch wenn du nie eine Vorlage kopierst. Und sobald eine Vorlage für dein Team funktioniert, gehört sie als Skill ins Repository, wo sie versioniert, reviewt und für alle gleich ist.