Produktanforderungen auf Mehrdeutigkeit und fehlende Entscheidungen prüfen
Autor: AILesson9 Min. EinrichtungszeitGetestet mit:ChatGPTGeprüft am: 2026-08-28
Schnelle Antwort
Formulierungen erkennen, die unvereinbare Implementierungen zulassen, und benötigte Entscheidungsverantwortliche und Belege sichtbar machen. Angeben: Anforderungsdokument, Produkt- und Systemkontext, Prüfungsumfang und Zuständigkeiten. Erwartetes Ergebnis: Eine Anforderungsprüfung mit Fundstellen für Mehrdeutigkeiten, Entscheidungslücken, Konflikten, Risiken, Klärungsfragen und Bereitschaftsstatus.
1
Kontext hinzufügen
Dein Text bleibt in diesem Browser. AILesson Prompts sendet ihn nicht an ein Modell oder einen Server.
2
Dein Prompt
Nicht ausgefüllte Felder bleiben als Platzhalter sichtbar, sodass du den Prompt weiterhin kopieren und bearbeiten kannst.
Prüfen Sie die genauen Produktanforderungen auf Mehrdeutigkeiten, Konflikte und fehlende Entscheidungen.
PRD, User Stories, Kriterien, Diagramme, Begriffe, Links, Versionen, Kommentare und Entscheidungsprotokoll:
[requirements]
Nutzende, Arbeitsabläufe, aktuelles Verhalten, Plattformen, Zustände, Rollen, Daten, Integrationen, Einschränkungen, Risiken und Richtlinien:
[context]
Release, Teams, Verantwortliche, Prüfungen, Schweregrade, Bereitschaft, Umgebungen und Überarbeitungsumfang:
[review]
Bewahren Sie genaue Auszüge und Fundstellen. Kennzeichnen Sie subjektive Adjektive und Adverbien, nicht definierte Substantive und Akteure, unbestimmte Mengenangaben, versteckte Standardwerte, Passivkonstruktionen, die Verantwortlichkeiten verbergen, Pronomen mit mehreren möglichen Bezugswörtern, uneinheitlich verwendete Begriffe, Lösungsvorgaben ohne benannten Bedarf, Beispiele, die fälschlich als vollständige Regeln verstanden werden könnten, sowie Wörter wie einfach, schnell, intuitiv, nahtlos, flexibel, sicher, unterstützen, in Echtzeit, normalerweise, angemessen und usw. Führen Sie für jedes Problem mindestens zwei wesentlich unterschiedliche Implementierungen auf, die die Formulierung zulässt, außerdem die Folge für Nutzende oder System, den Schweregrad, die betroffene Anforderung, eine angegebene entscheidungsverantwortliche Person, benötigte Belege und eine neutrale Klärungsfrage. Prüfen Sie zudem Umfangsgrenzen, Vorbedingungen, Auslöser, Zustände und Übergänge, Berechtigungen, Datenquelle und -lebenszyklus, Verhalten bei leeren Zuständen, Fehlern, Laden, Offlinebetrieb und Wiederholungsversuchen, Nebenläufigkeit und Idempotenz, Lokalisierung, Barrierefreiheit, Datenschutz, Sicherheit, Analytik, Leistung, Kompatibilität, Migration, Rücksetzung, Abhängigkeiten und Abnahmekriterien. Ermitteln Sie Widersprüche zwischen Artefakten und Entscheidungen, die im Protokoll fehlen. Erfinden Sie keine Antworten und schreiben Sie ungeklärte Entscheidungen nicht als Fakten um. Schließen Sie mit einer Trennung blockierender und nicht blockierender Lücken, einer nach Abhängigkeit und Risiko geordneten Entscheidungswarteschlange sowie dem Bereitschaftsstatus für Implementierung und Tests ab.
Standardmäßig privatDer Prompt wird lokal in deinem Browser zusammengestellt. Gib keine vertraulichen Informationen in einen KI-Dienst ein, es sei denn, deine Organisation erlaubt dies.
Von der Eingabe zum Ergebnis
Ein ausgearbeitetes Beispiel
Sieh dir an, wie konkreter Kontext dieses Rezept in ein nutzbares Ergebnis verwandelt.
Tatsächliche Eingabe
Anforderungsdokument
PRD v0.7, Abschnitt 2: ‚Die Zuständigkeit für die Abnahme soll für alle Nutzenden einfach erkennbar sein. Anfragende Personen sollen schnell die richtige Person zuweisen können. Das System soll sie angemessen benachrichtigen und in Echtzeit aktualisieren. Nicht zugewiesene Fälle usw. unterstützen.‘ User Story AC-4: ‚Bei einer Übergabe im Zustand Ready wird die Änderung gespeichert, wenn die verantwortliche Person eine abnehmende Person auswählt.‘ Diagramm D2 zeigt die anfragende Person bei der Auswahl; Kommentar C18 besagt, dass die koordinierende Person bearbeiten darf. Entscheidungsprotokoll: nur Webprototyp; keine Benachrichtigungen in diesem Release; nur aktive Mitglieder des Arbeitsbereichs; genauer Wortlaut ausstehend. Eine andere User Story besagt, dass der Status bei vorhandener abnehmender Person zu Assigned wechselt; das aktuelle Zustandsmodell enthält jedoch nur Draft, Active, Ready und Accepted.
Produkt- und Systemkontext
Rollen: Die anfragende Person erstellt; die verantwortliche Person führt die Arbeit aus; die abnehmende Person genehmigt die Abnahme; die koordinierende Person verwaltet den Arbeitsbereich. Freigegeben: Die anfragende oder koordinierende Person darf optional eine abnehmende Person festlegen; die verantwortliche Person darf nur lesen. Das Auditprotokoll erfasst handelnde Person, alten und neuen Wert sowie Zeitpunkt. Bestehende Mitglieder-IDs; keine Änderung der Aufbewahrung. Nur Web. Barrierefreiheit erfordert Tastaturbedienung, programmatisch ermittelbare Beschriftung und eine nicht ausschließlich farbliche Statusanzeige. Datenschutzprüfung abgeschlossen. Namen der Analyseereignisse und Leistungsziel ungeklärt.
Prüfungsumfang und Zuständigkeiten
Release eines Prototyps für einen Gebrauchstauglichkeitstest. Produkt verantwortet Entscheidungen zum Arbeitsablauf, Design den Wortlaut, Engineering Zustände und Fehlerverhalten, Barrierefreiheit prüft die Interaktion, Research verantwortet das Testskript. Schweregrade: B verhindert Implementierung oder Test; M erlaubt die Umsetzung, birgt aber das Risiko uneinheitlichen Verhaltens; L ist redaktionell. Bereitschaft setzt voraus: keine B-Lücken, prüfbare Kriterien, geprüftes Design, funktionsfähiger Prototyp sowie Unit- und Barrierefreiheitsprüfungen. Nur diagnostizieren; endgültige Anforderungen nicht umschreiben.
Beispielausgabe
Bereitschaft: nicht bereit; sechs blockierende Entscheidungen und mehrere Lücken mittleren Schweregrads bleiben offen.
B1 – Akteurskonflikt. AC-4 besagt „verantwortliche Person wählt aus“, D2 zeigt die anfragende Person und C18 nennt die koordinierende Person. Der freigegebene Kontext erlaubt hingegen der anfragenden oder koordinierenden Person die Auswahl und gewährt der verantwortlichen Person nur Leserechte. Dies lässt unvereinbare Autorisierungs- und Sicherheitstests zu. Die Produktverantwortung muss die freigegebene Regel in allen Artefakten bestätigen; als Beleg dienen Entscheidungsprotokoll und Kontext.
B2 – Zustandskonflikt. Eine User Story führt Assigned ein, doch im freigegebenen Zustandsmodell gibt es keinen solchen Zustand. Implementierungen könnten entweder einen neuen Zustandsübergang ergänzen oder Ready beibehalten und lediglich das Feld anzeigen. Dies wirkt sich auf Persistenz, Analytik, Migration und Tests aus. Entscheidung durch Produkt: Verändert die Zuweisung einer abnehmenden Person den Arbeitsablaufzustand oder nur die Darstellung eines Feldes?
B3 – Widerspruch bei Benachrichtigungen. „Angemessen benachrichtigen“ lässt E-Mail, Push-Mitteilung, produktinterne Mitteilung oder überhaupt keine Benachrichtigung zu; laut Entscheidungsprotokoll sind in diesem Release keine Benachrichtigungen vorgesehen. Zudem bleiben empfangende Person, Auslöser, Wiederholungsverhalten und Abwahl undefiniert. Produkt muss Benachrichtigungen für diesen Umfang entfernen oder ausdrücklich ausschließen; niemand sollte Verhalten erfinden.
B4 – Berechtigung und ungültige Daten. „Die richtige Person“ könnte eine beliebige nutzende Person, ein aktives Mitglied, ein für die Rolle qualifiziertes Mitglied oder eine vorgeschlagene Person meinen. Die freigegebene Grenze sind aktive Mitglieder des Arbeitsbereichs, doch die Abnahmekriterien behandeln weder die Eingabe inaktiver oder externer Personen noch eine gleichzeitige Deaktivierung. Produkt und Engineering müssen beobachtbare Ablehnung und Wiederherstellung definieren; Design verantwortet später den Wortlaut.
B5 – Verhalten ohne Zuweisung. „Nicht zugewiesene Fälle usw. unterstützen“ legt nicht fest, ob das Feld bei der Erstellung leer bleiben darf, später geleert werden kann, wer es leeren darf, wie es dargestellt wird oder ob Ready fortbestehen kann. Produkt verantwortet diese Entscheidungen; „usw.“ ist nicht prüfbar.
B6 – Speichern, Fehler und Nebenläufigkeit. „Gespeichert“ könnte eine optimistische lokale Anzeige oder eine bestätigte Persistenz auf dem Server bedeuten. Es fehlen Verhalten beim Laden, bei Fehlern, Wiederholungsversuchen, mehrfacher Übermittlung, zwei gleichzeitig bearbeitenden Personen, veralteter Ansicht, Auditierung und Rücksetzung. Engineering schlägt Optionen vor; Produkt genehmigt die für Nutzende sichtbare Regel.
Lücken mittleren Schweregrads: Für „einfach“, „schnell“ und „in Echtzeit“ fehlen Messgrößen; genauer Wortlaut und Namen der Analyseereignisse sind ausdrücklich offen. Tastaturreihenfolge, programmatisch ermittelbare Beschriftung, Fokus nach einem Fehler und nicht ausschließlich farbliche Anzeige benötigen Kriterien. „Alle Nutzenden“ steht im Konflikt mit rollenabhängigen Bearbeitungsrechten; Anzeige und Bearbeitung sollten unterschieden werden.
Entscheidungsfolge: Akteur/Zustand/Benachrichtigung → keine Zuweisung und Berechtigung → Speichern/Nebenläufigkeit/Fehler → barrierefreie Interaktion/Wortlaut → Analytik/Leistung. Testbereitschaft besteht erst, nachdem die B-Punkte in beobachtbare Kriterien überführt wurden.
Warum das funktioniert
1
Beispiele konkurrierender Implementierungen machen abstrakte Mehrdeutigkeiten für Entscheidungsverantwortliche konkret.
2
Nach Abhängigkeiten geordnete Lücken verhindern, dass Teams Kriterien verfeinern, obwohl das zentrale Verhalten noch nicht entschieden ist.
Ergebnis prüfen
Enthält jede Mehrdeutigkeit den genauen Text und zwei wesentlich unterschiedliche Interpretationen?
Werden fehlende Entscheidungen nur bekannten Verantwortlichen zugewiesen und niemals stillschweigend gelöst?
Umfasst die Bereitschaft Zustände, Berechtigungen, Daten, Fehlerfälle, Barrierefreiheit, Datenschutz, Tests und Rücksetzung?
Sicher nutzen
Häufig gestellte Fragen
Praktische Antworten dazu, wann du dieses Rezept verwenden solltest, was du bereitstellen solltest und wo menschliche Prüfung weiterhin wichtig ist.
Was sollte ich vorbereiten, bevor ich „Produktanforderungen auf Mehrdeutigkeit und fehlende Entscheidungen prüfen“ verwende?
Bereiten Sie für „Produktanforderungen auf Mehrdeutigkeit und fehlende Entscheidungen prüfen“ das Anforderungsdokument, den Produkt- und Systemkontext sowie Prüfungsumfang und Zuständigkeiten vor. Ersetzen Sie Platzhalter ausschließlich durch Informationen, die Sie überprüfen können. Wenn ein Detail unbekannt ist, weisen Sie ausdrücklich auf diese Unsicherheit hin, statt das Modell zu einer Schlussfolgerung aufzufordern.
Wann ist das Ergebnis von „Produktanforderungen auf Mehrdeutigkeit und fehlende Entscheidungen prüfen“ noch nicht einsatzbereit?
Das Ergebnis ist noch nicht einsatzbereit, wenn es das angegebene Resultat – eine Anforderungsprüfung mit Fundstellen für Mehrdeutigkeiten, Entscheidungslücken, Konflikten, Risiken, Klärungsfragen und Bereitschaftsstatus – nicht anhand der bereitgestellten Belege liefert oder wenn es auf ungeklärten Annahmen, fehlenden Freigaben oder erfundenen Details beruht. Nutzen Sie die Prüfpunkte als Freigabekriterien: Überarbeiten Sie die Ausgangsdaten oder beauftragen Sie eine namentlich benannte, befugte Person mit der Prüfung, statt ein unbelegtes Ergebnis sprachlich zu verfeinern.
Für welche KI-Werkzeuge sind Tests zu „Produktanforderungen auf Mehrdeutigkeit und fehlende Entscheidungen prüfen“ dokumentiert?
Im veröffentlichten Testnachweis für „Produktanforderungen auf Mehrdeutigkeit und fehlende Entscheidungen prüfen“ ist mit Stand vom 28.08.2026 ChatGPT aufgeführt. Dies bestätigt dokumentierte Testläufe, garantiert jedoch weder die Kompatibilität noch identische Ergebnisse in späteren Produktversionen. Bei einem anderen Werkzeug oder einer anderen Version sollten alle Einschränkungen sichtbar bleiben und die Ergebnisprüfungen vor der Verwendung wiederholt werden.
Vom Verstehen von KI zum Erledigen von Aufgaben. Übe Prompting, das Überprüfen und das Verbessern von Ergebnissen in interaktiven Lektionen für Arbeit und Alltag.
ChatGPT
