How to Write a Software Brief

Why Most Software Briefs Fail

Most software development projects that go over budget or fail to deliver what was wanted can trace at least part of the problem to an inadequate brief. Requirements that were ambiguous, scope that was assumed rather than stated, constraints that were not communicated, and success criteria that were never defined - these are the inputs that produce confused development, missed expectations, and expensive surprises.

The frustrating thing is that most inadequate briefs are not the result of laziness or incompetence. They are the result of genuine difficulty - it is hard to write clearly about something you have not built yet, and most people writing software briefs have never done it before. The discipline of translating a business need into a clear technical requirement is not obvious, and the details that matter most are often the ones that seem most obvious and therefore go unstated.

This guide is designed to help you write a brief that gives your development team - or any developer you approach - a genuine opportunity to deliver what you actually need. It covers the structure of a good brief, the information that matters most and why, the common omissions that cause problems, and practical techniques for capturing requirements clearly.

It is also honest about what a brief can and cannot achieve. A brief is not a specification - it is the starting point for a conversation that leads to a specification. Even the best brief will require clarification, refinement, and iteration. The goal is not a document that answers every question, but one that gives developers enough to engage seriously and quote accurately.

Who Should Read This Guide

This guide is written for:

• Business owners and founders who are commissioning bespoke software for the first time
• Product managers and project managers who need to document requirements for development teams
• Non-technical decision-makers who are responsible for a software project but do not have an engineering background
• Anyone who has received wildly varying quotes for a software project and wants to understand why

It assumes no technical background. Technical concepts are explained where they are relevant to the brief-writing process.

What a Brief Is For

Before getting into how to write a brief, it helps to be clear about what a brief is actually for. Different purposes produce different briefs.

Getting accurate quotes

If your primary purpose is getting accurate, comparable quotes from multiple developers, your brief needs to be specific enough that every developer is quoting on the same scope. Vague briefs produce quotes that vary by a factor of five or ten because developers are making different assumptions about what is included. Specific briefs produce quotes that vary more narrowly and are easier to compare meaningfully.

Starting a scoping conversation

If you are approaching a developer you already trust and the goal is to start a scoping conversation rather than to get a complete quote, your brief can be less detailed. The brief gets you into the conversation - the conversation produces the specification. In this case, you need enough detail to communicate the problem and the general shape of the solution, but the fine detail will emerge through discussion.

Communicating to an existing team

If you are communicating requirements to an existing development team - either in-house or a team you are already working with - the brief can assume shared context and focus on what is new or specific to this request rather than explaining everything from scratch.

The guidance in this guide is primarily aimed at the first use case - getting accurate quotes from developers you have not worked with before. The principles apply to all three, but the level of detail required is highest for this purpose.

The Structure of a Good Brief

A good software brief covers six areas, in roughly this order. Each is covered in detail in the sections below.

1. The problem you are solving
2. The users and their needs
3. The scope - what the system needs to do
4. The technical context - what already exists
5. The constraints - what must be true
6. The success criteria - how you will know it has worked

Not every brief needs to cover every area in equal depth. A brief for a simple internal tool used by one person has different requirements from one for a consumer-facing SaaS product used by thousands. Apply judgment about what matters most for your specific project.

1. The Problem You Are Solving

Start with the problem, not the solution. The most common mistake in software briefs is jumping straight to a description of the system - 'we need an app that does X, Y, and Z' - without explaining why. Understanding the problem allows a developer to propose a better solution than the one you have in mind, and it provides essential context for making the hundreds of small decisions that arise during development.

Describe the current situation

What is happening today that the software will change? Who is doing what, how are they doing it, and what is wrong with the current approach? Be specific and concrete - 'our team processes about 200 invoices per week manually, which takes roughly four hours of time and produces errors about 5% of the time' is more useful than 'we have an inefficient invoicing process'.

Explain the impact of the problem

