Analyzing Functional Requirements, Constraints, and Change Points in LLD Prompts

Welcome. This course is organized around the decisions expected of an SDE-2 backend candidate: first designing clean object models, then applying patterns and production concerns, and later moving into distributed systems and AI-enabled backend features. We begin with the most easily skipped—and most interview-visible—skill: turning a vague design prompt into a specification you can defend.

In an LLD interview, “Design a parking lot” is not yet a design problem. It is an incomplete statement of intent. Before drawing classes or writing Python, you need to determine what the system must do, the rules it must obey, what is deliberately excluded, and which parts may plausibly evolve. By the end of this lesson, you should be able to produce a concise, confirmed requirements sheet in the first few minutes of an interview.

---

Why requirement extraction comes before classes

A premature class diagram often looks polished but solves the wrong problem. Consider the prompt:

“Design a parking lot system where cars are assigned spots as they arrive.”

Several meaningful decisions are hidden inside that single sentence:

• Does the lot support only cars, or motorcycles and trucks too?
• Is spot assignment simply “any available spot,” or must it prefer the nearest suitable spot?
• Does a vehicle receive a ticket, and is pricing in scope?
• Are entries and exits single-threaded simulation calls, or can simultaneous arrivals occur?
• Is persistence required, or does data live only in memory?
• Must the system support multiple lots, floors, gates, reservations, or EV charging?

None of those questions has a universally correct answer. The interviewer is checking whether you recognize ambiguity, select sensible scope, and make assumptions explicit rather than silently encoding them into classes.

The distinction between requirements categories matters:

Category	Meaning	Parking-lot example
Functional requirement	Observable capability or behavior	The system assigns an arriving vehicle to a compatible available spot.
Business rule	Condition governing valid behavior	A vehicle cannot occupy two spots simultaneously.
Constraint	Limit on the solution or operating environment	The initial version is in-memory and single-process.
Error behavior	Expected response to invalid action	Exit is rejected if a ticket is unknown or already closed.
Scope boundary	Explicitly excluded concern	Payments and physical gate hardware are out of scope.
Likely change point	A dimension expected to vary later	The spot-assignment policy may change from “first available” to “nearest available.”

A functional requirement says what the system accomplishes. A constraint says the conditions within which it must accomplish it. A change point says where today’s decision is likely to be replaced or expanded tomorrow.

The broader engineering process starts with stakeholder needs and progressively turns them into a stable set of system requirements. In an interview, you perform a deliberately compressed version of that process.

---

A five-minute clarification routine

Use a repeatable routine. It prevents the common failure mode of asking scattered questions until the interviewer interrupts with, “Please start designing.”

1. Restate the prompt as a system goal

Start with a brief paraphrase, then ask for confirmation:

“I’ll design the core domain logic for assigning vehicles to spots, tracking their stay, and releasing spots on exit. Before I model it, I’d like to confirm the supported actions, rules, and scope.”

This shows direction without prematurely committing to an architecture.

2. Ask only questions that alter the design

Group questions into four reliable buckets. You do not need to ask every question in every bucket; choose the few with the largest impact on state, behavior, public APIs, or object relationships.

Primary capabilities

Ask what users or other systems must be able to do.

For the parking-lot prompt:

• “Which vehicle categories must be supported initially?”
• “Should entry assign a spot automatically, or can an attendant choose one?”
• “Does the system issue a ticket and later calculate a charge?”
• “What information must be queryable: available spots, a vehicle’s location, ticket status, or pricing?”
• “Is there one lot, or are multiple floors or lots required?”

A useful test is: Could I express this as an operation with inputs, outputs, and a visible result? If yes, it is likely a functional requirement.

Rules and completion

Ask what determines success, failure, transition, or completion.

• “What makes a spot compatible with a vehicle?”
• “When no compatible spot exists, should entry be rejected or should the vehicle wait?”
• “When exactly is a spot considered free: on payment, on gate exit, or when an attendant closes the ticket?”
• “Are duplicate entry requests for the same vehicle rejected?”
• “Can a ticket be used more than once to exit?”

These questions reveal state transitions without requiring you to design the state model yet. They also uncover the validity conditions that later become invariants.

Error handling

Ask how invalid or exceptional operations behave.

• “Should invalid tickets raise an error, return a failure result, or be ignored?”
• “What happens if a vehicle tries to exit with an already closed ticket?”
• “How should the system respond to a request for a vehicle type that the lot does not support?”
• “Should assigning a currently occupied spot be impossible by construction, or should the operation explicitly report failure?”

For interview purposes, it is usually enough to agree on a consistent convention: invalid domain actions are rejected with a domain error or an explicit failure result. The exact Python exception hierarchy comes later.

Scope boundaries and operating constraints

Clarify what you are not building. This is not avoiding work; it is protecting the design from irrelevant complexity.

• “Should I model payments, taxes, refunds, and receipts, or only calculate a fee?”
• “Are physical gates, sensors, and license-plate recognition out of scope?”
• “Should this be an in-memory simulation, with no database or network API?”
• “Should I account for concurrent arrivals at several entrances?”
• “Do you want a fixed lot layout, or should floors and capacities be configurable?”

Some questions identify non-functional constraints. “Persist all tickets in a database” constrains storage. “Support concurrent entries safely” constrains correctness under concurrency. “Use a fixed three-floor layout” constrains configurability. In a conventional LLD interview, do not import HLD-scale concerns such as global traffic estimates unless the prompt raises them; establish whether concurrency and persistence are in scope, then design accordingly.

---

Turn answers into a designable specification

Questions by themselves do not demonstrate strong analysis. After receiving answers, convert them into short, testable statements and explicitly confirm them. A good requirements sheet is a working contract for the remainder of the interview.

