requirements-engineering

Write acceptance criteria in Given/When/Then (Gherkin) format so each criterion is atomic, deterministic, and automatable. Include concrete examples, cover negative and error scenarios, and avoid vague phrases like "works well" that cannot be verified.

Decompose the request into INVEST-compliant stories using the "As a [role], I want [goal], so that [benefit]" format. Identify implicit requirements, edge cases, and non-functional needs, then link each story to a business objective in a traceability matrix.

INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Stories meeting these six properties are appropriately sized for a sprint, clearly scoped, and verifiable through acceptance criteria.

Flag conflicts explicitly rather than silently choosing one side, document each stakeholder's position, and propose a resolution path. Final decisions require stakeholder validation since requirements tools do not replace domain expert judgment.

Skip requirements elicitation when implementing from an already approved specification, since expanding approved requirements with unstated features is gold plating. This workflow is for capturing and formalizing needs, not for code implementation.