beginnerintermediateadvanced

System Design · Section 2

Functional vs Non-Functional Requirements

Level: beginner
Read: 20 min
Concepts: 4

The full shape of a requirement: six categories of what a system must do, eleven categories of how well it must do it, and the discipline of turning every vague word — "fast," "reliable," "scalable" — into a number before calling a requirement done.

This section

Foundation of System Design Interview starting with Functional vs Non Functional RequirementssudoCODE

What is true here

A functional requirement is a feature, workflow, business rule, user action, data produced, or external integration.
A non-functional requirement falls into one of three groups: speed & volume, trustworthiness, or operability.
A requirement with no number in it — "fast," "reliable" — cannot fail a test, and is not yet a requirement.
RPO bounds acceptable data loss, looking backward; RTO bounds acceptable downtime, looking forward — sized independently.

What you will be able to do

Sort a feature request into its six functional categories
Sort a quality goal into its eleven non-functional categories, and the three groups they fall into
Turn a vague word ("fast", "reliable", "scalable") into a percentile, a percentage, or a time bound
Read a five-figure requirements block (capacity, latency, availability, RPO, RTO) and say what it rules out

What it does

The full functional side — six categories, one example each.

Functional requirements, in full

standardbeginner

A functional requirement is anything describing what the system does: a feature, a workflow, a business rule, a user action, the data it produces, or an outside system it talks to.

Think of it as

If you can act it out as a story — "a user does X, and Y happens" — it is functional. Six flavours of that story: features, workflows, business rules, user actions, data produced, and external integrations.

text

Functional requirement categories:
  Feature · Workflow · Business rule
  User action · Data produced · External integration

Six flavours of "a user does X, and Y happens"

Feature

A capability the system offers — "users can upload a profile photo"

Workflow

An ordered sequence to a goal — cart, address, payment, confirmation

Business rule

A constraint on what is allowed — orders under $10 do not get free shipping

User action

One thing a person does — "clicks Submit to place an order"

Data produced

What the system creates as a result — "each order produces an invoice PDF"

External integration

Another system this one talks to — "payment goes through a third-party gateway"

The six categories of functional requirement

The six categories of functional requirement
Category	Example
Feature	"Users can upload a profile photo"
Workflow	"Checkout: cart -> address -> payment -> confirmation"
Business rule	"Orders under $10 do not qualify for free shipping"
User action	"A user clicks Submit to place an order"
Data produced	"Each order produces an invoice PDF"
External integration	"Payment is processed via a third-party gateway"

Together

text

Feature request: "Let users check out with a saved card."

  Feature:              save and reuse a payment card
  Workflow:              cart -> select saved card -> confirm -> receipt
  Business rule:         a card must pass a $0 auth check before saving
  User action:           "select saved card" tap during checkout
  Data produced:         an order record, a receipt
  External integration:  the card network's tokenization API

Remember: Six categories cover every functional requirement: feature, workflow, business rule, user action, data produced, external integration.

How well it does it

The full non-functional side, and the discipline of making every part of it measurable.

The eleven non-functional categories

corebeginner

Eleven qualities a design should state a target for: latency, throughput, availability, durability, consistency, scalability, security, observability, recoverability, compliance, and cost.

Think of it as

Group the eleven into three questions: how fast and how much (latency, throughput, scalability), how trustworthy (availability, durability, consistency, security, compliance), and how operable (observability, recoverability, cost).

What we're doing: Take one feature and state a target for every applicable non-functional category, showing how many decisions "process a payment" actually hides.

requirements.txttext

Feature: "Process a payment."

Latency:        p95 under 500ms
Throughput:      500 payments/second at peak
Availability:     99.99%
Durability:       a confirmed payment is never lost
Consistency:      a payment cannot be double-charged
Security:         card data never touches app logs
Compliance:       PCI-DSS scope minimized
Observability:     every payment traceable end to end
Recoverability:    RPO 0, RTO under 5 minutes
Cost:              under $0.01 overhead per transaction

3: Speed & volume group — how fast, and how many at once.
6: Trustworthiness group — consistency here specifically rules out a double charge, the most expensive mistake this feature could make.
10: Operability group — these are rarely asked for up front, and are exactly the ones that get skipped under deadline pressure.

Why this works: Naming all eleven categories against one feature is what turns "process a payment, make it reliable" into something a team can actually build against and test. Skipping a category does not remove the requirement — it just means nobody decided the number on purpose.

Only stating latency and calling the requirements done

Wrong

text

Requirements: "Process a payment in under 500ms."

(nothing said about consistency, so a double-click during
a slow network retry double-charges the customer)

Better

text

