Functional Requirements - Gathering Requirements | OneNoughtOne

0/246

System Design (LLD)LLD Problem-Solving Framework

Gathering Requirements

LevelIntermediate

Duration90 mins

TopicLLD Problem-Solving Framework

1 / 4

Functional Requirements

The Foundation of Every Design

Every exceptional software system begins not with code, not with architecture diagrams, not even with technology choices—but with a crystal-clear understanding of what the system must do. These are functional requirements: the behaviors, actions, and capabilities that define a system's purpose.

In the context of Low-Level Design, understanding functional requirements is not merely a procedural step—it is the intellectual foundation upon which every class, interface, method, and data structure is built. Miss a functional requirement, and you'll build the wrong system. Misunderstand one, and you'll design components that don't fit together. Overlook edge cases within requirements, and your design will crumble under real-world conditions.

This page will transform how you approach the "what does the system do?" question. You'll learn to extract requirements with surgical precision, categorize them systematically, and use them as the compass that guides every design decision.

What You Will Learn

By completing this page, you will master: • The precise definition of functional requirements and their distinction from other requirement types • Systematic techniques for extracting functional requirements from problem statements • How to decompose complex requirements into actionable, designable components • Methods for validating completeness and consistency of functional requirements • Real-world patterns for translating requirements into design artifacts

Defining Functional Requirements

Functional requirements describe what a system must do—the specific behaviors, features, and functions that the system must exhibit. They answer questions like:

What actions can users perform?
What data does the system process?
What outputs does the system produce?
What business rules must the system enforce?

In contrast to non-functional requirements (which describe how well the system performs—speed, reliability, scalability), functional requirements are about capability and behavior.

The Litmus Test

Ask yourself: "Can I demonstrate this requirement by showing the system doing something?" If yes, it's likely a functional requirement. If the answer is about speed, reliability, or quality characteristics, it's probably non-functional.

Example: "Users can search for books by title" → Functional (demonstrable action) Example: "Search returns results in under 200ms" → Non-functional (quality characteristic)

The Anatomy of a Functional Requirement

A well-formed functional requirement has several key components:

Components of a Functional Requirement
Component	Description	Example
Actor	Who or what initiates the behavior	User, Admin, External System, Scheduled Job
Action	The verb describing what happens	Create, Update, Delete, Search, Calculate, Notify
Object	What entity is being acted upon	Order, User Account, Payment, Reservation
Preconditions	What must be true before the action occurs	User must be authenticated, Item must be in stock
Postconditions	What must be true after the action completes	Order status changed to 'Confirmed', Email sent
Business Rules	Constraints that govern the behavior	Maximum 5 items per order, Discount applies only to premium members

Categories of Functional Requirements

Functional requirements can be organized into several meaningful categories that help ensure completeness:

Functional Requirement Categories

•User-Facing Operations — Actions that users directly perform: login, search, purchase, configure settings, view reports. These are typically the most visible requirements.
•Data Management — How data is created, read, updated, and deleted. Includes validation rules, data transformations, and persistence behaviors.
•Business Logic — Rules that encode domain knowledge: pricing calculations, eligibility checks, workflow state transitions, compliance rules.
•Integration Requirements — How the system interacts with external systems: APIs consumed, data exchanges, event publishing/subscribing.
•Administrative Operations — Actions performed by operators: user management, configuration changes, maintenance operations, audit capabilities.
•Automated Behaviors — Actions triggered by the system itself: scheduled jobs, event-driven reactions, notifications, cleanup processes.

Extracting Requirements from Problem Statements

In LLD interview scenarios and real-world design tasks, requirements don't arrive as neat lists. They come embedded in problem statements, buried in conversations, or implied by context. The ability to extract requirements is a critical skill.

The Noun-Verb Extraction Technique

This foundational technique systematically identifies actors, actions, and entities:

Step-by-Step Extraction Process

•Read the entire problem statement without making notes. Understand the overall context and purpose.
•Highlight all nouns — These are candidate entities (User, Order, Product, Payment) and potential actors.
•Highlight all verbs — These are candidate actions/operations (create, update, search, calculate, notify).
•Map verbs to nouns — Associate actions with the entities they affect to form requirement candidates.
•Identify implicit requirements — What's not said but clearly expected? (e.g., 'users can register' implies password validation, email verification).
•Group by category — Organize extracted requirements into meaningful clusters (user operations, admin operations, automated processes).

