01
Start with the Process That Needs to Improve
Describe what happens today. Who starts the work? What information do they provide? Which people review it? Where does it slow down or become difficult to track? Use a recent example to make the explanation concrete. A purchase request that needed three approval rounds tells a developer more than a broad request for a powerful procurement platform.
Separate the problem from the proposed feature. For example, ‘managers cannot see which requests are waiting for them’ describes a need. A dashboard may help, but an approval queue or a better notification could be more suitable. Keeping the need visible makes it easier to compare solutions.
02
List the People and the Decisions They Make
Identify each user group and the tasks it should perform. Include people outside the organisation when they are part of the journey: customers, suppliers, members, partners, or contractors. Note who creates, edits, reviews, approves, exports, and deletes information.
Access rules should be specific. ‘Managers can see their own team’ is more useful than ‘role-based access required’. Also describe how a person moves between roles, how temporary access works, and what should happen when someone leaves.
03
Bring Examples of the Information
Existing forms, spreadsheets, reports, and screenshots help reveal the structure of the work. Use approved or anonymised samples. Explain which fields are required, which are calculated, and which must match another system. Include at least one incomplete or unusual example so exception handling is not overlooked.
For a migration, record where the information lives, who owns it, its approximate volume, and how clean it is. Old records may need reconciliation or archiving before they become useful in a new application. A project estimate should acknowledge that work.
04
Map Integrations and Practical Constraints
Name the applications that must exchange information and explain the direction of each exchange. Does a customer record originate in the CRM or the website? Does an order need to appear in an accounting system? Who resolves a failed update? Available APIs, provider accounts, and technical access can materially change the scope.
Add constraints that affect delivery: important dates, hosting arrangements, internal approval steps, accessibility needs, and the people available for review. Distinguish a fixed business deadline from a preferred target. Be clear about who can supply content, policies, product information, and access credentials.
05
Define the First Useful Release
Group requirements into what must work for launch, what can follow, and what still needs investigation. A first release should complete a useful journey rather than expose a large number of unfinished features. For each essential capability, describe an observable result that your team can accept.
For example: ‘A manager can approve a submitted request, and the requester can see the decision and timestamp.’ Add examples for rejection, missing information, and permission restrictions. These acceptance criteria make demonstrations more useful and help both parties identify changes to scope.
06
Use the Brief to Compare Proposals
A proposal should connect the brief to deliverables, assumptions, responsibilities, exclusions, and milestones. Ask how changes are handled, how testing will involve your team, and what handover includes. Compare the proposed scope rather than only the headline price.
Before starting, agree the commercial treatment of source code, third-party services, licences, ongoing hosting, and support. A useful brief does not remove every unknown. It makes the known requirements visible and gives the remaining questions a place in the plan.