For a scoped version of the parking-lot prompt, it might read:

In scope

1. The system supports cars, motorcycles, and trucks in one parking lot with multiple floors.
2. On entry, it assigns an available compatible spot and creates a ticket.
3. On exit, it validates the ticket, calculates a time-based charge, closes the ticket, and releases the spot.
4. The system can report availability by spot category.
5. A vehicle is rejected when no compatible spot is available.
6. Invalid, unknown, and previously closed tickets are rejected.

Constraints and assumptions

• The design is an in-memory simulation; persistence, user interfaces, and physical gates are excluded.
• One entry or exit operation is processed at a time.
• Payment authorization is excluded; fee calculation is in scope.

Open for later extension

• Different spot-assignment policies and pricing policies.
• Additional vehicle and spot categories.

This specification is better than notes such as “handle parking, tickets, fees” because every item has a clear outcome. For example, “calculate a time-based charge” can later be checked with a ticket having a known entry and exit time.

End the clarification phase with a direct confirmation:

“To confirm: I’ll focus on the in-memory domain model for allocation, tickets, availability, and time-based fees. I’ll exclude payments and hardware, and I’ll keep assignment and pricing replaceable because those policies may change. Does that scope match what you want?”

This brief checkpoint reduces rework and makes your later trade-offs legible to the interviewer.

---

Identify change points without overengineering

A change point is an aspect of the system whose rules, variants, or integrations are likely to change independently of the core domain behavior. Identifying one does not mean immediately applying a pattern, adding abstract base classes, or building for every hypothetical future. It means recording a credible variation so the next design decisions do not unnecessarily lock it in.

A practical question is:

“If this requirement changed next week, which rule would change while the rest of the system should remain stable?”

For the parking lot, likely answers include:

Requirement area	Current decision	Plausible future variation	Why it is a change point
Spot assignment	Select first compatible available spot	Select nearest spot, EV-priority spot, or accessible spot	The allocation rule varies independently from ticket creation.
Pricing	Charge by duration	Flat rate, weekend rate, lost-ticket fee, subscription discount	The fee rule changes without changing occupancy tracking.
Vehicle categories	Car, motorcycle, truck	EVs, buses, reserved vehicles	Compatibility rules may expand.
Notifications	No notification	Send receipt by email or SMS	A new side effect should not distort core exit logic.
Storage	In-memory	Database-backed ticket history	Persistence may change while domain rules remain the same.

By contrast, the following are usually not immediate change points:

• “Use Python.” This is an implementation choice, not a varying domain rule.
• “Reject an invalid ticket.” This is a stable correctness rule, not a policy with multiple plausible implementations.
• “Support exactly one lot” when the interviewer explicitly says it is fixed and extensions are out of scope. Mention it as a boundary, but do not create a multi-lot framework preemptively.

A useful discipline is to classify uncertain items into three outcomes:

1. Confirmed requirement: the interviewer has specified it; design for it.
2. Explicit assumption: you need an answer now, so state a reasonable default and invite correction.
3. Deferred extension: it is believable but not required; note the boundary and keep the relevant seam narrow.

For example:

“I’ll assume one pricing scheme for this version. Since pricing rules commonly vary, I will avoid embedding fee calculation across ticket and spot classes. If you want, I can discuss how I would extend it after the core flow works.”

That answer balances extensibility with delivery. It is much stronger than either extreme: hard-coding every policy into one method, or creating a large hierarchy of abstractions before the interviewer has requested any variation.

---

A compact interview worksheet

During the first five minutes, organize your notes in this form:

Notes area	What to capture
Goal and actors	Who initiates actions and what outcome they need
Capabilities	Main commands and queries
Rules and failures	Validity conditions, completion conditions, and rejected actions
Constraints	Fixed size, in-memory or persistent, synchronous or concurrent, configurable or fixed
Out of scope	Explicit exclusions that prevent scope creep
Change points	Policies, integrations, categories, or lifecycle rules likely to vary
Assumptions	Unspecified choices you made and announced

This is intentionally small enough to fit on a shared whiteboard. It also becomes a traceability map for the design that follows:

• capabilities later become public operations;
• rules later determine object state and invariants;
• constraints influence class boundaries and implementation choices;
• change points guide where flexibility may be warranted.

Do not use the worksheet mechanically. If an interviewer says, “Ignore payment, but focus on thread-safe allocation at multiple entrances,” the concurrency constraint is now central; spend your clarification time there. Conversely, if they ask for a simple simulation, do not consume time on database isolation or distributed locks.

---

A final quality check before designing

Before you transition to entities and classes, review your requirements quickly against five tests:

1. Unambiguous: Could two engineers interpret this requirement differently?
2. Complete enough: Do the principal actions, success cases, failures, and end states have answers?
3. Consistent: Does any requirement contradict another?
4. Testable: Can you describe an observable pass or fail outcome?
5. Scoped: Have you named both what you will build and what you will not build?

For instance, “The lot efficiently assigns a parking spot” fails the testable criterion because “efficiently” is undefined. A stronger version is either “assign the first compatible available spot” or “choose the nearest compatible available spot according to a supplied distance ordering.” The first defines a simple required behavior; the second introduces a deliberate allocation policy and therefore a likely change point.

The goal is not perfect product requirements. It is enough shared clarity to make a focused, coherent LLD answer possible.

---

You should now be able to turn a one-line LLD prompt into a short specification containing functional requirements, rules and error behavior, constraints, scope boundaries, stated assumptions, and credible change points. The most important interview habit is simple: confirm the problem before solving it.

Next, we will use the requirements sheet to identify the domain concepts worth modeling, and distinguish entities, value objects, and services without prematurely turning every noun into a class.