OneNoughtOne
0/273
Loading content...
Read aloud is unavailable in this browser.
Every extraordinary system—from the payment processing engines that handle billions of transactions daily to the messaging platforms connecting billions of users—begins not with code, databases, or microservices. It begins with a single, deceptively simple question: What should this system actually do?
This question, and the systematic process of answering it, forms the discipline of functional requirements gathering. It is the absolute first step in any system design endeavor, whether you're architecting a new product from scratch, extending an existing platform, or answering a system design interview question.
Yet despite its fundamental importance, requirements gathering is often rushed, misunderstood, or treated as a mere formality before the 'real' engineering work begins. This is a critical mistake. The quality of your system design is bounded by the quality of your requirements understanding. No amount of elegant architecture can compensate for solving the wrong problem.
By the end of this page, you will deeply understand what functional requirements are, how they differ from other types of requirements, proven techniques for extracting them, how to document them precisely, common pitfalls to avoid, and why mastery of this skill separates capable engineers from exceptional architects.
At its core, a functional requirement describes what a system must do—the behaviors, features, and capabilities that the system must exhibit to satisfy its users and achieve its purpose.
Functional requirements answer questions like:
Think of functional requirements as the contract between the system and its stakeholders. They define the obligations the system must fulfill, independent of how those obligations are technically implemented.
Functional requirements focus exclusively on what the system does, not how it does it. 'Users can send messages to other users' is a functional requirement. 'Messages are stored in a distributed Cassandra cluster' is an implementation detail. Keeping this distinction clear prevents premature architectural decisions from contaminating your requirements.
Formal Definition:
A functional requirement is a statement that describes a specific behavior or function of the system—an action the system must perform, data it must process, or a response it must provide to a given stimulus. Functional requirements are deterministic: given the same input and system state, the same output should result.
Examples across different domains:
| System Type | Example Functional Requirement | What It Defines |
|---|---|---|
| E-commerce Platform | Users can add items to a shopping cart | User action capability |
| Social Media | Users can post text, images, or videos up to 10 minutes | Content creation with constraints |
| Banking System | Transfer funds between accounts with immediate balance reflection | Financial transaction behavior |
| Ride-Sharing | Match riders with available drivers within 5-mile radius | Core matching functionality |
| Messaging App | Deliver messages with read receipts and typing indicators | Communication features |
| Search Engine | Return relevant results for user queries | Query-response behavior |
| Video Streaming | Allow users to resume playback from where they left off | Stateful playback feature |
Notice that each example describes an observable behavior. A user (or another system) interacts with the system, and the system responds in a defined way. This observability is key—functional requirements must be verifiable. If you can't test whether the system satisfies a requirement, the requirement is too vague.
Not all requirement statements are created equal. A vague requirement like 'the system should be user-friendly' is nearly useless—it provides no actionable guidance and cannot be verified. In contrast, a well-formed functional requirement is specific, measurable, and testable.
Let's dissect the components of an excellent functional requirement:
Example: Transforming a Vague Requirement into a Well-Formed One
❌ Vague: "Users can upload files."
✅ Well-Formed: "Authenticated users can upload files up to 100MB in PDF, DOCX, or TXT format. Files are associated with the user's account and are accessible only to the uploading user unless explicitly shared. Upload progress is displayed during transfer. Upon successful upload, the system stores the file, generates a unique URL, and sends a confirmation notification. If the file exceeds size limits or is in an unsupported format, the upload is rejected with a specific error message."
The second version answers virtually every question a developer might ask during implementation. It eliminates ambiguity and prevents the need for clarification meetings mid-development.
Every ambiguous requirement is a future bug, a design conflict, or a scope disagreement waiting to happen. If your requirement can be interpreted two different ways, it WILL be interpreted two different ways—and you'll discover this at the worst possible time.
Functional requirements don't exist as a flat list. They naturally cluster into categories that help organize thinking and ensure completeness. Understanding these categories helps you systematically explore the full scope of what a system must do.
Systematic Exploration:
When gathering requirements, use these categories as a checklist. For each category, ask:
This systematic approach prevents the common mistake of focusing only on 'happy path' core features while overlooking essential supporting functionality like authentication or error handling.
Core business features are the visible tip of the iceberg. Supporting features—authentication, authorization, audit logging, error handling, admin tools—often represent 70% or more of total system complexity. Don't let stakeholders (or yourself) underestimate them.
Two widely-used formats for capturing functional requirements are User Stories and Use Cases. Each has strengths, and understanding both allows you to choose the right tool for the context.
User Stories:
User stories are lightweight, informal descriptions of functionality from the perspective of an end user. They follow the template:
As a [type of user], I want [goal/desire] so that [benefit/reason]
User stories emphasize the why behind the functionality, keeping the user's value at the center.
Well-crafted user stories for a social media platform
——Use Cases:
Use cases are more formal and detailed. They describe a sequence of interactions between an actor (user or system) and the system to achieve a specific goal. Use cases include:
1234567891011121314151617181920212223242526272829303132333435363738
# Use Case: Transfer Funds Between Accounts ## ActorAuthenticated account holder ## Preconditions- User is authenticated and has an active session- User owns at least two accounts (source and destination)- Source account has sufficient balance for the transfer amount ## Main Flow (Happy Path)1. User selects "Transfer" from the dashboard2. System displays user's accounts with current balances3. User selects source account4. User selects destination account5. User enters transfer amount6. System validates amount is > 0 and <= source balance7. System displays confirmation with amount, accounts, and any fees8. User confirms the transfer9. System atomically debits source and credits destination10. System records transaction in audit log11. System displays success confirmation with transaction ID12. System sends notification to user's registered email ## Alternative Flows- 3a. User only has one account → Display message and suggest opening a new account- 6a. Amount exceeds balance → Display error, suggest maximum transferable amount- 8a. User cancels → Return to dashboard, no changes made ## Exception Flows- 9a. System failure during transfer → Rollback any partial changes, display error, log incident- Network timeout at any step → Preserve form state, prompt retry ## Postconditions- Source account balance reduced by transfer amount + fees- Destination account balance increased by transfer amount- Transaction record created with timestamp, accounts, amount- Email notification dispatchedWhen to Use Which:
| Aspect | User Stories | Use Cases |
|---|---|---|
| Detail Level | High-level, conversational | Detailed, step-by-step |
| Best For | Agile planning, prioritization | Complex workflows, contract documentation |
| Audience | Product teams, stakeholders | Developers, QA, architects |
| Flexibility | Easy to change, negotiable | More formal, harder to modify |
| Completeness | Requires acceptance criteria | Self-contained with flows |
In practice, many teams use user stories for backlog management and sprint planning, then elaborate critical or complex stories into full use cases when detailed specifications are needed for implementation. The formats complement each other.
Requirements don't appear fully formed. They must be systematically extracted from stakeholders, existing systems, domain expertise, and careful analysis. Here are proven techniques used by experienced architects and product managers:
Requirements passed through multiple intermediaries degrade like a game of telephone. Whenever possible, engineers should have direct access to actual users or domain experts—not just product managers summarizing what they think users want.
The Art of Asking Questions:
The quality of requirements is directly proportional to the quality of questions asked. Here's a framework for interrogating any potential requirement:
What exactly happens? — Get specific. 'Users can message each other' becomes 'users can send text messages up to 10,000 characters, with attachments up to 25MB, supporting images, PDFs, and documents.'
Who can do this? — All users? Authenticated users? Premium users? Admins? External systems?
When can this happen? — Always? During business hours? Only after other conditions are met?
What are the constraints? — Limits on size, frequency, number? Time windows? Geographic restrictions?
What triggers this? — User action? System event? Scheduled process? External webhook?
What's the expected response time? — Immediate? Within seconds? Eventually?
What happens if it fails? — Retry? Notify? Fail silently? Compensate?
In system design interviews, demonstrating strong requirements gathering skills is often the difference between a marginal pass and a strong hire signal. Interviewers deliberately give vague prompts to see if candidates clarify before designing.
The Interview Context:
When an interviewer says 'Design Twitter' or 'Design a URL shortener,' they're testing whether you:
Functional requirements questions for 'Design a messaging app'
——The Scoping Dance:
After clarifying, explicitly scope the design. State what you WILL and WILL NOT cover:
'Given our 45 minutes, let me focus on: core 1:1 messaging with text and images, user presence, and message delivery guarantees. I'll defer group chat, voice/video, and end-to-end encryption for now, but I'm happy to discuss those if time allows.'
This demonstrates maturity. You're managing scope, communicating constraints, and prioritizing—exactly what real architects do.
Common Mistakes:
When you ask a clarifying question that makes the interviewer pause and say 'Good question, let me think...' you've demonstrated senior-level thinking. You've identified an ambiguity they may not have explicitly considered.
Requirements only have value if they're accessible, understandable, and maintained. Documentation practices vary by organization, but certain principles are universal.
Documentation Principles:
Structured Requirements Document Template:
12345678910111213141516171819202122232425262728293031323334353637
# Product Requirements Document: [System Name] ## 1. Overview- Purpose and business context- Key stakeholders- Document version and history ## 2. User Personas- Description of primary user types- Their goals, pain points, and contexts of use ## 3. Functional Requirements ### 3.1 User Authentication [AUTH]| ID | Requirement | Priority | Acceptance Criteria ||----|-------------|----------|---------------------|| AUTH-001 | Users can register with email and password | Must | Registration completes in <2s, confirmation email sent || AUTH-002 | Users can log in with valid credentials | Must | Login completes in <1s, session created || AUTH-003 | Users can reset forgotten password | Must | Reset email sent within 30s || AUTH-004 | Users can enable 2FA | Should | TOTP and SMS options available | ### 3.2 Core Features [CORE]| ID | Requirement | Priority | Acceptance Criteria ||----|-------------|----------|---------------------|| CORE-001 | Users can create posts with text up to 5000 characters | Must | Post appears in feed within 5s || CORE-002 | Users can attach up to 4 images per post | Must | Images upload with progress indicator |... ## 4. Glossary- Active User: A user who has logged in within the past 30 days- Post: A content item created by a user, containing text and/or media... ## 5. Appendices- Related documents- Change log- Approval signaturesEven experienced engineers fall into requirements gathering traps. Awareness of these pitfalls is the first step to avoiding them.
Good requirements are neither too vague nor too prescriptive. They're 'just right'—specific enough to verify, flexible enough to allow design choices. Finding this balance is an art developed through practice.
We've covered substantial ground on functional requirements—the cornerstone of system design. Let's consolidate the key takeaways:
What's Next:
Functional requirements tell us what the system does, but non-functional requirements tell us how well it does it. The next page explores performance, scalability, availability, security, and other quality attributes that often prove more challenging—and more critical—than the features themselves.
You now understand functional requirements at a professional level. You can identify them, extract them, document them, and explain their importance. This foundation is essential—every architectural decision you make will trace back to the requirements you gathered.