Functional and non-functional requirements
What it must do, and how well.
Functional requirements are what the system does: customers can place an order, restaurants can accept or reject it. Non-functional requirements are how well it does it: how fast, how available, how safe, how much it may cost. Teams often write the first list carefully and forget the second, then discover too late that the system works but is too slow, or goes down every Friday night.
Nobody hands you a tidy list. You find requirements by asking. "How many orders per day?" gives you load. "Can an order be placed twice by accident?" gives you correctness. "What if the site is down for a minute?" gives you availability. "Where do customers live?" tells you about latency and legal rules on data.
The most common non-functional requirements are latency (how long one request takes), throughput (how many requests per second), availability (what fraction of time it works), durability (data is never lost once confirmed), consistency (everyone sees the same data) and cost. A useful requirement carries a number: "fast" is a wish, "95 percent of searches return within 300 ms" is a target you can test.
Your turn
List one functional and one non-functional requirement for a clinic booking site.
Stuck? The second should include a number or a promise.
What to remember
Functional = what the system does.
Non-functional = how well it does it.
Ask questions to uncover both, and attach numbers.
Know the common ones: latency, throughput, availability, durability, consistency, cost.
State which requirement wins when they conflict.