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
Leave a comment
Your email address will not be published. Required fields are marked *