How to write a software project brief

A useful software brief explains the business problem, the people affected and the constraints around the work. It does not need to prescribe every screen or technical choice. Its purpose is to help you and a potential engineering partner reach the same understanding before discussing scope and cost.

Begin with what happens today

Describe the current workflow and where it breaks down. A request such as “we need a customer portal” names a solution, but leaves the reason for building it unclear.

A more useful starting point might be: “Customers email our operations team for order updates. The team checks two internal systems before replying. We want customers to see the information they need without waiting for a manual response.”

That example is illustrative. It describes a workflow, its users and an intended change. It also raises useful questions about data access, permissions and the freshness of the information.

Identify the users and their important tasks

List who will use the system and what each person needs to accomplish. A customer, an operations employee and an administrator may need very different access.

Start with the essential journeys. For a portal, that could mean signing in, finding an order, viewing its status and asking a question. Explain what successful completion looks like, including unusual situations such as missing information or an account with several users.

Describe the result you want

Connect the proposed software to a practical business goal. You might want to reduce manual follow-up, make a process easier to track or introduce a service customers cannot currently access.

If you have a baseline, include it. If you do not, say so. A target without a baseline can still guide discussion, but it should not be treated as an established outcome or a delivery guarantee.

Name the systems and constraints

Identify the applications, databases or external services the new software may depend on. Share available documentation and note where access is still uncertain. Do not include credentials or sensitive customer records in an initial enquiry.

Also explain constraints that could change the plan: a launch date tied to another event, required approval steps, accessibility needs, data-handling requirements or an internal team that will take over maintenance.

Separate the first release from later ideas

Divide requirements into essential first-release journeys, useful additions and questions that need investigation. This gives the engineering team room to recommend a coherent starting point.

For example, a portal's first release might show account-specific order information and support requests. Advanced reporting or recommendations could be considered later. The correct boundary depends on which journeys make the first release useful on its own.

Ask for assumptions with the proposal

When you request a proposal, ask the provider to explain the assumptions behind the scope. Which integrations are included? What must your team supply? How will the work be reviewed? What happens when a requirement changes? What documentation and handover are included?

This makes proposals easier to compare because you can see whether they describe the same work.

A brief you can start with

1. Business problem: What happens today, and why does it need to change?
2. Users: Who is affected, and what must they be able to do?
3. Desired result: What would make the project useful?
4. First release: Which journeys are essential?
5. Existing systems: What must the software connect to or work alongside?
6. Constraints: What dates, budget expectations or operating requirements matter?
7. Ownership: Who makes decisions, reviews the work and maintains it after launch?
8. Open questions: What still needs discovery?

You can begin with honest gaps. A good brief makes uncertainty visible so it can be addressed before it becomes expensive rework.