How to write a custom software brief

You can start a software brief with one ordinary job. Take an enquiry that came in last week and follow it through your business. Record who handled it, where they stored the details and how the quote was approved. Include what happened when the customer changed their mind.

That gives a builder something concrete to scope. A list of features such as “dashboard, automation and reporting” leaves most of the work undefined.

Describe the job before the screens

Write the starting point and the finish. One business might describe it like this: “An enquiry arrives through the website. Our administrator checks the details and sends a quote to the manager for approval. After the customer accepts, we assign a date and a crew.”

Then list the people involved, the tools they use and the information that changes hands. Name the tool your team checks for the current record. If invoices are created and updated in the accounting tool, say so. A new dashboard should not quietly become a second version of the accounts.

Bring a redacted example of the form, spreadsheet or email your team uses today. Remove customer details and credentials before sharing it.

Name the decisions a person must make

An administrator may be able to prepare a quote but need a manager to approve it. A contractor may need the job address and instructions without access to the customer's payment details.

For each role, say what they can view, create, change and approve. Mention what happens when somebody leaves the business or is away. Permissions are part of the brief, even when the first release has only a few users.

Include three awkward cases

A routine job can hide the decisions your team makes when something goes wrong. Choose three exceptions that already happen in your business:

• A customer changes the scope after accepting the quote.
• The person who normally approves work is unavailable.
• A required payment, supplier response or piece of information never arrives.

Write what your team does now and what you want them to do in the new flow. Decide which steps can wait and which need a visible warning or a person's decision. “Send it again” needs a rule for avoiding duplicate jobs, invoices or notifications.

Draw a boundary around the first release

Choose a complete flow with a clear finish. For the enquiry example, the first release might end when an approved job appears on the schedule. Stock management and customer reporting can remain separate later decisions.

List the essentials, later ideas and exclusions. Record the existing tools that must stay, the data that needs moving and who can provide access. An integration depends on what the supplier actually supports, so flag unanswered access questions before agreeing a fixed scope.

Write one acceptance example

An acceptance example makes the finished work easier to assess:

“A new enquiry creates one draft job. The administrator can edit its details. Only a manager can approve its quote. Once accepted, the job appears on the schedule once. If it is cancelled, the crew can see that it is cancelled.”

Use your own process and include an exception. Ask who will test it and who can sign off the result.

A brief you can copy

1. The problem: what prompted this project?
2. One real job: where does it start and finish?
3. People and permissions: who can do what?
4. Current tools: which record is authoritative?
5. Exceptions: what happens when the usual flow breaks?
6. First release: essentials, later ideas and exclusions.
7. Data and access: what must move, and who supplies it?
8. Acceptance: one example your team can test.
9. Budget and deadline: your budget range and why the deadline matters.
10. Approver: who can agree the scope and next step?

You do not need to choose a programming language or design every screen before the discussion. Bring the problem, the people and the flow. The written scope can then identify the work, separate costs and open questions before a build is agreed.

Article tools

Copy for LLM View as markdown