Functional vs Non-Functional Requirements in System Design

Functional vs Non-Functional Requirements in System Design

Every successful system begins with well-defined requirements. In system design, requirements fall into two fundamental categories: functional requirements that define what the system does, and non-functional requirements that define how well the system performs. Confusing or neglecting either category is one of the most common reasons systems fail in production or interviews go sideways.

This guide covers both types in depth, shows you how to extract them from vague problem statements, and walks through real-world examples from companies like Netflix, Uber, and Twitter.

What Are Functional Requirements?

Functional requirements describe the specific behaviors, features, and capabilities a system must provide. They answer the question: "What should the system do?" These are the features your users interact with directly.

Functional requirements are typically expressed as user stories or use cases:

• A user can create an account with email and password
• The system sends a confirmation email after registration
• Users can search for products by name, category, or price range
• The system calculates and displays the total price including tax
• An admin can ban a user account

Functional requirements are testable and binary — the system either supports the feature or it does not. They form the core contract between the engineering team and stakeholders.

What Are Non-Functional Requirements?

Non-functional requirements (also called quality attributes or system qualities) describe how the system performs its functions. They define constraints on performance, scalability, availability, security, and other cross-cutting concerns.

Examples of non-functional requirements:

• The system must handle 10,000 concurrent users
• Page load time must be under 200 milliseconds
• The system must be available 99.99% of the time
• All user data must be encrypted at rest and in transit
• The system must comply with GDPR regulations

Non-functional requirements often determine the architecture of a system. A system that must handle 100 users per day has a very different architecture than one that must handle 100 million. The functional requirements might be identical.

Comparison Table

Categories of Non-Functional Requirements

Non-functional requirements span many dimensions. Here are the most important ones for system design:

Performance

Latency and throughput are the two key performance metrics. Latency measures how long a single request takes. Throughput measures how many requests the system handles per unit of time. These often trade off against each other.

Scalability

Can the system handle growth? Horizontal scaling adds more machines while vertical scaling adds more power to existing machines. Your scalability requirements determine whether you need a simple monolith or a distributed architecture.

Availability

High availability means the system remains operational even when components fail. This is measured in "nines" — 99.9% availability allows about 8.7 hours of downtime per year while 99.99% allows only 52 minutes.

Consistency

Do all users see the same data at the same time? Consistency models range from strong consistency (all reads reflect the latest write) to eventual consistency (reads may lag behind writes temporarily). The CAP theorem forces trade-offs here.

Security

Authentication, authorization, encryption, audit logging, and compliance with regulations like GDPR or HIPAA. Security requirements often add significant complexity to the architecture.

Durability

Once data is written, it must not be lost. This requires replication across multiple storage locations and regular backups. Financial systems often require zero data loss, which demands synchronous replication.

How to Extract Requirements from Vague Problem Statements

In interviews and real projects, requirements are rarely handed to you clearly. You must extract them through questions. Here is a systematic approach:

Vague Statement: "Design a chat application"

Step 1: Identify Users and Use Cases
  - Who uses it? Individuals, groups, businesses?
  - One-on-one chat? Group chat? Channels?
  - Text only? Or also images, video, files?

Step 2: Extract Functional Requirements
  - Users can send text messages to other users
  - Users can create group chats with up to 500 members
  - Users see typing indicators and read receipts
  - Messages support text, images, and file attachments
  - Users can search message history

Step 3: Extract Non-Functional Requirements
  - Message delivery latency under 200ms
  - Support 50 million daily active users
  - Messages must never be lost (durability)
  - 99.99% availability
  - End-to-end encryption for all messages

Step 4: Identify Constraints
  - Must work on mobile (iOS/Android) and web
  - Must comply with data retention regulations
  - Budget constraints for infrastructure

Real-World Examples

Netflix

Notice how Netflix's non-functional requirements drive major architectural decisions. The need for global low-latency streaming led them to build Open Connect, their own CDN with thousands of servers worldwide. The need for 99.99% availability led them to pioneer chaos engineering with tools like Chaos Monkey.

Uber

Uber's non-functional requirements create interesting trade-offs. Location tracking requires high throughput for millions of updates per second, favoring eventual consistency. But payment processing demands strong consistency — you cannot charge a rider twice or pay a driver the wrong amount.

