Functional vs Non-Functional Requirements
Functional requirements describe what the system does. Non-functional requirements describe how well it does it. Confusing the two is the most common rookie mistake in system design.
The split that decides everything
Before you draw a single box, before you pick a single technology, you need to know two things: what the system has to do, and how well it has to do it. The first is functional requirements. The second is non-functional. Get these clear and the design follows. Get them muddled and you will build the wrong thing well, or the right thing badly.
Functional requirements (FR)
These are the user-visible features. Things you could write as a sentence ending in a verb the user performs.
For a URL shortener, the functional requirements look like:
- Users can submit a long URL and get back a short URL.
- Visiting the short URL redirects to the long URL.
- Users can see the click count for their links.
- Users can set a custom alias.
That's it. Notice none of these say anything about how fast, how scalable, or how secure. They just describe behavior.
Non-functional requirements (NFR)
These describe the qualities the system must have while doing the functional things. They are the constraints that make architecture necessary.
For the same URL shortener:
- The system must serve 100 million redirects per day.
- Redirects should resolve in under 100ms at the 99th percentile.
- The service should be available 99.99% of the time.
- Short URLs must never collide.
- Click counts can be a few seconds stale; that's acceptable.
This is where architecture lives. The functional requirement says "redirect a URL". The non-functional requirement says "do it 100 million times a day, in under 100ms, with four nines of uptime, while keeping the IDs unique". Those NFRs are why you need a cache, a CDN, a distributed ID generator, and replication.
The categories of NFRs you actually need to ask about
In an interview or design review, walk through this checklist. You will not need every one for every system, but you should know which apply.
| Category | Example question |
|---|---|
| Scale | Daily active users? Peak QPS? Storage growth per year? |
| Latency | p50, p95, p99 targets for each user-facing flow? |
| Availability | How many nines? Is downtime measured per region? |
| Consistency | Strong, eventual, or read-your-writes? Per operation? |
| Durability | Can we lose any data on a crash? Within how many seconds? |
| Security | Auth, encryption at rest and in transit, audit logging? |
| Compliance | GDPR, HIPAA, PCI? Data residency requirements? |
| Cost | Budget envelope? Cost per user limit? |
The hidden requirements nobody mentions
Here is what separates seniors from juniors. Seniors ask about the requirements no one wrote down.
Operational requirements. Who runs this at 3 AM? How does on-call see what's wrong? Can we deploy without downtime? Can we roll back in 5 minutes? If the answer to any of these is "we'll figure it out later", later costs ten times more than now.
Evolution requirements. What features will likely be added in the next year? Designing for "we will never need that" is how monoliths become unmaintainable. Designing for every imaginable future is how you build a configuration server when you needed a CRUD app. Aim for the middle.
Failure requirements. What happens when (not if) the database goes down? When the network partitions? When a downstream API returns 500s for an hour? "It throws an exception" is not an answer.
How to gather requirements in a real meeting
The product manager almost never gives you NFRs. They give you FRs and assume the system "just works fast". You have to extract NFRs by asking. Three questions usually unlock the conversation:
- How many users do you expect in year one? This anchors scale.
- What is unacceptable downtime for the business? This anchors availability.
- Which feature is the most painful for the user if it is slow? This anchors latency priorities.
From those three answers you can usually back into all the other NFRs.
Walking through a real example
Imagine your PM says: "We need to build a comment system for our blog."
A junior engineer hears that and starts thinking about MongoDB schemas.
A senior engineer asks:
- How many comments per post on average? Top of distribution?
- How fast does a new comment need to appear for the author? For other readers?
- Do we need threaded replies? How deep?
- Do we moderate before or after publishing?
- What happens to comments if a post is deleted?
- Do users need to edit or delete their own comments?
- How long do we retain comment data?
- Are there legal requirements (CSAM scanning, takedown requests)?
Now you have an actual specification. Half the questions reveal product decisions the PM had not even thought about. That is the value of this step. You are not just designing a system, you are designing the conversation that produces the system.
Walk-away rules
Before you build anything, force yourself to write FRs and NFRs separately. Two columns on a page. If a "requirement" can fit in either column, it is too vague to be useful. Sharpen it until it lands clearly in one. Only then do you start drawing boxes.