Requirements gathering (functional and non-functional) in HLD - Deep Dive

Overview - Requirements gathering (functional and non-functional)

What is it?

Requirements gathering is the process of collecting and understanding what a system must do and how it should perform. It includes two main types: functional requirements, which describe specific behaviors or functions, and non-functional requirements, which describe qualities like speed, security, and usability. This process helps ensure the system meets the needs of its users and stakeholders. Without clear requirements, building a useful system is very difficult.

Why it matters

Without proper requirements gathering, systems often fail to solve the right problems or disappoint users because they miss key features or quality expectations. This can lead to wasted time, money, and frustration. Clear requirements help teams build the right system efficiently and avoid costly changes later. It connects the ideas of users and developers into a shared understanding.

Where it fits

Before requirements gathering, learners should understand basic project goals and stakeholder roles. After mastering requirements gathering, learners typically move on to system design, where they use these requirements to create architecture and detailed plans.

Mental Model

Core Idea

Requirements gathering is like making a detailed shopping list that tells exactly what to buy and how good it should be, so the final meal satisfies everyone.

Think of it like...

Imagine planning a birthday party. Functional requirements are the activities planned, like games and cake cutting. Non-functional requirements are how the party should feel, like being fun, safe, and on time. Both are needed for a great party.

┌───────────────────────────────┐
│       Requirements Gathering   │
├───────────────┬───────────────┤
│ Functional    │ Non-Functional│
│ Requirements  │ Requirements  │
│ - Features    │ - Performance │
│ - Actions     │ - Security    │
│ - Behaviors   │ - Usability   │
└───────────────┴───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Functional Requirements

Concept: Functional requirements describe what the system should do, focusing on specific tasks and behaviors.

Functional requirements answer questions like: What actions should the system perform? What inputs and outputs are expected? For example, a banking app must allow users to transfer money and check balances. These requirements are often written as clear statements or user stories.

Result

You can list clear, actionable features that the system must have to meet user needs.

Understanding functional requirements is the first step to knowing what the system must do, which guides all design and development.

2

Foundation

Understanding Non-Functional Requirements

Concept: Non-functional requirements describe how the system performs and behaves, focusing on qualities rather than specific actions.

These include performance (speed), reliability (uptime), security (protection), usability (ease of use), and scalability (handling growth). For example, the banking app should process transactions within 2 seconds and protect user data. These qualities affect user satisfaction and system success.

Result

You recognize the importance of system qualities that impact user experience and trust.

Knowing non-functional requirements ensures the system is not just functional but also reliable, secure, and pleasant to use.

3

Intermediate

Techniques for Gathering Requirements

🤔Before reading on: do you think interviews or surveys are better for gathering detailed requirements? Commit to your answer.

Concept: Different methods exist to collect requirements from stakeholders, each with strengths and weaknesses.

Common techniques include interviews (one-on-one talks), surveys (questionnaires), workshops (group discussions), observation (watching users), and document analysis (reviewing existing materials). Choosing the right method depends on the project context and stakeholder availability.

Result

You can select appropriate techniques to gather clear and complete requirements.

Understanding various gathering methods helps tailor the process to get the best information from stakeholders.

4

Intermediate

Distinguishing Between Requirement Types

🤔Before reading on: do you think a requirement like 'the system must be easy to use' is functional or non-functional? Commit to your answer.

Concept: It is crucial to correctly classify requirements to avoid confusion and ensure proper handling during design and testing.

Functional requirements specify actions (e.g., 'user can reset password'). Non-functional requirements specify qualities (e.g., 'password reset must be secure and fast'). Misclassifying can lead to missed tests or design flaws.

Result

You can clearly separate what the system does from how well it does it.

Correct classification prevents misunderstandings and ensures all requirements are addressed properly.

5

Intermediate

Documenting Requirements Effectively

🤔Before reading on: do you think writing requirements in long paragraphs or short clear statements is better? Commit to your answer.

Concept: Clear documentation helps everyone understand and agree on what the system should do and how.

Requirements should be written clearly, concisely, and unambiguously. Use formats like user stories, use cases, or requirement specifications. Include acceptance criteria to define when a requirement is met. Good documentation supports communication and future reference.

Result

You produce requirements that reduce confusion and guide development and testing.

Effective documentation is key to aligning team understanding and reducing costly errors.

6

Advanced

Handling Conflicting Requirements

🤔Before reading on: do you think all stakeholder requirements can always be met? Commit to your answer.

Concept: Stakeholders often have conflicting needs; resolving these conflicts is essential for project success.

Conflicts arise when different stakeholders want opposing features or qualities. Techniques to resolve include prioritization, negotiation, and trade-off analysis. For example, increasing security might reduce usability. Documenting decisions and rationale helps maintain clarity.

Result

You can manage and resolve requirement conflicts to create a balanced system.

Knowing how to handle conflicts prevents project delays and ensures stakeholder satisfaction.

7

Expert

Validating and Managing Requirements Changes

🤔Before reading on: do you think requirements stay fixed throughout a project? Commit to your answer.

Concept: Requirements often evolve; managing changes carefully is critical to avoid chaos and ensure quality.

