How to write a software brief a team can actually use

Start with one observable problem

Describe who is affected, what they are trying to do, and where the current process breaks down. “Replace our spreadsheet” describes a proposed solution. “Dispatchers cannot tell which requests have been assigned” describes a problem that several solutions might address.

Include a recent example with sensitive details removed. Show the input, the steps taken, and the result. If the problem occurs only at month end, explain that constraint. A concrete exception often reveals more than a long list of desired features.

Separate requirements from assumptions

Name the systems that must remain, the information that must move, and the people who can approve a change. Distinguish a firm deadline from a preferred date. Explain why each hard constraint exists so the team can recognize when a proposed approach violates it.

Keep a separate list of unanswered questions. You might know that customers need status updates without knowing whether a portal is necessary. Leaving that question open makes the brief more accurate and creates room for a simpler implementation.

Define a result and a next decision

Choose a result someone can observe: every request has an owner, a report no longer requires copying records, or an administrator can resolve an exception without database access. Record how the process works today so the comparison has a starting point.

Finish with the decision the brief should support. That may be choosing between configuration and development, estimating a small first release, or identifying a risky integration to test. Assign one person to answer follow-up questions and keep the document current as the team learns.

A strong first brief can fit on a few pages. Its value comes from shared understanding, not the number of requirements it contains.

A brief that makes the next decision possible.

Use a short working document, with a named decision-maker and a place to record uncertainty. The GOV.UK discovery guidance is a useful reference for separating an underlying problem from a proposed solution. For a commercial project, the following example turns that principle into a concrete brief.

The unknown is deliberately different from the requirement. “Must work offline” might eventually become necessary, but writing it as a settled requirement before observing the working environment could commit the project to unnecessary complexity. Record the evidence that would settle it and who will collect that evidence.

Likewise, make the first outcome independent of an interface. A queue, notification, or mobile view is useful only if it helps the people involved assign and complete the work. This lets the delivery team compare approaches without renegotiating the business objective every time an implementation choice changes.

Use the brief to choose the next step.

1. ObserveCollect real examples and exceptions.
2. FrameAgree the problem, constraints, and unknowns.
3. DecideChoose an investigation, configuration change, or first build.

Before estimating delivery, ask a person outside the discovery conversation to explain the proposed outcome from the brief alone. If they cannot distinguish the current failure from the preferred solution, revise the document. If a supplier dependency remains unresolved, commission a bounded integration check rather than assigning certainty to the entire project.

A useful stopping rule is that each blocking uncertainty has an owner and an evidence-gathering action. Not every detail needs an answer. The important distinction is between a detail the team can reasonably resolve during delivery and an assumption that could invalidate the investment. Keep the original brief alongside later decisions so changes in scope have an understandable history.