Worked Example: Library Management System

Let's apply the extraction technique to a typical LLD problem:

Problem Statement: "Design a library management system. The system should allow librarians to add, update, and remove books. Members can search for books, borrow available books, and return them. The system should track borrowing history and send overdue notifications. Members can reserve books that are currently borrowed by others."

Extracted Nouns (Entities/Actors)

•Librarian (Actor)
•Member (Actor)
•Book (Entity)
•Borrowing History (Entity)
•Reservation (Entity)
•Notification (Entity)
•System (Actor - for automated actions)

Extracted Verbs (Actions)

•Add (books)
•Update (books)
•Remove (books)
•Search (for books)
•Borrow (books)
•Return (books)
•Track (history)
•Send (notifications)
•Reserve (books)

Derived Functional Requirements

From the extraction above, we can formalize the following functional requirements:

Library System Functional Requirements
ID	Requirement	Actor	Category
FR-001	Librarians can add new books to the catalog	Librarian	Data Management
FR-002	Librarians can update book information	Librarian	Data Management
FR-003	Librarians can remove books from the catalog	Librarian	Data Management
FR-004	Members can search books by title, author, or ISBN	Member	User Operations
FR-005	Members can borrow available books	Member	User Operations
FR-006	Members can return borrowed books	Member	User Operations
FR-007	System tracks complete borrowing history per member	System	Data Management
FR-008	System sends notifications for overdue books	System	Automated Behavior
FR-009	Members can reserve books currently borrowed by others	Member	User Operations

Identifying Implicit Requirements

The most dangerous requirements are those never explicitly stated but absolutely expected. Missing an implicit requirement can derail an entire design. Expert designers develop intuition for uncovering these hidden requirements.

Categories of Implicit Requirements

Implicit requirements typically fall into predictable categories:

Common Implicit Requirements

•Authentication & Authorization — If users have roles (admin, member), the system implicitly needs login, role verification, and access control.
•Data Validation — Any data entry implies validation rules. Emails must be valid, dates must be sensible, quantities must be positive.
•Error Handling — Every operation that can fail needs defined failure behavior. What happens if a book doesn't exist? If a user is already at borrowing limit?
•State Transitions — Entities with status fields have implicit state machines. A book goes from Available → Borrowed → Returned. What transitions are valid?
•Audit & History — Business operations often require tracking who did what and when. This is rarely stated but frequently expected.
•Concurrency — If multiple users can act simultaneously, there are implicit requirements around race conditions. Two members reserving the same book at once?
•Edge Cases — Boundaries and limits are often implicit. Maximum books borrowed? Reservation expiration? Late return penalties?

The Implicit Requirement Checklist

For every explicit requirement, ask: • Who is allowed to perform this action? (Authorization) • What validation must inputs pass? (Data validation) • What if it fails? (Error handling) • What state changes occur? (State management) • Should this be auditable? (Audit trail) • Can this happen concurrently? (Concurrency) • Are there limits or boundaries? (Edge cases)

This systematic questioning reveals hidden requirements before they become design defects.

Example: Uncovering Implicit Requirements

Consider the explicit requirement: "Members can borrow available books."

Applying our checklist reveals numerous implicit requirements:

Implicit Requirements Derived from 'Members can borrow books'
Category	Implicit Requirement	Design Impact
Authorization	Only authenticated members can borrow	Need authentication check before borrow operation
Validation	Book must exist and be available	Check book status before allowing borrow
State Change	Book status changes to 'Borrowed'	Update book state and record borrower
State Change	Borrowing record is created	Create association between member and book with date
Edge Case	Member may have borrowing limit	Check current borrowed count against limit
Edge Case	Book may have outstanding reservations	Determine who gets priority—first reserver?
Concurrency	Two members might borrow simultaneously	Need atomic check-and-update for book status
Error Handling	What if book is suddenly unavailable?	Return clear error message, suggest alternatives
Audit	Track who borrowed what and when	Store borrower ID, book ID, timestamp

This single explicit requirement expanded into nine implicit requirements that directly impact the design. Each one requires class responsibilities, method behaviors, or data structures to be addressed.

Requirement Decomposition

Complex requirements often need decomposition before they can drive design decisions. A high-level requirement like "Members can borrow books" actually encompasses multiple sub-behaviors that need individual attention.

