beginnerintermediateadvanced

System Design · Requirements

Functional vs Non-Functional Requirements

The full shape of a requirement, and how to make every part of it measurable

Six functional categoriesfeature, workflow, rule, action, data, integration
Eleven non-functional categoriesspeed, trust, and operability
"Fast" needs a percentilevague words always hide a number
RPO looks back, RTO looks forwarddata loss vs downtime — sized separately

1.Functional requirements, in full

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.

Key features

Feature: a capability the system offers
Workflow: an ordered sequence of steps to a goal
Business rule: a constraint on what is allowed
User action: one thing a user does, e.g. "submits a form"
Data produced: what the system creates or stores as a result
External integration: another system this one talks to

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"

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"

Command

text

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

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

2.The eleven non-functional categories

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

Key features

Latency/throughput/scalability: speed and volume
Availability/durability/consistency: trustworthiness of the data
Security/compliance: who can do what, and what the law requires
Observability/recoverability/cost: what it takes to run it

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

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

Signature

latency / throughput / availability / durability / consistency / scalability / security / observability / recoverability / compliance / cost

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

3.Turning vague requirements into measurable targets

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.

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

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

Command

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

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

4.Worked numeric examples

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.

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

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.

Command

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)

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

Spotted a mistake on this page? Tell us.

Read Sheet