Acceptance Criteria

Acceptance Criteria: {{PROJECT_NAME}}

Project: {{PROJECT_NAME}} Version: {{VERSION}} Date: {{DATE}} Author: {{AUTHOR}} Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}}

Document History

Version	Date	Author	Changes
0.1	{{DATE}}	{{AUTHOR}}	Initial draft

1. Purpose & Methodology

1.1 What Are Acceptance Criteria?

Acceptance criteria are the conditions that a system must satisfy to be accepted by a stakeholder. They answer the question: "How will we know when this feature is done?"

Good acceptance criteria are:

Testable — Can be verified with a specific test procedure
Clear — Unambiguous; no room for interpretation
Complete — Cover happy path, error paths, and edge cases
Agreed — Signed off by the business BEFORE development begins

1.2 Format: Given / When / Then (Gherkin-Style)

Given [an initial context / precondition that is true]
When  [an action or event occurs]
Then  [the expected outcome is observed]
And   [additional expected outcomes, chained]

Given a registered user with valid credentials
When the user submits the login form
Then the user is redirected to the dashboard
And a session token is created and stored in a secure cookie
And the last login timestamp is updated in the database

1.3 Categories of Acceptance Criteria

Category	Description	Example
Positive (Happy Path)	System works as expected with valid inputs	Successful login
Negative (Sad Path)	System handles invalid inputs gracefully	Wrong password error
Edge Case	Boundary conditions and unusual but valid scenarios	Login at exact session timeout
Integration	System works correctly with external services	Payment processed via Stripe
Non-Functional	Performance, accessibility, security criteria	Page loads in < 2 seconds
Data	Correct data storage, retrieval, and validation	Fields saved with correct types

2. Feature Acceptance Criteria

Module: {{MODULE_1_NAME}}

Feature: {{FEATURE_1_NAME}} (FR-{{XXX}})

Feature Description: {{BRIEF_DESCRIPTION}} Business Requirement: BR-{{XXX}} Linked User Stories: US-{{XXX}}, US-{{XXX}}

Positive Scenarios:

#	Scenario	Given	When	Then
AC-001	{{SCENARIO_NAME}}	{{PRECONDITION}}	{{ACTION}}	{{EXPECTED_RESULT}}
AC-002

Negative Scenarios:

#	Scenario	Given	When	Then
AC-003	{{INVALID_INPUT_SCENARIO}}	{{PRECONDITION_WITH_BAD_DATA}}	{{ACTION}}	{{ERROR_MESSAGE_OR_BEHAVIOR}}
AC-004

Edge Cases:

#	Scenario	Given	When	Then
AC-005	{{BOUNDARY_CONDITION}}	{{EDGE_CONDITION}}	{{ACTION}}	{{EXPECTED_RESULT}}

Non-Functional Acceptance Criteria:

#	Category	Criterion
AC-006	Performance	Feature completes in < {{X}} seconds under normal load
AC-007	Accessibility	Feature is fully operable by keyboard; ARIA labels present
AC-008	Security	{{SECURITY_CRITERION_IF_APPLICABLE}}

Feature: User Registration (FR-020)

Feature Description: New users can create accounts using email and password. Business Requirement: BR-{{XXX}} Linked User Stories: US-{{XXX}}

Positive Scenarios:

#	Scenario	Given	When	Then
AC-010	Successful registration	A user visits /register with a valid, unregistered email	User submits form with valid email, strong password, and required fields	Account is created; confirmation email sent; user redirected to email verification page
AC-011	Email verification sent	Account was just created	System processes registration	Verification email arrives within 2 minutes with unique, expiring link
AC-012	Verification link works	User receives verification email	User clicks verification link	Email verified; user redirected to login; account marked as verified

Negative Scenarios:

#	Scenario	Given	When	Then
AC-013	Duplicate email	An account already exists with [email protected]	User submits registration with [email protected]	Error "An account with this email already exists" shown; no new account created
AC-014	Weak password	User is on registration form	User submits password "abc123"	Inline error shown: "Password must be at least 8 characters and include uppercase, number, and special character"
AC-015	Invalid email format	User is on registration form	User submits "notanemail" in email field	Inline validation error shown before form submission
AC-016	Empty required field	User is on registration form	User submits with required field empty	Inline error shown; form not submitted

Edge Cases:

#	Scenario	Given	When	Then
AC-017	Email with plus addressing	User submits [email protected]	Registration submitted	Account created; treated as valid email
AC-018	Verification link expiry	Verification link generated 25+ hours ago	User clicks expired link	Error "Verification link has expired"; option to resend verification email shown
AC-019	Double registration attempt	User submits form; due to slow network submits twice	Two identical POST requests sent	Only one account created; second request returns appropriate error

Positive Scenarios:

#	Scenario	Given	When	Then
AC-020	Successful login	A verified user with valid credentials	User submits login form	Authenticated; redirected to dashboard; session created
AC-021	Remember me	A verified user checks "Remember Me"	User submits login form	Session persists for 30 days; user stays logged in after browser close

