How to Gather and Prioritize Requirements in System Design Interviews: A Beginner's Guide

Imagine, you're in a system design interview and asked to design YouTube or Twitter like complex systems on the fly.

What should you do?

Start by gathering and prioritizing requirements before diving into the design itself.

This critical first step ensures you’re solving the right problem and sets the stage for a great design.

And in order to do this, you must know how to effectively clarify what needs to be built (functional requirements) and under what conditions (non-functional requirements), all while keeping an eye on time and priorities.

In this guide, we will explain the process of requirements gathering in system design, cover the basic steps you must follow, and list the mistakes that should be avoided.

Why Requirement Gathering is Essential

Before sketching any architecture or writing any pseudo-code, you need to understand what you're building and why.

Here’s why gathering requirements is such an important foundation for system design interviews:

• Avoid Misalignment: If you don’t fully clarify the problem, you might design something that doesn’t solve the interviewer’s core question. In other words, answering the wrong question well is worse than answering the right question poorly. Proper requirement gathering ensures your design addresses the right needs and use cases, so you don't waste time on irrelevant features or assumptions.

• Prioritize Critical Features: Not all features are equally important. By understanding the requirements, you can focus on the must-haves first and postpone or drop the less critical ones. This prioritization helps you concentrate on functionality that delivers the most value (or that the interviewer cares about most). For example, when designing a video platform like YouTube, the ability to upload and stream videos is far more critical than a nice-to-have feature like adding video comments or reactions.

• Set Clear Scope Boundaries: System design questions are often intentionally broad or vague. Gathering requirements helps you define the scope of the problem—what's included and what's out-of-scope. By clarifying what's needed, you set boundaries that make the problem more manageable. If a requirement is beyond the core use case or time constraints, it's perfectly fine to acknowledge it and label it as out-of-scope (or a future enhancement). In fact, explicitly marking certain things as "nice-to-have" or "phase 2" features shows that you've thoroughly explored the problem space.

In short, taking the time to ask “What exactly are we building?” and “What constraints must it satisfy?” will save you from designing in the wrong direction. It ensures that when you start sketching components, you’re aiming at the right target.

Check out the top 10 system design interview questions.

Understanding Functional vs. Non-Functional Requirements

In system design (and requirement gathering in general), requirements usually fall into two broad categories: functional and non-functional. It’s important to cover both in an interview.

Let’s break down what each term means and why both are crucial.

Functional Requirements (The What)

Functional requirements describe what the system should do – the features and behaviors of the system from the user's perspective. These are the capabilities that fulfill the end-user’s needs or the core business goals.

In other words, if you’re designing a product or service, the functional requirements are the specific functions or features it must provide.

• Examples: For a service like Twitter, functional requirements might include the ability to post tweets, follow other users, view a timeline of followed users' tweets, and search tweets. For YouTube, key functional requirements would be video upload, video playback streaming, search for videos, like/share videos, and a recommendation feed.

• Clarifying Functional Needs: In an interview, clarify what core features are expected. Ask questions like: “What are the primary actions a user should be able to perform?” and “Which features are in scope?” For instance, if asked to design "a video sharing platform," clarify if it needs user accounts, comments, or live streaming, or just basic upload/watch functionality. Often, interviewers will expect you to enumerate these major features as part of understanding the problem.

Functional requirements are essentially the to-do list for your system’s capabilities. They define the minimum viable product (MVP) for the design.

Ensure you enumerate them clearly, since they will directly inform which components and services you need in your architecture.

Non-Functional Requirements (The How / Constraints)

Non-functional requirements describe how the system should perform and outline the constraints or quality attributes of the system. They don't add new features but rather define the conditions under which the system must operate.

These are often called quality attributes or "ilities" (because many end in “-ility”) and can be critical in shaping the design choices.

According to one source, non-functional requirements are the quality constraints the system must satisfy – things like scalability, performance, security, maintainability, etc.

Key non-functional aspects to consider include:

• Scalability: How well should the system handle growth in users or data? For example, should the system support 1 million daily active users or 10 million? Do we need to design for geographical distribution (global users) or just a local region? Clarifying expected traffic volume, data size, or request rates is crucial. If you're designing a service like Twitter, ask about the scale: e.g., "Should we expect around 500 million tweets per day, or what's the scale of read/write operations?" Knowing the scale will determine if you need strategies like load balancing or database sharding from the start.

