Card 03/ 09
Requirements Example: A Food Delivery App
Browse, order and track the courier, in under 200 ms, without losing an order.
Sorting requirements into functional and non-functional is easiest to see on a real product. Here it is applied to a food delivery app, where a hungry customer is waiting on every screen.
| Requirement | Kind | Why |
|---|---|---|
| Customers browse restaurants near them | Functional | An action a customer takes |
| Customers place and pay for an order | Functional | An action a customer takes |
| Customers track the courier on a map | Functional | A feature, even though it updates live |
| Restaurant pages load in under 200 ms for 95% of requests | Non-functional | How quickly browsing must respond |
| No confirmed order is ever lost | Non-functional | How safely ordering must keep its data |
| The app stays usable at the Friday evening peak | Non-functional | How much load the features must survive |
What to notice. Every non-functional row qualifies a functional one. The 200 millisecond target, written "200 ms", is about browsing. The promise never to lose an order is about placing one. The peak requirement is about all three. A non-functional requirement with no behaviour to qualify is usually a slogan, such as "the app should be modern".
Notice too which qualities rank highest. A customer is waiting with the app open, so speed matters on every screen, and losing a paid order is the worst failure of all. Those two lines will shape most of the design: a cache for browsing, and a database that confirms every order is stored before the app says it is.
So when you sort a list like this one, the order of importance in the second column is as much a decision as the sorting itself.
← → move through sections and cards