Functional & Non-Functional Requirements

Foundations

A system design starts from requirements, not boxes. Functional requirements are the verbs users perform, each with an observable result, such as create an item or fetch it. Non-functional requirements are the qualities those verbs must keep, stated as numbers: a latency target such as 50 ms, an availability such as 99.9%, a durability rule such as never lose a write.

Requirements also decide what is not built. Test each tempting extra against the busiest request path: if it adds work to every call of the hottest verb, such as a write on every read, it is a real cost that needs an explicit decision. Writing declined extras on an out-of-scope list keeps the design honest about what it answers.

Take a service with two verbs, create(item) and get(id). Its quality lines might read: get under 50 ms, items never lost, 99.9% availability. A request to count every get sounds small, but it adds a write to the hottest call, so it goes on the out-of-scope list unless someone accepts that cost.

Case Scenario

To see how requirements shape a design before any box is drawn, consider a URL shortener like bit.ly: an owner turns a long URL into a short code, and a visitor opening that code is redirected to the original address. Creating and redirecting are the verbs; redirects under 50 ms and never losing a mapping are the qualities, and click counts are the tempting extra.

A shortener begins with two small user actions, but one extra sentence can change the busiest request. If “show click counts” is accepted casually, every redirect gains work that was never budgeted; custom domains and abuse detection widen the design again. The team needs a firm boundary: create and redirect are in scope, redirects stay under 50 ms, mappings are durable, and click counts must not add a write to the redirect path.

The Pattern

For this shortener, scope create and redirect, require redirects under 50 ms and durable mappings, and defer click counts, custom domains, and abuse detection; click counts are the request that threatens a write on every redirect.

Treat each user action as a functional requirement: an owner creates a short link and a visitor opens it. State observable results and failures, not components. The redirect target is under 50 ms, mappings are never lost, and availability gets a number such as 99.9%.

Pressure-test extras against the request path. Click counts require work on every open, while custom domains and abuse detection introduce separate concerns. Record those as non-goals so the finished design answers the agreed problem and each boundary can be revisited explicitly.

What you leave with

A list this short fits a 45-minute design. Each number should be one a reviewer could argue with, such as 50 ms or 99.9%, because those are the numbers that later decide caches, replicas, and queues.