What if you could avoid costly mistakes by simply asking the right questions first?
Why Requirements gathering (functional and non-functional) in HLD? - Purpose & Use Cases
Imagine building a house without a clear plan. You ask the owner what they want, but only get vague answers. You start building rooms, but later find out the kitchen needs to be bigger and the roof must withstand heavy snow. You have to tear down walls and redo work repeatedly.
Without clear requirements, the project drags on. Builders waste time fixing mistakes. Costs rise, and frustration grows. The final house may not fit the owner's needs, causing disappointment and delays.
Requirements gathering helps us collect clear, detailed needs before starting. We separate what the system must do (functional) from how well it must do it (non-functional). This clarity guides design and development, reducing costly changes later.
Start building without clear specs
Fix problems as they appear
Repeat fixesGather detailed needs first
Plan design based on needs
Build with confidenceClear requirements enable smooth project flow, better design decisions, and a system that truly meets user needs.
When creating a mobile app, gathering functional requirements defines features like login and messaging, while non-functional requirements ensure fast loading and data security, leading to a reliable and user-friendly app.
Clear requirements prevent costly rework.
Functional needs define what the system does.
Non-functional needs define system quality and constraints.
Practice
functional requirement in system design?Solution
Step 1: Understand functional requirements
Functional requirements specify the actions or features the system must perform, such as user login or data processing.Step 2: Differentiate from non-functional requirements
Non-functional requirements describe qualities like speed, security, or usability, not specific features.Final Answer:
A feature that defines what the system should do -> Option DQuick Check:
Functional = What system does [OK]
- Confusing functional with non-functional requirements
- Thinking security is a functional requirement
- Mixing usability with system features
non-functional requirement?Solution
Step 1: Identify non-functional requirements
Non-functional requirements describe system qualities like performance, reliability, or security.Step 2: Match options to definitions
The system shall respond to user requests within 2 seconds specifies response time, a performance metric, which is non-functional. Others describe features (functional).Final Answer:
The system shall respond to user requests within 2 seconds -> Option AQuick Check:
Non-functional = system qualities [OK]
- Choosing features as non-functional requirements
- Ignoring time or performance constraints
- Confusing functional and non-functional examples
- The system must allow users to upload files.
- Uploads must complete within 5 seconds.
- The system must support 1000 concurrent uploads.
Which of these is a functional requirement?
Solution
Step 1: Identify functional requirements
Functional requirements describe what the system does, such as allowing file uploads.Step 2: Analyze each option
A is performance (non-functional). B is capacity/scalability (non-functional). D is availability (non-functional).Final Answer:
The system must allow users to upload files -> Option CQuick Check:
Functional = system features [OK]
- Selecting performance, capacity, or availability as functional
- Confusing capacity constraints as functional
- Ignoring direct feature statements
Solution
Step 1: Identify requirement type
Handling 1000 requests per second is about performance, a non-functional quality.Step 2: Explain why listing as functional is wrong
Functional requirements describe features, not performance metrics. Mislabeling causes confusion in design and testing.Final Answer:
Non-functional; it describes performance, so listing as functional is incorrect -> Option BQuick Check:
Performance = non-functional [OK]
- Calling performance a functional requirement
- Confusing user behavior with system qualities
- Ignoring the impact of mislabeling requirements
Solution
Step 1: Identify functional requirements in options
Functional requirements describe features like sending messages or creating profiles.Step 2: Identify non-functional requirements in options
Non-functional requirements describe qualities like speed, availability, or security.Step 3: Analyze each option pair
Users can send messages; messages must be delivered within 1 second pairs sending messages (functional) with delivery speed (non-functional). Others mix two functional or two non-functional requirements incorrectly.Final Answer:
Users can send messages; messages must be delivered within 1 second -> Option AQuick Check:
Functional + Non-functional = Users can send messages; messages must be delivered within 1 second [OK]
- Mixing two functional or two non-functional requirements
- Confusing UI features with system qualities
- Ignoring delivery time as non-functional
Ready to prove it?
Pass the test and this pattern moves unknown
