practical guide
How do you prepare a software brief?
Connect the problem, users, data and acceptance criteria on one page. Define what the solution must enable and what stays out of scope.
You will have a brief to review before estimating development, with open questions clearly marked.
Free, with no sign-up. This example uses fictional data.
Prepare one specific work scenario
Choose a task, such as reviewing open service requests. Gather approved information about the work, roles and data. Use fictional records for the example. Record who confirms the scope and understands the data. Describe the problem through a specific situation. Do not turn a desired outcome into a promise of savings.
A brief template to copy
Copy the template and complete it for one bounded task. A complete fictional example follows for comparison.
NAME AND GOAL Problem in the current work: [specific case] After delivery, the user can: [verifiable action and result] USERS AND PERMISSIONS [Role]: [what they see and what they may change] FIRST DELIVERY SCOPE Included: [actions needed for the chosen scenario] Out of scope: [explicit exclusions] DATA AND SOURCES Required fields: [minimum set] Source and owner: [existing system or responsible person] Access and transfer: [confirmed or an open question] RESPONSIBILITIES Scope and acceptance confirmed by: [person or role] Data and permissions confirmed by: [person or role] ACCEPTANCE CRITERIA When [role] performs [action], they see [expected result]. When [prohibited action or invalid data], the system [expected behaviour]. If saving fails, [message and data state]. OPEN QUESTIONS [Unknown fact, who confirms it and which decision it affects] BENEFIT CHECK [What we record in the current process and after delivery] Brief status: [draft or approved, with the responsible person]
How the workflow works in practice
Illustrative examples with fictional data. They show the process and human review, not the results of a client project.
A brief for reviewing service requests
- Input
A fictional service team manages requests in a shared spreadsheet. The manager wants to find open requests and see who they are assigned to. Technicians need to see only their own requests and mark them resolved. The manager creates requests and assigns a technician. Required fields: request ID, description, technician and an open or resolved status. The first delivery does not include invoices, email notifications or importing the old spreadsheet. The service manager owns the process and confirms the scope and permissions. Unknown: how users sign in and the record retention rules.
- Output
BRIEF: service request overview Goal: the manager can find open requests and see the assigned technician in one place. The current source is a shared spreadsheet. Users: the manager sees all requests, creates them and assigns a technician. A technician sees only their own requests and can mark them resolved. Scope: manual request entry, assignment, status-based views and changing status to resolved. Out of scope: invoices, email notifications and importing the old spreadsheet. Data: request ID, description, technician and status. The manager enters new records. The old spreadsheet remains a separate source. Responsibility: the service manager confirms scope, permissions and acceptance. Fictional data for checking the filter: S-201 is open and assigned to Luka. S-202 is resolved. Each criterion is checked from its own starting state. Acceptance criteria: 1. The manager enters S-201, "Device inspection", technician Luka and open status. On reopening it, the same record is shown. 2. Luka sees S-201. Technician Iva cannot read or change S-201, including through an attempt to access the record directly. 3. Luka marks S-201 resolved. After a refresh, the manager sees it among resolved requests. 4. A request without a description cannot be saved. The user sees which field needs more information. 5. If saving fails, the user sees an error. The system does not show an unconfirmed change as saved and preserves the entered text for another attempt. 6. With S-201 open and S-202 resolved, the manager selects open status. The list shows S-201 and the assigned technician, and does not show S-202. Open: the manager confirms the sign-in method and record retention rules before that part of development is estimated. Benefit check: record the time needed to find an open request and assignment errors before and after delivery. Status: draft for review. This example does not approve development or data transfer.
- Process
- Describe the problem and desired result in two sentences.
- Define roles and permitted actions. Name the person who confirms permissions.
- Limit the first delivery to one scenario. Record what stays out of scope.
- List data, sources and owners. Mark an unconfirmed integration as an open question.
- Write verifiable acceptance criteria. Review the brief with the process owner before estimation and development.
- Human review
- Roles and permissions match the actual work.
- The scope does not assume unconfirmed integrations.
- Every acceptance criterion has a verifiable result.
- The process owner confirms open questions before estimation.
- What we measure
- Number of questions that block estimation or development.
- Number of scope changes caused by an unclear brief.
- Share of acceptance criteria that can be checked without further interpretation.
- Time and errors in the chosen scenario before and after delivery.
Check before using
- Roles and permissions match the actual work.
- The scope does not assume unconfirmed integrations.
- Every acceptance criterion has a verifiable result.
- The process owner confirms open questions before estimation.
- The example is a proposal, not an implemented system. Confirm decisions and permissions before applying it to real records.
Apply it to your process.
Explore our Custom software service to check feasibility and scope. Bring the completed brief and open questions.