Requirements analysis in LLD - Deep Dive

Overview - Requirements analysis

What is it?

Requirements analysis is the process of understanding and documenting what a system must do. It involves gathering needs from users and stakeholders, then organizing these needs clearly. This helps ensure the system built matches what people actually want and need.

Why it matters

Without requirements analysis, systems often miss key features or have confusing designs that don't solve real problems. This leads to wasted time, money, and unhappy users. Good requirements analysis saves effort by guiding design and development with clear goals.

Where it fits

Before requirements analysis, learners should know basic communication and problem-solving skills. After this, they can learn system design, architecture, and implementation. Requirements analysis is the bridge between understanding problems and building solutions.

Mental Model

Core Idea

Requirements analysis is like creating a clear, shared map of what a system must do before building it.

Think of it like...

Imagine planning a road trip with friends: you first discuss where everyone wants to go, what stops to make, and how long the trip should take. This shared plan avoids confusion and ensures everyone enjoys the journey.

┌─────────────────────────────┐
│      Stakeholders & Users    │
└──────────────┬──────────────┘
               │ Gather needs
               ▼
┌─────────────────────────────┐
│   Requirements Analysis      │
│ - Understand needs           │
│ - Clarify & document         │
└──────────────┬──────────────┘
               │ Clear requirements
               ▼
┌─────────────────────────────┐
│      System Design           │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What are requirements?

Concept: Introduce the idea of requirements as needs or conditions a system must satisfy.

Requirements describe what a system should do or how it should behave. They come from people who will use or be affected by the system. Examples include 'The app must let users log in' or 'The website should load within 2 seconds.'

Result

Learners understand that requirements are the starting point for building any system.

Understanding that requirements are the foundation prevents building systems that don't solve real problems.

2

Foundation

Types of requirements

Concept: Explain the two main types: functional and non-functional requirements.

Functional requirements describe specific behaviors or functions, like 'send email notifications.' Non-functional requirements describe qualities like speed, security, or usability, such as 'the system must handle 1000 users simultaneously.'

Result

Learners can distinguish between what a system does and how well it does it.

Knowing these types helps organize needs clearly and ensures no important aspect is missed.

3

Intermediate

Gathering requirements effectively

🤔Before reading on: do you think asking users directly is the only way to gather requirements? Commit to your answer.

Concept: Introduce methods to collect requirements from different sources.

Requirements can be gathered by interviews, surveys, observation, workshops, or studying existing systems. Each method reveals different insights. Combining methods gives a fuller picture.

Result

Learners see that gathering requirements is an active, varied process, not just asking questions.

Understanding multiple gathering methods prevents missing hidden or unspoken needs.

4

Intermediate

Documenting requirements clearly

🤔Before reading on: do you think writing requirements in technical language is best? Commit to your answer.

Concept: Teach how to write requirements so everyone understands them.

Requirements should be clear, simple, and unambiguous. Use plain language, avoid jargon, and include examples. Organize them in lists or tables with unique IDs for easy reference.

Result

Learners can create documents that reduce confusion and disagreements later.

Clear documentation is key to aligning all stakeholders and guiding development smoothly.

5

Intermediate

Prioritizing requirements

🤔Before reading on: do you think all requirements are equally important? Commit to your answer.

Concept: Explain how to decide which requirements matter most.