Validation ensures requirements are correct, complete, and feasible before design. Change management involves tracking changes, assessing impact, and communicating updates. Tools like requirement management software help. Poor change control leads to scope creep and project failure.

Result

You maintain a stable, accurate set of requirements throughout the project lifecycle.

Understanding validation and change management protects the project from costly rework and confusion.

Under the Hood

Requirements gathering works by engaging stakeholders through communication channels to extract explicit and implicit needs. Functional requirements are captured as discrete actions or features, while non-functional requirements are often derived from quality expectations and constraints. These inputs are analyzed, clarified, and documented to form a shared understanding that guides design and development. Iterative feedback loops refine requirements to adapt to new insights or changes.

Why designed this way?

This process evolved to reduce misunderstandings between users and developers, which historically caused project failures. Early software projects lacked clear requirements, leading to wasted effort. Structured gathering and classification into functional and non-functional types help organize complexity and ensure all aspects of system behavior and quality are addressed. Alternatives like informal or ad-hoc gathering proved unreliable.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Stakeholders  │─────▶│ Communication │─────▶│ Requirements  │
│ (Users,      │      │ Channels     │      │ Analysis &    │
│ Clients)     │      │ (Interviews, │      │ Documentation │
└───────────────┘      │ Surveys, etc)│      └───────────────┘
                       └───────────────┘
                              │
                              ▼
                  ┌─────────────────────────┐
                  │ Functional & Non-Functional│
                  │ Requirements List         │
                  └─────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Is 'fast response time' a functional requirement? Commit to yes or no.

Common Belief: Many think performance aspects like 'fast response time' are functional requirements.

Reality: Performance is a non-functional requirement describing how well the system performs, not what it does.

Why it matters: Misclassifying can cause teams to overlook performance testing or design optimizations, leading to poor user experience.

Quick: Do you think requirements gathering ends once the first document is written? Commit to yes or no.

Common Belief: Some believe requirements gathering is a one-time task completed at the start.

Reality: Requirements gathering is iterative; requirements evolve as understanding deepens and conditions change.

Why it matters: Ignoring changes leads to outdated requirements, causing mismatches between the system and user needs.

Quick: Do you think all stakeholders always agree on requirements? Commit to yes or no.

Common Belief: People often assume all stakeholders have aligned requirements.

Reality: Stakeholders frequently have conflicting needs that must be negotiated and prioritized.

Why it matters: Failing to resolve conflicts causes project delays, scope creep, or unsatisfactory systems.

Quick: Is writing long, detailed paragraphs better than short clear statements for requirements? Commit to yes or no.

Common Belief: Some think more detailed paragraphs always improve clarity.

Reality: Long paragraphs can confuse; clear, concise statements with acceptance criteria are more effective.

Why it matters: Poor documentation leads to misunderstandings and errors during development and testing.

Expert Zone

1

Non-functional requirements often have hidden dependencies that affect multiple system parts, requiring cross-team coordination.

2

Prioritizing requirements is not just about importance but also feasibility, cost, and risk, which experts balance carefully.

3

Effective requirements gathering includes anticipating future needs to design flexible systems, avoiding costly rewrites.

When NOT to use

Requirements gathering is less effective in highly exploratory or research projects where goals are unclear; in such cases, prototyping or iterative discovery methods like Agile user stories or design sprints are better.

Production Patterns

In real-world projects, requirements gathering is integrated with Agile ceremonies like backlog grooming and sprint planning, continuously refined with stakeholder feedback and automated traceability tools to link requirements to code and tests.

Connections

User Experience Design

Builds-on

Understanding requirements deeply informs UX design by clarifying what users need and expect, ensuring the interface supports both functional and non-functional goals.

Project Management

Supports

Clear requirements enable project managers to plan scope, schedule, and resources accurately, reducing risks and improving delivery predictability.

Legal Contract Drafting

Similar pattern

Both require precise, unambiguous language to define obligations and expectations, preventing disputes and ensuring mutual understanding.

Common Pitfalls

#1 Mixing functional and non-functional requirements in the same statements.

Wrong approach:

"The system must allow users to login quickly and securely."

Correct approach:

"Functional: The system must allow users to login. Non-functional: The login process must complete within 2 seconds and use encryption."

Root cause:

Confusing what the system does with how well it does it leads to unclear requirements.

#2 Writing vague requirements without measurable criteria.

Wrong approach:

"The system should be user-friendly."

Correct approach:

"The system should allow new users to complete registration within 5 minutes without assistance."

Root cause:

Lack of specific acceptance criteria makes it impossible to verify if the requirement is met.

#3 Ignoring stakeholder conflicts and assuming all requirements can coexist.

Wrong approach:

Including all requested features without prioritization or trade-offs.

Correct approach:

Prioritizing features based on stakeholder value and feasibility, negotiating trade-offs where needed.

Root cause:

Assuming unlimited resources and ignoring practical constraints causes project failure.

Key Takeaways

Requirements gathering captures what a system must do (functional) and how well it must do it (non-functional).

Clear separation and documentation of these requirements prevent misunderstandings and guide design and testing.

Effective gathering uses appropriate techniques and involves continuous validation and change management.

Resolving conflicts and prioritizing requirements are essential to deliver a balanced, successful system.

Understanding requirements deeply connects technical work with user needs and business goals.