October 4, 2026
Software StrategySoftware project brief template for business owners
A software project brief explains what you want built, who will use it, and how you will recognize acceptable behavior. Start with the business outcome, connect it to a user task, and describe an observable acceptance check. Separate facts, assumptions, exclusions, and unknowns so a software partner can develop the details with you.
By Chris Sutton
Use the downloadable software project brief worksheet to prepare that conversation. Download it without providing an email address. Copy these headings into your brief: context, business outcome, users and tasks, acceptance checks, facts and sources, assumptions and validation, exclusions, unknowns and owners, systems and access, alternatives, first scope, and handoff ownership. You can arrive with a specific idea and unfinished details; the worksheet gives those gaps a place to live.
What a software project brief does before a specification
Your starting point might be “customers should check their job status online.” That is enough to begin. Add an example of the current process, explain whose work should change, and name constraints you already know. Leave technical choices open unless an existing system or contract requires them.
The brief establishes intent and boundaries. A specification develops the agreed behavior in enough detail to implement and verify it: rules, data, interfaces, failure handling, and technical decisions. The brief is an input to that work, and your product and engineering partner should help shape it. You do not need to design the database before asking for help.
GOV.UK’s discovery guidance recommends questioning a proposed solution, exposing assumptions, and agreeing exclusions. Its guidance concerns government services; this worksheet adapts those ideas for an initial business conversation without prescribing a government discovery process. GOV.UK: How the discovery phase works.
Connect the outcome to a task and a check
Write three linked statements:
- Business outcome: What should become possible or improve for the business?
- User task: What does a particular person need to do, and why?
- Observable acceptance check: Given a stated situation, what action should produce what visible result?
“A useful dashboard” leaves too much room for interpretation. “A customer sees the approved status of their own job, with its update time” names behavior you can inspect. Add an exception so the expected response to missing information is also visible.
GOV.UK recommends evidence-based user needs describing the person’s problem and purpose. It connects those needs to more specific stories with acceptance criteria and dependencies. Wavelength’s Software Project Brief Worksheet links outcomes, tasks, and checks as an editorial adaptation. GOV.UK: Learning about users and their needs.
Fictional worked example: a service company’s job status portal
In this fictional example, customers email staff for job updates. Staff check a dispatch tool and reply. The owner wants customers to check approved status online.
On small screens, scroll the table sideways to read all columns.
| Record | Proposed brief entry |
|---|---|
| O1: Business outcome | Make routine job status visible without a staff reply. |
| T1: Customer task | Check the current approved status of their own job. |
| T2: Dispatcher task | Approve a customer-facing status in the dispatch tool without entering it again in the portal. |
| F1: Fictional fact and source | Staff use a dispatch tool and reply by email; source: dispatcher’s fictional workflow walkthrough, linked to T1/T2. |
| F2: Fictional fact and source | Dispatcher confirms responsibility for customer-facing status approval, linked to T2/C2. |
| A1: Assumption | Customers will use self-service status checks. Operations manager validates through conversations with intended users before committing to portal scope. |
| E1: Exclusions | Payments, appointment changes, and portal messaging are outside the proposed first release. |
The following checks connect those tasks to observable behavior. They are proposed requirements, not test results.
On small screens, scroll the table sideways to read all columns.
| Check | Situation and action | Expected behavior |
|---|---|---|
| C1, linked to T1 | Customer A opens job J1, which belongs to Customer A and has approved status “Awaiting visit.” | Show “Awaiting visit” and its approval time. Customer B cannot view J1. |
| C2, linked to T2 | The dispatcher approves a new customer-facing status for J1 in the dispatch tool. | On the next successful refresh, show that status and approval time without separate portal entry. |
| C3, linked to T1 | The status refresh fails after a previously successful refresh. | Retain the last confirmed status and approval time, label the update unavailable, and offer a way to contact the dispatcher. |
The dispatcher reviews the approved source status and time against the portal for C2. The operations manager checks retained values, the warning, and contact path during a simulated refresh failure for C3. Also specify first-visit failure: show no invented status. If the portal is unavailable, provide a contact route outside it. Record any offline-access exclusion and fallback owner. To assess business benefit separately, record enquiries before launch and decide how to track portal use afterward.
Separate facts, assumptions, exclusions, and unknowns
A fact needs a source: an observed workflow, a sample record, or an accountable person’s confirmation. An assumption needs validation. An exclusion names work deliberately left outside this version. An unknown identifies information you cannot yet supply.
Keep unknowns actionable with an owner and a next step. In the fictional brief:
On small screens, scroll the table sideways to read all columns.
| Unknown | Owner | Next step |
|---|---|---|
| U1: Can the dispatch tool expose approved status and approval time through read-only access? | System administrator | Inspect a sample export and vendor documentation with the engineering partner before estimating the integration. |
| U2: How old may a displayed status be before staff must intervene? | Operations manager | Agree a freshness rule and manual fallback before accepting the refresh behavior. |
The dispatch tool’s data access determines whether approved updates can appear automatically. The acceptable age of a status determines when staff must intervene. If an owner is unassigned, say so and give the business decision maker responsibility for assigning one. Keep the question unresolved until its owner supplies evidence.
Check an existing tool before expanding the build
Run the same task and acceptance checks against an existing-tool alternative. For this fiction, first inspect whether the dispatch tool’s customer view can meet customer access needs and the status checks. Record what works, what fails, and what remains unknown. No capability is assumed here.
GOV.UK’s technology guidance recommends exploring assumptions and interfaces and identifying components to build, buy, or obtain freely. It supports checking alternatives, not a conclusion that buying is cheaper. GOV.UK: Choosing technology.
A configurable customer view may mean accepting its workflow limits. A custom portal introduces software and integration ownership. A staff-managed status email process may remain a useful fallback but still requires a staff reply. Compare these tradeoffs against the business outcome and the actual checks before choosing.
Size the first scope and make estimates conditional
Propose a complete first task: customer access to an approved job status, the dispatcher’s update path, and unavailable-update handling. Defer the excluded capabilities in E1. Counting screens alone misses the work needed to connect them to data and operating rules. Ask for a written estimate with deliverables, effort and calendar ranges, client responsibilities, excluded costs, and assumptions that trigger revision. Separate investigation from implementation and build costs from recurring operation. Agree how scope changes are approved.
An estimate should name what it assumes about data access, record quality, permissions, update frequency, migration, user groups, and support after launch. Include any fixed deadline and its reason, a budget range if known, and who can approve a smaller scope. Mark preferences separately from hard constraints.
If the dispatch tool’s data access is unresolved, ask which inspection would narrow the estimate and what happens if read-only access is unavailable. A prototype or integration investigation may be the next bounded step. The brief supports sizing; it does not itself establish a fixed price or delivery date. Our 100-hour app service is a sprint to consider once the proposed scope fits, not a size every idea must fit.
Use the worksheet for a shared handoff
Download the worksheet and complete its context and outcome fields first. Repeat the task and check records for each essential workflow. Add facts with sources, assumptions with validation steps, exclusions, systems, and unknowns. Keep blank fields labelled “unknown” rather than guessing. Use the fictional section as a model, then remove it from your own brief.
Ask your partner to review the task-to-check links, identify missing decisions, and propose scope and technical options. Agree who approves business rules and acceptance, who controls system access, and who owns status corrections and support after launch. Specify ownership of code and hosting accounts, maintenance responsibilities, and ongoing costs. Before launch, agree the handoff package: account access, code and deployment instructions, export and recovery instructions, operating notes, and staff training. Name who accepts it and when support responsibility transfers. Record changes with a date and reason so both sides use the same version.
For broader planning topics, browse our software strategy guides. When you want to discuss a specific build, book a call and bring the brief and its open questions. Start by agreeing the first usable scope and which unknowns need resolving before an estimate.