# Acceptance Criteria (BDD): [Feature name]

> Acceptance criteria for one feature, written as Gherkin feature files
> with Given/When/Then scenarios and traced to the user stories they
> accept. The syntax follows the Gherkin reference published by the
> Cucumber project (cucumber.io). Scenarios written this way can be read
> by the business and run as automated tests. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write the scenarios together: product owner, developer and tester
  (the "three amigos") in a short session before the story is pulled
  into an iteration.
- Start with the rules (section 2), then write one or two concrete
  examples for each rule. A rule without an example is untested; an
  example without a rule is hard to maintain.
- Describe behaviour in business terms. "When the policyholder submits
  the claim" is good; "When I click the blue button" is not.
- Keep each scenario short: a handful of steps, one When, and Then steps
  that check outcomes the user can observe.
-->

## Document control

<!-- Guidance: Identify the feature and link it to the stories and epic it belongs to. -->

| Field | Value |
|---|---|
| Document ID | [AC-FEATURE-001] |
| Feature | [Feature name] |
| Epic | [Epic ID and title] (`product/epic`) |
| Stories covered | [US-nnn, US-nnn] (`product/user-story`) |
| Version | [0.1] |
| Status | [Draft / Agreed / Automated / Retired] |
| Owner | [@product-owner] |
| Contributors | [@developer], [@tester] |
| Feature file path | [features/claims/notify-claim.feature] |
| Last updated | YYYY-MM-DD |

## 1. Feature and stories

<!-- Guidance: State the feature in one sentence of business value and list the stories it accepts. Pitfall: one feature file covering half the product, which nobody can read in one sitting. -->

[One sentence: who gets what value from this feature.]

| Story ID | Story | Priority | Scenarios |
|---|---|---|---|
| US-101 *(Example)* | As a policyholder I want to report a burst pipe online so that I do not wait on the phone | Must | SC-01, SC-02 |
| US-102 *(Example)* | As a policyholder I want to add photos so that the handler can assess the damage quickly | Should | SC-03 |
| US-103 *(Example)* | As a claims handler I want claims above the referral limit routed to me so that large losses get a check | Must | SC-04, SC-05 |
| [US-nnn] | [Story] | [Priority] | [SC-nn] |

## 2. Business rules and examples

<!-- Guidance: List each rule the feature must respect, with the examples that illustrate it. Gherkin's Rule keyword (available since Gherkin 6) groups scenarios under the rule they illustrate. Keep the rule IDs from the business rules catalogue so the two documents agree. -->

| Rule | Statement | Source | Examples |
|---|---|---|---|
| BR-CLM-004 *(Example)* | A claim can be notified online only for an active policy | `requirements/business-rules-catalogue` | SC-01, SC-02 |
| BR-CLM-007 *(Example)* | Claims with an estimated value above 5,000 are referred to a handler before any payment | Claims authority matrix | SC-04, SC-05 |
| BR-CLM-009 *(Example)* | Each photo must be 10 MB or smaller, at most 10 photos per claim | Upload policy | SC-03 |

## 3. Feature file

<!-- Guidance: Paste or write the feature file here. Rules from the Gherkin reference: the first keyword is Feature, one Feature per file; Background runs before each scenario of its Feature or Rule (one per level); Scenario Outline needs at least one Examples table whose headers match the <placeholders>; tags start with @; comments are whole lines starting with #. Tag each scenario with its scenario ID and story ID so test reports trace back. -->

The example file below is the source of truth for the feature. Keep it
in the code repository next to the step definitions, and copy it here
only for review and sign-off. Each Rule block carries the rule ID from
section 2, and each scenario carries its scenario and story tags, so a
failing test in a report points straight back to the story it accepts.
The Scenario Outline runs once per row of its Examples table, which
gives four test runs for one written scenario.

