Software Requirements Brief: A Template to Write Before You Talk to a Developer

A software requirements brief is a short document that describes the business problem a system must solve, who will use it, how the work happens today, which features matter most and the constraints around it. It gives a developer enough to ask good questions, estimate realistically and suggest where to start, without designing the solution.

A good brief needs no technical language. It needs the facts only you know: how your business actually works, where it breaks, and what would count as success. This guide explains what belongs in a brief, gives you a template to copy, and shows a filled example.

What is the difference between a brief, a BRD and a full specification?

A brief is written by the buyer to start a conversation and get an estimate. A business requirements document (BRD) and a software requirements specification are written later, usually with an analyst, to define in testable detail what will be built.

The formal end of this spectrum is described in ISO/IEC/IEEE 29148, the international standard for requirements engineering, which sets out what a full specification should contain. You do not need that level of rigour to approach a developer. Writing a 60-page specification alone, before speaking to anyone, often locks in assumptions a short conversation would have challenged.

What sections should a software requirements brief include?

A useful brief covers twelve areas. Each one answers a question the developer would otherwise have to ask, or worse, guess.

How do you prioritise features with MoSCoW?

Sort every feature into Must Have, Should Have, Could Have or Won't Have this time. The Agile Business Consortium, which maintains the method, defines Must Haves as the minimum usable subset of requirements: without them the solution is not viable, not legal or not safe. Should Haves are important but the solution still works without them, perhaps with a workaround. Could Haves are wanted but have less impact if left out. Won't Have this time records what has been agreed as out of scope for now, so it does not creep back in.

The Consortium's guidance is that Must Have effort should not exceed 60 percent of the total, so the Should and Could items act as contingency. A practical test for each item: "If this is missing on day one, can we still run the process, even with a manual workaround?" If yes, it is not a Must.

What non-functional needs belong in a brief?

Non-functional needs describe how the system must behave rather than what it does. Buyers often leave them out, yet they change the architecture and the estimate. Cover at least these:

• Security and access. Who may see what, whether you need single sign-on with your existing accounts, two-factor login and an audit trail of who changed which record. If security is critical, the OWASP Application Security Verification Standard (ASVS) is a published checklist you can ask vendors to map their approach against.
• Availability. When the system is used (office hours, round the clock, across time zones) and what happens to the business if it is down for an hour or a day.
• Languages. Every language the interface and the documents need. Right-to-left scripts such as Arabic or Urdu affect layout, printing and search, so name them early.
• Devices. Desktop, tablet, phone, barcode scanners, label or receipt printers, and whether anyone works without a reliable connection.
• Accessibility. If public users or staff with disabilities will use it, name W3C's Web Content Accessibility Guidelines (WCAG 2.2) as the target.
• Hosting and data location. Cloud, your own servers, or a specific country, and any rules your sector or customers impose.
• Volumes. Users at the same time, transactions per day, documents per month. Real numbers from your current records beat guesses.

How should a brief handle budget?

You do not need to state an amount. Describe the approach instead: whether a budget has been approved or must be justified, whether you prefer a fixed scope or phased delivery, which financial year the spend falls in, and who signs off. Ask vendors to price the first phase separately from later phases, and to state hosting, licences and support as separate lines so you see the cost of running the system, not only building it.

Copy-paste software requirements brief template

Copy the list below into a document and answer each prompt in plain language. Short, specific answers beat long general ones. Mark anything you are unsure about as an open question rather than leaving it out.

1. Business problem. In three to five sentences: what is going wrong, since when, and what it costs (hours, errors, delays, lost orders). What has already been tried?
2. Goal. One sentence describing the situation after the system is live.
3. Users and roles. List each role (for example sales rep, warehouse supervisor, finance manager, customer), roughly how many people, and what each role must be able to see, create, approve or not see.
4. Current workflow. Number the steps of the main process from start to finish. Note the tool used at each step and where information is re-typed or lost.
5. Exceptions. What happens when things go wrong: returns, cancellations, partial deliveries, disputed invoices, approvals that are refused, customers over their credit limit.
6. Features: Must Have. The minimum without which the system is not worth launching.
7. Features: Should Have, Could Have, Won't Have this time. Everything else, sorted honestly.
8. Data and documents. Records you keep and where (spreadsheets, an accounting package, paper), approximate volumes, documents produced (invoices, delivery notes, certificates), and who owns each data set.
9. Integrations. Each system it must connect to, what data flows, which direction, and how often.
10. Reports. The five to ten reports or dashboards people actually use, who reads them and how often.
11. Non-functional needs. Security and access, availability, languages, devices, accessibility, hosting and data location, volumes.
12. Constraints. Deadlines and why they exist, regulations, technology you must keep, blackout periods such as year-end.
13. Budget approach. Approved or to be justified, phased or fixed, financial year, approver.
14. Decision makers. Who approves scope, who signs off each phase, who answers day-to-day questions.
15. Success measures. Three to five measurable outcomes you will check after launch.
16. Attachments. Sample spreadsheets, forms and reports, each with one line explaining what it is.

