acceptance-criteria

name	acceptance-criteria
description	Write testable acceptance criteria and acceptance tests for requirements using Given/When/Then, checklist, and rule-based formats. Use when defining the conditions that prove a requirement is correctly implemented.
intent	Create acceptance criteria that define the specific, testable conditions under which a requirement is considered satisfied. Covers three formats (Given/When/Then, checklist, rule-based), SMART criteria for requirements, and the separation between acceptance criteria (conditions) and acceptance tests (procedures). Use this to close the gap between "what does this requirement mean?" and "how do we prove it works?"
type	component
theme	re-artifacts
best_for	["Defining done for user stories and requirements","Creating testable conditions for functional and non-functional requirements","Bridging the gap between requirements and test cases"]
scenarios	["Developers keep asking what 'done' means for this requirement","I need to write acceptance criteria that QA can turn into test cases"]
estimated_time	5-10 min per requirement
trigger	需要定义功能完成标准
input	PRD 文档
output	验收标准列表
next	user-story
dependencies	prd-development

Purpose

Create acceptance criteria that define the specific, testable conditions under which a requirement is considered satisfied. Use this to close the gap between "what does this requirement mean?" and "how do we prove it works?"

This is not test case writing -- acceptance criteria define what to verify. Test cases define how to verify it. Acceptance criteria live in requirements; test cases live in test plans.

Key Concepts

Acceptance Criteria vs. Acceptance Tests

Aspect	Acceptance Criteria	Acceptance Tests
What	Conditions for satisfaction	Procedures to verify conditions
Who writes	BA / Requirements Engineer	QA / Test Engineer
When	During requirements specification	During test planning
Format	Given/When/Then, checklists	Step-by-step test procedures with expected results
Lives in	SRS, user stories	Test plan, test management tool

Three Formats for Acceptance Criteria

1. Given/When/Then (Gherkin) Best for behavior-driven scenarios with clear preconditions and triggers:

Given [precondition],
When [action],
Then [expected result].

2. Checklist Best for straightforward pass/fail conditions:

- [ ] [Condition that must be true]
- [ ] [Another condition that must be true]

3. Rule-Based Best for business rules with multiple examples:

Rule: [Business rule statement]
Example: [Input] -> [Expected output]
Example: [Different input] -> [Different expected output]

SMART Acceptance Criteria

Every acceptance criterion should be:

• Specific -- Describes a single, concrete condition
• Measurable -- Has a pass/fail determination
• Achievable -- Technically feasible
• Relevant -- Traces to a requirement or user need
• Testable -- A tester can verify it without interpretation

Anti-Patterns

• The Obviously True -- "The system shall function correctly." Every requirement should function correctly.