Not all requirements can be done at once. Prioritize based on value, cost, risk, and dependencies. Techniques include MoSCoW (Must, Should, Could, Won't) and ranking by stakeholders.

Result

Learners understand how to focus efforts on what delivers the most benefit first.

Prioritization helps manage limited resources and avoid building unnecessary features.

6

Advanced

Handling changing requirements

🤔Before reading on: do you think requirements stay fixed once gathered? Commit to your answer.

Concept: Teach how to manage requirements that evolve during a project.

Requirements often change due to new insights or market shifts. Use version control, traceability, and regular reviews to track changes. Communicate updates clearly to all teams.

Result

Learners can adapt to change without losing control or causing chaos.

Knowing how to handle change prevents costly rework and keeps the project aligned with real needs.

7

Expert

Detecting hidden and conflicting requirements

🤔Before reading on: do you think all requirements are openly stated and consistent? Commit to your answer.

Concept: Reveal how to find needs users may not express and resolve contradictions.

Users may not know or say everything they want. Techniques like scenario analysis, prototyping, and conflict resolution help uncover hidden needs and fix conflicts between requirements.

Result

Learners gain skills to reveal true needs and avoid building conflicting features.

Detecting hidden and conflicting requirements is crucial for building systems that truly satisfy users and avoid costly mistakes.

Under the Hood

Requirements analysis works by collecting raw needs from diverse sources, then refining and structuring them into clear, testable statements. This involves communication, negotiation, and documentation. Internally, it creates a shared understanding that guides design and development, reducing ambiguity and errors.

Why designed this way?

It was built this way because early software projects failed due to unclear or changing needs. Structured analysis methods emerged to bring order, improve communication, and manage complexity. Alternatives like building without analysis led to costly rework and failures.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Stakeholders  │──────▶│ Requirements  │──────▶│ System Design │
│ & Users      │       │ Analysis      │       │ & Development │
└───────────────┘       └───────────────┘       └───────────────┘
        ▲                      │                        │
        │                      ▼                        ▼
   Feedback Loop         Documentation           Implementation

Myth Busters - 4 Common Misconceptions

Quick: Do you think requirements are only about what the system does? Commit yes or no.

Common Belief: Requirements only describe system functions and features.

Reality: Requirements include both what the system does (functional) and qualities like performance and security (non-functional).

Why it matters: Ignoring non-functional needs leads to systems that work but fail in speed, reliability, or user satisfaction.

Quick: Do you think once requirements are set, they never change? Commit yes or no.

Common Belief: Requirements are fixed and unchanging after initial gathering.

Reality: Requirements often evolve due to new insights, technology changes, or market shifts.

Why it matters: Treating requirements as fixed causes projects to deliver outdated or incomplete solutions.

Quick: Do you think writing requirements in technical jargon helps clarity? Commit yes or no.

Common Belief: Using technical language makes requirements clearer for everyone.

Reality: Technical jargon confuses non-technical stakeholders and causes misunderstandings.

Why it matters: Poor communication leads to misaligned expectations and costly rework.

Quick: Do you think all user needs are openly stated during gathering? Commit yes or no.

Common Belief: Users always clearly state all their needs and wants.

Reality: Users often have hidden or unspoken needs that require careful techniques to uncover.

Why it matters: Missing hidden needs results in incomplete systems that frustrate users.

Expert Zone

1

Requirements traceability is subtle but vital: linking each requirement to design, code, and tests ensures nothing is lost or misunderstood.

2

Balancing stakeholder priorities requires diplomacy and negotiation skills beyond technical knowledge.

3

Non-functional requirements often drive architecture decisions more than functional ones, a fact many overlook.

When NOT to use

Requirements analysis is less effective in very small or throwaway projects where speed matters more than precision. In such cases, agile or exploratory approaches with minimal upfront analysis may be better.

Production Patterns

In real systems, requirements analysis is integrated with agile user stories, continuous feedback loops, and automated traceability tools to keep evolving needs aligned with development.

Connections

User Experience Design

Builds-on

Understanding user needs deeply during requirements analysis helps create designs that truly satisfy users' goals and emotions.

Project Management

Supports

Clear requirements enable better planning, risk management, and resource allocation in projects.

Legal Contract Drafting

Similar pattern

Both require precise, unambiguous language to avoid misunderstandings and disputes, showing how clarity in communication is universal.

Common Pitfalls

#1 Writing vague requirements that are open to interpretation.

Wrong approach:

The system should be fast.

Correct approach:

The system must respond to user actions within 2 seconds under normal load.

Root cause:

Misunderstanding that vague terms lead to different interpretations and implementation errors.

#2 Ignoring non-functional requirements like security or scalability.

Wrong approach:

Only list features without mentioning performance or security.

Correct approach:

Include requirements such as 'The system must encrypt user data at rest' and 'Support 10,000 concurrent users.'

Root cause:

Focusing only on visible features and neglecting system qualities.

#3 Not involving all relevant stakeholders during gathering.

Wrong approach:

Gather requirements only from the project sponsor.

Correct approach:

Include users, developers, testers, and business representatives in requirement sessions.

Root cause:

Assuming one viewpoint covers all needs, leading to incomplete requirements.

Key Takeaways

Requirements analysis is the essential first step to understand what a system must do and how well it must perform.

Clear, well-documented requirements prevent misunderstandings and guide successful system design and development.

Requirements evolve, so managing changes and prioritizing needs are critical skills.

Detecting hidden and conflicting requirements early avoids costly mistakes and ensures user satisfaction.

Effective requirements analysis combines communication, organization, and negotiation to align all stakeholders.