Hierarchical Decomposition

Complex requirements form hierarchies where high-level capabilities decompose into specific operations:

Requirement Hierarchy Example

Text

FR-005: Members can borrow available books
├── FR-005.1: System verifies member authentication
├── FR-005.2: System validates book exists and is available
├── FR-005.3: System checks member hasn't exceeded borrowing limit
├── FR-005.4: System checks for active reservations by other members
├── FR-005.5: System updates book status to 'Borrowed'
├── FR-005.6: System creates borrowing record with due date
├── FR-005.7: System calculates due date based on book type/member tier
├── FR-005.8: System notifies member of successful borrowing
└── FR-005.9: System cancels member's own reservation if exists

The Stepwise Refinement Process

Decomposition follows a disciplined process:

Decomposition Steps

•Identify the happy path — What happens when everything goes right? List each step in sequence.
•Identify preconditions — What must be true before the operation can proceed? Each becomes a validation step.
•Identify postconditions — What must be true after completion? Each becomes a state change or side effect.
•Identify alternative paths — What happens at each step if something goes wrong? Each becomes an error-handling requirement.
•Identify cross-cutting concerns — Logging, auditing, notifications—these apply across steps.

Decomposition Drives Design

Each sub-requirement often maps to a specific design element: • Validation steps → Guard clauses or validator classes • State changes → Domain entity methods • Side effects → Domain events or direct calls • Error handling → Exception classes and handlers • Cross-cutting concerns → Interceptors, decorators, or aspect-oriented patterns

Example: Complete Decomposition

Let's decompose the "Reserve a Book" requirement completely:

FR-009: Members can reserve books currently borrowed by others

Successful Reservation Flow

•Member requests to reserve a specific book
•System verifies member is authenticated
•System verifies book exists in catalog
•System verifies book is currently borrowed (not available)
•System verifies member doesn't already have this book
•System verifies member doesn't already have pending reservation for this book
•System checks member hasn't exceeded reservation limit
•System creates reservation with timestamp and queue position
•System notifies member of successful reservation
•System returns reservation confirmation with estimated availability

Prioritizing Functional Requirements

Not all requirements are equally important. In LLD interviews and real projects, time is limited. You must prioritize which requirements to address first and which can be deferred or simplified.

The MoSCoW Framework

A classic prioritization technique that categorizes requirements:

MoSCoW Prioritization Categories
Category	Meaning	LLD Interview Approach
Must Have	Core functionality without which the system is useless	Design these first and most thoroughly. They define your core classes.
Should Have	Important functionality expected in a complete system	Design after core is solid. Show awareness but may simplify.
Could Have	Nice-to-have features that enhance the system	Mention during discussion. Design may note extension points.
Won't Have	Out of scope for current iteration	Explicitly state exclusions. Shows scoping discipline.

Applying Prioritization: Library System Example

Prioritized Requirements

•Must Have: Add books, Search books, Borrow books, Return books — These define the core purpose of a library system.
•Should Have: Track borrowing history, Reserve books — Important but system works without them for basic operation.
•Could Have: Overdue notifications, Fine calculation — Enhances system but can be manual initially.
•Won't Have: Book recommendations, Social features — Outside scope of basic library management.

Interview Strategy

In LLD interviews, explicitly state your prioritization:

"For the core design, I'll focus on the Must-Have requirements: book management and borrowing. I'll design the system to be extensible for reservations and notifications, but I'll detail those only if time permits."

This demonstrates maturity and pragmatism—interviewer-winning qualities.

Core vs. Extended Requirements

Another useful distinction separates core requirements (essential for MVP) from extended requirements (complete feature set):

Core Requirements

•Define the primary user journey
•Enable the system to fulfill its core purpose
•Required for any meaningful system operation
•Address in the first design iteration

Extended Requirements

•Enhance user experience or efficiency
•Address edge cases and advanced scenarios
•May require more complex patterns
•Design for extensibility, implement later

From Requirements to Design Artifacts

Functional requirements don't just inform design—they directly generate design artifacts. Understanding this mapping accelerates the transition from requirements to implementation.

Requirement-to-Artifact Mapping

