Clarifying requirements and scope

Low-level design prompts are short on purpose: “design a parking lot”, “design a library”. The rules that make a design right or wrong are missing. Who pays how much? What happens on a tie, after midnight, when something is missing or done twice? Until those rules are known, no design can be checked, and an interviewer may hold some back to see whether you ask.

Clarifying is the first step of the answer framework. Its output is small and concrete: a short list of numbered, testable requirements and an equally explicit list of what is out of scope, in about five minutes.

Ask about behaviour, not technology

Useful questions are about what the system does and the rules it follows. A checklist to run through:

• Actors and actions. Who uses it, and what can each of them do? (Driver, attendant, administrator.)
• Rules and limits. How many, how much, how long, and exactly where the boundary is: is 60 minutes one hour or two?
• Failures. What if the thing is missing, full, already done, expired or paid twice?
• Money and time. Units and rounding, time zones, stays that cross midnight, periods that start or end.
• Lifecycle. Which states does an object go through, can a step be undone, does anything expire?
• Qualities inside the program. May two threads use it at once? How much work may one operation do? Must the results be repeatable in tests?

Questions about databases, clouds or services belong to a high-level design round. In an LLD round they use up time and say nothing about the classes.

Functional and non-functional requirements

A functional requirement says what the system does: “a car pays 40 for each started hour”. A non-functional requirement says how well, or under what constraints, it does it. In low-level design these qualities are local to one program:

• Determinism: the fee calculator takes the time as an argument instead of reading the clock, so a test can choose any moment.
• Cost of an operation: pricing a stay takes the same few steps whatever its length, with no loop over hours.
• Thread safety: two exits paying the same ticket at the same moment cannot both succeed.
• Memory bounds: a rate limiter keeps a fixed amount of data per user, not every request it has seen.

Good requirement guides keep both kinds and ask that each one can be verified. NASA’s checklist for requirements, for example, asks whether each requirement is uniquely numbered, whether it states what is needed rather than how to build it, and whether a test, demonstration, inspection or analysis can show that it is met. It lists words such as “fast”, “user-friendly” and “flexible” as ones to avoid (NASA Systems Engineering Handbook, Appendix C).

A worked clarification: parking fees

Prompt: “Design the fee calculation for a parking lot.” Here is a five-minute exchange, condensed:

1. Which vehicles? Cars and motorcycles. A ticket at the entry records the type and the time.
2. How is the fee counted? Per started hour: car 40, motorcycle 20. One minute into an hour counts as the hour.
3. Is a short stop free? Up to 15 minutes, yes. A longer stay is charged from its first minute.
4. Is there a maximum? Yes: each started 24-hour block costs at most 250 for a car and 120 for a motorcycle.
5. What if a stay crosses midnight? Nothing special; the blocks are counted from the entry time.
6. A lost ticket? A flat 500.
7. What can go wrong at the pay desk? An unknown ticket, a ticket that is already paid, an exit time before the entry time. Each is refused with its own message.
8. Payments by card, monthly passes, several lots? Not now.

The result is written down at once, numbered, one rule per line:

• R1 A ticket records the vehicle type (car or motorcycle) and the entry time.
• R2 Each started hour costs 40 for a car and 20 for a motorcycle.
• R3 A stay of 15 minutes or less costs nothing; a longer stay is charged from its first minute.
• R4 Each started 24-hour block, counted from the entry time, costs at most 250 for a car and 120 for a motorcycle.
• R5 A stay that crosses midnight is one stay; nothing restarts at midnight.
• R6 A lost ticket costs a flat 500, whatever the stay.
• R7 These are refused, each with its own message: an unknown ticket, a second payment of a ticket, an exit time before the entry time.
• R8 (non-functional) The calculator never reads the clock; the times are passed in.
• R9 (non-functional) Pricing a stay takes the same few steps whatever its length.
• Out of scope: O1 how the money is collected (cash, cards, wallets); O2 monthly passes and reservations; O3 several lots and choosing a parking spot; O4 storage and hardware (barriers, cameras, ticket printers): everything stays in memory.

