A product requirements document can be a pretty formal thing, used to hold teams accountable for what they eventually ship. An outline is not one of those. If your organization uses them, this initial outline may eventually evolve into an official requirements document. But here it’s intended as a tool to help you think, to form an idea of the product in your mind. Nobody outside your design team (very possibly a team of one) needs to see it.
This book makes extensive use of a hypothetical sample app, SnackLog, a tool for keeping track of purchases that you make throughout the day. Instead of reading a detailed description of the app, though, see how thoroughly you can understand the idea of the app by reading its initial requirements outline, shown in Figure 1.2.
Figure 1.2. Outlining the requirements and antirequirements of SnackLog, our example app
As you may have gathered, the whole point of SnackLog is to easily record casual purchases like coffee and parking, and not to be a full-blown money-management app. The need SnackLog serves is to track small cash purchases you make while you’re out and about and stop them from falling through the cracks of your full-fledged budgeting system.
Note that this requirements outline doesn’t mention anything about screens, navigation, or the details of how the features work. Instead, it tries to map out what the app needs to do; figuring out how can come later.