Write verifiable acceptance criteria

Autor: AILesson6 min de configuraçãoTestado com:ChatGPTRevisado em: 2026-08-28

Resposta rápida

Translate requirements into observable pass conditions, edge cases, exclusions, and evidence. Forneça: Requirement and user outcome, Business and quality rules, Scope and unknowns. Resultado esperado: A testable acceptance set with traceability, examples, and unresolved decisions.

1

Adicione seu contexto

Seu texto permanece neste navegador. O AILesson Prompts não o envia para um modelo ou servidor.

2

Seu prompt

Campos não preenchidos permanecem visíveis como marcadores de posição, para que você ainda possa copiar e editar o prompt

Write verifiable acceptance criteria for the requirement.

Approved requirement, user, purpose, and source:
[requirement]

Business, data, permission, state, threshold, accessibility, performance, and error rules:
[rules]

Scope, exclusions, platforms, dependencies, unresolved terms, and approver:
[boundaries]

Use only supplied rules. Split compound behavior into atomic criteria. For each criterion provide ID, source requirement, precondition, action or event, observable expected result, test data or boundary example, evidence, and priority. Cover happy path, empty/invalid/duplicate input, permission boundaries, interrupted or partial completion, time and locale behavior, recovery, accessibility, and non-functional thresholds only where relevant and specified. Mark ambiguous requirements as Decision needed; do not invent a threshold or implementation. Detect conflicts and untestable words such as fast, intuitive, appropriate, or real time. Finish with out-of-scope checks and a traceability matrix.
Experimente no Playground
Privado por padrãoA montagem do prompt acontece localmente no seu navegador. Evite colocar informações confidenciais em qualquer serviço de IA, a menos que sua organização permita.

Da entrada ao resultado

Um exemplo prático

Veja como um contexto concreto transforma esta receita em um resultado útil

Entrada real

Requirement and user outcome
REQ-12: An authenticated employee can save a draft expense claim and return later without submitting it, so incomplete work is not lost.
Business and quality rules
A claim has ClaimID, employee ID, currency, line items, receipt attachments, status, created/updated timestamps. Draft may omit receipts and cost center. Only the employee who created it may view/edit. Submit validates required fields and is out of this story. Autosave is requested as 'quickly' but no interval is approved. Supported web locales are en-GB and zh-CN. Attachments must use existing upload rules.
Scope and unknowns
Web only. Offline editing and manager access are out of scope. Identity and upload services are dependencies. Product owner approves criteria. Session-expiry behavior and draft retention period are unresolved.

Exemplo de saída

AC-01 | REQ-12 | authenticated employee starts a claim | selects Save draft | a unique ClaimID is stored with creator, Draft status, currency, existing line data, and updated timestamp; no submission occurs | evidence: persisted record and UI confirmation | Must. AC-02 | REQ-12 | draft lacks receipt and cost center | Save draft | save succeeds because those fields are optional for Draft | boundary example: one line item, no attachment/cost center | Must. AC-03 | ownership rule | employee B requests employee A's draft by UI or direct URL | access denied and no claim details exposed | evidence: authorization test/log | Must. AC-04 | return later | creator signs in later in en-GB or zh-CN | draft appears with stored values and locale-appropriate presentation; underlying amounts/timestamps remain unchanged | Must. AC-05 | upload dependency | attachment save fails under existing upload rules | draft behavior and recoverable message require confirmation; do not claim attachment persisted | Decision needed.

Decisions needed: autosave interval replacing “quickly”; session-expiry behavior for unsaved edits; retention period and deletion notice. Out of scope: submission validation, manager access, offline editing. Traceability: REQ-12→AC-01/02/04; ownership→AC-03; upload dependency→AC-05.

Por que isso funciona

  1. 1

    Observable results and boundary examples make agreement testable before implementation starts.

  2. 2

    Decision-needed labels keep product ambiguity from being hidden inside a test case.

Verifique o resultado

  • Is each criterion atomic, observable, and traceable to a supplied requirement?

  • Are edge conditions relevant rather than generic boilerplate?

  • Were missing thresholds and undefined terms left as decisions?

Use com confiança

Perguntas frequentes

Respostas práticas sobre quando usar esta receita, o que fornecer e onde a revisão humana ainda é importante

What should I prepare before using “Write verifiable acceptance criteria”?

For “Write verifiable acceptance criteria,” prepare Requirement and user outcome, Business and quality rules, and Scope and unknowns. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Write verifiable acceptance criteria” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A testable acceptance set with traceability, examples, and unresolved decisions—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Write verifiable acceptance criteria”?

The published test record for “Write verifiable acceptance criteria” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

Mais maneiras de explorar

Onde esta receita se encaixa

Mantenha o trabalho em andamento