Functional Requirements System Design Interview: Scope First

The first five minutes of a system design interview are not a warm-up. They decide what you spend the next forty minutes designing. When you are asked to "design a social feed" or "design a URL shortener", the exercise is about turning an ambiguous prompt into a bounded problem. Functional requirements in a system design interview are that boundary, and getting them right is the core skill this article is about.

Here is a repeatable script for the opening: restate, confirm, list behaviours, park what is out of scope, then design. It includes two worked examples and a way to practise until the script sounds like you rather than a recital.

Why Functional Requirements Come First in a System Design Interview

A functional requirement describes what the system must do, expressed as something a user or another system can observe. "A user can publish a short message." "A user can follow another account." "A link can be created and redirected." Each one is a behaviour, not a technology.

Non-functional requirements describe the quality of that behaviour: how fast, how available, how consistent, how large. Scale, latency, availability and consistency all live here. Interviewers typically want both lists, and they want them in that order, because the second list is meaningless until you know what the system actually does. Saying "we need low latency" before you know whether the system reads or writes more is a sentence with no content.

The scoping phase is where you show how you think. A common view among interviewers is that the opening tests whether you can take a vague prompt, ask sensible questions, and produce a shared, bounded problem statement. If your scope is wrong, every component you draw afterwards is answering a question nobody asked.

The common failure mode is speed. Candidates hear "design Twitter" and within two minutes are naming caches, queues and sharding keys. Then the interviewer says, "assume we only care about the home timeline, not search," and half of what was drawn becomes irrelevant. The fix is not to design more slowly overall. It is to spend the first few minutes deliberately, so the remaining time is spent on the right problem.

A Five-Minute Scoping Script You Can Reuse

Here is the sequence. It fits comfortably in five minutes and gives you a shared reference for the rest of the interview.

Step 1: Restate the prompt in one sentence

Say it back in your own words and ask for confirmation. "So the goal is a service where people post short messages and see a feed of the accounts they follow. Is that the right shape?" This catches misunderstandings before they cost you anything.

Step 2: Name the core actors

List who interacts with the system and the top two or three actions each performs. For a social feed: end users who post and read, and internal services that assemble feeds. For a URL shortener: users who create links, and anonymous visitors who follow them. Admins and analytics systems usually exist, but naming them is not the same as scoping them in.

Step 3: List functional requirements as short verb phrases

Keep each one to a single observable behaviour.

• A user can write a short post.
• A user can subscribe to another account's updates.
• A user can read a chronological feed of the accounts they follow.

Short verb phrases are easy to confirm, easy to revisit, and easy to trace to a design decision later. If a requirement takes a paragraph to state, it is probably two requirements or a design choice in disguise.

Step 4: Park out-of-scope items explicitly

Say what you are not doing and why. "I will leave payments, content moderation and analytics out of scope, because they do not change the core feed design. We can add them if you want to go there." Parking items is not laziness. It shows you know the difference between a bounded problem and an unbounded one, and it gives the interviewer an easy way to redirect you.

Step 5: Ask one or two questions that change the design

Ask about the things you genuinely cannot decide alone: who uses the system most, whether reads or writes dominate, and what can be approximate or delayed. Skip anything you could answer yourself, and skip anything that sounds like fishing for the "right" answer.

Write all of this down. In a shared document or on a whiteboard, a short list of requirements becomes the reference you point back to when you justify a trade-off. "I chose fan-out on write because requirement three says the feed must be ready when the user opens the app." That sentence is worth more than any diagram.

Worked Example: A Social Feed

Start with the vague prompt: "design a social feed."

The scoped version might be: a user can write a short post; a user can follow another account; a user can read a chronological feed of the accounts they follow. Out of scope: direct messages, search, trending topics, moderation.

Now watch how each requirement maps forward. Publishing is a write path. Reading a chronological feed is a read path that has to gather posts from many accounts. That tension is the whole design. If you fan out on write, you push each post into every follower's feed at post time, which makes reads cheaper and writes more expensive. If you fan out on read, you gather posts when the feed is requested, which does the reverse.

That is where a non-functional requirement starts to shape things. If the feed must feel fresh, fan-out on read becomes harder to justify. If traffic is heavily read-dominated, fan-out on write starts to look attractive despite the write cost. Notice that neither statement is a functional requirement. They are qualities of the behaviour you already agreed on, and they only make sense once the behaviour exists.

Keep the functional list this small on purpose. Three behaviours give you plenty to design and plenty to trade off.

Worked Example: A URL Shortener

Now take "design a URL shortener." The scoped functional list is short: a user can submit a long URL and receive a short one; a visitor can follow a short link and be redirected to the original; a link can optionally expire after a set time. Out of scope, and said out loud: analytics dashboards, custom domains, bulk imports.

The interesting difficulty here is almost entirely non-functional. Redirects must be fast and highly available, because every redirect is on a user's critical path and a failure is visible. That is a quality of the redirect behaviour, not a behaviour itself. Saying "redirects must be fast" as a functional requirement muddles the list and makes the later trade-offs harder to explain.

Keeping the two lists separate also makes the design conversation cleaner. The functional list tells you what to build. The non-functional list tells you where to spend effort: caching hot links, replicating for availability, choosing a key-generation scheme that avoids collisions without a bottleneck.

Functional vs Non-Functional: Keeping the Two Lists Separate