• Performance (Latency & Throughput): What are the expected response times and throughput for the system? For instance, “Should each request complete in under 200ms?” or "How many requests per second should the system handle at peak?" Performance requirements help you decide on caching, indexing, or other optimizations. For a real-time system (like a stock trading platform), you might need very low latency; for a bulk processing system, maybe throughput is more important than per-request latency.

• Reliability & Availability: How important is uptime? Is the system expected to be highly available (e.g., 99.99% uptime with minimal downtime) or is some downtime acceptable? Also, consider fault tolerance: can the system tolerate failures of some components without downtime? For example, "Should our design ensure no single point of failure and support failover if a server goes down?" These considerations will influence using redundant servers, multiple data centers, backups, etc.

• Security: Are there specific security or privacy requirements? Almost every system should consider security, but the depth can vary. Ask if there are particular concerns like data privacy regulations (GDPR, HIPAA, etc.), need for encryption (data at rest or in transit), user authentication/authorization standards, or protection against certain attacks (DDoS, SQL injection). For example, a design for a payment system should include strong security requirements (encryption, fraud detection, etc.), whereas a public tweets system might emphasize availability over strict privacy (but still needs basic security). Security is often overlooked in interviews, but it's fundamental – systems that don't consider security can be vulnerable to attacks.

• Maintainability, Extendibility, Monitoring, etc.: These are other non-functional factors. In an interview context, you might not have time to delve deeply into these, but it's good to mention if relevant. For instance, observability (logging and monitoring) might be worth noting as a non-functional goal, or maintainability (designing a modular system that can be extended easily in the future).

Non-functional requirements often dictate the architecture of the system.

For example, if you need to handle millions of users (scalability requirement), you'll lean toward a distributed, microservices or sharded design rather than a single monolith.

If you need high availability, you'll introduce redundancy and replication.

If low latency is critical, you might choose in-memory caches or CDNs. These requirements can eliminate certain approaches and guide you toward appropriate solutions.

Pro Tip: Be as specific as possible with non-functional requirements. Rather than vaguely saying “the system must be fast or scalable,” try to attach numbers or concrete targets to them.

For example, saying "the service should handle 10k requests per second with <100ms latency for 95% of requests" is much more useful than "it should be fast and scalable." Specific requirements help you and the interviewer reason about trade-offs.

As one expert notes, general statements like “the system should be highly available or secure” are fine to mention, but precise targets (like 99.9% availability or response times under 200ms) show a deeper understanding.

Check out the beginners guide to system design.

How to Gather Requirements in a System Design Interview

So, how do you actually gather these requirements during the interview?

Typically, the interviewer will give you a one-liner or a very high-level prompt (e.g., "Design an online video streaming service" or "Build a ride-sharing system like Uber"). It's your job to flesh out the details by asking questions and driving the conversation.

This phase should be interactive and collaborative — treat the interviewer like a teammate who has information you need.

Here’s a step-by-step approach to gather requirements effectively, along with some example questions and tips:

1. Clarify the Problem and Functional Scope

Start by understanding the goal of the system and identifying the core functionality. It’s often good to restate the problem in your own words and make sure you’re on the same page.

For example: “Okay, you said ‘design YouTube’. To clarify, is the main goal to allow users to upload videos and for others to stream/watch them? Are we focusing on any specific aspect like just the video streaming backend, or the entire product (including things like recommendations and comments)?”

This gives the interviewer a chance to refine the scope if needed.

Next, dive into functional requirements with clarifying questions.

Think about the end-users and what they need from the system.

Put yourself in their shoes, as suggested by one guide: imagine what the user or client expects to see and do.

Here are some key clarifying questions for functional requirements:

• Who are the users and what are they trying to do? – Identifying the primary actors helps focus the features. “Are we designing this for end-users watching videos, content creators uploading videos, or both?” Different user types might have different requirements.

• What core features should the system have? – List out primary use cases. “For a social network like Twitter, do we need to support tweeting, retweeting, following, and feed generation? Is direct messaging in scope or out-of-scope?” If the interviewer hasn't mentioned a feature, ask if it's needed. It's better to ask than to assume wrongly.

• Are there any specific scenarios or edge cases to consider? – “Should our URL shortener handle custom aliases or just random? Any size limits on the content (e.g., max tweet length)? Any important edge cases like extremely large files for an upload service?” This helps uncover details that might not be obvious from the one-line prompt.

