Interview Prep
Requirements Gathering
Requirements gathering is the foundation of system design. A well-defined problem is half-solved. Learn to ask the right questions that reveal the true constraints and shape the architecture.
- Clarity — Transform vague problems into concrete specifications
- Categorization — Separate functional from non-functional requirements
- Prioritization — Focus on what matters most for the design
The quality of your design is bounded by the quality of your requirements.
The Requirements Matrix
Requirements fall into a structured matrix that guides every subsequent design decision.
DfRequirements Engineering
Requirements engineering is the process of defining, documenting, and maintaining requirements for a system. In system design interviews, it means eliciting both functional and non-functional requirements, understanding their relationships, and identifying constraints that limit the solution space.
Functional Requirements: What the System Does
Functional requirements define the system's behavior—what users and other systems can do.
| Category | Examples | Impact on Design |
|---|---|---|
| Core Features | User registration, posting, search | Defines API surface |
| Data Operations | CRUD, bulk operations, imports/exports | Shapes data model |
| Integrations | Payment gateways, third-party APIs | Introduces external dependencies |
| User Roles | Admin, regular user, guest | Requires authorization model |
Eliciting Functional Requirements
Ask these questions systematically:
- Who are the users? Different user types have different needs
- What are the core use cases? The top 3-5 operations that define the system
- What data flows through the system? Entities, relationships, volume
- What are the edge cases? Error states, concurrent operations, failure modes
Interviewers often provide a deliberately incomplete problem statement. Candidates who only address the obvious use cases miss an opportunity to demonstrate thoroughness. Proactively ask about edge cases, error handling, and secondary features.
Non-Functional Requirements: How the System Behaves
Non-functional requirements (NFRs) define the quality attributes of the system. They are the primary drivers of architectural decisions.
DfQuality Attributes
Quality attributes are the non-functional characteristics that determine how well a system performs its functions. They include performance, scalability, availability, reliability, security, and maintainability. Each quality attribute has specific measurable metrics and trade-offs with other attributes.
The SCALE Framework
Use this framework to systematically capture NFRs:
| Attribute | Metrics | Common Targets |
|---|---|---|
| Scalability | Concurrent users, QPS, data growth | 1M users, 10K QPS, 2x annual growth |
| Consistency | Read-after-write, eventual lag | Strong for payments, eventual for feeds |
| Availability | Uptime percentage, MTTR | 99.99% (52 min/year downtime) |
| Latency | P50, P95, P99 response times | P99 < 200ms |
| Elasticity | Auto-scaling speed, burst capacity | Scale to 10x in 5 minutes |
Availability Calculation
Here,
- =Availability as a fraction
- =Mean Time Between Failures
- =Mean Time To Repair
Availability Targets in Practice
For 99.99% availability (four nines):
Allowed downtime per year: 52.6 minutes Allowed downtime per month: 4.38 minutes Allowed downtime per week: 1.01 minutes
This requires redundant everything: load balancers, application servers, databases, network paths. A single database without failover cannot achieve this.
The Constraint Space
Beyond functional and non-functional requirements, constraints limit your solution space:
Types of Constraints
| Constraint | Examples | Impact |
|---|---|---|
| Technical | Existing tech stack, legacy systems, specific databases | Limits technology choices |
| Business | Budget, timeline, team size, market requirements | Limits scope and complexity |
| Regulatory | GDPR, HIPAA, data residency, audit requirements | Forces specific patterns |
| Operational | Current deployment pipeline, on-call capacity | Limits operational complexity |
The Requirements Conversation Template
Use this template to guide your conversation with the interviewer:
Opening Questions
- "Can you describe the system's primary use case?"
- "Who are the main user groups?"
- "What is the expected scale—users, data, QPS?"
Depth Questions
- "What consistency guarantees are needed?"
- "What are the latency requirements for the critical path?"
- "What is the expected data growth rate?"
Constraint Questions
- "Are there any existing systems this must integrate with?"
- "What is the timeline for this project?"
- "Are there regulatory requirements we need to consider?"
Don't ask all questions at once. Ask a few, propose a preliminary design, then ask more targeted questions as you learn more. This demonstrates iterative thinking and keeps the conversation dynamic.
Prioritizing Requirements
Not all requirements are equal. Use the MoSCoW method to prioritize:
DfMoSCoW Prioritization
MoSCoW is a prioritization technique that categorizes requirements into four groups:
- Must Have: Critical for the system to function; the system fails without them
- Should Have: Important but not vital; the system works without them
- Could Have: Desirable enhancements; improve user experience
- Won't Have: Explicitly out of scope for this iteration
Prioritization Example: URL Shortener
| Priority | Requirement | Rationale |
|---|---|---|
| Must | Create short URLs | Core functionality |
| Must | Redirect to original URL | Core functionality |
| Should | Custom aliases | Differentiator |
| Should | Analytics on clicks | Business value |
| Could | QR code generation | Nice to have |
| Won't | Enterprise admin panel | Out of scope |
From Requirements to Architecture
Requirements directly map to architectural decisions:
Requirement-to-Architecture Mapping
Here,
- =The resulting system design
- =Functional and non-functional needs
- =Limitations on the solution space
| Requirement Pattern | Architectural Implication |
|---|---|
| High read throughput | Read replicas, caching, CDN |
| Strong consistency | Synchronous replication, distributed transactions |
| Global availability | Multi-region deployment, conflict resolution |
| Real-time updates | WebSockets, server-sent events, message queues |
| Complex queries | Document database or search engine |
Failing to identify a critical requirement early can invalidate your entire design. If you discover during the deep dive that the system needs strong consistency but you designed for eventual consistency, you'll need to backtrack significantly. This is why thorough requirements gathering is essential.
Practice Exercises
-
Requirements Elicitation: A friend asks you to design a "simple" chat application. Write down 15 questions you would ask to clarify the requirements. Categorize each as functional, non-functional, or constraint.
-
Prioritization Exercise: For a ride-sharing app, list 10 features and prioritize them using MoSCoW. Justify each prioritization decision.
-
Constraint Analysis: Given a system that must comply with GDPR, list all the architectural implications this constraint introduces. How does it change your data model, storage, and access patterns?
-
Requirements to Architecture: For each of these requirements, identify the primary architectural decision it drives:
- 99.99% availability
- P99 latency < 100ms
- Support 1M concurrent users
- Strong consistency for financial transactions
Key Takeaways:
- Requirements fall into three categories: functional, non-functional, and constraints
- Use the SCALE framework to systematically capture non-functional requirements
- Prioritize using MoSCoW to focus design effort on what matters most
- Requirements directly map to architectural decisions—identify them early
- Don't ask all questions at once; iterate as you learn more about the system
What to Learn Next
-> Estimation Techniques Master back-of-the-envelope calculations for capacity planning.
-> High-Level Design Techniques for sketching system architecture quickly and clearly.
-> Deep Dive Design Methods for diving deep into critical system components.
-> System Design Interview Framework The five-phase framework for structured system design interviews.
-> Databases SQL vs NoSQL, indexing, replication, and sharding.
-> API Design REST, GraphQL, gRPC, versioning, and rate limiting.