Start with the boundary
State the problem, the intended users and what the first release deliberately leaves out. A handover becomes difficult to estimate when every feature is equally essential. Identify the one workflow that must work before adding convenience features.
Connect screens to real actions
A screen inventory is useful, but screenshots alone do not explain behaviour. For each important action, describe the input, the validation, the successful result and the failure state. A “Save observation” button needs more detail than its location and colour.
Make data explicit
List the fields needed for the task, where they come from and who may change them. Mark required and optional fields. Use invented or redacted examples, never live employee or customer information. Record ownership, deletion and export questions rather than silently choosing a policy.
Write acceptance checks
For an illustrative observation workflow: “When a required field is empty, the record is not submitted and the interface identifies the missing value.” Another check could describe how a manager filters unresolved observations. These statements allow discussion of behaviour without prescribing a particular technology.
Leave a visible question log
Not every answer will be available. Separate agreed requirements from assumptions, decisions waiting for approval and known risks. Include a version date and a named decision owner in the eventual project document. A transparent open-question list is more useful than a specification that looks finished but hides uncertainty.
Editorial planning guidance. Examples are fictional; implementation decisions require project-specific assessment.
All field notes