Write verifiable acceptance criteria

작성자: AILesson6 분 소요테스트::ChatGPT검토일: 2026-08-28

빠른 답변

Translate requirements into observable pass conditions, edge cases, exclusions, and evidence. 제공할 내용: Requirement and user outcome, Business and quality rules, Scope and unknowns. 예상 결과: A testable acceptance set with traceability, examples, and unresolved decisions.

1

맥락 추가

텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.

2

프롬프트

채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다

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.
Playground에서 사용해 보기
기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.

입력에서 결과까지

적용 예시

구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요

실제 입력

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.

예시 출력

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.

효과가 있는 이유

  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.

결과 확인

  • 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?

안심하고 사용하세요

자주 묻는 질문

이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변

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.

더 많은 탐색 방법

이 레시피가 적합한 상황

작업을 계속 진행하세요