• What does success look like for this system? – “Is there a particular goal, like fast response time for user requests or handling a certain amount of traffic?” This question can segue into non-functional requirements, but it's also a way to gauge if the interviewer has a specific focus in mind (e.g., perhaps they care a lot about real-time updates or consistency for this system).

As you ask these questions, write down the requirements (on paper or a whiteboard if in person, or verbally summarize if virtual). It shows you’re methodically collecting info, and it gives you a checklist to refer to later.

Interviewers often appreciate a structured approach, and they might even chime in with “Yes, please also consider X” or “Don’t worry about Y for now” as you ask.

Remember to confirm and paraphrase: “So, to recap, the core functionalities we need are A, B, and C, and we won’t worry about D and E for now, correct?”

This confirmation ensures you and the interviewer agree on what the functional scope is. It's much easier to design a system when both parties have the same mental model of what features it includes.

2. Identify Non-Functional Requirements (Constraints & Targets)

Once the basic features are understood, transition into clarifying the non-functional aspects – those critical environment and performance constraints under which the system must operate.

You might lead with something like, “Next, I’d like to understand some expectations around scale, performance, and other constraints, to inform the design.”

This signals to the interviewer that you know these factors are important.

Important non-functional questions to ask (many of these can be framed as asking for numbers or ranges):

• Scale & Volume: “Approximately how many users or transactions should the system support? What are we looking at in terms of daily active users or requests per second?” If designing YouTube, for example, you’d ask about expected number of video uploads per day or concurrent video streams. For Twitter, you might ask, “How many tweets per day or peak QPS (queries per second) should we design for?” If the interviewer doesn’t have exact numbers, you can propose reasonable assumptions (e.g., "Let's assume on the order of 1 million daily active users to make sure our design scales"). Discussing scale early ensures you design with scalability in mind.

• Performance: “Are there latency or response time requirements? For instance, should user requests (like loading the timeline) complete within a certain number of milliseconds?” If the system involves user interactions, likely yes – nobody wants a slow app. For something like a search feature, the expectation might be sub-second query responses. If the interviewer hasn’t mentioned it, you can say something like, “I’ll aim to have most requests return in under 200ms as a target unless you say otherwise,” which shows proactiveness.

• Data Storage & Consistency: “How much data are we dealing with, and is consistency a major concern?” This covers database size and whether the system can allow eventual consistency or needs strong consistency. For example, in an e-commerce system design, you might ask if inventory counts must be strongly consistent or if slight delays are acceptable. In many cases, this can be an assumption you state: e.g., “I will assume we need to store on the order of tens of millions of records, and that some parts of the system (like user posts) can be eventually consistent within a few seconds.” If consistency or transactionality is key (like in banking), definitely clarify that.

• Availability & Reliability: “Is there an uptime requirement or fault tolerance level we should meet? (e.g., 99.9% uptime, no single point of failure)”. If not explicitly stated, you can infer based on the application: a financial transaction system likely needs near-100% uptime and strong disaster recovery; a internal tool might tolerate more downtime. Mention ideas like redundancy, replication, or multi-data-center if relevant to show you’re considering reliability.

• Security & Privacy: “Are there specific security requirements or privacy concerns we should keep in mind?” For instance, “Any user data that needs encryption or special protection? Do we need to worry about GDPR compliance for user info?” Even if the interview is not security-focused, asking shows thoroughness. If the interviewer says "good point, yes we should ensure data is private" you can note things like using HTTPS, encryption at rest, authentication systems, etc., in your design. At minimum, note that you'd include basic security measures (auth, encryption, rate limiting) in any real system.

• Other Constraints: Sometimes the interview might have unique constraints like legacy systems, specific technology choices, or deadlines. For example: “Are we assuming we build from scratch, or do we have to integrate with an existing system or use a specific technology (e.g., must use AWS services)?” Usually for interviews, the answer is "build from scratch with whatever tech makes sense," but if it's a company-specific scenario, it's good to ask.

It’s your responsibility to uncover these details in a system design interview.

Interviewers often won't volunteer numbers or requirements unless you ask, because part of the test is seeing if you know to ask.

If they don’t have exact answers (they often expect you to come up with reasonable assumptions), that’s fine – propose some and see if the interviewer agrees.

For example, if designing a new Twitter, you might say, “Twitter has hundreds of millions of users, but for our design exercise, let's assume 50 million monthly active users and maybe 1 million daily active. Does that sound reasonable?”

