Functional requirements describe what the system does: create an order, upload a file, send a message, search products, or follow a user.

Non-functional requirements describe how well it must operate.

Attribute	Interview question	Typical design implications
Latency	How quickly must a request complete?	Caching, indexing, locality, async processing
Throughput	How many operations per second?	Horizontal scaling, batching, partitioning
Availability	What fraction of time must it work?	Redundancy, failover, graceful degradation
Durability	Can acknowledged data be lost?	Replication, persistent logs, backups
Consistency	How quickly must writes become visible?	Strong reads, quorum protocols, coordination
Scalability	How does capacity grow with load?	Stateless services, partitioning, autoscaling
Security	Who may access which data?	Authentication, authorization, encryption, audit logs
Maintainability	How safely can the system evolve?	Clear boundaries, automation, testing, observability

Clarify the scope: distinguish must-have requirements from optional features. For example, a URL shortener may require creating and resolving links, while analytics, custom aliases, and expiration policies may be secondary.

Translate vague goals into measurable targets: replace 'fast' with a target such as p95 latency below 200 ms for a specified operation; replace 'highly available' with a defined availability objective. Targets depend on the product and must be agreed upon rather than assumed.

Prioritize quality attributes: some goals conflict. Strong consistency can increase latency or reduce availability during network partitions. Durability and multi-region recovery can increase cost. State which requirements dominate.