How to Write a Software Requirements Brief

Most software quotes go wrong before a single line of code is written. A business sends three agencies a two-paragraph email, gets back three prices that are wildly different, and has no way to tell which one is realistic. The agencies were not being careless. They were each guessing at a different project, because the email left them room to.

A requirements brief fixes that. It is a short document, usually a few pages, that describes what the business needs the software to do, for whom, and within what constraints. It does not need to be technical. It needs to be specific. This guide walks through what to put in it, section by section, with a template structure you can copy.

Why a good brief gets better quotes

When a brief is vague, every agency fills the gaps with its own assumptions. One assumes five users, another assumes fifty. One assumes the software will talk to your accounting system, another assumes someone will re-key invoices. The result is quotes you cannot compare, and later, arguments about what was "in scope".

A clear brief does three things:

• It narrows the range. Agencies are pricing the same project, so the differences between quotes reflect their approach and rates rather than their guesses.
• It surfaces the expensive parts early. Integrations, data migration and compliance requirements drive cost more than screens do. If they are written down, they get priced.
• It protects you later. A brief becomes the reference point when someone asks whether a feature was always part of the plan.

Brief vs SRS vs RFP: which do you need?

These three documents get mixed up, and it is worth knowing the difference before you start writing.

• Requirements brief — a business-level description of what you need. Written by the business owner or operations lead. A few pages. Used to get quotes and start conversations with agencies. This is what most SMEs need.
• Software Requirements Specification (SRS) — a detailed, structured document covering every function, rule and non-functional requirement. Usually written by a business analyst or the development team during discovery. Can run to dozens of pages. Useful for large or regulated projects, but rarely the right starting point for a small business.
• Request for Proposal (RFP) — a formal procurement document that wraps requirements in evaluation criteria, commercial terms and submission rules. Common in government and large corporates. Overkill for most private SMEs.

If you are a growing UAE business replacing spreadsheets or an ageing system, write a brief. A good agency will turn it into a detailed specification during discovery, and you should expect that as part of the engagement.

The template, section by section

Below is the structure we recommend. Copy the headings into a document and fill each one in. Where a section does not apply, say so explicitly rather than deleting it; "no integrations needed" is useful information.

1. Business context and goals

Explain who you are, what the business does, and why you are doing this project now. Then state what success looks like in business terms, not technical ones.

• Company overview: what you do, how many locations or entities, roughly how many staff will use the system.
• The problem: what is going wrong today (manual work, errors, slow reporting, a system that is no longer supported).
• Goals: two to five outcomes, for example "month-end close no longer depends on one person's spreadsheet".
• Deadline drivers: anything with a fixed date, such as a new branch opening or a compliance deadline.

Example sentence: "We distribute building materials from two warehouses in Dubai and Sharjah. Orders are taken by phone and WhatsApp and entered into spreadsheets, and stock figures are rarely right."

2. Users and roles

List the types of people who will use the system and what each needs to do. Roles matter because each one adds permissions, screens and testing.

• Internal roles: for example sales staff, warehouse team, accounts, managers, owners.
• External users: customers, suppliers, sub-agents or drivers, if any will log in.
• Approximate numbers per role, now and in two to three years.
• Language needs: English only, or Arabic and English.
• Devices: office desktops, tablets in a warehouse, phones in the field.

3. Core workflows and features

Describe the main processes the software must support, step by step, in plain language. Then list features and prioritise them using MoSCoW:

• Must have — the system is useless without it.
• Should have — important, but the first release could go live without it.
• Could have — nice to have if time and budget allow.
• Won't have (this time) — explicitly out of scope for now.

The "won't have" list is underrated. It tells agencies what not to price, and it stops scope drifting during the build.

Skip the screen designs. You do not need wireframes in a brief. Describe what people need to do, and let the design work happen later.

4. Integrations and existing systems

List every system the new software needs to exchange data with, and which direction the data flows. This is one of the biggest cost drivers, so be thorough.

• Accounting or ERP software in use today.
• Payment gateways, banks or payment links.
• E-commerce platforms, marketplaces or booking channels.
• Email, SMS or WhatsApp messaging.
• Any government or third-party portals you exchange data with.
• For each: the product name, whether it has an API (if you know), and what data needs to move.