Out of scope is a requirement too. It stops you from building what nobody asked for (gold-plating), and it shows the interviewer that you saw those areas and left them out on purpose.

From requirements to tests

Here is a fee calculator and a pay desk written from R1 to R9. The comments name the requirement each constant or check comes from:

"""Parking fees, written from the lesson's requirements R1 to R9."""
from dataclasses import dataclass
from datetime import datetime, timedelta

RATE = {"car": 40, "motorcycle": 20}  # R2: per started hour
DAILY_CAP = {"car": 250, "motorcycle": 120}  # R4: per started 24-hour block
GRACE = timedelta(minutes=15)  # R3
LOST_TICKET_FEE = 500  # R6
HOUR, DAY = timedelta(hours=1), timedelta(hours=24)


class FeeError(Exception):
    """A payment that the rules refuse (R7)."""


def started_hours(duration):
    whole, rest = divmod(duration, HOUR)
    return whole + (1 if rest else 0)


def fee(kind, entered, left):
    """The fee of one stay: the exit time is passed in (R8), and any stay costs the same work (R9)."""
    if left < entered:
        raise FeeError("exit before entry")
    stay = left - entered
    if stay <= GRACE:
        return 0
    full_days, rest = divmod(stay, DAY)
    last_block = min(started_hours(rest) * RATE[kind], DAILY_CAP[kind])
    return full_days * DAILY_CAP[kind] + last_block


@dataclass
class Ticket:
    number: int
    kind: str
    entered: datetime
    paid: bool = False


class PayDesk:
    def __init__(self):
        self.tickets = {}

    def issue(self, kind, entered):
        if kind not in RATE:
            raise FeeError(f"no rate for {kind}")
        ticket = Ticket(len(self.tickets) + 1, kind, entered)  # R1
        self.tickets[ticket.number] = ticket
        return ticket

    def pay(self, number, left, lost=False):
        ticket = self.tickets.get(number)
        if ticket is None:
            raise FeeError("unknown ticket")
        if ticket.paid:
            raise FeeError("already paid")
        amount = LOST_TICKET_FEE if lost else fee(ticket.kind, ticket.entered, left)
        ticket.paid = True
        return amount


if __name__ == "__main__":
    nine = datetime(2026, 1, 5, 9, 0)
    stays = [("car", 15), ("car", 16), ("car", 61), ("car", 7 * 60), ("car", 30 * 60),
             ("motorcycle", 125)]
    for kind, minutes in stays:
        amount = fee(kind, nine, nine + timedelta(minutes=minutes))
        print(f"{kind:<10} {minutes:>5} min  fee {amount}")
    late = nine.replace(hour=23, minute=30)
    amount = fee("car", late, late + timedelta(minutes=100))
    print(f"car 23:30 to 01:10 next day  fee {amount}")

    desk = PayDesk()
    ticket = desk.issue("car", nine)
    paid = desk.pay(ticket.number, nine + timedelta(minutes=80))
    print("ticket", ticket.number, "pays", paid)
    for number in (ticket.number, 7):
        try:
            desk.pay(number, nine + timedelta(hours=2))
        except FeeError as refusal:
            print("ticket", number, "refused:", refusal)

car           15 min  fee 0
car           16 min  fee 40
car           61 min  fee 80
car          420 min  fee 250
car         1800 min  fee 490
motorcycle   125 min  fee 60
car 23:30 to 01:10 next day  fee 80
ticket 1 pays 80
ticket 1 refused: already paid
ticket 7 refused: unknown ticket

Each requirement then becomes at least one test whose name starts with its number. A reviewer, or an interviewer, can read down the list and see that nothing was forgotten:

import sys
import time
import unittest
from datetime import datetime, timedelta

from parking_fee import FeeError, PayDesk, fee

NINE = datetime(2026, 1, 5, 9, 0)


