Begin with the problem in business terms
Describe what is difficult today. Explain where work slows down, where information becomes unreliable or where customers and employees experience unnecessary friction. A statement such as ‘we need a dashboard’ names a possible output. A statement such as ‘managers cannot see which requests are overdue without combining three spreadsheets’ explains the problem.
Include why the problem matters. It may be delaying service, increasing errors, limiting growth, creating compliance risk or consuming time that should be spent on customers.
Explain how the work happens now
Outline the current workflow from beginning to end. Mention the forms, spreadsheets, email conversations and existing applications involved. Identify where information is entered, checked, approved, changed and reported.
You do not need to document every exception at this stage. The goal is to help the reader see the main route through the process and the points where work regularly becomes difficult.
Identify the people who will use or depend on the system
Different users normally need different information and permissions. A brief should distinguish between employees, managers, administrators, customers, suppliers and external partners where relevant.
- Who starts the process?
- Who reviews, approves or changes information?
- Who needs reports or oversight without doing the daily work?
- Who should only see their own records?
Estimated user numbers are also useful. A system for twelve internal users has different operational requirements from a portal serving thousands of customers.
Describe the outcome, not only the features
Explain what should become easier, faster, safer or more visible. Useful outcomes might include reducing repeated data capture, shortening approval time, giving customers secure access to their records or producing reliable reports without manual consolidation.
Features can then be assessed against those outcomes. This keeps the project focused and makes it easier to decide what belongs in the first release.
List important constraints and dependencies
Mention deadlines, budget expectations, regulatory requirements, existing hosting arrangements and applications that may need to connect to the solution. If historical data must be imported, explain where it currently lives and how reliable it is.
Also identify what cannot change. Your customers may need to keep submitting a familiar spreadsheet, for example, while a new system improves the work behind it.
Separate essentials from ideas
A useful brief distinguishes between what the first release must achieve, what would be valuable later and what remains uncertain. This is particularly important when several stakeholders have contributed requests.
- Essential: required for the core workflow to produce a useful result.
- Later: valuable once the central process is working.
- Open question: requires investigation, user input or technical confirmation.
What the brief does not need
You do not need to choose the programming language, database or cloud platform unless your organisation already has a valid technical constraint. You also do not need polished interface designs. Those decisions should follow a shared understanding of the business and users.
A practical brief structure
- Organisation and project background
- Current problem and its effect
- Current workflow and tools
- Users, roles and approximate numbers
- Desired business outcomes
- Essential first-release capabilities
- Existing data, integrations and constraints
- Known deadline, budget range and decision process
Frequently asked questions
How long should a software brief be?
Two to five clear pages are often enough for an initial discussion. Supporting process maps, example spreadsheets or forms can be attached separately.
Can the brief change after discovery?
Yes. Discovery exists to test assumptions, clarify the workflow and recommend a responsible scope. The brief begins the conversation; it should not prevent better decisions.
Should we ask several developers to quote from the same brief?
You can, but compare how each provider understands the problem and manages uncertainty, not only the total price. Quotes based on different assumptions are not directly comparable.
Nuvise helps businesses turn operational problems into a clear, practical software scope before significant development begins.
