requirements-specification

name	requirements-specification
description	Convert approved product and business intent into precise functional, non-functional, interface, data, and acceptance requirements.

Requirements Specification

Use when a change needs detailed behavioral requirements across systems or stakeholders.

Procedure

1. Gather approved product intent, business rules, user flows, constraints, and source policies.
2. Identify actors, triggers, preconditions, normal flows, alternative flows, failure behavior, and outputs.
3. Specify data, permissions, interfaces, limits, performance/reliability expectations, and auditability where relevant.
4. Use testable language and define terms that could otherwise be interpreted differently.
5. Trace each requirement to a business/product need and flag conflicts or missing decisions.
6. Separate requirements from proposed architecture unless a technical constraint is itself mandatory.
7. Review for completeness with the owning product and technical roles.

Quality gate

Every requirement should be testable or otherwise objectively verifiable.