How to write a software development brief

Describe the outcome before the features

A useful brief explains who needs help, what they do today and what should become easier. You do not need to select a programming language before a development conversation. Name someone who can clarify the business rules.

Copy these prompts into your brief

Answer what you know and mark unknowns explicitly. Use anonymised examples rather than customer records or passwords.

• Users: who performs the work, and who approves it?
• Current process: what starts the task and how is it completed?
• First release: what one complete outcome must work?
• Rules: what information is required, and what happens when it is missing?
• Connections: which tools, data sources and account owners are involved?
• Constraints: budget range, timing, devices and support needs.

Turn a feature into something testable

For an illustrative booking workflow, “booking management” is vague. “A customer requests an available time; a coordinator confirms or declines it; both see the final status” identifies the result. Add what should happen when two people request the same slot.

Keep decisions and unknowns separate

End with open questions, assumptions and who will answer each one. Ask which unknowns need discovery before an estimate is reliable. Update the agreed brief when scope changes so the estimate and acceptance criteria stay aligned.