Here is a test you can apply in the moment. If it describes behaviour a user can observe, it is functional. If it describes a quality of that behaviour, it is non-functional.

A two-column sketch works well on a whiteboard or in a shared document. Copy this pattern:

The non-functional column is what drives architecture trade-offs. Freshness pushes you toward pushing data at write time. Read-heavy traffic pushes you toward caching and read replicas. Availability pushes you toward replication and away from a single point of failure. Consistency requirements decide whether you can accept stale reads or need stronger guarantees. Partitioning choices follow from scale and access patterns, not from the feature list.

One warning: do not let the non-functional list grow until nothing gets designed. Three or four qualities that genuinely matter beat a page of adjectives. "The system should be scalable" constrains nothing and signals that you have not chosen what to optimise for.

Clarifying Questions That Earn Points

Good questions change the design. Here are the categories worth asking about.

Who uses the system, and which action matters most? A feed read by millions of passive users is a different problem from one read by a few thousand heavy posters.

What is the read-to-write ratio? This single question often reshapes the answer, because read-heavy and write-heavy systems pull toward different trade-offs.

What can be approximate or delayed? If a feed can be a few seconds stale, or a count can be eventually consistent, simpler options open up. This is often the highest-value question you can ask.

Questions to avoid: anything answerable from the prompt, and anything that sounds like you are hunting for the interviewer's preferred answer. "Should I use a queue here?" is a design question you should answer yourself, with reasoning.

Phrase questions so they carry your reasoning. Instead of "is it read-heavy?", try: "I expect reads to dominate heavily here, since most users read far more than they post. Should I design for that, or do you want me to assume a more balanced mix?" You have shown your thinking and given the interviewer an easy way to correct you. A question phrased this way does double duty: it clarifies the scope and demonstrates how you reason.

Common Mistakes When Stating Functional Requirements

Listing technologies instead of behaviours. "We will use Redis and Kafka" is not a requirement. It is a solution to a problem you have not stated yet.

Writing requirements so broad they constrain nothing. "The system should be scalable" and "the system should be reliable" could describe almost anything. Say what the user can do, then say how well it must work.

Skipping confirmation. If you design against your own assumptions without checking them, you may spend twenty minutes on the wrong system. One sentence of confirmation prevents that.

Forgetting to revisit the list. When the interviewer adds a constraint mid-interview, go back to your list and say what changed. "That adds a new requirement, so let me adjust the scope." This shows the list is a working tool, not a formality.

Treating scoping as a preamble. The opening minutes shape everything after them. Candidates who rush this phase often produce an impressive diagram of the wrong problem.

How to Practise This Opening Five Minutes

Scoping is a skill, and it improves with repetition. Try this routine.

Pick three familiar products and write a scoped functional requirement list for each in under five minutes. Use the script: restate, confirm, list behaviours, park out-of-scope items. Do it on paper first, then out loud.

Record yourself speaking the script and listen for filler and vagueness. You are listening for two things: whether your requirements are behaviours rather than technologies, and whether you sound like you are thinking or reciting.

Practise the phrase "I will assume X, is that reasonable?" and then move on without waiting for a long answer. In a real interview you cannot stall, and a confident assumption followed by progress is better than silence.

Run the full sequence until it is automatic: state, confirm, list, park, then design. The goal is not to memorise sentences. It is to make the opening calm and predictable, so your attention is free for the hard trade-offs later. Speaking the script aloud and reviewing your own performance is a useful way to rehearse this kind of opening.

For the wider set of fundamentals articles, browse our blog, and to see what else is available, visit our home page.

The takeaway: in the first five minutes, agree on a small list of observable behaviours, park everything else out loud, and ask the one or two questions that actually change the design. Everything you draw afterwards will be easier to justify, because you will both be looking at the same problem.

Frequently asked questions

How many functional requirements should I list in a system design interview?

Aim for three to five core behaviours. Enough to give the design real substance, few enough that you can confirm them quickly and still have time to design. If your list runs to ten items, you are probably describing features rather than the core behaviours that shape the architecture.

What is the difference between functional and non-functional requirements in a system design interview?

Functional requirements describe behaviour a user can observe, such as writing a post or following an account. Non-functional requirements describe the quality of that behaviour: latency, availability, consistency, scale. State the functional list first, because the non-functional list only makes sense once you know what the system does.

Should I write functional requirements down during the interview?

Yes. A short written list on a whiteboard or in a shared document gives you a reference you can point back to when justifying a trade-off, and it lets the interviewer correct your scope early. It also stops you from silently changing the problem halfway through.

What if the interviewer gives me a very vague system design prompt?

Treat vagueness as the point of the exercise. Restate the prompt in one sentence, name the core actors, propose a small set of behaviours, and ask for confirmation. Then park the parts you are excluding and say why. You are converting an ambiguous prompt into a bounded problem, which is a common view of what the opening is testing.

Do I need to cover every feature of a real product like Twitter or YouTube?

No, and trying to will cost you the interview. Real products carry years of accumulated features. Pick the two or three behaviours that create interesting design tension, say explicitly that the rest are out of scope, and design those well.

How long should the requirements-gathering phase take before I start designing?

About five minutes is a practical target. That is long enough to restate the prompt, list behaviours, park out-of-scope items and ask one or two clarifying questions, and short enough to leave the bulk of the interview for design and trade-offs.

Read more interview fundamentals on our blog.