A first software brief does not need to be long. It should explain how the work happens, who uses the system and what a completed outcome looks like. That creates a better shared understanding than a list of feature names alone.
Use the checklist below to prepare an initial discussion. Scope, cost and timing still need to be assessed against your data, integrations and delivery arrangements.
1. Describe the work and the problem first
Choose a concrete situation and follow it from the moment work arrives. Record the steps, owners, spreadsheets or systems used, and what is delivered at the end. Identify repeated entry, waiting, missing information and common errors.
A request for an admin panel describes an interface. A description of colleagues checking incoming enquiries, assigning an owner and tracking replies gives a development team a workflow to discuss.
- Who requests the system, uses it daily and approves the work?
- How is each step completed today?
- Which problem should the first version solve?
- What can wait until a later phase?
2. Map data, permissions and integrations
List the information the system needs to read and change, and prepare examples with sensitive details removed. For existing platforms, establish who owns the data, how it can be exported and whether a supported integration method exists.
Permissions need more detail than logged in or logged out. A person may need to view only their own tasks, change particular fields or approve selected operations. Mapping roles early helps reveal whether the proposed workflow fits the business.
| Area | Information to prepare |
|---|---|
| Users | Roles, daily work and approval responsibilities |
| Data | Fields, examples, sources and update owners |
| Integrations | Current platforms, export formats and available interfaces |
| Permissions | Who may view, change, approve and export |
3. Define completion through demonstrable scenarios
Turn a feature into a sequence someone can repeat. For example: a colleague creates an enquiry, a manager assigns an owner, the owner updates its status, and the manager can view outstanding cases by date.
Include exceptions such as missing required data, duplicates, insufficient permissions and a temporarily unavailable integration. Acceptance should establish whether the work can be completed, not merely whether a screen exists.
- Specify inputs, actions and expected results
- Identify which roles may perform each action
- Describe the expected response to errors and exceptions
- Use the same scenarios for demonstrations, testing and delivery
4. Discuss delivery, maintenance and handover early
Alongside features, describe testing, data migration, training, account management, maintenance and support. These activities influence whether the team can take over and use the system effectively.
Clarify how source code, domains, hosting accounts and data exports are handed over, and how additional requirements will be assessed. Record the arrangements in the agreed delivery documents rather than relying on assumptions.
- Who manages production and third-party accounts?
- Which operating instructions and training are included?
- Where are issues reported, and how are they followed up?
- How can the business export its data if it changes systems?
5. Prioritise a complete first workflow
Separate requirements into essential for the first version, suitable for a later phase and still to be confirmed. Keep the first version centred on a complete core workflow rather than every feature the team can imagine.
Use the same brief, scenarios and delivery checklist when comparing proposals. If costs differ, understand whether the quotes include different integration, data preparation, testing or maintenance work before making a decision.
