Requirements: the questions that decide the design

Part of the free System Design course on LogicWiz, in the chapter: How to run a design interview. The interactive whiteboard exercises and simulations run in the app.

Week 1, Day 3: The five minutes that save the other forty

"Kabir said: a vague answer to 'how fast?' is worse than a slow system."

From Meera's notebook

Two kinds of requirement

Kabir gave Meera one sheet of paper with two columns.

Functional requirements are what the system does: "a user sees the status of their order", "a rider's location updates on the map". These are verbs. They tell you which APIs exist.

Non-functional requirements are how well it does it: how fast, how available, how consistent, how large. These are adjectives and numbers. They tell you which components you need.

Most candidates list functional requirements and stop. But two systems can do the same things and still look nothing alike. A school attendance tracker and a UPI payment switch both record events and show them back. Their designs share almost nothing, because their non-functional columns differ.

The questions, in the order to ask them

You do not need a long checklist. Five questions cover most of it:

  1. Who uses it and how many? (Drives scale. "Roughly how many daily users?")
  2. What are the core actions? (Drives the API. Pick the two or three that matter and defer the rest out loud.)
  3. Reads or writes? (Drives caching and storage. On SwiftKart, order status is read about five times for every update.)
  4. How fresh must the data be? (Drives consistency. "If the status is 5 seconds old, is that OK?")
  5. What happens if it goes down? (Drives availability. A payment switch cannot; a profile page can.)

💡 Tip: Say your assumptions out loud when the interviewer will not decide: "I'll assume 2 million daily users and 5-second freshness. Tell me if that's wrong." Stating a number is better than asking five more questions.

Why "how fast?" is not a requirement

"Fast" is not testable. "p99 under 300 milliseconds" is. (p99 means 99 out of every 100 requests are faster than that number.) "Highly available" is not testable. "99.95% available, about 4 hours of downtime a year" is. When Meera wrote "low latency" in her first design, Kabir circled it: "Low compared to what? Whatever number you pick, that is the number the cache has to meet."

A useful habit: write each non-functional requirement as a number with a unit.

A worked example: five questions, forty seconds

Here is how the opening of the order-tracking interview sounds when it goes well.

Meera: "Who uses this page, and roughly how many?" Kabir: "Customers. Say 2 million a day, and more during a match."

Meera: "Is it mostly people checking status, or mostly the system updating it?" Kabir: "Checking. Each customer opens it about ten times a day. Orders change status about four million times a day in total. So reads outnumber updates roughly five to one."

Meera: "If the status is a few seconds old, is that acceptable?" Kabir: "Five seconds is fine. A wrong status is not."

Meera: "And if the page is down?" Kabir: "Customers phone support, and that costs real money. Aim high."

In forty seconds she has a user count, a read-heavy mix, a freshness budget and an availability target. Each one will justify a specific component later. The read-heavy mix is why a cache may earn its place on the board. "A wrong status is not" acceptable, so any cached status must be refreshed whenever the order changes. It must never be left to lag behind.

Asking the questions is part of the test

Many candidates think, "The interviewer will tell me the requirements." So they wait to be handed the problem. In real work and real interviews, the requirements are deliberately vague. Whether you ask the right questions is part of what is being graded. An interviewer who answers every question patiently is not wasting your time; they are watching what you decide to ask.

Scoping out loud

You cannot design everything in 45 minutes, so say what you are leaving out: "I'll cover live status and delivery ETA. I'll skip payments and promotions unless you want them." That sentence takes five seconds and shows judgement.

⚠️ Warning: Do not defer the hard requirement. If "must survive the IPL final" is the interesting one, you cannot scope it out. Cut breadth, never the difficulty the interviewer came to see.

📌 Summary: Functional requirements say what it does; non-functional ones say how well, as numbers with units. State assumptions as numbers. Scope out loud, but never cut the hard part.

What Meera learns next

Requirements give you numbers to estimate with. Module 2 turns "2 million daily users" into requests per second, gigabytes and a clear idea of which components you need.

Check your understanding

  1. Which of these, written for the SwiftKart tracking page, is a non-functional requirement?
  2. Meera's first draft says "The page must be fast and highly available." What would Kabir say?
  3. You ask how many people use the page and the interviewer says, "Up to you." What is the strongest reply?
  4. You have 45 minutes to design order tracking that must survive the IPL final. What should you say you are leaving out?