specifying-by-examplelisted

# Specifying by Example ## Workflow: Writing SBE specifications 1. **Clarify the business goal.** Ask what problem the feature solves and for whom. If the user provides a user story, extract the goal. If they provide raw requirements, ask "why are we building this?" 2. **Identify rules.** Extract the distinct business rules from the requirements. Each rule is a constraint or behavior the system must enforce. Name each rule explicitly. 3. **Generate examples for each rule.** For every rule, produce: - The **happy path** (main success scenario). - **Key boundary conditions** (edges where behavior changes). - **Important negative cases** (what the system should refuse). Use realistic data (real names, plausible amounts), not "foo"/"bar." 4. **Write Gherkin scenarios.** Convert each example into a Given-When-Then scenario following these rules: - **Declarative, not imperative.** Describe *what* happens, not UI steps. No CSS selectors, button names, or page navigation. - **One behavior per scenario.** Each scenario has exactly one When-Then pair. - **Essential data only.** Include only data that illustrates the rule. Omit incidental details (user IDs, timestamps, irrelevant fields). - **Ubiquitous language.** Use the same terms the business uses. No `user_id`, `POST /api/orders`, or `status = 2`. - **Name the rule.** Group scenarios under a `Rule:` keyword in Gherkin. 5. **Use Scenario Outlines for boundary tables.** When a rule has many input-outp