How to define requirements in system design

Meera’s whole instruction to Arjun fits on one sticky note: “Make it hold at noon.” Arjun spends the afternoon drawing eleven boxes and comparing databases.

The city league’s offer is firm: SeatJaldi will sell the Pune Monsoon T20 Cup final at the 40,000-seat stadium, with tickets from ₹799 to ₹4,999. The sale opens at noon. Today, the app runs on one ₹1,200-a-month server.

At six, Meera asks one question: “Which of your boxes makes sure two people never get the same seat?” Arjun stares at his drawing. None does, and with no list to check it against, he cannot say if it is good or bad.

So they write a one-page list and stick it on the wall. Reading it aloud, Meera stops at “the seat map opens in under 2 seconds” and “the app stays up through the noon rush”. Arjun asks, “Aren’t those both fast?” Meera is not sure.

List what the system must do, how well it must do it, and what you are not building. Then read the list back to whoever asked.

• Must do: the jobs, such as pick a seat and pay.
• How well: how fast, how often up, how correct.
• Not building: ideas you say no to, on purpose and in writing.

Arjun was like a man who tours ten halls before saying how many guests are coming. You have seen apps do the same: a bus-booking app takes your money, then says the seat is gone. Nobody had written “never sell a seat twice”.

A food app is quick on home Wi-Fi but spins for ten seconds on a patchy network. Someone tested “it works”, but nobody wrote “it works on a slow phone”.

Lesson 1 gave four design-review steps. Here is its first step, written out in full.

1. 1

   Ask who and how many

   For SeatJaldi: cricket fans, far more than today’s 100 members, all arriving at noon.

2. 2

   Write the must-dos

   One line per job.

3. 3

   Write the how-wells

   How fast, how often up, how correct.

4. 4

   Write the not-building list

   Name the ideas you are saying no to, so nobody builds them by accident.

5. 5

   Read it back

   Fix anything Meera hears differently.

A functional requirement is what the system does, and a non-functional requirement is how well it does it. Think “300 guests” versus “the AC works”.

A hall with 300 chairs and a broken AC is the wrong hall. Four how-well words come up often. The first asks: is it there when fans need it?

For SeatJaldi, the app must answer all through the noon sale. The second word asks how long a fan waits after a tap.

Meera’s line: the seat map opens in under 2 seconds on a slow 4G phone. The third word is about right answers.

Its worst failure at SeatJaldi has its own name.

The last word is about keeping what you saved: a paid booking must survive a crash.

Out of scope means a thing you decide, on purpose and in writing, not to build this time. Harpreet said no to the pool before booking, so he never paid for one.

SeatJaldi parks two ideas: chat and an offline mode. Neither decides whether 40,000 seats sell at noon. Parked is not forgotten: the list keeps each idea and why it waits.

Constraints go on the page too. They are the limits you cannot change, like Harpreet’s budget, and they rule out designs. SeatJaldi has two people, a ₹1,200-a-month server, Meera’s ₹6 lakh of savings, and the date of the final.

A requirement is only useful when you can test it, so put a number or a named moment next to every how-well word.

Harpreet’s “good food” is too vague to check. “Food served soon after the guests sit” is better, but it still needs a number the caterer can be held to.

A designer checks six:

• Availability: up for which window?
• Latency: how many seconds, on which network, for how many taps out of 100?
• Consistency: which answers must never be wrong?
• Durability: which data must survive a crash?
• Cost: how many rupees a month?
• Operability: can two people run and fix it?

Not every part needs the same bar. Who owns seat A12 must be exactly right. The “seats left” count can lag a few seconds.

These words pull against each other and against cost. To make sure no seat sells twice, two fans tapping the same seat must take turns, which can slow a tap at noon. So write both lines and choose on purpose which wins.

A worked example: “99.9% availability”. A 30-day month has 30 × 24 × 60 = 43,200 minutes. The allowed 0.1% is 43,200 × 0.001 = 43.2 minutes down a month.

That sounds strong, but one 10-minute outage at noon stays inside it and wipes out the sale. So name the window: “up for the whole sale”. For a short sale, count taps, not minutes: “at least 999 of every 1,000 booking taps succeed from noon to sell-out”.

Measure speed where fans feel it: on the phone, from the tap. That time includes finding the server and connecting to it, which the server’s own clock does not count.

• Ask whoever wants it built, often a product manager: who uses it, and how many?
• When are they busiest?
• What must never go wrong?
• What can wait?
• What is the budget, and the date?
• How will we know it worked?

Try it yourself

1. 1

   Pick an app

   A bus-pass app: riders buy a monthly pass and show a QR code to the conductor.

2. 2

   Write 3 must-dos

   Each starts with “The rider can”.

3. 3

   Write 3 how-wells

   Cover latency, durability and availability, each with a number or moment.

4. 4

   Park one idea

   Name 1 thing the first version skips.

5. 5

   Read it aloud

   Rewrite any line two people could read two ways.

• Must do: the rider can choose a route and a month, pay by UPI, and open a QR pass.
• How well: the pass opens in under 2 seconds on slow 4G. A paid pass is never lost, even if a machine crashes. The app answers all day on the 1st of the month, when most riders renew.
• Not building: loyalty points.
• You got it right if every how-well line has a number or a named moment, and one idea is parked.

“Will it hold at noon?” was too vague to answer. Split into written lines, it became a list a design can be checked against.

Arjun holds his drawing beside the wall page and finds the gap at once: nothing guards “no seat sold twice”. From now on, Meera works like Harpreet’s hall manager, reading the list back before anyone draws a box.

One doubt stays on the wall. “Fast” already has a name, latency. But “survive the rush” is about many people at once, and nothing on the wall counts the crowd. What is that called?