def after(**duration):
    return NINE + timedelta(**duration)


class Fees(unittest.TestCase):
    def test_r1_ticket(self):
        """R1: a ticket records the vehicle type and the entry time"""
        ticket = PayDesk().issue("motorcycle", NINE)
        self.assertEqual((ticket.kind, ticket.entered), ("motorcycle", NINE))

    def test_r2_started_hours(self):
        """R2: 61 minutes are two started hours"""
        self.assertEqual(fee("car", NINE, after(minutes=61)), 80)
        self.assertEqual(fee("motorcycle", NINE, after(minutes=61)), 40)

    def test_r3_grace_period(self):
        """R3: 15 minutes cost nothing, 16 minutes cost one hour"""
        self.assertEqual(fee("car", NINE, after(minutes=15)), 0)
        self.assertEqual(fee("car", NINE, after(minutes=16)), 40)

    def test_r4_daily_cap(self):
        """R4: 7 hours are capped at 250; 30 hours cost 250 + 6 x 40"""
        self.assertEqual(fee("car", NINE, after(hours=7)), 250)
        self.assertEqual(fee("car", NINE, after(hours=30)), 490)

    def test_r5_midnight(self):
        """R5: 23:30 to 01:10 is one stay of two started hours"""
        late = NINE.replace(hour=23, minute=30)
        self.assertEqual(fee("car", late, late + timedelta(minutes=100)), 80)

    def test_r6_lost_ticket(self):
        """R6: a lost ticket costs 500, whatever the stay"""
        desk = PayDesk()
        ticket = desk.issue("car", NINE)
        self.assertEqual(desk.pay(ticket.number, after(minutes=20), lost=True), 500)

    def test_r7_refusals(self):
        """R7: an unknown ticket, a second payment and an exit before entry are refused"""
        desk = PayDesk()
        ticket = desk.issue("car", NINE)
        desk.pay(ticket.number, after(hours=1))
        cases = [
            ("unknown ticket", lambda: desk.pay(99, after(hours=1))),
            ("already paid", lambda: desk.pay(ticket.number, after(hours=2))),
            ("exit before entry", lambda: fee("car", NINE, after(minutes=-5))),
        ]
        for message, action in cases:
            with self.subTest(message):
                with self.assertRaises(FeeError) as refused:
                    action()
                self.assertEqual(str(refused.exception), message)

    def test_r8_time_passed_in(self):
        """R8: the times are passed in, so a test can use any moment"""
        far = datetime(2040, 6, 1, 9, 0)
        later = fee("car", far, far + timedelta(hours=3))
        self.assertEqual(later, fee("car", NINE, after(hours=3)))

    def test_r9_constant_work(self):
        """R9: a thousand ten-year stays are priced in well under a second"""
        start = time.perf_counter()
        for _ in range(1000):
            amount = fee("car", NINE, after(days=3650))
        self.assertEqual(amount, 3650 * 250)
        self.assertLess(time.perf_counter() - start, 1.0)


if __name__ == "__main__":
    suite = unittest.defaultTestLoader.loadTestsFromTestCase(Fees)
    unittest.TextTestRunner(stream=sys.stdout, verbosity=2).run(suite)

test_r1_ticket (__main__.Fees.test_r1_ticket)
R1: a ticket records the vehicle type and the entry time ... ok
test_r2_started_hours (__main__.Fees.test_r2_started_hours)
R2: 61 minutes are two started hours ... ok
test_r3_grace_period (__main__.Fees.test_r3_grace_period)
R3: 15 minutes cost nothing, 16 minutes cost one hour ... ok
test_r4_daily_cap (__main__.Fees.test_r4_daily_cap)
R4: 7 hours are capped at 250; 30 hours cost 250 + 6 x 40 ... ok
test_r5_midnight (__main__.Fees.test_r5_midnight)
R5: 23:30 to 01:10 is one stay of two started hours ... ok
test_r6_lost_ticket (__main__.Fees.test_r6_lost_ticket)
R6: a lost ticket costs 500, whatever the stay ... ok
test_r7_refusals (__main__.Fees.test_r7_refusals)
R7: an unknown ticket, a second payment and an exit before entry are refused ... ok
test_r8_time_passed_in (__main__.Fees.test_r8_time_passed_in)
R8: the times are passed in, so a test can use any moment ... ok
test_r9_constant_work (__main__.Fees.test_r9_constant_work)
R9: a thousand ten-year stays are priced in well under a second ... ok