Why does the current situation matter? What does it cost in time, money, errors, or missed opportunities? Understanding the impact helps a developer understand how much investment is justified and how to prioritise when trade-offs need to be made.

Describe the desired future state

What would a successful outcome look like? Not the system you want to build, but the situation you want to be in once the system exists. 'The invoicing process will take less than thirty minutes per week, with error rates below 0.1%' is a better description of the desired outcome than 'we want an automated invoicing system'.

Explain why now

What has changed, or what is changing, that makes this the right time to address the problem? Is there a regulatory deadline, a market opportunity, a change in team size, or a specific event that is driving the timing? Understanding the timeline driver helps a developer understand how to prioritise speed versus quality.

2. The Users and Their Needs

Software is built for people to use. Understanding who those people are and what they need is fundamental to building something that works for them. Developers who understand users make better decisions about every aspect of the system - the workflows, the interface, the data, and the error handling.

Define the user types

List every distinct type of person who will use the system. These might include: end users who perform the core workflows, administrators who manage the system and its users, managers who need reporting and oversight, external users like customers or partners, and any automated systems or integrations that interact with the system.

For each user type, note: approximately how many of them there are, how frequently they will use the system, their level of technical sophistication, and the device or context in which they will use the system (office desktop, mobile in the field, or both).

Describe what each user type needs to do

For each user type, describe the core workflows they need to perform. What does a typical session look like? What are they trying to accomplish, what information do they need to do it, and what do they need the system to do or produce as a result?

Be as concrete as possible. 'The field engineer needs to log a site visit, record the work performed, take photos, and submit the record for approval' is more useful than 'the field engineer needs to record their work'.

Note the pain points with the current approach

What frustrates users about the current way of doing things? What workarounds have they built? What do they wish they could do that they cannot? This information helps a developer design a system that addresses real frustrations rather than building something that replicates the same problems in a new format.

3. The Scope - What the System Needs to Do

The scope section is the heart of the brief - the description of what the system needs to do. This is where most briefs fall short, either because they are too vague to be useful or because they describe solutions rather than requirements.

List the features and functions

List the distinct features or capabilities the system needs to provide. For each feature, describe: what it does, who uses it, what inputs it requires, and what outputs or changes it produces. Aim for a level of detail that is specific enough to be unambiguous but does not pre-solve the technical implementation.

Distinguish between features that are essential - without which the system cannot serve its purpose - and features that are desirable but not critical for the initial launch. This distinction is important for scoping and for the inevitable trade-offs that arise when budget or timeline is constrained.

Describe the data the system needs to manage

What information does the system need to store, process, and produce? This might include: the records or entities the system manages (customers, orders, products, cases), the relationships between them, the information that needs to be captured for each, and the reports or outputs that need to be generated.

You do not need to design the database - that is the developer's job. But describing the information requirements in business terms gives the developer what they need to design it well.

Describe the workflows in detail

For the most important workflows, describe the steps in sequence. What triggers the workflow? What does the user do at each step? What decisions need to be made, and who makes them? What happens at the end? What happens when something goes wrong?

Workflow descriptions are often best done as numbered steps with decision points clearly marked. 'If X, then Y. If Z, then W' is clearer than prose descriptions of the same logic.

Define what is out of scope

Explicitly stating what is not included in this project is as important as stating what is. Out-of-scope items prevent developers from including or excluding things based on assumptions. 'This project does not include a mobile app - the system will be web-based only' or 'invoicing is out of scope for this phase - the system will integrate with our existing invoicing tool' are examples of scope boundaries that need to be explicit.

4. The Technical Context

Developers need to understand the technical environment your system will operate in. This context affects architecture decisions, integration requirements, technology choices, and cost.

Existing systems and integrations

List every system that the new software needs to connect to or work alongside. For each, note: what the system is, what data or functionality needs to be shared, and whether an API or other integration mechanism already exists. Include internal systems, third-party services, databases, and any other technical components that are relevant.

