Requirements: what to ask first

The first five minutes of a design round show the interviewer how you think. They give you one short sentence, such as "design a food-ordering app". Then they watch. Do you ask questions, or do you start to draw?

Everything after this step depends on it. If the requirements are wrong, even a very good drawing is wrong. A food app for 500 people and a food app for 50 lakh (5,000,000) people are not the same design.

A weak answer says: "It should be fast, it should always work, and it should handle many users." Every system should. These words do not change the design. A strong answer gives each need a number: "The menu opens in under 2 seconds. The app may be down for at most 1 hour in a month. At 8 pm the app gets 1,400 requests per second."

At SDE-1 level you should ask the main questions and write the numbers down. At SDE-2 and SDE-3 level you should do more. Choose the numbers yourself when the interviewer does not give them. Say them aloud. Show how each number changes the design.

Think about booking a bus for a wedding trip. The first sentence is: "Take 40 people from Pune to Goa." That is what the bus must do. A good travel agent asks more. When must you arrive? Must the bus have air conditioning? What is the budget? What if the bus breaks on the way? These answers say how well the bus must do its job. With them, the agent can choose the right bus.

A requirement is one need of a system, written as a clear sentence. In lesson 1 you met the two kinds of needs. Now they have names.

• A functional requirement says what the system does. It is an action: "A user can place an order." Write three to five of them.
• A non-functional requirement says how well the system does it. It is about numbers: how many users, how fast, how often it may fail.

You also say what you will leave out, which is called out of scope. For example: "I will not design the payment page." Say it aloud and ask if that is fine. This saves time for the parts that matter.

Three numbers to ask for

1. Scale: how much traffic. Ask how many users, and when they are busiest. Turn it into requests per second. You did this in lessons 1 and 2: requests divided by seconds.
2. Speed: how fast. Ask how long the main screen may take to open, for example "under 2 seconds".
3. Failures: how much downtime, and what data must never be lost. Downtime is the time when users cannot use the system. Ask how many minutes per month are fine. Ask which data must never be lost or wrong.

Three words that interviewers use

Interviewers often use three words. Each one means a group of non-functional requirements. Make each one concrete with a number or a plain fact.

• Reliability means that the system keeps doing the right thing, even when something goes wrong. A server may break, a user may send wrong input, or a bug may appear. It has two parts: the system keeps running, and the data stays right. Its numbers: the downtime allowed per month, and "a confirmed order is never lost".
• Scalability means that the system still works well when traffic grows. Its numbers: the traffic now, and the traffic after growth, for example "3 times more in one year".
• Maintainability means that other engineers can understand, fix and change the system without fear. There is no standard number for it. A useful fact to agree on is the size of the team that must run the system, for example "4 engineers".

Speed is not one of the three words. It is still a number you ask for. A system that is fast for 100 users can be slow for 1 million.

What if the interviewer gives no numbers?

Some interviewers say: "You decide." Do not wait and do not guess in silence. An assumption is a number that you choose and say aloud, because you do not know the real one. Say each number as an assumption: "Assumption: 5 lakh orders in the busiest 2 hours. Is that fine?" Then write it down. The interviewer can correct you.

You are asked to design a food-ordering app. We look at a busy evening.

Assumptions (made up to teach with, not real traffic):

• 5 lakh (500,000) orders arrive in the busiest 2 hours of an evening (8 pm to 10 pm). 1 lakh = 100,000.
• One order comes with about 20 requests: the restaurant list, a menu, the cart, the order itself, and tracking.
• One server answers 500 requests per second (as in lesson 1).
• 4 engineers will build and run the app.
• Orders will grow 3 times in one year.
• A month has 30 days.

Step 1: functional requirements. Three actions, and what we leave out.

1. A user sees restaurants and their menus.
2. A user places an order.
3. A user tracks the order.

Out of scope: the payment page, and the apps for restaurants and delivery partners. We say this aloud.

Step 2: scale.

• 2 hours = 2 x 60 x 60 = 7,200 seconds
• Requests = 500,000 orders x 20 = 10,000,000
• Requests per second = 10,000,000 / 7,200 = 1,389 (rounded from 1,388.9)
• Orders per second = 500,000 / 7,200 = 69 (rounded from 69.4)

Step 3: speed. Assumption: the menu opens in under 2 seconds.

Step 4: failures. Assumptions: the app must still work if one server breaks. It may be down for at most 60 minutes per month. A confirmed order is never lost.

• Minutes in a month = 30 x 24 x 60 = 43,200
• 60 minutes of downtime = 60 / 43,200 = 0.0014, which is 0.14% of the month

Step 5: scalability and maintainability.

• Traffic after growth = 3 x 1,389 = 4,167 requests per second
• Team: 4 engineers. A design with many different parts is too much for 4 people. We prefer few parts.

Step 6: see how the numbers change the design. This is why we asked.

• Servers to handle the traffic now = 1,389 / 500 = 2.78, so 3 servers.
• 3 servers can answer 3 x 500 = 1,500. If one breaks, 2 x 500 = 1,000 is left, which is less than 1,389. The app must still work when one server breaks, so we need 4 servers (3 x 500 = 1,500 are left after one breaks).
• After growth: 4,167 / 500 = 8.3, so 9 servers. With one extra server in case one breaks: 10 servers.
• One server would be 1,389 / 500 = 2.8 times too busy.

Here is the answer to the predict box. "Fast and reliable" is not a requirement yet, because it has no number. Two engineers can read it and build two very different systems. The fix is to ask for a number for each word:

• Asking first solves: building a system of the wrong size. In the example the answers led to 4 servers now and 10 servers after growth.
• It costs: time. The clock in lesson 2 gives about 5 minutes to this step. If you ask 20 questions, you use the time you need for deep dives.
• I would change it when: the interviewer gives all the numbers. Then confirm them in one sentence and move on. If the interviewer says "you decide", I would state my assumptions quickly and go on.
• Harder numbers cost more. Asking for downtime of 5 minutes per month, and not 60, needs more servers and more care. Choose a number from what a failure costs the business. An hour of failure in a lunch-ordering app for one office is small. The same hour at 8 pm for a big delivery app is a lot.
• Numbers also trade against each other. Four servers instead of three costs 4 / 3 = 1.33 times more (33% more), and buys the ability to survive one broken server.

"Requirements are the list of features." A feature list is only the functional part. In the example, the three actions did not decide how many servers to use. The numbers did: 1,389 requests per second led to 4 servers. Features say what to build, and numbers say how big.

"If the interviewer does not give numbers, I should not guess." The interviewer often wants you to guess. A system cannot be designed without a size. State an assumption with a number, ask "is that fine?", and write it down. A stated assumption is a strong answer. A silent guess is a weak one.

"The harder the numbers, the better. I should ask for no downtime at all." Every hard number costs money and effort. No system is never down. Ask what an hour of failure costs, then choose the number that matches. Asking for the strongest number on every line shows that you do not see the cost.

1. What is the difference between a functional and a non-functional requirement? Give an example of each for a food-ordering app. Then say what reliability, scalability and maintainability mean, in one plain sentence each.
2. A college app is used by 90,000 students to check a new timetable. Each student makes 5 requests in the first 10 minutes. One server answers 500 requests per second. (a) How many requests per second arrive? (b) How many servers handle the traffic? (c) How many servers do you need if one may break and the site must still work?
3. The interviewer says: "Design a ticket-booking site. You decide the numbers." What do you do in the first minutes?