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.
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
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.
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 |
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?"
Prioritizing Requirements
Not all requirements are equal. Use the MoSCoW method to prioritize:
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 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 |
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
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.