Describe the users and the job
List each user group, the task it must complete and the decisions it can make. “Administrators and customers” is not enough; distinguish who creates, reviews, approves, corrects and only views a record.
Name data and system boundaries
Identify the system that owns each important record, the fields that must move and the direction and frequency of exchange. Include privacy, retention and access constraints that affect design before an interface is promised.
Turn expectations into users, records, interfaces and observable acceptance.
Separate the first release from later ideas
State what must work at first acceptance and place useful but nonessential ideas in a later backlog. This prevents optional reports, roles and integrations from silently changing the delivery date and price.
Write acceptance in observable terms
Connect every requirement to an expected result and reviewer. Instead of “the portal is easy to use”, specify the user, starting state, action, expected record and evidence that confirms completion.