If you do not know the technical details of your existing systems - whether they have APIs, what data they contain, how they are hosted - note that and flag it as something that needs to be investigated. Gaps in this information are better surfaced in the brief than discovered mid-project.

Technology preferences or requirements

Do you have requirements or preferences about the technology used to build the system? This might include: the programming language or framework (if you have an existing team with specific skills), the cloud platform (if you are committed to AWS or Azure), the database technology, or specific tools you want to use.

If you do not have technology preferences, say so - this gives the developer freedom to recommend the most appropriate stack for your requirements.

Hosting and deployment

Where does the system need to run? Options include: cloud hosting (AWS, Azure, Google Cloud), on-premises hosting on your own servers, or a managed hosting service. If you have existing hosting infrastructure, note it. If you do not have a preference, say so.

Security and compliance requirements

Are there specific security requirements the system must meet? Do you operate in a regulated industry with compliance obligations - financial services regulation, healthcare data requirements, GDPR considerations that go beyond the standard? Note any specific requirements that will constrain the technical design.

5. The Constraints

Constraints are the boundaries within which the solution must operate. Making them explicit prevents developers from proposing solutions that cannot work for you and allows them to make trade-offs intelligently.

Budget

Sharing a budget range is almost always beneficial, despite the understandable reluctance to do so. A developer who knows your budget can tell you honestly whether it is sufficient for your requirements, propose a scope that fits within it, or tell you what you would need to cut to make it work. Without a budget, developers either guess - which produces inaccurate quotes - or quote for the full scope you have described without knowing whether you can afford it.

You do not need to share an exact number. A range - 'we have a budget of £30,000 to £50,000 for this project' - gives the developer what they need without committing you to the top of the range.

Timeline

When does the system need to be live? Is this a firm deadline driven by an external constraint - a regulatory requirement, a product launch tied to an event, a commitment to a client - or an aspirational target? The distinction matters because firm deadlines affect the development approach and often the cost.

If there is no firm deadline, say so. 'We would like to launch within six months but there is no hard deadline' gives the developer useful information without creating artificial urgency.

Team and organisational constraints

Are there constraints on your side that will affect the project? Do you have limited availability to participate in the project? Do decisions need to go through a particular approval process? Are there holidays or other events that will reduce availability at certain times? These constraints affect the project timeline and the engagement model.

Performance requirements

Are there specific performance requirements the system must meet? How many users need to be able to use the system simultaneously? What is the acceptable response time for key operations? How much data will the system need to handle? If you do not have specific requirements, describe your expectations in business terms - 'the system needs to be fast enough that users do not notice delays' is a useful starting point even if it is not a precise specification.

6. The Success Criteria

Success criteria define how you will know the project has delivered what it was supposed to deliver. They are important both for evaluating the outcome and for making decisions during development when scope trade-offs are necessary.

Functional success criteria

What does the system need to be able to do for the project to be considered successful? These are typically derived from the features and workflows described in the scope section - 'a field engineer can log a site visit and submit it for approval in under five minutes on a mobile device' is a functional success criterion.

Business success criteria

What business outcomes do you expect the system to produce? These might be measurable - 'the time spent on manual invoicing will reduce from four hours to thirty minutes per week' - or directional - 'the system will eliminate the manual data entry errors that currently occur during the invoicing process'. Business success criteria connect the technical deliverable to the business problem it is solving.

Non-functional success criteria

What qualities does the system need to have beyond its functionality? These might include: performance benchmarks, security standards, accessibility requirements, uptime requirements, or usability standards. Non-functional success criteria are often forgotten in briefs and discovered as requirements only after development is underway.

Common Omissions That Cause Problems

Beyond the six core areas above, there are specific types of information that are consistently omitted from software briefs and consistently cause problems when they are missing.

Error handling and edge cases

What happens when things go wrong? What should the system do if a user enters invalid data, if an external system is unavailable, if a required field is missing, or if a process fails partway through? Developers who do not have guidance on error handling make their own decisions, which may not match your expectations.