They might adjust it, but at least you've put a stake in the ground that you can design around.

When you state an assumption or a requirement, validate it with the interviewer. This can be as simple as asking “Does that assumption make sense?” or “Am I in the right ballpark with that number?”.

Validating assumptions prevents you from going down a wrong path. If the interviewer says "Actually, think bigger — expect 10x that number of users," then you know to design an even more scalable architecture.

If they say "We don't need to worry about that level of scale", you can scope back accordingly. This back-and-forth shows good communication and that you’re not just making blind guesses.

3. Time-Box and Prioritize the Requirements

Gathering requirements is essential, but remember, you have limited time in an interview (often ~35-45 minutes total).

You typically want to spend a small but significant portion of that on requirements – enough to cover the bases, but not your entire interview!

A good rule of thumb is to time-box this phase to about 5-10 minutes at the start of the interview. In a rush of enthusiasm, some candidates either blow past this step (too short) or get stuck endlessly discussing details (too long).

Aim for a balanced approach.

If you find yourself deep in the weeds of requirements (e.g., debating minor feature details or very specific metrics) and 5-10 minutes have passed, it's a sign to wrap it up.

You can say something like, “I have a good handle on the requirements now: we need X, Y, Z features and A, B, C constraints. If it's okay, I'll start discussing the high-level design and we can clarify further on the fly.”

This shows awareness of time.

Interviewers appreciate when you can self-regulate and move the conversation forward once the key points are nailed down.

Critically, part of requirement gathering is also prioritizing what you've collected. Not everything on your list will be equally important to address in depth.

Identify the core requirements – the ones that define the system’s success – versus the nice-to-haves.

A useful technique (borrowed from product management) is the MoSCoW method, which classifies requirements into Must-haves, Should-haves, Could-haves, and Won't-haves. In an interview setting, you might not formally categorize them this way, but you can do it mentally or implicitly:

• Must-haves are the fundamental features and constraints without which the system fails (e.g., for YouTube: video upload & playback are must-haves; for an Uber-like system: ride request, match driver to rider).

• Should-haves are important but not absolutely core. If time allows, you'll cover them. (e.g., comments on videos, or a rating system for drivers in Uber).

• Could-haves are nice extras or future enhancements (e.g., video filters or stories on a video platform, which aren't core to the basic service).

• Won't-haves (for now) are explicitly out-of-scope things you decide not to include, often because of time or because they’re less relevant to the interviewer’s interest (e.g., maybe live streaming is out-of-scope for your "design YouTube" interview, unless specified).

When you articulate your requirements, it can be helpful to briefly mention priority.

For example: “The core features we'll definitely need to design are A, B, and C. It would also be nice to have D and E, but given time constraints, I might focus on A, B, C primarily and only discuss D/E if time permits.”

This communicates to the interviewer that you are intentionally focusing on what's most important, which is a sign of good judgment. It aligns with advice to distill requirements into a clear, concise set of goals and avoid an unfocused design.

Additionally, consider which requirements will drive the “hard parts” of the system design.

Nearly every system design question has a challenging aspect (maybe it's the scale, maybe it's a particular feature like real-time updates or a heavy write load). Use your requirement discussion to identify that.

For instance, if you realize one major requirement is that "the system should handle 1 million concurrent users globally," you know scalability is the crux and you'll need to focus on a distributed architecture.

Or if "users should see updates in real-time," then real-time streaming is the crux (perhaps requiring technologies like WebSockets or long polling). Highlighting the hardest requirement and keeping it in focus helps ensure you address what likely matters most to the interviewer.

Example – Applying Prioritization: Imagine you're asked to design Instagram.

After some discussion, you have a list of requirements: users can post photos and videos, follow others, see a feed, like and comment on posts, maybe basic messaging, plus non-functional needs like handling 100 million users, low latency feed refresh, high availability, and so on.

You might prioritize by saying, “The must-haves are photo/video posting, a user feed, and the ability to follow/like. Comments and messaging are secondary – I'll mention how they could fit, but focus on the core posting & feed in design. Non-functional musts are handling high traffic and ensuring the feed is updated in near real-time. I'll treat things like exact storage costs or minor features as lower priority given the time.”

This way, the interviewer knows you’re focusing your design on what matters most (posting and feed generation under high scale), which is likely the main challenge they want to see you solve.

Check out the 50 advanced system design interview questions.