analyze-requirementslisted

# Analyze requirements Turn an ambiguous need into a set of unambiguous, testable acceptance criteria before design or code starts. ## When to use Whenever a need arrives that isn't yet expressed as testable criteria — a new feature, a change request, a bug that implies a missing behavior — or whenever the workflow reaches the Analysis step. ## Method Apply Behavior-Driven Development's Given/When/Then structure (Cucumber/Gherkin) to state each criterion as a concrete example, then stress it with a standard edge-case taxonomy (ISTQB equivalence partitioning + boundary value analysis): 1. **Restate the need in one sentence.** If it takes more than one sentence, split it into multiple needs — each gets its own criteria. 2. **Write acceptance criteria as Given/When/Then.** For each distinct behavior: - `Given` the initial context/state (3-5 steps max per scenario — more and it stops reading as a spec and becomes an implementation). - `When` the triggering action. - `Then` the expected, observable outcome (behavior/contract level — no implementation detail). One criterion = one behavior. If it needs "and" to describe, it is probably two criteria. 3. **Enumerate edge cases per input**, using equivalence partitioning + boundary value analysis: - Valid equivalence class(es) — one representative example, not every value in the class. - Invalid equivalence class(es) — what must be rejected and how. - Boundaries — min, max, min-1, max+1, empty, zero, nu