----------------------------------------------------------------------
Ran 9 tests in 0.002s

OK

unittest treats every method whose name starts with test as a test, and with verbosity=2 it prints each test’s name and the first line of its docstring. The last lines load the tests of Fees and run them with a runner that writes to standard output (by default unittest reports on standard error). Loading the class directly also works where unittest.main() cannot find the tests by itself, as in this page’s browser runner; on your computer, python3 -m unittest -v test_parking_fee runs the same tests.

What each test pins down:

• test_r1_ticket: the ticket keeps the vehicle type and the entry time.
• test_r2_started_hours: 61 minutes are two started hours, at both rates.
• test_r3_grace_period: 15 minutes cost 0, and 16 minutes cost one hour.
• test_r4_daily_cap: 7 hours pay the cap; 30 hours pay the cap once plus 6 started hours.
• test_r5_midnight: 23:30 to 01:10 is priced as one stay of two started hours.
• test_r6_lost_ticket: a lost ticket costs 500, even after only 20 minutes.
• test_r7_refusals: each refusal raises FeeError with its own message, one sub-test each.
• test_r8_time_passed_in: a three-hour stay costs the same on any date, even years ahead.
• test_r9_constant_work: a thousand ten-year stays are priced in well under a second.

R9’s test has a generous margin on purpose: a calculation that loops over every hour would need millions of steps for those stays and fail it, while normal slowdowns of a busy computer or a browser would not.

Boundaries hide inside the rules

Most wrong answers are right in the middle and wrong at the edges. “Per started hour” is a typical trap: dividing the minutes by 60 with floor division rounds the hour down and undercharges every stay that is not a whole number of hours. The edge case is exactly 60 minutes, where both rules agree:

from datetime import timedelta

HOUR = timedelta(hours=1)


def hours_rounded_down(stay):
    return stay // HOUR  # the common mistake: a started hour is dropped


def hours_started(stay):
    whole, rest = divmod(stay, HOUR)
    return whole + (1 if rest else 0)


for minutes in (59, 60, 61, 125):
    stay = timedelta(minutes=minutes)
    down, started = hours_rounded_down(stay), hours_started(stay)
    print(f"{minutes} min: rounded down {down}, started {started}")

59 min: rounded down 0, started 1
60 min: rounded down 1, started 1
61 min: rounded down 1, started 2
125 min: rounded down 2, started 3

timedelta // timedelta gives a whole number rounded down, and divmod() gives that number and the remainder, so “add one when there is a remainder” counts started hours exactly, with no floating-point division. Whenever a rule has a number in it, test just below, at and just above that number.

Rules that are not stated at all are where follow-up questions come from. Listen for:

• Ties: two bids at the same price, two players with the same score.
• Crossing a boundary: a booking that spans midnight, a stay that starts on one tariff and ends on another.
• Failure halfway: what happens to a reserved seat if the payment fails afterwards?
• Repetition: the same request twice, a second cancellation, a retry after a timeout.

Key takeaways

• Ask about behaviour and rules (actors, limits, failures, money, time, lifecycle), not about technology.
• Write requirements down as you hear them, numbered (R1, R2 …), one rule each, with numbers instead of words such as “fast”.
• Non-functional requirements in LLD are local: deterministic time, the cost of one operation, thread safety and memory bounds.
• List what is out of scope; it is a decision too.
• Turn every requirement into at least one test named after it, and test both sides of every boundary.