Twitter

Twitter's functional requirement of "users can post tweets visible to their followers" seems simple, but the non-functional requirement of "a tweet by a celebrity with 50 million followers must appear in all follower timelines within 5 seconds" is what makes the architecture complex. This led Twitter to build a fan-out-on-write system for most users but fan-out-on-read for celebrities — a hybrid approach driven entirely by non-functional constraints.

Trade-offs Between Requirements

Requirements often conflict with each other. Recognizing and navigating these conflicts is a key skill in system design.

• Consistency vs. Availability: The CAP theorem proves you cannot have both during network partitions. Banking systems choose consistency. Social media chooses availability.
• Latency vs. Durability: Writing to multiple replicas increases durability but adds latency. Writing to memory is fast but risks data loss.
• Cost vs. Performance: Running servers in 20 regions gives low latency globally but costs significantly more than a single region.
• Security vs. Usability: Multi-factor authentication improves security but adds friction to the user experience.

Example: E-commerce Inventory Check

Option A: Strong consistency (always accurate stock count)
  - Every read checks the primary database
  - Higher latency (50-100ms per product page)
  - Never shows "in stock" for sold-out items

Option B: Eventual consistency (slightly stale stock count)
  - Reads from cache/replica (5-10ms per product page)
  - May occasionally show "in stock" briefly after selling out
  - Handle with: "Sorry, item became unavailable" at checkout

Most e-commerce sites choose Option B for browsing,
Option A for the actual purchase transaction.

Common Mistakes When Defining Requirements

• Being too vague: "The system should be fast" is not a requirement. "P99 latency under 200ms" is.
• Ignoring non-functional requirements: A system that does everything correctly but takes 30 seconds per request is useless.
• Gold-plating: Requiring 99.999% availability when 99.9% is sufficient wastes enormous engineering effort and money.
• Not prioritizing: Not all requirements are equally important. Use MoSCoW (Must, Should, Could, Won't) to prioritize.
• Assuming requirements are static: Requirements evolve. Design your system to be flexible where requirements are likely to change.

Requirements in System Design Interviews

In interviews, always spend the first 5 minutes clarifying requirements. This demonstrates maturity and prevents you from designing the wrong system. Use this checklist:

Interview Requirements Checklist:

1. Core use cases (2-3 main features)
2. User scale (DAU, MAU)
3. Traffic patterns (read-heavy? write-heavy? bursty?)
4. Data scale (how much data? growth rate?)
5. Latency expectations
6. Availability target
7. Consistency needs (strong? eventual?)
8. Geographic distribution
9. Any specific constraints (budget, compliance, existing infra)

For more on building reliable systems that meet their requirements, explore System Design Basics and SLA, SLO, and SLI.

Frequently Asked Questions

How many requirements should I define in a system design interview?

Focus on 3-5 functional requirements and 3-5 non-functional requirements. You do not need an exhaustive list — what matters is demonstrating that you think about both categories and can prioritize. The interviewer wants to see that your architecture decisions are driven by requirements.

Which is more important, functional or non-functional requirements?

Both are equally important but serve different purposes. Functional requirements determine what you build. Non-functional requirements determine how you build it. A system that meets all functional requirements but crashes under load is just as useless as one that is perfectly scalable but missing core features.

How do non-functional requirements affect cost?

Each additional "nine" of availability roughly doubles your infrastructure cost. Going from 99.9% to 99.99% requires redundancy, multi-region deployment, and sophisticated failover mechanisms. Always match your non-functional targets to actual business needs. Not every system needs to be as available as a pacemaker.

Can functional requirements be non-functional and vice versa?

The line can blur. "The system must send an email within 5 minutes of registration" has both a functional component (sending email) and a non-functional component (within 5 minutes). In practice, it is more useful to separate the behavior (what happens) from the quality (how fast or reliably it happens).

How do requirements change as a system grows?

Early-stage systems focus on functional completeness — get the features right. As the user base grows, non-functional requirements become dominant. A startup with 100 users does not need to worry about global CDNs, but Netflix with 200 million subscribers does. Design for your current scale with a clear path to the next order of magnitude.