Describe the current day
Explain who does the work, what starts it, which tools they open, and where information gets copied or lost. A screen recording or a walkthrough of a real process is often more useful than a long feature list. Remove personal or confidential information before sharing examples.
Name the problem and its owner
Write down the specific difficulty the project should address and the person who can confirm it has been addressed. Different teams may experience the same process differently. Identify the people who approve scope, provide access, test the build, and operate it after launch.
Separate the first release from the future
Group requirements into what the first usable release needs, what can follow, and what remains uncertain. A dependency such as access to a supplier API may be more important than a visible screen. Record these dependencies early so a schedule is based on actual constraints.
Bring the systems into the conversation
List existing tools, integrations, data formats, access restrictions, and migration needs. Explain which systems must remain. Include expected device use, accessibility needs, and the conditions in which people work. These details influence both interface design and architecture.
Define acceptance in observable terms
Replace “easy to use” with a task someone can perform and check. For example: an administrator can find a student, correct an attendance entry, and see the change in the relevant view. Include error states, permissions, and recovery, not only the successful path.
Plan the handover before the launch
Agree how source code, accounts, documentation, training, and support responsibilities will be handed over. Define which ongoing costs belong to the business and which services are included in the engagement. These decisions make the build easier to operate after the first release.