Requirements:
  Latency:      p95 under 500ms
  Consistency:  idempotency key required — a retried
                request must never charge twice

What you see: A customer double-clicks "Pay" on a slow connection, the client retries the request, and the payment goes through twice — because nobody stated a consistency requirement, only a latency one.

Why: Latency is the easiest non-functional category to remember because it is the most visible. Consistency, durability and the rest are just as binding — they are simply invisible until the system is already in production and one of them was missed.

Three questions, eleven categories

Speed & volume

Latency

time per operation

Throughput

ops per second

Scalability

stays fast under load

Trustworthiness

Availability

up when called

Durability

data survives

Consistency

readers agree

Security

access protected

Compliance

meets regulation

Operability

Observability

you can tell what it is doing

Recoverability

fast to recover

Cost

to build and run

The eleven non-functional categories, grouped

The eleven non-functional categories, grouped
Group	Category	Question it answers
Speed & volume	Latency	how long does one operation take
Speed & volume	Throughput	how many operations per second
Speed & volume	Scalability	does it stay fast as load grows
Trustworthiness	Availability	is the service up when called
Trustworthiness	Durability	does written data survive
Trustworthiness	Consistency	do all readers see the same data
Trustworthiness	Security	is access and data protected
Trustworthiness	Compliance	does it meet legal/regulatory rules
Operability	Observability	can you tell what it is doing
Operability	Recoverability	how fast can it recover from failure
Operability	Cost	what it costs to build and run

Together

text

Feature: "Process a payment."

  Latency:         p95 under 500ms
  Throughput:       500 payments/second at peak
  Availability:      99.99% (money is on the line)
  Durability:        a confirmed payment is never lost
  Consistency:       a payment cannot be double-charged
  Security:          card data never touches app logs
  Compliance:        PCI-DSS scope minimized
  Observability:      every payment traceable end to end
  Recoverability:     RPO 0, RTO under 5 minutes
  Cost:               under $0.01 processing overhead per transaction

Remember: Eleven categories, three groups: speed & volume, trustworthiness (availability, durability, consistency, security, compliance), and operability.

Turning vague requirements into measurable targets

standardbeginner

Any requirement stated with a word like "fast," "reliable," or "scalable" needs a number attached before it means anything testable — ask what percentile, what percentage, or what time bound the word is standing in for.

Think of it as

For every vague word, there is a standard question that turns it into a number: "fast" -> what percentile, in milliseconds? "reliable" -> what percentage of uptime, over what window? "scalable" -> to how much traffic, by when?

text

"fast"        -> p95/p99 latency, in ms
"reliable"    -> % availability, over what window
"scalable"    -> to what peak RPS, by when
"secure"      -> against which threat model, which controls
"durable"     -> RPO — how much data loss is acceptable

What we're doing: Take a stakeholder sentence full of vague words and turn every one of them into a number, using the standard question for each.

requirements.txttext

Stakeholder: "The checkout flow needs to be fast,
reliable, and able to handle a big spike on Black Friday."

Turned into targets:
  Fast:      p95 checkout completion under 2 seconds
  Reliable:  99.95% availability during checkout
  Spike:     10x normal peak RPS, sustained for 6 hours

1: Three vague words in one sentence — fast, reliable, and a spike with no size attached.
5: Each vague word gets the standard question applied: fast -> what percentile, in ms.
7: "A big spike" becomes an actual multiplier and duration — without this, nobody can say whether the design handles it or not.

Why this works: A design cannot be tested against a word. Turning each vague term into a number, using the standard question for that word, is what makes a requirement something a test can actually pass or fail against.

Accepting a vague requirement without pushing back

Wrong

text

Requirement, as written: "Make it scalable."

(design proceeds with no target — "scalable" is treated
as done once the code technically CAN add more servers)

Better

text

Requirement, clarified: "Scalable to 5x current peak
traffic (50K req/s) within 6 months, without a
rewrite of the data layer."

What you see: The system "is scalable" in the sense that it could theoretically add more servers, but nobody verified it actually holds up past 2x current load — the requirement was never falsifiable in the first place.

Why: "Scalable" with no target is not a requirement — it is a mood. Without a number, there is no test that could ever fail it, which means it was never actually specified.

The same sentence, before and after the standard question

A mood — nothing can fail it

+"Fast" — at what percentile, in what unit?
+"Reliable" — what percentage, over what window?
+"Scalable" — to how much load, by when?
+No test could ever return false, so nothing was specified

A target a test can fail

−A percentile and a unit, so a run either passes or does not
−A percentage and a window, so a month can be measured
−A multiplier and a duration, so a load test can be written
−Each number narrows the design space before anything is drawn

