How do I write good requirements and specifications?
Principle. A requirement must be testable. If nobody can verify it, it is a wish.
A professional specification states
- Problem and user story — who needs what, and why
- Scope and explicit exclusions
- Functional requirements with acceptance criteria (Given / When / Then)
- Non-functional requirements — latency targets, availability, security, accessibility, data retention
- Roles and permissions, API and data contracts, state transitions and error behaviour
- Threats, invariants and edge cases
- Migration compatibility, metrics, test plan and rollback plan
Estimation. Estimate in ranges, break work into slices deliverable in days, and track risk separately from effort.
Pitfalls: gold-plating, hidden assumptions, scope creep without a change process.