You do not need to specify every error case - that is part of the technical design. But describing the most important failure scenarios and what you expect to happen gives the developer critical guidance.

Reporting and analytics requirements

What information do you need to be able to extract from the system? What reports do you need? What data do you need to analyse? Reporting requirements often receive inadequate attention in briefs because they seem secondary to the core functionality, but they significantly affect the database design and can be expensive to add retrospectively.

User authentication and access control

How do users log in? Can users register themselves or are they invited? Are there different levels of access - can some users see or do things that others cannot? These requirements seem obvious but are frequently not specified, leading to implementations that need to be reworked when the actual requirements become clear.

Data migration

If you are replacing an existing system, what happens to the data in that system? Does it need to be migrated to the new system, and in what form? Data migration is often a significant and expensive undertaking that is omitted from briefs because it seems like an afterthought.

Training and documentation

Will users need training to use the system? Who will provide it? Do you need written documentation? Does the developer need to produce system documentation? These requirements should be specified rather than assumed.

Post-launch support

What happens after the system goes live? Who is responsible for bug fixes, security updates, and performance issues? Is the developer expected to provide ongoing support, and on what terms? Post-launch requirements should be agreed upfront rather than negotiated after the project is complete.

Practical Techniques for Writing a Better Brief

Beyond the structure above, there are practical techniques that help produce better briefs.

Use examples and scenarios

Abstract requirements are harder to understand and easier to misinterpret than concrete examples. Rather than describing a feature in the abstract, describe a specific scenario in which it would be used. 'When a customer places an order, the system should automatically send a confirmation email and update the inventory' is clearer than 'the system should handle order processing and inventory management'.

Involve the people who will use the system

The people who will use the system every day usually have the clearest view of what it needs to do and where the current process fails. Involving them in brief-writing - through interviews, workshops, or review of a draft - significantly improves the quality and completeness of the requirements.

Review with someone who was not involved in writing it

Briefs written by people close to the problem often have gaps that are invisible to the author because the missing information seems obvious. Having someone who was not involved in the project review the brief and ask questions about what they do not understand is one of the most effective ways to identify and fill these gaps.

Use wireframes or mockups for interface-heavy requirements

For systems with complex user interfaces, describing the interface in words is often inadequate. A rough wireframe - even a hand-drawn sketch - communicates interface requirements more clearly and more efficiently than paragraphs of description. Wireframes do not need to be polished designs, just clear enough to show the intended layout and content.

Iterate rather than aiming for perfection

The perfect brief is the enemy of the useful one. A good-enough brief that gets you into a productive conversation with a developer is more valuable than a perfect brief that takes so long to produce that you never start the conversation. Aim for a brief that covers the six areas above with reasonable detail, then expect to refine it through conversation.

What to Do With the Brief

Once you have a brief, the next step is using it to have productive conversations with developers.

Share it before the first meeting

Send the brief to developers before the first conversation. This allows them to come prepared with specific questions rather than spending the first meeting covering ground that could have been covered in writing. It also gives you a sense of how carefully they have read and engaged with it - a developer who comes to the first meeting with specific, thoughtful questions has engaged more seriously with your project than one who is asking about things that were clearly covered in the brief.

Expect questions and use them

A developer who asks many specific questions about your brief is not demonstrating ignorance - they are demonstrating engagement. The questions a developer asks reveal what they have thought about and what they are uncertain about. Use the questions to refine the brief and to gain insight into how the developer is thinking about the project.

Be prepared to revise

The brief is a starting point, not a final specification. Expect to revise it as developers ask questions that reveal gaps or ambiguities, as you think more carefully about specific requirements, and as the scoping process with your chosen developer clarifies what the system actually needs to do. A brief that is treated as fixed rather than as a starting point for collaboration produces worse outcomes than one that evolves through the scoping process.

A Brief Template

The following template covers the six areas described in this guide. Use it as a starting point and adapt it to your specific project.

Frequently Asked Questions

Related Resources