Start a software brief by showing how one piece of work moves through the business. A real form or spreadsheet is often the most useful example.
Follow a task through the business
Describe where a request starts, who checks it, what is recorded and how it is completed. Include the awkward cases: a duplicate entry, an incorrect amount, a cancellation or missing information. These details help us understand the rules the software needs.
List the records and permissions
Identify the records you keep and who can view, add, approve or correct them. Note any reports and exports staff rely on. If data already exists, explain where it is stored and whether it has been checked; migration needs its own plan.
Check the connections
List payment providers, SMS services, accounting tools or other systems that must connect. Tell us who controls those accounts and whether access is available. Include hosting, backups and the people responsible for running the software after handover.
Choose a first release you can test
Pick the workflow that would make the biggest difference first. Agree a few tasks staff can try with sample data, including corrections and permission checks. Keep later ideas in a separate list so they do not quietly change the first release’s price or schedule.



