Functional vs Non-functional Requirements

FRs describe WHAT the system does. NFRs describe HOW WELL. Miss either and you're designing in the dark.

How It Works

Functional requirements (FRs) are capabilities — what the system must DO. "Users can post messages." "Admins can delete content." "Orders can be refunded." Non-functional requirements (NFRs) are qualities — how well it must do those things. "p99 latency under 200ms." "99.99% availability." "Support 100K concurrent users." "No data loss." Why separating them matters: FRs drive component boundaries and data model; NFRs drive scaling strategy and technology choices. A system with vague NFRs ends up over-engineered for the wrong metric (cost-optimized when latency matters, or vice versa). In interviews, after naming FRs, explicitly ask the interviewer OR state NFRs yourself — candidates who skip this and jump to architecture look like they're pattern-matching on memorized answers, not designing.

Real-World Example

When WhatsApp was built, the functional requirements were minimal — send a text message, receive a text message, show delivery status. The non-functional requirements were extreme — global delivery in under 500ms, work on 2G connections, 2 billion concurrent users. Those NFRs drove every architectural choice: Erlang for the connection layer (tested at 20M simultaneous connections), binary XMPP instead of verbose JSON (saved bandwidth on 2G), careful memory-per-connection budgeting. Get the NFRs wrong and you design the wrong system even with correct FRs — the functional spec alone doesn't tell you whether you need Erlang or Ruby on Rails.