Translate requirements into observable pass conditions, edge cases, exclusions, and evidence
6 min setupTested with:ChatGPTReviewed: 2026-08-28
1
Add your context
Your text stays in this browser. AILesson Prompts does not send it to a model or server.
2
Your prompt
Unfilled fields remain visible as placeholders, so you can still copy and edit the 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.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.
From input to outcome
A worked example
See how concrete context turns this recipe into a usable result
Actual input
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.
Example output
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.
Why this works
1
Observable results and boundary examples make agreement testable before implementation starts.
2
Decision-needed labels keep product ambiguity from being hidden inside a test case.
Check the result
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?