# 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 |

---

<!-- GUIDANCE: Acceptance criteria define the conditions under which a feature is considered
"done" and accepted by the business. This document consolidates acceptance criteria at the
feature/module level (complementing the granular criteria in individual user stories).
It serves as the basis for UAT test cases and final sign-off. -->

## 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]
```

**Example — User Login:**
```
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

<!-- GUIDANCE: Organize by module/feature. For each feature, provide:
- Feature reference (FR-XXX)
- Business requirement reference (BR-XXX)
- Positive scenarios (at least 1)
- Negative scenarios (at least 1 per input type)
- Edge cases (boundary conditions)
Copy the feature block below for each feature. -->

---

### 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@example.com | User submits registration with email@example.com | 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 user+tag@example.com | 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 |

---

#### Feature: User Login (FR-021)

**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}})

<!-- Copy and fill this block for each additional feature -->

**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

<!-- GUIDANCE: Integration scenarios test that your system works correctly with external services.
These often require special test environments (sandbox mode, mock services). -->

| # | 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

<!-- GUIDANCE: These criteria apply across all features. Reference the NFR document for targets.
Each item here is a must-pass before any milestone or production release. -->

### 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

<!-- GUIDANCE: This table maps acceptance criteria to UAT test scenarios.
The UAT team uses this to prepare their test scripts. -->

| 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

<!-- GUIDANCE: Every acceptance criterion must trace back to a requirement.
Orphaned acceptance criteria (no requirement) suggest scope creep.
Requirements with no acceptance criteria will not be verifiable. -->

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