How Requirements Generate Design Elements
Requirement Element	Design Artifact	Example
Primary entity nouns	Domain classes/entities	Book → `Book` class with properties
Action verbs	Service methods or entity behaviors	Borrow → `BorrowingService.borrowBook()` or `Member.borrow(book)`
Business rules	Validation logic, policy classes	Max 5 books → `BorrowingPolicy.canBorrow(member)`
State changes	State machine patterns, status enums	Book status → `BookStatus` enum + state transitions
Relationships	Associations, aggregations	Member borrows Books → `Member` has list of `Borrowing`s
Events/Notifications	Domain events, observer pattern	Overdue notification → `BookOverdueEvent` + handlers
Search/query operations	Repository methods, query objects	Search by title → `BookRepository.findByTitle()`

Traceability Matrix

Professional requirements management maintains traceability—the ability to trace from requirement to design element to code to test. While full traceability may be overkill for LLD interviews, understanding the concept strengthens your design thinking.

Traceability Example
Markdown
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
## FR-005: Members can borrow available books
 
### Design Elements
- **Service:** BorrowingService.borrowBook(memberId, bookId)
- **Entity:** Borrowing (links Member, Book, with dueDate)
- **Validation:** BorrowingPolicy.validateBorrowing(member, book)
- **State Change:** Book.status transitions from AVAILABLE to BORROWED
- **Event:** BookBorrowedEvent raised for downstream processing
 
### Key Classes Involved
- Member (borrower)
- Book (item borrowed)
- Borrowing (the transaction record)
- BorrowingService (orchestrates the operation)
- BorrowingPolicy (encapsulates business rules)
 
### Tests Required
- testBorrowBook_Success
- testBorrowBook_BookNotAvailable
- testBorrowBook_MemberAtLimit
- testBorrowBook_BookNotFound
- testBorrowBook_ConcurrentBorrowing

Common Pitfalls in Functional Requirements

Even experienced designers fall into requirement-related traps. Awareness of these pitfalls prevents costly mistakes.

Pitfalls to Avoid

•Premature Solutioning — Jumping to implementation details before understanding what's needed. 'Use a HashMap' is not a requirement; 'Lookup books by ISBN in constant time' might be.
•Vague Requirements — Accepting ambiguous language without clarification. 'System should handle many users' is not actionable. 'System supports 10,000 concurrent users' is.
•Missing Negative Requirements — Focusing only on what the system does, not what it must NOT do. 'Users cannot access other users' private data' is a requirement too.
•Ignoring Edge Cases — Happy path thinking. What happens at boundaries? Zero items, maximum items, null inputs, concurrent access?
•Conflating Functional and Non-Functional — Mixing 'what it does' with 'how well it does it.' Keep these separate for clear design thinking.
•Over-specification — Dictating implementation in requirements. 'Store books in a SQL database' constrains design unnecessarily. 'Persist book data durably' doesn't.
•Scope Creep — Adding requirements beyond the stated problem. Stay focused on what's asked, note extensions as future possibilities.

The Most Dangerous Pitfall

Assuming you understand requirements without validation. In interviews, always restate your understanding: "So the system needs to support X, Y, and Z. Is that correct?" This catches misunderstandings early and shows communication skill.

Summary: Mastering Functional Requirements

Functional requirements are the foundation upon which all design decisions rest. Mastery of requirements gathering separates architects from coders.

Key Takeaways

•Functional requirements define what the system does — behaviors, capabilities, and actions that users and systems can perform.
•Use noun-verb extraction to systematically identify entities and operations from problem statements.
•Every explicit requirement hides implicit requirements — authorization, validation, error handling, state management, concurrency, edge cases.
•Decompose complex requirements into atomic, designable sub-requirements using happy path analysis and exception identification.
•Prioritize ruthlessly — distinguish Must-Have from Should-Have from Could-Have. Time is always limited.
•Requirements directly generate design artifacts — entities, services, policies, events, repositories.
•Avoid common pitfalls — vague requirements, premature solutioning, missing edge cases, conflating functional and non-functional.

What's Next:

With a solid understanding of functional requirements, we turn to their equally important counterpart: non-functional requirements. These define how well the system performs its functions—speed, reliability, scalability, security, and more. Together, functional and non-functional requirements provide the complete picture needed for robust low-level design.

Page Complete

You now understand how to identify, extract, analyze, decompose, and prioritize functional requirements. This skill forms the foundation for every design decision you'll make. In the next page, we explore non-functional requirements—the quality attributes that separate good systems from great ones.