Functional and Non-Functional Requirements

Two Kinds of Requirements

Before you draw a single box in a system design interview, you pin down what you are building.

Functional requirements describe what the system does. They are features a user can see and use.

Non-functional requirements (NFRs) describe how well it must do those things: speed, safety, uptime, and scale.

Throughout this lesson, we use a coding competition platform as the running example.

The Four Core Features

Our platform has exactly four functional requirements.

Users can view a list of problems, then open a problem and code it in one of several languages.

They can submit their code and get instant feedback on whether it works.

During a competition, they can view a live leaderboard showing who is ahead.

Notice that each one starts with a user action. That is a quick test for a functional requirement.

Say What You Will Not Build

Stating scope also means naming what is out of scope.

For this platform, we skip authentication, user profiles, payments, analytics, and social features.

These are real features. They are simply not the heart of this problem, and any one of them could eat an entire interview.

Saying this out loud shows focus and lets the interviewer object early if they disagree.

Availability Over Consistency

The first NFR is a trade-off: the platform favors availability over consistency.

Availability means the system keeps responding. Consistency means every user sees the exact same, latest data at the same moment.

During a competition, a leaderboard that lags a few seconds is annoying. A platform that goes down is a disaster.

So when the two conflict, we keep the site up.

Run Untrusted Code Safely

The second NFR is secure, isolated execution.

Every submission is code written by a stranger. It could be buggy, slow, or deliberately harmful.

Isolation means each submission runs in its own sealed environment, often called a sandbox.

If one program crashes or misbehaves, it cannot touch the servers, the database, or other users' code.

Notice that the misbehaving program stays trapped inside its own box, so the servers, the database, and other submissions are untouched.

Put Numbers on Speed and Scale

Good NFRs are measurable. Our last two have hard numbers.

Submission results within 5 seconds. This is an SLA, a promise about response time, and it is what makes feedback feel instant.

Scale to 100,000 concurrent users in a competition. They all hit the system at the same time, not spread across a day.

Numbers like these give you something concrete to design against.

Why Scope Comes First

Interviewers expect you to state scope and NFRs before any architecture.

Design choices only make sense against requirements. A 5-second SLA and 100,000 concurrent users shape the design more than any single feature.

Skipping this step risks building the wrong thing or solving problems nobody asked about.

Your move: list the features, name what is out, state NFRs with numbers, then design.

For a coding competition platform, "Users can view a live leaderboard during a competition" is a _____ requirement.

• functional
• non-functional

Answer: functional

It describes a feature the user can see and use, and it starts with a user action. That makes it functional. Non-functional requirements describe how well the system performs, such as speed, safety, uptime, and scale.

In a system design interview, first list the _____, then name what is _____, then state _____ with numbers, and finally _____ the architecture.

Answer: In a system design interview, first list the features, then name what is out of scope, then state NFRs with numbers, and finally design the architecture.

The recommended order is: features → out of scope → measurable NFRs → design. Design choices only make sense when they are measured against requirements. That is why architecture comes last.

Which of the following is a non-functional requirement for a coding competition platform?

• Submission results are returned within 5 seconds
• Users can submit code and get feedback
• Users can open a problem and code it
• Users can view a list of problems

Answer: Submission results are returned within 5 seconds

Returning submission results within 5 seconds describes how well the system performs. It is a measurable response-time promise (an SLA), so it is non-functional. The other three options are user-facing features that begin with a user action, so they are functional.