Eliciting and Clarifying Requirements

Hello! Welcome to the first lesson of our new module, "The Low-Level Design Process."

In the previous modules, you've built a fantastic toolkit of OOP principles, SOLID guidelines, and a wide array of design patterns. You've mastered the building blocks. Now, we shift our focus from what these tools are to how to use them in a structured process to solve a complete design problem from start to finish. This module is designed to mirror the flow of a typical low-level design interview.

Today, we're starting at the very beginning. The learning outcome for this lesson is to elicit and clarify functional requirements and use cases from a problem statement. The first 5-10 minutes of an LLD interview are often the most critical. This is where you collaborate with the interviewer to define the problem's scope. Getting this step right prevents you from designing the wrong system and demonstrates a mature, methodical approach to problem-solving.

The Importance of a Solid Foundation

In a system design interview, you're typically given a vague, one-sentence problem statement like "Design a parking lot system." A common mistake is to immediately jump into drawing class diagrams or writing code. An experienced interviewer is looking for something else first.

Let's watch a short clip that explains what interviewers expect at the beginning of an object-oriented design interview.

As the video highlights, the goal is not to assume, but to clarify. You need to transform an ambiguous problem into a concrete set of features and constraints that you can solve within the interview's timeframe.

Functional vs. Non-Functional Requirements

The requirements you elicit will generally fall into two categories: functional and non-functional.

• Functional Requirements: These define what the system should do. They describe specific behaviors, features, or functions. For example, "A user must be able to book a parking spot."
• Non-Functional Requirements (NFRs): These define how the system should perform its functions. They relate to qualities like performance, scalability, security, and reliability. For example, "The system should confirm a booking within 200 milliseconds."

In LLD interviews, the primary focus is on functional requirements, as they directly shape the classes, objects, and their interactions. NFRs are more central to High-Level Design (HLD), but it's still good practice to be aware of them.

A Framework for Asking Clarifying Questions

To ensure you cover all your bases systematically, it's helpful to use a framework. One excellent mnemonic for guiding your conversation with the interviewer is the SCALE framework.

Let's explore this framework using the "Low-Level Design (LLD) :Interview Framework" article.

Here's a summary of the SCALE framework to guide your thinking:

• S - Scope: What are the core features? What should we definitely include, and what can we leave out?
  • "Should the system handle multiple vehicle types?"
  • "Are we designing for a single parking lot or a chain of lots?"
• C - Constraints: What are the system's boundaries or limitations? This can relate to scale or technology.
  • "What is the capacity of the parking lot?"
  • "Are there any concurrency concerns to consider, like multiple cars entering at once?"
• A - Assumptions: What can we assume to be true to simplify the problem? Always state your assumptions explicitly to the interviewer.
  • "Can we assume the parking lot has a single entrance and exit for now?"
  • "I'll assume that payment integration is out of scope and we're just handling the ticketing and spot allocation."
• L - Limitations: What is explicitly out of scope? This is the flip side of Scope and helps fence the problem.
  • "So, we will not handle staff management or reporting features in this design?"
  • "We will focus on the booking flow and not on user registration, correct?"
• E - Edge Cases: What are the unusual or error conditions the system must handle?
  • "What happens if a user tries to exit without a valid ticket?"
  • "How do we handle the lot being full?"

Using this framework turns the initial phase of the interview from a monologue into a collaborative dialogue.

Putting It into Practice: Designing a Parking Lot

Let's see how this works with a classic LLD problem. The problem statement is simple: "Design a parking lot."

First, read this short guide on the essential questions you should be asking for this problem.

Now, let's watch a detailed requirement-gathering session for the same problem. As you watch, try to categorize the requirements being discussed using the SCALE framework.

After that discussion, you would have a list of concrete functional requirements like this:

• The parking lot has a capacity of 30,000 spots.
• It supports multiple vehicle types: motorcycle, compact car, large car.
• It has multiple entrances and exits.
• A ticket is issued at the entrance with an assigned spot.
• The system must handle hourly pricing.
• Payment can be made via cash or credit card.
• The system should not allow more vehicles than its capacity.

By clarifying these points, you have scoped the problem from a vague idea into a specific, solvable challenge.

Defining Use Cases

Once you have a set of functional requirements, the next logical step is to identify the primary use cases. A use case describes a specific interaction between a user (or "actor") and the system to achieve a goal. It helps translate what the system does (requirements) into how someone uses it.

Let's look at another example, an elevator system, to see how requirements lead to use cases.

From the video, some key use cases for the elevator system are:

• Call the elevator: A user on a floor requests an elevator.
• Move/Stop the elevator: The system moves the car between floors.
• Open/Close the doors: The system operates the doors when at a floor.
• Indicate elevator position: The system displays the current floor.
• Make an emergency call: A user inside the car requests assistance.

Defining these use cases is vital because they will directly inform the public methods of your main classes later in the design process.

Test your understanding!

Imagine you are in an interview and the problem statement is: "Design a library management system."

Using the SCALE framework, list at least five clarifying questions you would ask the interviewer to define the scope of the problem. For each question, mention which part of the SCALE framework it addresses.

Show answer

Here are some great questions you could ask:

1. Scope: "Should the system handle just books, or also other media like DVDs and magazines?"
2. Scope/Users: "Will there be different types of users, like members and librarians? Do they have different permissions (e.g., librarians can add new books)?"
3. Constraints: "Is this for a single library branch, or does it need to support a multi-branch system where a book can be returned to any branch?"
4. Assumptions: "Can we assume we don't need to handle the actual purchasing of new books, just the management of existing inventory?"
5. Edge Cases: "How should the system handle overdue books? Should it calculate fines?"
6. Limitations: "For this initial design, should we ignore user notifications (e.g., reminders for due dates) and focus only on the core borrowing and returning flow?"

Conclusion

Congratulations on completing the first step in the low-level design process! This initial phase of clarification is not just a formality; it's the foundation upon which your entire design is built. A strong foundation leads to a stable structure.

Key Takeaways:

• Always Clarify, Never Assume: The primary goal at the start of an LLD interview is to transform ambiguity into a well-defined problem scope through a dialogue with your interviewer.
• Use a Framework: A systematic approach like the SCALE framework (Scope, Constraints, Assumptions, Limitations, Edge Cases) ensures you ask comprehensive and intelligent questions.
• From Requirements to Use Cases: Once functional requirements are clear, identify the main use cases. These user-centric actions will guide the design of your classes and their methods.

In our next lesson, we will build directly on the work done here. We'll take our clarified requirements and use cases and move on to the next step: "Identify core domain entities, their attributes, and behaviors." This is where we'll start sketching out the first draft of our classes.