```gherkin
# language: en
@feature-notify-claim
Feature: Notify a home insurance claim online
  Policyholders report damage to their home online and get a claim
  reference without calling the contact centre.

  Background:
    Given the policyholder "Ana Ruiz" is signed in
    And she holds home policy "HP-20481"

  Rule: BR-CLM-004 Only active policies can notify a claim online

    @SC-01 @US-101
    Scenario: Claim notified for an active policy
      Given her policy "HP-20481" is active
      When she reports "escape of water" damage that happened yesterday
      Then she sees a claim reference
      And she receives a confirmation e-mail with the same reference

    @SC-02 @US-101
    Scenario: Claim rejected for a lapsed policy
      Given her policy "HP-20481" lapsed last month
      When she tries to report "escape of water" damage
      Then she is told that the policy is not active
      And she is offered the contact centre number

  Rule: BR-CLM-009 Photos are limited in size and number

    @SC-03 @US-102
    Scenario Outline: Photo upload limits
      Given her policy "HP-20481" is active
      And she has notified a claim
      When she uploads <count> photos of <size> MB each
      Then the upload is <result>

      Examples:
        | count | size | result   |
        | 3     | 4    | accepted |
        | 10    | 10   | accepted |
        | 11    | 2    | rejected |
        | 1     | 12   | rejected |

  Rule: BR-CLM-007 Large claims are referred to a handler

    @SC-04 @US-103
    Scenario: Claim above the referral limit is referred
      Given her policy "HP-20481" is active
      When she reports damage with an estimated value of 7,500
      Then the claim status is "Referred to handler"
      And no payment is offered online

    @SC-05 @US-103
    Scenario: Claim at the referral limit is not referred
      Given her policy "HP-20481" is active
      When she reports damage with an estimated value of 5,000
      Then the claim status is "Open"
```

## 4. Traceability

<!-- Guidance: Show the chain from story to rule to scenario to automated test and its latest result, so that the product owner can see what "done" means. Pitfall: scenarios that are agreed but never automated, so they silently drift from the product. -->

| Scenario | Story | Rule | Automated test | Last result |
|---|---|---|---|---|
| SC-01 *(Example)* | US-101 | BR-CLM-004 | notify-claim.feature:14 | [Pass / Fail / Not run] |
| SC-02 *(Example)* | US-101 | BR-CLM-004 | notify-claim.feature:21 | [Result] |
| SC-03 *(Example)* | US-102 | BR-CLM-009 | notify-claim.feature:30 (4 examples) | [Result] |
| SC-04 *(Example)* | US-103 | BR-CLM-007 | notify-claim.feature:46 | [Result] |
| SC-05 *(Example)* | US-103 | BR-CLM-007 | notify-claim.feature:53 | [Result] |

Copy the links into `requirements/traceability-matrix` when the project
keeps one matrix for all requirements.

## 5. Writing checklist

<!-- Guidance: Run through this list before the scenarios are marked Agreed. -->

| Check | Question |
|---|---|
| Business language | Would a stakeholder recognise every step without a developer explaining it? |
| One behaviour | Does each scenario test one rule, with a single When? |
| Observable outcome | Do the Then steps check what a user or another system can observe, not internal state? |
| Boundaries | Are values at, just below and just above each limit covered (SC-04 and SC-05 test both sides of 5,000)? |
| Independence | Can each scenario run alone and in any order? |
| Background | Does the Background hold only context that every scenario under it needs? |
| Keywords | Are colons used only after keywords that take them (Feature, Rule, Background, Scenario, Scenario Outline, Examples)? |
| Tags | Does every scenario carry its scenario ID and story ID? |
| Definition of done | Does the team's definition of done (`product/definition-of-done`) require these scenarios to pass? |

## 6. Common anti-patterns

<!-- Guidance: Use this list in refinement to rewrite weak scenarios before they are automated. -->

| Anti-pattern | Why it hurts | Rewrite as |
|---|---|---|
| UI scripting ("When I click Submit, then I type...") | Breaks when the screen changes, hides the rule | One business-level When step |
| Several When steps in one scenario | Tests two behaviours; a failure does not say which | Split into two scenarios |
| Then steps that check database rows | Couples the test to the design | Check what the user or a downstream system sees |
| Long Background with data for one scenario only | Every scenario pays for it and readers lose context | Move that Given into the scenario |
| Examples tables with dozens of rows | Hard to review, slow to run | Keep boundary and representative rows; cover the rest with unit tests |
| Vague data ("a big claim") | Readers disagree on the limit | Use concrete values next to the boundary |

## 7. Open questions

<!-- Guidance: Record questions raised in the three amigos session with an owner, so stories are not pulled in with unknowns. -->

| ID | Question | Owner | Due | Answer |
|---|---|---|---|---|
| Q-01 *(Example)* | Should a claim at exactly 5,000 be referred? Agreed: no, the rule says "above" | [@product-owner] | YYYY-MM-DD | Answered, SC-05 |
| [Q-nn] | [Question] | [@name] | YYYY-MM-DD | [Answer] |

## Standard and licence note

Based on the Gherkin reference published by the Cucumber project at
https://cucumber.io/docs/gherkin/reference/ (keywords Feature, Rule,
Background, Scenario or Example, Scenario Outline, Examples, the step
keywords Given, When, Then, And, But, tags and comments). The feature
file, rules and examples are fictional and original text written for
this collection. Check the current Gherkin reference before use, as
keyword support can change between Gherkin versions. Template licence:
MIT.