The standard question behind each vague word

The standard question behind each vague word
Vague word	Question to ask	Measurable form
Fast	at what percentile, in what unit?	p95 latency under 300ms
Reliable	what % uptime, over what window?	99.95% monthly availability
Scalable	to what peak load, by when?	handles 10x traffic by Q3
Durable	how much data loss is acceptable?	RPO of 5 minutes
Recoverable	how long can it stay down?	RTO of 30 minutes

Together

text

Vague: "The search feature should be fast and reliable."

Measurable:
  "Search returns results within 300ms at p95,
   with 99.9% monthly availability."

Remember: Every vague word has a standard question behind it: fast -> percentile in ms, reliable -> % over what window, scalable -> to how much, by when.

Worked numeric examples

standardbeginner

Five numbers that show what a real, measurable requirements block looks like together: 10 million requests a day, p95 latency under 300ms, 99.95% monthly availability, an RPO of 5 minutes, and an RTO of 30 minutes.

Think of it as

Read the five numbers as one requirements block for one system, not five unrelated facts — capacity sets the scale, latency and availability set the quality bar, RPO/RTO set the disaster-recovery bar.

text

Capacity:      10,000,000 requests/day
Latency:       p95 under 300ms
Availability:  99.95% monthly
RPO:           5 minutes (max acceptable data loss)
RTO:           30 minutes (max acceptable downtime)

What we're doing: Read one realistic requirements block and derive what it implies for design, the same way a design doc's opening section would be read.

requirements.txttext

Capacity:      10,000,000 requests/day
Latency:       p95 under 300ms
Availability:  99.95% monthly
RPO:           5 minutes
RTO:           30 minutes

1: ~116 req/s average — but capacity estimation (a later section) also needs a peak factor, since traffic is never perfectly flat.
2: p95, not average — 1 in 20 requests is explicitly allowed to be slower than 300ms.
3: 99.95% allows about 21.6 minutes of downtime a month — a design with a single point of failure almost certainly cannot hold this.
4: RPO 5 minutes rules out a design that only backs up once a day.
5: RTO 30 minutes rules out any manual, human-driven failover process that reliably takes longer than that.

Why this works: Five numbers, read together, already constrain the design before a single component is drawn: 99.95% availability rules out single points of failure, RPO 5 minutes rules out infrequent backups, RTO 30 minutes rules out slow manual failover. This is what "measurable" requirements are for — they narrow the design space immediately.

Confusing RPO with RTO

Wrong

text

"RPO of 30 minutes" used to mean "the system can be
down for 30 minutes" — describing downtime tolerance
using the data-loss metric

Better

text

RPO (Recovery Point Objective): how much DATA the
system can afford to lose — measured backward in time.

RTO (Recovery Time Objective): how much DOWNTIME the
system can afford — measured forward from the failure.

What you see: A recovery plan is built around the wrong number — data loss tolerance is used to size a failover process, or downtime tolerance is used to size a backup frequency — and the two get silently swapped in a design review.

Why: RPO looks backward from the failure ("how much did we lose"); RTO looks forward from the failure ("how long until we are back"). They bound two different things and are sized independently — a system can have a tight RPO and a loose RTO, or the reverse.

Five numbers, and what each one has already ruled out

Capacity — 10,000,000 requests/day

About 116 requests/second on average, before any peak factor is applied.

Latency — p95 under 300ms

19 in 20 requests finish under 300ms. The 20th is explicitly allowed to be slower.

Availability — 99.95% monthly

About 21.6 minutes of downtime a month. Rules out any single point of failure in the path.

RPO — 5 minutes

Data loss, measured backward from the failure. Rules out a once-a-day backup.

RTO — 30 minutes

Downtime, measured forward from the failure. Rules out a manual failover that takes longer.

What each figure means and where it comes from

What each figure means and where it comes from
Figure	Meaning	Rough conversion
10M requests/day	total daily traffic	~116 req/s average, before peak factor
p95 < 300ms	latency bound, 95th percentile	19 in 20 requests finish under 300ms
99.95% monthly	availability bound	~21.6 minutes downtime allowed per month
RPO 5 min	max acceptable data loss	backups/replication must be no more than 5 min stale
RTO 30 min	max acceptable downtime	failover must complete within 30 min of an outage

Together

text

10,000,000 requests / 86,400 seconds per day
  = ~116 requests/second average

99.95% availability over a 30-day month
  = 0.05% of 43,200 minutes
  = ~21.6 minutes of allowed downtime per month

Remember: RPO looks backward — how much data loss is acceptable. RTO looks forward — how much downtime is acceptable. They are sized independently.