Requirements before boxes
Functional and non-functional, separated on purpose, because the second list is where every interesting decision comes from.
Functional requirements are what it does: post a message, see a feed, upload a file. They are usually easy and usually agreed. Non-functional requirements are how well: fresh within how long, available how often, correct under what concurrency, responsive at which percentile, for how many people, at what cost. Two systems with identical functional requirements and different non-functional ones are different systems.
A non-functional requirement without a number is decoration. "Fast" is not a requirement; "the feed renders in under a second at the ninety-fifth percentile on a mid-range Android over 4G" is a requirement, and it rules things out immediately, which is what requirements are for. Note the percentile: designing to the average is designing for the users who were already happy.
In almost every problem, one requirement is load-bearing and the rest follow. If a chat must show messages in the same order to everyone, that single line dictates the write path. If a feed may be thirty seconds stale, an entire tier of complexity is now optional. Find that requirement early and say so out loud, because the rest of the design hangs from it.
You should now be able to
- Split requirements into functional and non-functional
- Write a non-functional requirement with a number in it
- Identify the requirement that is doing all the work
Loading…