A practical requirements checklist before code

Begin with one concrete journey

A checklist works best alongside a real scenario. Choose a journey such as joining a membership service, then walk through what the user, administrators and connected systems need to do.

Record unanswered questions as decisions to resolve. An honest unknown is more useful than an assumption hidden inside a polished specification.

1. Outcome and boundaries

• What outcome does the user need?
• What is explicitly outside this change?
• Which constraints are fixed, and which are open to discussion?
• Who can approve the decisions?

2. People and permissions

• Who can start, view, change or cancel the process?
• What happens when permission changes midway through?
• Which information should each person be able to see?
• How are actions attributed for later review?

3. Data and state changes

• Which information is required, optional or derived?
• What states can the record be in?
• Which transitions are allowed?
• What happens to existing data when the rules change?

4. Failure, timing and recovery

• What if a connected service is unavailable?
• What if the same request arrives twice?
• What if two people act at the same time?
• Can the user recover without accidentally repeating a payment or losing work?
• Which time zone and boundary rules apply?

5. Evidence for acceptance

• What observable result proves the main requirement?
• Which negative and failure cases must be demonstrated?
• Can a reviewer connect each result to the relevant rule?
• Who decides whether unresolved gaps prevent release?

Make the checklist part of a conversation

Different answers can reveal a product decision, a technical constraint or a missing business rule. Discuss those differences before treating the specification as ready.

Return to the checklist when the scope changes. Readiness is a property of the current specification and its evidence, rather than a box checked once at the beginning.