Depending on the circumstances, I tend toward outcome-based documents that help define the what more than the how. The simplest form is to specify one or more

Depending on the circumstances, I tend toward outcome-based documents that help define the what more than the how. The simplest form is to specify one or more of each of these: goals, non-goals, and anti-goals. Goals are things like: user data entry is appreciably faster. Contrast that with "how" statements like "all user data entry will be on one screen" which only hints at the true motivation and may end up being in tension with the true motivation. Non-goals are either things that are out of scope (e.g., we will not be introducing new fields to capture during this project) or things that would be fine if they happened as a side-effect but aren't guaranteed (e.g., we will not be putting effort into reducing our cloud spending as part of this project). Anti-goals are things that you explicitly want to prevent from happening — we do not want to purchase new servers for this project. These "anti-goals" are often non-functional goals in more formal frameworks. If you are uncertain about the utility of a project, starting with a "motivation" section can be a helpful exercise.