5. Data, migration and reporting

Say where your data lives today and what needs to come across. Agencies cannot price migration if they do not know it exists.

• Current data sources: spreadsheets, an old database, an existing application.
• What must move: customers, suppliers, products, open orders, balances, history.
• Rough volumes: hundreds, thousands or hundreds of thousands of records.
• Known quality issues: duplicates, inconsistent product codes, missing fields.
• Reports and dashboards you need on day one.

If migration is a big part of the project, our guide to data migration planning covers what to think about.

6. Compliance

You do not need to specify how compliance is achieved, but you should say which rules apply to you so the agency can account for them.

• VAT: will the system issue tax invoices or credit notes?
• E-invoicing: will the system need to produce structured invoices as the UAE rollout reaches your business? See preparing for UAE e-invoicing.
• Personal data: will the system hold customer or employee personal data, and are you aware of your obligations under the UAE data protection law (PDPL)?
• Data location: do you, your customers or your regulator require data to be stored in the UAE?
• Sector rules: anything specific to healthcare, finance, education or your free zone.

7. Non-functional needs

These are requirements about how the system behaves rather than what it does.

• Security: login requirements, two-factor authentication, audit trails, who can see what.
• Hosting: cloud, a particular provider, or on your own servers.
• Performance: peak usage times, number of concurrent users, acceptable response times.
• Availability: whether the system must work outside business hours or offline.
• Support: what help you expect after launch.

8. Budget range, timeline and decision process

• A budget range, even a wide one.
• Target launch date and whether it is fixed or flexible.
• Who makes the decision, and who will be the day-to-day contact during the project.
• How you will compare proposals and when you plan to decide.

Sharing a budget range feels risky, but it is one of the most useful things you can do. It lets an agency propose the right shape of project, such as a smaller first phase, rather than a full build you cannot afford.

A worked example (illustrative)

The following is a simplified, fictional brief for a generic UAE distributor. It is not based on a client.

• Context: Distributor of packaged food products, one warehouse in Dubai, around 20 staff using the system. Orders arrive by phone, email and WhatsApp. Stock is tracked in spreadsheets and is often wrong.
• Goals: one place to take orders; accurate stock by batch and expiry date; tax invoices issued from the system; weekly sales reports without manual work.
• Users: sales (6), warehouse (8), accounts (3), management (3). Arabic and English invoices.
• Must have: order entry, stock by batch and expiry, delivery notes, VAT tax invoices, customer statements.
• Should have: mobile order taking for sales staff, reorder alerts.
• Could have: customer self-service ordering portal.
• Won't have: payroll, manufacturing.
• Integrations: current accounting software (export of invoices and payments), WhatsApp notifications.
• Data: around 3,000 products and 800 customers in spreadsheets; duplicates known.
• Compliance: VAT-registered; will need e-invoicing readiness; customer contact data only.
• Budget and timeline: a stated range; target go-live before peak season; owner signs off, operations manager is day-to-day contact.

Common mistakes

• Describing a solution instead of a problem. "We need an app" says less than "our drivers cannot confirm deliveries until they get back to the office".
• No data or migration section. Migration is often a significant share of the effort and is the part most likely to be left out of a quote.
• Missing integrations. If an integration is discovered halfway through a build, it is a change request.
• Everything is a must-have. If every feature is critical, none of them are prioritised.
• No decision owner. Projects stall when nobody has authority to make calls.

How to send the brief and compare responses

Send the same brief to every agency you are considering. Ask each one to return, at a minimum:

• Their understanding of the problem, in their own words.
• The assumptions behind the estimate, and what is excluded.
• How the work is phased, and what the first release includes.
• How they handle discovery, testing, data migration and launch.
• What support and maintenance looks like after launch, and what it costs.
• Who owns the code and the data.

When the responses come back, compare the assumptions before you compare the prices. A low quote that excludes migration and testing is not cheaper. For more on choosing between agencies, see how to choose a software development company in Dubai, and for how we approach estimates, see how we price projects.

If you have a brief ready, or half ready, send it to us and we will tell you what we would need to give you a firm estimate.