Worked example: a distributor replacing spreadsheets (illustrative)

The example below is invented to show the level of detail that works. It is not a client project.

Business problem. A building-materials distributor with three branches runs orders, stock and customer balances on shared spreadsheets plus an accounting package. Branch stock figures disagree, sales staff promise items that are not available, and month-end takes the accountant several days of reconciliation.

Goal. One system where an order checks live stock and the customer's credit position, and finance closes the month from the same data.

Users and roles. About 12 sales staff (create quotes and orders, see own customers), 6 warehouse staff (pick, pack, receive, count), 2 finance staff (invoices, payments, credit holds), 3 branch managers (approve discounts above a set level, see branch reports) and 1 owner (everything).

Current workflow. Customer phones or messages on WhatsApp → sales checks the branch spreadsheet → order typed into a sales sheet → warehouse prints it and picks → delivery note handwritten → finance types the invoice into the accounting package at day end.

Exceptions. Part deliveries when stock is short; returns of damaged goods; customers over their credit limit; transfers between branches; price overrides.

Data. Around 1,800 active items, 600 active customers, two years of invoices in the accounting package. Finance owns customers and balances; the operations manager owns items and stock.

Integrations. Keep the accounting package for the general ledger in phase 1; post invoices and payments to it daily. Reports. Stock by branch, sales by rep and customer, aged receivables, slow-moving items. Non-functional. English only, desktop for office staff, tablets in the warehouse, cloud hosting acceptable. Constraints. Go live at the start of a financial quarter, not during the busy season. Success measures. Branch stock matches physical counts, no order released for a customer over limit without approval, month-end closed faster than today.

A brief like this lets a vendor see that stock, orders and invoicing are tightly linked, so the pilot should prove those together. If your brief describes a wider ERP, our guide to which ERP modules to implement first explains the dependency order.

What mistakes make a requirements brief hard to estimate?

The same problems appear in many briefs, whatever the size of the business:

• Solution-first briefs. "We need an app like X" or "build it in a particular framework" describes a solution before the problem. State the problem and let vendors propose; you can still state technology you must keep.
• Missing exceptions. The happy path is often the smaller part of the work. Returns, cancellations, partial payments and refused approvals are where effort hides.
• No data owner. If nobody is named as responsible for customer, item or employee data, nobody can answer questions or sign off a migration.
• Everything is a Must. A list where every feature is essential gives the vendor nothing to phase and inflates the first estimate.
• Unexplained attachments. A folder of spreadsheets without a line on each is hard to interpret correctly.
• Hidden decision makers. A finance director or IT lead who appears late, with new requirements, resets the estimate.
• Copying a competitor's feature list. It describes their business, not yours.

How do software vendors use your brief?

A capable vendor uses a brief in three ways.

1. To estimate. Expect a range with stated assumptions, not a single number. Read the assumptions carefully: they tell you what the vendor understood. Our guide to custom software development cost explains what drives the range.
2. To ask questions. A list of sharp follow-up questions is a good sign. A quote with no questions on an unclear brief usually means the uncertainty has been priced in or ignored.
3. To choose a pilot. The brief shows which modules carry the most risk or value, so the first working release can prove them. Our article on how to choose a software development company covers what to look for in the responses.

Checklist before you send the brief

• The problem is stated before any feature
• Every user role is listed, with an approximate headcount
• The main workflow is written step by step, with exceptions
• Features are sorted into Must, Should, Could and Won't Have this time
• Must Haves are genuinely the minimum usable set
• Every data set has a named owner
• Integrations name the system, the data and the direction
• Non-functional needs cover security, availability, languages, devices and hosting
• Deadlines include the reason behind them
• Decision makers and the approval route are named
• Success measures can be checked after launch
• Each attachment has a one-line explanation

When is a brief not the right approach?

A brief is the right first step for most custom projects, but not all of them.

• When ready-made software may fit. If your process is standard, compare packaged products first. Our guide to custom software vs ready-made software sets out when each makes sense.
• When procurement rules require a formal tender. Public bodies and some regulated firms must issue a full specification or request for proposal. The brief is still a useful internal starting point.
• When the idea is still forming. If you cannot yet describe the workflow, a short discovery workshop with the vendor will produce a better brief than writing alone.
• When the brief becomes a specification. Detailed screen designs written by the buyer alone tend to fix assumptions before anyone has tested them.

Taking your brief to Timeline Digital

If you have a brief, or half of one, you can share it with us and we will come back with questions before any estimate. Our five-step process starts with understanding the business and planning the scope, and Timeline Digital starts with a free pilot of 2 to 3 key modules before the full project, so you see working software before committing. Read more about our custom software development services.