Functional Requirements
Functional requirements define what the system must do from the user and business perspective.
They describe expected behavior, not implementation details.
What to Clarify First
Focus on these four areas:
- Core features: the main capabilities the system must provide
- User actions: what users (or other actors) can do
- System behavior: how the system should respond to those actions
- Scope boundaries: what is in scope vs explicitly out of scope
At this stage, avoid performance and scaling details.
First confirm the correct problem, then design the solution.
Why This Step Matters
System design prompts are usually ambiguous on purpose.
Strong candidates reduce ambiguity before drawing architecture.
If requirements are unclear, you may design an elegant solution for the wrong problem.
Repeatable Method
1. Identify Actors
List everyone that interacts with the system:
- end users
- admins or operators
- external services and partner systems
Useful question:
“Who uses this system, and what does each actor need to do?“
2. Identify Core Use Cases
Capture the highest-value flows first:
- must-have vs nice-to-have functionality
- primary read and write actions
- critical user journeys
Useful question:
“What is the single most important workflow this system must support?“
3) Define Boundaries and Assumptions
Make constraints explicit:
- out-of-scope features
- business assumptions
- integration assumptions
Useful question:
“Should we include payments, notifications, and moderation now, or treat them as out of scope?”
Example Domains to Practice
You can practice this approach on:
- URL shortener
- notification system
- file upload system
For each domain, compare weak vs strong requirement questions and note how clarified requirements change the final design.
Common Mistakes
- Jumping into architecture before requirements are clear
- Asking implementation questions too early
- Asking too many low-value questions without prioritization
- Failing to confirm final agreed scope
A strong habit is to summarize before moving on:
“Let me summarize the functional requirements we agreed on.”
Expected Output Before Architecture
Before drawing components, write a short requirement summary:
- actors
- prioritized use cases
- explicit in-scope items
- explicit out-of-scope items
- assumptions to validate later
This creates a clear contract for the rest of the interview or design session.