Functional and Non-Functional Requirements

Requirements define what a system must do and how well it must do it. Functional requirements describe behavior: the operations users and other systems can perform. Non-functional requirements (also called quality attributes) describe measurable properties of that behavior: how fast, how available, how consistent, how durable, how secure. Architecture is driven mostly by the non-functional requirements, because many designs can satisfy the same functional list.

Functional requirements

A functional requirement names an actor, an action, and a result: "a user posts a message and followers see it in their feed".

Guidelines for gathering them:

• Write them as short verbs plus nouns: create link, follow user, upload file, search product.
• Prioritize. Keep the two to four core flows and state the rest as out of scope.
• Identify actors: end users, administrators, other services, external partners.
• Identify the read and write operations separately, since they usually scale differently.
• Ask about data lifetime: is data kept forever, or deleted after a retention period?

flowchart TD
    P["Vague prompt"] --> Q["Clarifying questions"]
    Q --> F["Functional list: core flows"]
    Q --> N["Non-functional targets"]
    Q --> O["Out of scope"]
    F --> D["Design"]
    N --> D

Non-functional requirements

Latency and throughput

Latency is measured per request and reported as percentiles: p50 (median), p95, p99. Averages hide slow requests, so percentiles are used. A p99 of 200 ms means 99 percent of requests complete within 200 ms and 1 percent are slower. Fan-out amplifies the tail: if a request calls 100 backends in parallel and each backend is slow on 1 percent of calls, the probability that at least one call is slow is 1 - 0.99^100, about 63 percent. Throughput is measured in requests per second (QPS) or bytes per second. The two are related but not interchangeable: batching increases throughput and typically increases latency for individual items.

Availability

Availability is the fraction of time a service is operational. It is expressed in "nines":

The requirement should state which operations must stay available. Redirects in a URL shortener may need 99.99 percent, while link creation may tolerate less.

Consistency

Consistency here means whether reads reflect the most recent writes across replicas. Strong consistency means every read returns the latest acknowledged write. Eventual consistency means replicas converge if writes stop, but reads may return stale data in the meantime. Financial balances and inventory counts commonly require strong consistency. Like counts and feed ordering commonly tolerate eventual consistency. See consistency models for precise definitions.

Durability

Durability means an acknowledged write survives failures. It is achieved by writing to non-volatile storage (a write-ahead log) and replicating to more than one machine or failure domain before acknowledging. Durability is separate from availability: a system can be down and still not have lost data.

Scalability

State the expected growth: users, requests, data volume, over a time horizon. This determines whether the design must be partitioned from the start or can begin on a single primary database.

Security

Ask what must be protected and from whom: authentication, authorization, encryption of data in transit and at rest, audit logging, and regulatory constraints such as data residency.

Trade-offs between attributes

Non-functional requirements conflict. Stating a target for each makes the conflicts visible.

Worked example: photo feed

Prompt: "design a photo-sharing feed". Clarifying answers produce the following list.

Each row maps to a decision. Eventual consistency for feeds permits precomputed feeds and asynchronous fan-out through a queue. Durability of uploads requires replicated object storage before acknowledgment. The 99.9 percent target on reads permits a monthly downtime budget of about 43 minutes, which requires redundancy but not multi-region active-active deployment.

Turning requirements into design decisions

• Read-heavy with relaxed consistency: caching, read replicas, CDN.
• Write-heavy: partitioning, log-structured storage, asynchronous processing through queues.
• Strict consistency on a small dataset: a single leader with synchronous replicas or a consensus-based store.
• High availability: redundancy at every layer, no single points of failure, health checks and failover.
• Low latency for global users: data and compute placed near users, caching at the edge.

Interview questions

• Why are non-functional requirements more important than functional ones for architecture? Functional requirements determine which operations exist. Non-functional requirements determine the load, the failure tolerance, and the data guarantees, which decide storage, replication, and partitioning choices.
• Why use percentiles instead of average latency? A small fraction of slow requests is invisible in the mean but affects users, particularly when a request fans out to many backends and the slowest response determines total latency.
• What is the difference between availability and durability? Availability is whether the service responds now. Durability is whether committed data persists. A system can be unavailable temporarily without losing data.
• How should conflicting requirements be handled? State the priority explicitly per operation. For example, choose strong consistency for payments and eventual consistency for view counts within the same product.