Understanding Requirements

Before designing any system, you must understand what you are building and why you are building it. Misunderstood requirements can lead to overengineering, wasted effort, or an unusable product.

If I had an hour to solve a problem, I would spend 55 minutes thinking about the problem and 5 minutes on the solution — Einstein.

What Are Requirements?

Requirements are detailed descriptions of what a system should do and how it should behave. They act as a blueprint for developers, designers, and stakeholders.

Types of Requirements

Requirements are usually split into two categories:

1️⃣ Functional Requirements (FRs)

These describe what the system should do – the features and operations.

Examples:

• User can log in and log out.
• Users can upload and share photos.
• The system sends email notifications.
• Users can search for other users by username.

They capture the features and behavior of the system.

2️⃣ Non-Functional Requirements (NFRs)

These describe how well the system performs under certain conditions. They focus on quality, performance, and constraints.

Examples:

• Scalability: System must handle 10,000 concurrent users
• Latency: API should respond within 200ms
• Availability: should be 99.99%
• Reliability: The service should consistently returns correct and expected results.
• Security: Data should be encrypted in transit
• Consistency: Strong or eventual consistency depending on use case
• Efficiency: Minimize redundant operations and optimize resource usage.

They capture the constraints and expectations for the system.

Why Understanding Requirements Is Critical

1 Prevents Miscommunication

• Without clear requirements, developers and stakeholders may have different expectations.
• Miscommunication can lead to features that don't match user needs.

2 Guides Design & Architecture

• Requirements determine the architecture of the system.
• For example, a social media app with millions of users require a distributed system design, while a simple offline desktop tool does not.

3 Helps in Prioritization

• Not all features are equally important.
• Understanding core requirements helps team focus on what delivers value first.

4 Reduce Cost of changes

• Identifying requirements early reduces costly rework later in the development cycle.

Steps to Understand Requirements

When starting a design, ask structured questions:

Step 1: Clarify the Objective | Problem Statement

Ask:

• What is the purpose of the system?
• Who are the end users?
• What is the main business value?

Step 2: Define the Core Features (Functional Requirements)

List the primary operations your system must support.

What are the must-have user flows?

• Core features (must-have)
• Optional features (nice-to-have)
• Out-of-scope (explicitly excluded)

Step 3: Identify Non-Functional Requirements (Performance, Security, Scale)

Ask:

• How many users will be using this?
• What is the expected request volume?
• Is it real-time or eventual?
• What are the SLAs (Service Level Agreements)?

Step 4: Understand Constraints | Trade-offs

These could be:

• Technology limitations (e.g., must use MySQL)
• Do we prioritize consistency or availability?
• Do we optimize for low cost or high performance?
• Do we support all platforms or focus on one?
• Compliance rules (e.g., GDPR)
• Budget or timeline

Examples

1 Designing a Ride-Sharing App (Requirements Stage)

Functional Requirements:

• Riders can request rides.
• Drivers can accept/reject rides.
• Payments are processed through the app.
• Riders can see driver location in real-time.

Non-Functional Requirements:

• Must handle peak traffic (Office hours, National festivals, surge demand)
• Location updates should have < 2s latency
• Uptime of 99.9%
• Payment system must be secure & PCI compliant

Notice how defining these requirements early shapes the entire architecture – from using real-time location tracking systems to secure payment gateways.

Common Mistakes in Requirement Gathering

• Jumping straight into databases/tech stack before clarifying needs
• Ignoring non-functional requirements (often more critical than features)
• Overlooking edge cases (e.g., “What if a driver cancels mid-ride?”)
• Not aligning with business goals (building features nobody asked for)

Final Takeaway

Understanding requirements is the most critical step in system design.

• Functional requirements define what to build.
• Non-functional requirements define how it should perform.

If you skip this step, your design being over-engineered, under-engineered, or solving the wrong problem altogether.

Resources

1. System Design Template