What to put in a software brief before anyone builds

Most software briefs arrive as a list of features. A dashboard, a mobile app, notifications, reports, an admin area. The list is usually sensible, but it doesn’t tell a supplier what problem the software solves, who it is for or how you will know it worked. Two teams can read the same feature list and quote for very different systems, and both can be right.

A good brief is short. It describes the situation clearly enough that someone can ask useful questions, estimate honestly and push back where needed. This article sets out what we think belongs in one, what to leave out, and a checklist to work through before you send it.

Start with the problem, not the solution

Describe what is going wrong today, in plain terms. Who is affected, how often, and what it costs in time, errors, missed revenue or risk. If you have rough figures, include them and say how rough they are.

A useful test: could someone suggest a different solution from the one you have in mind, based only on your description of the problem? If the brief only makes sense with your solution already assumed, it is a specification, and it closes off options too early.

It also helps to say why now. A contract ending, a regulation coming into force, a team that has grown past what spreadsheets can handle. The reason shapes what matters most in a first release.

Users and roles

List the kinds of people who will use the system and what each needs to do. Be specific about roles rather than job titles: a coordinator who assigns work, a field worker who records it, a manager who approves it, a customer who wants to know where things stand.

For each role, note:

• roughly how many people there are;
• where and on what they work: an office desktop, a phone in a van, a tablet on a ward;
• what they can see and change, and what they must not;
• how comfortable they are with new software, and how much training time is realistic.

Permissions are often where a project’s real complexity hides. “Managers can see their own team’s records” sounds simple until someone covers two teams or moves between them. Writing down the awkward cases early saves rework later.

The one user journey that must work

Pick the single path through the system that matters most and describe it step by step. For a booking system, it might be a customer requesting a slot, a coordinator confirming it and a reminder going out. For an inspection tool, an inspector finding a fault, recording it with photos and someone being told.

Write it as a sequence of what people do and what the system does in response. Include what happens when it goes wrong: the customer cancels, the photo won’t upload, nobody responds.

This does two things. It gives a supplier something concrete to estimate and test against. And it forces a decision about priority. If everything is equally important, a first release will try to do everything, and do it thinly.

Existing systems and data

Very little software starts from nothing. List what the new system must live alongside:

• Systems it must talk to. Accounting, CRM, identity, payments, a scheduling tool. Say whether they have an API, who owns them and whether you have access to documentation.
• Data it must start with. Customer records, historical jobs, price lists. Where they live now, roughly how many records, and how clean they are. If the honest answer is “several spreadsheets, partly out of date”, say so.
• What it replaces. If a current tool is being retired, note what people rely on it for, including the unofficial uses nobody wrote down.

Integration and data migration are the two areas most often underestimated. A sample export, even a small anonymised one, tells a supplier more than a paragraph of description.

Constraints

Write down the things that are fixed, and why:

• Budget range. Even a broad one. Without it, a supplier has to guess which version of the system you can afford, and the conversation drifts.
• Dates that matter. Separate hard deadlines, such as a regulatory date, from preferences.
• Rules you must follow. Data protection, sector regulation, accessibility, where data may be stored.
• Technology you are tied to. An existing cloud provider, an identity system or a team who will maintain the code afterwards and knows a particular stack.
• Who decides. Who signs off scope, who answers questions during the build and how quickly.

If a constraint is a preference rather than a rule, label it. Suppliers treat everything in a brief as fixed unless told otherwise.

What “done” means for a first release

Define the first release by what people can do with it, not by a list of screens. For example: coordinators can assign jobs and field workers can complete them on their phones, with photos, for one region. Reporting and customer notifications come later.

Then say how you will judge it. Fewer missed appointments, less time spent chasing updates, a process that no longer depends on one person’s spreadsheet. You don’t need targets yet. You need to know what you will look at.

A first release is also where you find out what you got wrong. Plan for a period after launch to change things based on real use, and keep some budget for it.

What to leave open

A brief that specifies every detail leaves no room for the people building it to help. Some things are better left as questions:

• The technology. Unless you are tied to something, describe the constraints (who maintains it, where it runs, what it integrates with) and let the supplier propose.
• Screen designs. Rough sketches help show intent. Detailed layouts made before anyone has watched users work tend to get thrown away.
• Features you’re unsure about. List them separately as ideas. A short discovery or prototype can test whether they earn their place.

It is also fine to say what you don’t know. “We aren’t sure whether field staff need to work offline” is a useful sentence. It points at a question worth answering before the estimate is fixed.

Sometimes the honest outcome of looking hard at a problem is that new software isn’t the answer. A change to a process or a better use of an existing tool may do the job. The GOV.UK Service Manual makes the same point about discovery: stopping is a legitimate result if the research supports it. A brief written around the problem leaves room for that.

A short checklist

Before sending a brief, check that it covers:

• The problem, who it affects and why it matters now
• Each user role, how many people, what device they use and what they can see
• One user journey described step by step, including what goes wrong
• Systems to integrate with, and whether they have usable APIs
• Data to migrate, where it lives and how clean it is
• Budget range and any hard dates, with the reason for each
• Rules on data, accessibility and hosting
• Who makes decisions and who answers questions
• What the first release lets people do, and how you will judge it
• Open questions and ideas you’re unsure about, marked as such

Two or three pages is usually enough. If it runs much longer, the extra detail is probably about solutions rather than the problem.

When to bring in help

If you can describe the problem but struggle to settle the first release, or different people in the organisation want different things from the same system, a short discovery phase can help. We work with teams to map the roles and the user journey that matters, test the uncertain parts with a prototype and turn the result into a brief that can be estimated with confidence. Sometimes that work shows a smaller fix will do, and we will say so.

Sources

• GOV.UK Service Manual: How the discovery phase works