A software brief is the document you hand to a development team or supplier before any work begins. Its job is to explain what the business needs, why it needs it, and what constraints exist, without attempting to write the technical specification yourself. The brief starts the conversation; it does not replace the detailed requirements that follow during discovery.
The distinction matters because many businesses skip the brief and jump straight to a list of screens or features, or they write nothing and expect the supplier to infer everything from a conversation. Both approaches create problems later when assumptions surface as change requests or delivered functionality that misses the point.
What a brief is not
A brief is not a feature list, a wireframe deck, or a contract. It does not need to describe every button or data field. Those details belong in a specification, which is produced after the brief has been discussed and the scope has been explored. The brief also does not prioritise features—that is a separate exercise that happens once the full set of requirements is visible.
Who the brief is for
Write the brief for someone who understands software delivery but knows nothing about your business. Avoid internal acronyms, unexplained department names, and references to "the way we've always done it" without describing what that way actually is. The reader needs to grasp your operational context, not your office politics.
The core sections a brief should contain
- Business context: What the organisation does, which part of the business this system serves, and what problem you are solving.
- Current situation: How the process works today—spreadsheets, manual steps, existing software—and where it breaks down.
- Users and roles: Who will log in, what they need to do, and how their needs differ. A sales manager and a finance clerk using the same CRM have different goals.
- Core processes: The main workflows the system must support, described in business terms rather than technical ones. "A customer raises a support ticket, it is assigned to an engineer, and the customer receives status updates" is a process. "Build a ticketing module" is not.
- Integrations: Other systems the new software must exchange data with—accounting packages, email platforms, existing databases—and what direction the data flows.
- Constraints: Budget boundaries, hard deadlines, compliance requirements such as GDPR or industry-specific regulations, and any technology preferences or restrictions.
- Success measures: What "done" looks like in business terms—reduced processing time, fewer errors, self-service for customers—rather than technical delivery metrics.
When a brief is most useful
A brief is essential when you are approaching suppliers for estimates, because it gives each one the same starting information and makes quotes comparable. Without it, you will receive wildly different scopes priced against different assumptions, and you will not be able to evaluate them fairly.
It is also valuable when you are commissioning internal development work. A brief gives your own technology team a clear reference point and reduces the risk that they build what they assume you want rather than what you actually need.
How much detail is enough
The right level of detail is the point at which a competent supplier can ask informed questions rather than foundational ones. If a reader finishes your brief and their first response is "What does your company actually do?", the brief is too thin. If their first response is "Can you clarify the approval workflow on step three?", the brief has done its job.
As a practical test, give the brief to a colleague in a different department. If they can explain back to you what the system needs to achieve and who it is for, the brief is likely sufficient. If they are confused by the second page, rewrite it.
Describing processes without prescribing solutions
One of the hardest parts of writing a brief is describing what needs to happen without dictating how it should be built. Stating "the system must send an email when an order is approved" is reasonable. Stating "use SendGrid with a webhook triggered by a database update" is not—that level of decision belongs in technical design, not the brief.
Focus on outcomes and triggers: what event starts the process, what steps follow, who makes decisions, and what the end result should be. Let the development team propose the implementation approach during discovery.
Being honest about what you do not know
A good brief flags uncertainty rather than hiding it. If you are unsure whether a particular integration is needed, say so. If you do not know how many concurrent users to expect, state the range you can estimate and note the gap. Suppliers would rather work with a brief that honestly marks unknowns than one that presents guesses as facts, because the former leads to proper discovery while the latter leads to disputes.
Writing a shopping list instead of a problem statement
The most frequent mistake is treating the brief as a feature catalogue: "We need a dashboard, a reporting module, a user management page, and an export function." This tells the supplier what to build but not why, which means they cannot suggest better approaches, challenge unnecessary elements, or flag missing pieces. Start with the problem, then describe the processes that address it. The features will emerge from that.
Omitting existing systems and data
Many briefs describe the desired future state without mentioning what already exists. If your team currently works from four linked spreadsheets, a legacy Access database, and a shared email inbox, the supplier needs to know. Existing data shapes migration planning, and existing habits shape user adoption. A brief that ignores the current environment leads to a system that looks good in theory but fails in practice because it does not account for the transition.
Leaving out non-functional requirements
Performance expectations, data retention needs, accessibility standards, and security requirements are often absent from briefs. These are not minor details—they can fundamentally change the architecture and the cost. If you need the system to handle end-of-month reporting for thousands of records without timing out, or if you need data retained for a specific period to meet regulatory obligations, state that clearly.
Assuming one brief fits every supplier
Different suppliers may need slightly different information depending on their process. A supplier who runs a structured discovery phase needs less detail upfront than one who prices directly from your document. Adapt the brief's depth to the context, but do not strip out the core sections—just adjust how precisely each is defined.
Key checks before sending the brief
- Can someone outside your business understand the problem without asking you questions?
- Have you described who the users are, not just what the system does?
- Are existing systems and data sources mentioned, including their limitations?
- Have you stated constraints—budget, timeline, compliance—rather than leaving them to be negotiated later?
- Are unknowns flagged rather than silently guessed at?
- Does the brief describe processes and outcomes without prescribing technical solutions?
- Have you defined what success looks like in business terms?
A well-written brief does not guarantee a smooth project, but a poorly written one virtually guarantees a difficult one. The brief is the foundation on which estimates, discovery, and eventual specifications are built. Getting it right reduces ambiguity, narrows the space for misunderstanding, and gives both you and your supplier a shared reference point when difficult scope decisions arise later.