Software project brief: prepare your requirements for a quote

A software project brief describes the business problem, the people who will use the application and what the first release needs to do. Add existing data, integrations and project constraints. Development teams can then explain what their estimates include and what still needs clarification before work starts.

If you run a business or nonprofit, start with a process you know well. Choose a recent request and follow it from arrival to completion. Below you will find a template to fill in, a testable requirement example and a way to compare proposals.

Start with a piece of work you can show

“We need a CRM” tells a developer little about your team's work. Describe where a request arrives, who takes it, what information gets copied and how you know it is resolved. An anonymized request and an empty form may explain the process better than a long screen list.

Speak with the person who does the work. The GOV.UK guide to learning about user needs recommends examining the current process and testing assumptions through research. Record observations separately from assumptions you still need to check.

Choose an outcome you can verify. For example, a coordinator can see unassigned requests in a shared list. To measure time saved, record the current time spent and agree how to repeat that measurement. A desired percentage remains a target until you have evidence.

A software project brief template you can fill in

Copy these questions into a document and answer in your team's own words. When an answer is unknown, mark it “to confirm” and identify someone who can check. Use fictional data in your examples.

1. What does the organization do, and who makes decisions about this project?
2. Which process do we want to improve? How does it work today?
3. Where does work get stuck? Which anonymized example shows the problem?
4. Who will use the application? What can each role view and change?
5. List the tasks the first release must support. What can wait?
6. What data already exists? Where do you store it, and who will check it?
7. Name the services you need to connect. Who can confirm access and documentation?
8. What happens when a request is incomplete, cancelled or submitted twice?
9. Which devices does the team use? Describe any connection problems or accessibility needs.
10. How will we check each important workflow? Who accepts the delivery?
11. What is the budget range, and what should it cover? Which deadline matters, and why?
12. Who will run the application after launch? Describe the support and handover you need.

Add a short section for open questions. This is a starting document. Detailed requirements can develop through discussion with the developer. Atlassian's product requirements guide covers goals, assumptions and items outside the agreed scope.

Turn a feature request into something you can test

Consider the request “We need activity scheduling.” The following fictional example concerns a service team. Its rules illustrate a project discussion; they do not describe a client's configuration or results.

• A coordinator creates an activity, chooses an available employee and sets a time slot.
• The employee sees assigned activities and records completion.
• A cancellation preserves the reason so the coordinator can decide whether to reschedule.
• The first release covers scheduling and status tracking; automatic route optimization is assessed separately.

Acceptance criteria explain how to check the delivery. For this example, propose the following checks and confirm them with the team:

1. After saving, the activity appears in the selected employee's schedule on the correct date.
2. Another employee cannot open the activity through a direct link if they lack access.
3. Submitting the same completion twice does not create duplicate records.
4. A reversed completion follows the reporting rule agreed with the team.

These details affect estimation and testing. For a real product example, SocialCare brings records, scheduling, documents and operational reports together. The public project page uses demonstration data and keeps the client's name private.

List data and integrations before setting the budget

“Import from Excel” could mean one clean file or several versions with duplicate records. Explain what must be retained, who checks the import and how you will spot a missing record. For an initial discussion, share column names and a few fictional rows.

For each integration, name the service and subscription in use. Identify who manages the account and where to find the connection guide. Then ask the developer to check access before committing to the integration. Share passwords and keys only through an agreed secure-access channel, separately from the brief.

Ask suppliers to explain their quotes in the same format

Send the same version of the software project brief to every team. Ask them to explain the included scope and the assumptions behind the estimate. You can then check whether two prices cover the same work.

• Which workflows and roles does the first delivery cover?
• How will the team handle migration, integrations and acceptance tests?
• What input does the team need from your organization?
• Does the quote list recurring costs and external services separately?
• What will you receive at handover, and who will manage later changes?

An early estimate may depend on unverified assumptions. Ask for those assumptions to be visible. If the scope remains unclear, consider an initial discovery stage with defined deliverables before estimating the whole application.

If you are still choosing between an existing product and development, read when custom software is worth the investment. To choose a starting workflow, explore business processes worth considering for automation.

Questions before sending your brief

Do I need to choose a technology first?

You can describe the problem before choosing a technology. Mention existing systems and confirmed restrictions. The development team can then explain the options and trade-offs.

How detailed should a software project brief be?

Detailed enough to explain a complete workflow, its users and the limits of the first release. Include details that could change the scope. Keep long attachments separate and give them clear version numbers.

Can I request a quote before approving the budget?

Yes. Explain that the budget is under review and ask suppliers to describe scope options. Distinguish an indicative estimate from a proposal based on confirmed requirements.

Should I send real customer or employee records?

Use fictional data or anonymized examples for the initial discussion. If the project requires access to real records, agree the purpose and conditions of that access separately before any transfer.

Discuss your first workflow with BLIP Solutions

Prepare a description of the current process and a list of outstanding questions. Talk to Victor about your project requirements or email contact@blipsolutions.ro. We can start with that workflow to clarify what belongs in the first release.