Section 2: Promises a Kitchen Can Keep - Requirements: Functional & Non-Functional
Executive Summary: This section converts Section 1's clarifications into a contract: functional requirements that trace to Maya's order #1042 and Marco's 86 board, and non-functional requirements stated as numbers a test could verify — menu in 300 ms, checkout in 2 s, an 86 visible everywhere within 30 s. We draw the out-of-scope line with a reason per exclusion, defend two deliberately "slow" targets against pushback, and name the tension — freshness versus cheapness, honesty versus sales — that every later section must resolve.
The clarification phase is over, and the interviewer squares the page: "Okay — so what exactly are we building?" Resist the urge to recite features. What they want to see is whether you can write promises that can be measured. "The app should feel snappy" is decoration; "the menu renders in under 300 milliseconds at p99" is a commitment a test can verify and an engineer can be paged on. For a system this small, the requirements section is where most of the scoring happens.
The Functional Contract: What Maya and Marco Can Hold You To
Every requirement below traces to a moment in the running example. If it can't point to a person who needs it, it's a feature wish, not a requirement.
| # | Requirement | Who hits it in the story |
|---|---|---|
| F1 | Browse the menu with live availability — presets and ingredients, anything 86'd greyed out | Maya at 12:10; every open cart at 12:35 |
| F2 | Customize presets and build-your-own — remove, add, or change quantity; BYO composes from scratch | Harvest Cobb minus blue cheese, plus avocado, double chicken |
| F3 | Cart — hold the in-progress order; survive a refresh; never hold a price as truth | Maya between 12:10 and 12:11 |
| F4 | Server-priced checkout — the server computes $17.45 from the menu version; the client never sends money; payment via external PSP | Order #1042: 11.95 + 2.00 + 3.50 |
| F5 | Order lifecycle with two status views — customer: "in the kitchen, ready ~12:32"; kitchen: a prep queue in promise order | Maya's lock screen; Marco's tablet |
| F6 | The 86 toggle — kitchen staff mark an ingredient unavailable (and restore it) in one tap, audited | Marco, avocado, 12:35 |
| F7 | Honest promise times — the quoted pickup time derives from the actual queue, not a constant | "Quoted 12:32" with 40 salads ahead |
| F8 | Versioned menu administration — managers publish new menu versions; prices change by publishing, never by editing | Menu v47 behind everything above |
| F9 | Nutrition and allergen display + filter — computed per configured salad, labeled "prepared in a shared kitchen" | Maya's dairy allergy |
F6 and F7 are the requirements most candidates omit — and the ones that encode the restaurant rather than the app. A menu, a cart, and a checkout describe every e-commerce system ever built; the 86 board and honest promise times describe this one.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson