How to Write a Software Project Brief

Start with a short account of the current process. Who begins the work? Where is information recorded? Who handles the next step? Describe a recent example with sensitive details removed. This helps a developer distinguish the actual problem from a preferred interface.

Replace “We need a dashboard” with something like: “Our coordinator checks three spreadsheets every morning to find requests awaiting approval. Customers call because they cannot see what is happening.” The second version identifies people, information, and a repeated task. A dashboard may be part of the answer, but the brief has not prematurely decided it.

If you know the volume, handling time, or frequency of errors, include it and say how you measured it. Label an estimate as an estimate. If the team has not measured the problem yet, say so rather than supplying a number that looks authoritative.

Explain what should become easier or more dependable. For the coordinator example, the outcome might be that staff can identify every request needing action in one place, and customers can see an accurate status without contacting the office.

Separate a business goal from a launch check. “Reduce avoidable status calls” is a business goal to evaluate after adoption. “A customer can see the latest status of their own request” is behavior the team can test before launch. Both belong in the brief, but they answer different questions.

List the groups that will use the system and what each needs to do. A customer may submit a request; a coordinator may assign it; a manager may approve a change. Identify who owns the business process and who can settle questions during development.

Include important access boundaries. Does one customer organization have several users? Can contractors see only assigned work? Who can invite or remove people? These answers can affect scope much more than a visual preference.

Write the steps from a user's starting point to a useful result. For example: submit a request, receive an acknowledgment, have staff review it, see the updated status, and receive completion details. Include the staff actions needed to make the customer experience work.

Mark what must be included and what can wait. If scheduling remains manual, state that explicitly. If payments, live chat, or a mobile app are outside the first release, say so. An exclusion prevents a reasonable but different assumption from entering a proposal unnoticed.

Name the systems the project may need to connect to and explain why. Identify the source of customer records, documents, orders, or appointment information. Mention who controls those accounts and whether an export or integration has been checked.

Do not claim that an integration is simple because a product advertises an API. Write what needs to move, in which direction, and how quickly. “Import approved customer records once before launch” is a different requirement from “keep customer records synchronized throughout the day.”

Share a budget range if you have one and identify what it must cover. Distinguish the initial implementation budget from recurring services and support. If the range is not set, ask the company to identify a sensible discovery step and the information needed to estimate delivery.

Explain why a deadline matters. A fixed event, expiring system, or contractual dependency is different from a preferred launch month. Include your own availability for content, reviews, account access, and decisions. Those are delivery dependencies even when they are not development tasks.

Use those three labels where the distinction matters. A fact might be that staff currently use a shared customer spreadsheet. An assumption might be that it can provide the initial import. An open question might be whether customer organizations need multiple accounts.

This gives the development team permission to investigate without treating a guess as an agreed requirement. The GOV.UK discovery guide makes the broader point that understanding the problem and constraints comes before committing to build. Your brief should support that investigation, not pretend it has already answered everything.

Ask each company to explain its understanding of the problem, proposed first scope, assumptions, exclusions, discovery needs, estimated range, responsibilities, and support approach. Request the same response structure from everyone so differences are easier to identify.

Invite alternatives. A supported existing tool or a smaller integration may meet the outcome more effectively than a new application. You can ask for a recommended approach and one simpler option without asking companies to produce a complete unpaid technical design.

The following is a hypothetical brief for a small service business. Adapt its level of specificity rather than copying its requirements into an unrelated project.

Our office coordinates maintenance requests for business customers. Requests arrive by email and are copied into a shared spreadsheet. Customers call the office for updates. The coordinator currently checks messages and the spreadsheet before answering. We have not yet measured how much time those status checks take.

We want a customer to submit a request and see its current status, while the coordinator manages requests in one place. Customers should see only records belonging to their organization. Office staff need to review requests, change status, and add a completion note. We need to confirm whether every customer organization requires multiple users.

The first release should support customer invitations, sign-in, request submission, acknowledgment, staff review, status updates, and completion notes. Staff will continue scheduling work manually. Online payments, instant scheduling, live chat, and a separate mobile app are outside this first release. The portal should work in a phone browser.

Customer details are currently in a spreadsheet owned by the office manager. We assume a reviewed one-time import will be enough initially, but need that checked. A manager will consolidate feedback and approve decisions. Our initial implementation budget is not yet set; please separate discovery, delivery, and recurring costs. The launch date is flexible until we understand the effort. We also need recommendations for account recovery, backups, and post-launch support.

Please explain your recommended approach, the assumptions that affect the estimate, what discovery must resolve, and what our team must provide. Include a simpler existing-tool option if it could meet the outcome. Identify exclusions, acceptance checks, and ongoing responsibilities rather than supplying only a total price.

Send the same version to each company and record answers to shared questions in one place. If discovery changes the scope, update the brief and date the revision. A proposal is much easier to assess when you can trace its assumptions back to a shared description of the work.

Use our guide to choosing a software development company to evaluate the team behind the response. If you have a rough brief, share your project with DevConex to discuss the important gaps before development begins.

Long enough to explain the problem, users, first outcome, constraints, and unknowns without burying them. A short brief with relevant examples is more useful than a large document filled with unprioritized features. Put detailed background in supporting material.

No. The brief establishes the business need and boundaries. A technical specification describes implementation decisions and detailed behavior. The development team may help produce that specification after investigating the brief.

Include a realistic range if one is available, and say what it needs to cover. It helps companies propose an appropriate scope. If the budget is unsettled, be transparent and request a staged approach to resolving the uncertainty.

Yes. Explain the current process, the result you need, and the constraints. A clearly described problem with honest questions gives a capable team a useful starting point without prescribing the answer.