Negative Scenarios:

#	Scenario	Given	When	Then
AC-022	Wrong password	A registered user exists	User submits incorrect password	Generic error "Invalid email or password" (no enumeration); login not granted
AC-023	Non-existent email	No account for this email	User submits login	Same generic error "Invalid email or password" (prevent user enumeration)
AC-024	Account locked	User has made 5 failed attempts	User attempts login again	Message: "Account temporarily locked. Try again in 15 minutes."

Edge Cases:

#	Scenario	Given	When	Then
AC-025	Session expiry	User has been idle for 31 minutes	User attempts to navigate	Redirected to login; session cleared; unsaved work warning shown
AC-026	Login on unverified account	Account created but email not verified	User attempts to log in	Error "Please verify your email before logging in" with option to resend

Feature: {{NEXT_FEATURE_NAME}} (FR-{{XXX}})

Positive Scenarios:

#	Scenario	Given	When	Then
AC-{{NEXT}}

Negative Scenarios:

#	Scenario	Given	When	Then
AC-{{NEXT}}

Edge Cases:

#	Scenario	Given	When	Then
AC-{{NEXT}}

3. Integration Scenarios

#	Integration	Scenario	Expected Behavior	Test Environment
INT-001	{{EXTERNAL_SERVICE}}	{{SCENARIO}}	{{EXPECTED}}	Sandbox / Mock
INT-002	Email provider	Transactional email delivery	Email received within 2 minutes	Mailtrap / staging
INT-003	{{PAYMENT_PROVIDER}}	Successful payment	Transaction recorded; confirmation shown; webhook received	Stripe test mode
INT-004	{{PAYMENT_PROVIDER}}	Payment declined	User sees friendly error; no order created; no double-charge	Stripe test mode
INT-005	{{THIRD_PARTY_API}}	API timeout	System shows user-friendly error; request logged; no data corruption	Mocked timeout
INT-006	{{THIRD_PARTY_API}}	API unavailable	System degrades gracefully; non-dependent features still work	Service unavailable mock

4. Non-Functional Acceptance Criteria

4.1 Performance

#	Criterion	Target	Test Method
NF-AC-001	All pages load within target time	< 3s initial, < 1.5s subsequent	Lighthouse on staging
NF-AC-002	All API endpoints respond within target	< 500ms at p95 under normal load	k6 load test
NF-AC-003	Core Web Vitals pass	LCP < 2.5s, CLS < 0.1, FCP < 1.8s	Lighthouse

4.2 Accessibility

#	Criterion	Target	Test Method
NF-AC-010	No critical accessibility violations	0 critical violations	axe-core automated scan
NF-AC-011	Keyboard navigation complete	All features operable without mouse	Manual test
NF-AC-012	Color contrast compliant	≥ 4.5:1 text/background	Contrast checker

4.3 Security

#	Criterion	Target	Test Method
NF-AC-020	No OWASP Top 10 vulnerabilities	0 critical/high findings	OWASP ZAP scan
NF-AC-021	All user inputs sanitized	No XSS/injection vulnerabilities	SAST + manual testing
NF-AC-022	No sensitive data in client-side code	No API keys, tokens in browser	Code review + browser DevTools

5. UAT Scenario Mapping

AC ID	AC Description	UAT Scenario ID	UAT Tester	Status
AC-010	Successful registration	UAT-001	{{TESTER}}	Not Started
AC-011	Email verification sent	UAT-002
AC-020	Successful login	UAT-003
INT-003	Payment success	UAT-010
NF-AC-001	Page load performance	UAT-P01

6. Traceability to Requirements

AC ID	Acceptance Criterion	FR Reference	BR Reference	US Reference
AC-001	{{CRITERION}}	FR-{{XXX}}	BR-{{XXX}}	US-{{XXX}}
AC-010	Successful registration	FR-020	BR-{{XXX}}	US-{{XXX}}

Full traceability: [requirements-traceability-matrix.md](requirements-traceability-matrix.md)

Approval

Role	Name	Date	Signature
Author
Reviewer
Business Analyst
Product Owner
QA Engineer
AI Director (John)
Client Representative

Acceptance Criteria

Acceptance Criteria: {{PROJECT_NAME}}

Document History

1. Purpose & Methodology

1.1 What Are Acceptance Criteria?

1.2 Format: Given / When / Then (Gherkin-Style)

1.3 Categories of Acceptance Criteria

2. Feature Acceptance Criteria

Module: {{MODULE_1_NAME}}

Feature: {{FEATURE_1_NAME}} (FR-{{XXX}})

Feature: User Registration (FR-020)

Feature: User Login (FR-021)

Feature: {{NEXT_FEATURE_NAME}} (FR-{{XXX}})

3. Integration Scenarios

4. Non-Functional Acceptance Criteria

4.1 Performance

4.2 Accessibility

4.3 Security

5. UAT Scenario Mapping

6. Traceability to Requirements

Approval