System Design: A Checklist for Gathering and Documenting Requirements for All Occasions

Why Are Requirements So Important?

Gathering and defining requirements is the foundational first step in any system design process. It's not a step you can skip, as the quality of your final solution — whether in an interview or a real-world project — depends entirely on how well you establish these initial requirements.

Think of requirements as the blueprint for your system. They dictate what the system must do, how it should perform, and under what constraints. Without a clear blueprint, the design process becomes chaotic, which can lead to:

A non-functional architecture that can't handle the load or meet business needs.
Wasted resources from unnecessary complexity and expensive, unjustified technology choices.
Failure to meet business goals because the system doesn't solve the right problems.

A startup built a monolith, but a year later, it needed to scale. They spent two months urgently breaking it down into microservices—a costly and time-consuming fix that could have been avoided.
Real-world example

In essence, requirements connect business goals with technical implementation. Neglecting them in a system design interview is a near-guaranteed path to failure, even if your technical solution is brilliant.

The interviewer asks, "Design a URL shortening service." You immediately start drawing a sharded database, a global CDN, and redundant data centers. But what if the service is only for internal use with a load of 100 RPS? Your solution is overkill and expensive. The interviewer will ask, "Why do you need six servers when one would suffice?" and you'll lose points for an inadequate assessment.
Interview scenario

Don't rush into drawing diagrams. System design is about finding unique solutions, not applying generic templates. Without clarifying requirements, you're navigating a dark forest at night with your eyes closed, hoping to find a way out.

A Framework for Clarifying Requirements

Let's imagine you're in an interview, and the prompt is to design a marketplace. Instead of jumping to solutions, use a structured approach to ask targeted questions. Here's a checklist to guide you.

1. Functional Requirements

What are the core features the system must support?
Which use cases are the highest priority?
Are there any specific data constraints, like maximum file upload sizes?

Is a full-text search for products required, or is filtering by category sufficient? Is the system more read-heavy (browsing products) or write-heavy (placing orders)?
Example questions

2. Non-Functional Requirements

Scalability: What is the expected peak user load? What is the projected growth over the next year?
Availability: What is the required uptime (e.g., 99.9%)? Which components must be fault-tolerant?
Consistency: Is strong consistency required, or is eventual consistency acceptable for some data?
Performance: What is the acceptable response time for key APIs, like search? Is real-time support needed?

3. Data Characteristics

Volume: How many new orders are expected per day? What is the average size of a product record in the database?
Access Patterns: How often is product data updated? Are there any hot records that are accessed frequently?
Storage: Do old orders need to be archived? What is the data retention policy for logs?

4. Integrations and Security

Will the system integrate with external services like a payment processor or CRM? What are their API rate limits? Does data need to be encrypted? Is authentication required for all endpoints?
Example questions

5. Constraints and Assumptions

Infrastructure: Can we use cloud services (AWS/GCP), or are we limited to on-premise hardware?
Technology Stack: Are there restrictions on the database (e.g., only relational, or can we use NoSQL)?
Scope: Are we designing only the backend, or should the design include the CDN and caching layers?

Quick Interview Checklist

Functions: What are the MUST-HAVE vs. NICE-TO-HAVE features?
Scale: What are the peak loads, data growth projections, and geo-distribution needs?
Reliability: What is the SLA? What is the acceptable downtime? Are backups required?
Data: Clarify the volume, update frequency, and read/write patterns.
Integrations: Identify dependencies on external services.
Constraints: Are there any budget, timeline, or technology stack limitations?
Future: How might user traffic or feature needs evolve over time?

Final Tips

1. Think Aloud

Verbalize your assumptions. This gives the interviewer a chance to correct you and shows your thought process.

"I'm assuming that product search will account for 80% of the load, so I propose using a dedicated Elasticsearch index for it."

2. Use the 5W Method

Frame your questions around Who (users?), What (data?), Where (geo-distribution?), When (peak hours?), and Why (the system's core purpose?).

Sample Interview Dialogue

Candidate: "You mentioned that the system must display an up-to-date inventory. Does this mean we need strong consistency for inventory updates, or is a small window of inconsistency—say, 1-2 seconds—acceptable?"

Interviewer: "Eventual consistency with a delay of up to 5 seconds is acceptable."

Candidate: "Great. In that case, I propose using Cassandra for the inventory, with a Redis cache, to balance performance and consistency."