Functional vs Non-functional Requirements

In one line

Functional requirements say what the system does; non-functional requirements say how well it does it. Non-functional requirements are where system design actually happens.

0/6 · 0%

Think of it like this

A car. Functional = it drives, brakes, and turns. Non-functional = how fast it goes, how safe it is, how often it breaks down, and how much fuel it uses. Two cars with the same features can be very different on the second list.

Key ideas

01
Functional: every behavior a user can trigger — 'place order', 'refund payment', 'search products'.
02
Non-functional: Latency (p99 < 200ms), Availability (99.99%), Scalability, Reliability, Consistency, Durability, Security, Maintainability.
03
Latency is about user-perceived speed; throughput is about how many requests fit through.
04
Availability = uptime / total time. 99.9% = ~8.7h/year of downtime; 99.99% = ~52min/year.
05
Consistency spectrum: strong → eventual. Pick per-component, not globally.
06
Durability: data survives node loss — replication + backups + WAL are mechanisms.
07
Security: authn (who), authz (what they may do), encryption in transit and at rest.
08
Maintainability: can a new engineer deploy, debug, and extend without tribal knowledge?
09
Interview tip: when the prompt is thin ('design a chat app'), invent NFRs and say them out loud — that is the design brief.

Java / Spring map

→
In a Spring Boot service, latency numbers come from p99 metrics (Micrometer + Prometheus).
→
Durability maps to @Transactional + WAL in Postgres/MySQL, availability maps to replica config.

Code & diagrams

requirements shape the designdiagram

Rendering diagram…

AvailabilityMath.mdmarkdown

Memorize the nines, then learn how dependencies multiply them.

Nines      Downtime / year   / month    / week
99%        3.65 days         7.2 h      1.68 h
99.9%      8.76 h            43.8 min   10.1 min
99.95%     4.38 h            21.9 min   5.04 min
99.99%     52.6 min          4.38 min   1.01 min
99.999%    5.26 min          26.3 s     6.05 s

SERIAL dependencies multiply (all must be up):
  API 99.9% × DB 99.9% × Cache 99.9%  = 99.7%  (~26 h/year down)

PARALLEL redundancy (any one up is enough):
  1 − (1 − 0.99)²  = 99.99%   two independent 99% replicas
  → only true if failures are INDEPENDENT (different racks/AZs)

Rule: an SLO can never exceed the product of its hard dependencies.
      Want 99.99% on top of a 99.9% dependency? Make it soft
      (cache, fallback, async) or add redundancy.

Explain without notes

Which NFR does a cache improve, and which NFR does it hurt?

Why is 99.99% availability 'unsolvable' with a single server?

Your service calls four 99.9% dependencies synchronously. What is your best possible availability, and name two ways to raise it?

Practice

Write functional + NFRs for URL shortener, then for a payment system. Compare your lists.

Trade-offs

↔
Favor consistency → higher latency, lower availability during partitions.
↔
Favor durability → more writes, more cost.
↔
Favor low latency → caches, eventual consistency, more moving parts.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

SRE · Negotiating SLOs

Turning non-functional requirements into measurable SLOs.

Stateful · Load testing with k6

Open vs closed models and SLO thresholds that gate CI.

Completion checklist

I can list all 8 NFRs and give a mechanism for each.

Back to phase

Command Palette