In a textbook, requirements arrive as a neat numbered list. In real life they arrive as one vague sentence from someone in a hurry: "We need an app where people can order food." Everything else, you have to dig out.
This lesson is about how to dig, and how to sort what you find into two kinds of requirement that shape a design very differently.
Two kinds of requirement
Functional requirements say what the system does. Non-functional requirements say how well it has to do it.
For Tiffin:
| Functional (what) | Non-functional (how well) |
|---|---|
| Customers can search restaurants | Search results in under 300 ms |
| Customers can place an order | No accepted order is ever lost |
| Customers can pay online | Never charge a card twice for one order |
| Restaurants see new orders | New orders reach the kitchen within 10 seconds |
| Customers track their rider | Rider position is at most 15 seconds old |
A quick test: if you can phrase it as "the user can...", it's probably functional. If it has a number, an "always", a "never", or a "fast", it's probably non-functional.
The usual non-functional categories
Most non-functional requirements fall into a handful of buckets. Running through them is a good way to find the ones nobody mentioned:
- Performance - how fast? (latency: how long one request takes) and how much? (throughput: how many requests a second)
- Scale - how many users, requests, rows, cities, now and in two years?
- Availability - how much downtime is acceptable, and when? Ten minutes at 4am is not ten minutes at 8pm on a Saturday.
- Durability - can data ever be lost? Which data?
- Consistency - can someone ever see stale data? Which data, and how stale?
- Security and privacy - who can see what? What do laws require?
- Cost - what's the budget?
- Operability - who runs it? How do you deploy, monitor, debug it?
Why non-functional requirements drive the design
Here's a thought experiment. Take two apps with exactly the same functional requirements: "users can post a short message, and see posts from people they follow."
- App A is an internal tool for a 40-person company.
- App B is Twitter.
The functional requirements are identical. The designs couldn't be more different. App A is one server and one Postgres table. App B is one of the hardest distributed systems problems there is. The difference is entirely non-functional: scale, latency and availability.
That's why experienced engineers spend most of a requirements conversation on the non-functional side. The functional list tells you which features to build. The non-functional list tells you which architecture to build.
How to find them
People rarely volunteer non-functional requirements, because they assume them. Nobody says "and please don't lose orders". They'd just be furious if you did. Your job is to ask.
Ask about the worst moment
"What's the busiest time of the week?" For Tiffin, the answer is Friday and Saturday dinner, maybe a cricket final. Design for that moment, not the average.
Ask what happens when it goes wrong
"If the app is down for 5 minutes at 8pm, what happens?" Customers order from a competitor. Restaurants lose sales and complain. That tells you availability at dinner time is a business requirement, not a nice-to-have.
"If a customer sees a menu price that's 2 minutes old, does it matter?" Probably not much. "If they're charged twice?" Absolutely. Now you know where you need strong guarantees and where you can relax.
Ask for numbers, then sanity-check them
"How many orders a day?" If they say "millions", ask "today, or in three years?" Teams often describe the dream, not the launch. Design for the next 12-18 months with room to grow, not for the dream.
Ask who else cares
The product manager cares about features. Finance cares about refunds and reconciliation. Legal cares about where customer data is stored. Support cares about being able to look up an order. Each one is a source of requirements.
Sort the requirements
A clinic owner gives you this wish list. Which are functional, which are non-functional, and which hidden non-functional requirement is she assuming without saying it?
- Patients can book an appointment online.
- The booking page should be quick.
- Doctors see their schedule for the day.
- Two patients must never get the same slot.
- Patients get an SMS reminder the day before.
Show one answer
Functional: 1, 3 and 5. Non-functional: 2 (performance, though "quick" needs a number, say under 2 seconds) and 4 (consistency, and the most important line on the list).
Hidden ones: patient data must stay private (security and possibly law), and bookings must never be lost (durability). She also probably assumes the system works during clinic hours without anyone babysitting it (availability and operability).
Make them testable
"Fast" isn't a requirement. "Search returns in under 300 ms for 99% of requests" is. The difference: you can test the second one, and you'll know when you've met it.
A good non-functional requirement usually has three parts:
- What is measured (search latency, order loss, rider position age)
- The target (under 300 ms, zero, under 15 seconds)
- How often it must hold (for 99% of requests, during dinner hours, always)
That third part matters. "Under 300 ms" for every request is far harder and more expensive than "under 300 ms for 99% of them". A number like "for 99% of requests" is called a percentile: the p99 latency is the time that 99% of requests finish within. We'll come back to percentiles in Module 4 and uptime targets in Module 18.
Write down what you won't do
The last part of requirements is the list of things that are out of scope. For Tiffin's first version:
- One city only.
- No scheduled orders ("deliver at 7pm tomorrow").
- No group ordering.
- Riders are assigned by a person in the operations team, not automatically.
This list does two jobs. It stops the design from quietly growing to cover everything, and it makes the trade-offs visible: everyone agreed that automatic dispatch can wait. When it's needed, it becomes a new requirement and the design changes with it.
What to remember
- Functional requirements say what the system does. Non-functional requirements say how well.
- Non-functional requirements decide the architecture. Same features, different scale, completely different design.
- People rarely state non-functional requirements. Ask about the busiest moment, what happens when things fail, and who else cares.
- Make each one testable: what is measured, the target, and how often it must hold.
- Write down what's out of scope. It keeps the design honest and the trade-offs visible.