Describe the job, not a feature
“We need a dashboard” is a proposed answer. “The team cannot see which requests are overdue” is a problem that can be investigated.
Name the people using it
List which decisions each person makes, what information they need and how often they use the system. Different roles require different views.
Find the source of truth
Which existing system owns customer details, invoices or project status? Avoid duplicating important records unless there is a compelling reason.
Collect real examples
A handful of typical cases, including exceptions, exposes requirements better than a long list of imagined features.
Agree on constraints
Access, security, personal information, integrations and hosting requirements need attention before development.
Define a small first version
Choose the minimum set of tasks that would make the software genuinely useful. Save uncertain ideas for a later decision informed by real use.
The best brief is written in the language of the work, not in technical jargon.