Loading learning content...
Every software system carries two sets of requirements. The first is written—explicitly stated in problem statements, specifications, and feature requests. The second is unwritten—assumed, expected, understood by everyone but documented by no one.
The invisible requirements paradox:
Consider a simple requirement: 'Users can create accounts.' What's written is clear. But what's unwritten?
Each 'probably' represents an implicit requirement—something every reasonable stakeholder assumes but nobody explicitly states. Miss these, and your system will fail in ways that seem obvious in retrospect.
Why implicit requirements are dangerous:
Explicit requirements are testable. If the spec says 'max 5 books,' you can verify your design handles it. Implicit requirements are invisible until violated. Nobody tests for 'persists across restarts' until accounts disappear.
The senior engineer's superpower is seeing the unwritten—extracting implicit requirements before they manifest as production incidents.
By the end of this page, you will understand the distinction between explicit and implicit requirements, possess systematic techniques for extracting implicit requirements, know how to document and design for both, and develop the intuition to see what's unwritten. This completes your requirements understanding framework.
Let's establish clear definitions:
Explicit Requirements:
Directly stated in the problem statement or specification. Someone took the time to write them down.
Examples:
Implicit Requirements:
Not written, but expected based on domain knowledge, industry standards, common sense, or universal software expectations.
Examples:
The Continuum:
In practice, requirements exist on a spectrum from fully explicit to deeply implicit:
| Level | Description | Example |
|---|---|---|
| Fully Explicit | Stated with exact details | 'Loan period is 14 days' |
| Explicit but Vague | Stated without precision | 'Users can search for books' |
| Implied by Context | Clearly intended though not stated | 'Return must be of borrowed item' |
| Industry Standard | Expected in this domain | 'Library has catalog of books' |
| Common Sense | Universal assumption | 'Data doesn't spontaneously disappear' |
| Non-Functional Implicit | Quality expectations not stated | 'Search should feel responsive' |
Why We Need This Distinction:
Explicit requirements can be verified against the spec. If your design doesn't meet them, you failed to read the requirements.
Implicit requirements require interpretation. If your design doesn't meet them, it might be a legitimate oversight, or it might be that the requirement was genuinely not needed for this system.
The skill is knowing which implicit requirements absolutely must be in your design (universal expectations) versus which are optional (domain-specific assumptions that may not apply).
Implicit requirements are never tested explicitly. Nobody writes 'Test that accounts persist across restarts.' They're so obvious that testing seems absurd—until they're violated. Design for implicit requirements proactively, not reactively.
Implicit requirements cluster into recognizable categories. Knowing these categories enables systematic extraction.
Category 1: Data Integrity Expectations
Every system is expected to maintain data consistency:
Design implication: Your classes need proper relationships, validations, and state management.
Category 2: Logical Consistency Expectations
Operations should make logical sense:
Design implication: Guard clauses, validation methods, and state machines.
Category 3: Security Expectations
Even if not stated, basic security is expected:
Design implication: Authorization checks in service methods; access control design.
After reading any problem statement, run through these 8 categories. For each, ask: 'Does my domain have expectations here?' Most systems have implicit requirements in at least categories 1-4. Categories 5-8 depend on the domain's criticality.
Don't rely on intuition alone. Use systematic techniques to uncover what's unwritten.
Technique 1: The 'What Could Go Wrong?' Probe
For each operation, ask: 'What could go wrong if we didn't have validations?'
Operation: borrowBook(memberId, bookId)
Without validation, what could go wrong?
• Member borrows book that doesn't exist → Implicit: book must exist
• Member borrows already-borrowed copy → Implicit: copy must be available
• Member exceeds loan limit → Implicit: loan limit must be enforced
• Non-member tries to borrow → Implicit: borrower must be valid member
• Same person borrows same book twice → Implicit: depends on policy (clarify)
Each failure mode reveals an implicit requirement.
Technique 2: The Domain Expert Simulation
Imagine explaining your design to a domain expert (librarian, driver, hotel manager). What would they be appalled to discover is missing?
Domain: Library
Expert: Librarian
"You mean the system would let someone borrow a book without
a valid membership?!"
→ Implicit: Membership validation on borrow
"You mean there's no way to know who has overdue books?!"
→ Implicit: Query for overdue loans by member
"You mean fines just disappear when they're paid with no record?!"
→ Implicit: Payment history/audit trail
The expert's outrage reveals implicit expectations.
Technique 3: The State Machine Analysis
For each entity, define its lifecycle. The transitions reveal implicit requirements:
Entity: BookCopy
States: Available → Borrowed → Returned → Available
→ Reserved → AwaitingPickup → Borrowed
→ Lost
→ Damaged
Implicit requirements revealed:
• BookCopy must track current state (status field)
• Transitions must be validated (can't go Borrowed → Reserved)
• Some states are terminal (Lost?) or require special handling
• State history might be needed for audit
State machines make implicit behaviors concrete.
IMPLICIT REQUIREMENTS EXTRACTION System: Library Management System ═══════════════════════════════════════════════════════════════════DATA INTEGRITY EXPECTATIONS:═══════════════════════════════════════════════════════════════════I-001: Books in catalog persist indefinitelyI-002: Book-Copy relationship is always valid (no orphan copies)I-003: Member-Loan relationship is always valid (no orphan loans)I-004: Available copy count = total - borrowed - reserved (derived)I-005: Each BookCopy has unique identifier (barcode) ═══════════════════════════════════════════════════════════════════LOGICAL CONSISTENCY EXPECTATIONS:═══════════════════════════════════════════════════════════════════I-010: Can only return a book that was borrowedI-011: Return must be by the borrowing member (or authorized delegate)I-012: Due date must be in the future at loan creationI-013: Loan count cannot exceed member limit (5)I-014: Renewal only on active (not already returned) loansI-015: Reservation only on unavailable books (available = just borrow) ═══════════════════════════════════════════════════════════════════SECURITY EXPECTATIONS:═══════════════════════════════════════════════════════════════════I-020: Borrow requires authenticated memberI-021: Member can only view/manage their own loansI-022: Librarian can view/manage any member's loansI-023: Only librarian can waive finesI-024: Catalog modifications require librarian role ═══════════════════════════════════════════════════════════════════PERFORMANCE EXPECTATIONS:═══════════════════════════════════════════════════════════════════I-030: Search returns results in < 2 secondsI-031: Availability check is real-time (not stale)I-032: Loan limit check is real-time (prevent over-borrowing) ═══════════════════════════════════════════════════════════════════OPERATIONAL EXPECTATIONS:═══════════════════════════════════════════════════════════════════I-040: Loan operations are logged (who borrowed what when)I-041: Fine calculations are traceableI-042: System errors are logged with contextNotice the numbering (I-001, I-010...). This isn't just formatting—it's traceability. When you later design a validation in the Loan class, you can annotate it as 'Implements I-012.' This connects implementation to requirements, even implicit ones.
Once extracted, implicit requirements need to be incorporated into design. This affects class structure, method signatures, and relationship modeling.
Data Integrity → Relationship Design
Implicit data integrity requirements drive how you model relationships:
Implicit: "Loan must always reference valid Member and BookCopy"
Design choices:
• Loan constructor requires Member and BookCopy (non-null)
• Loan cannot exist without its parent entities
• Member.loans and BookCopy.loan are two-way references
• Deletion cascade must be considered (what if member deleted?)
Logical Consistency → Guard Clauses and Validations
Implicit logical rules become guard clauses in methods:
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849
// Implicit: I-013 - Loan count cannot exceed member limit (5)// Implicit: I-015 - Only borrow available copies class LoanService { borrowBook(member: Member, bookCopy: BookCopy): Result<Loan, BorrowError> { // Guard: I-013 - Must be under limit if (member.activeLoans.length >= Member.MAX_LOANS) { return Err(BorrowError.LoanLimitExceeded); } // Guard: I-015 - Copy must be available if (bookCopy.status !== BookCopyStatus.Available) { return Err(BorrowError.CopyNotAvailable); } // All implicit requirements satisfied, proceed const loan = new Loan(member, bookCopy, this.calculateDueDate()); bookCopy.markAsBorrowed(loan); member.addLoan(loan); return Ok(loan); }} // Implicit: I-010, I-011 - Return validationclass Loan { returnBook(returningMember: Member): Result<void, ReturnError> { // Guard: I-010 - Must be active (not already returned) if (this.status === LoanStatus.Returned) { return Err(ReturnError.AlreadyReturned); } // Guard: I-011 - Must be the borrowing member if (this.member.id !== returningMember.id) { return Err(ReturnError.UnauthorizedReturner); } // Process return this.status = LoanStatus.Returned; this.returnDate = DateTime.now(); this.bookCopy.markAsAvailable(); return Ok(); }}Security Expectations → Authorization Layer
Implicit security requirements shape your service boundaries:
Implicit: I-021 - Member can only view their own loans
Design options:
• MemberService.getLoans() always filters by authenticated member
• OR LoanRepository.findByMember() is the only exposed query
• Controller layer enforces member context
Implicit: I-023 - Only librarian can waive fines
Design options:
• FineService.waiveFine() requires librarian role parameter
• OR LibrarianService has waiveFine() while MemberService does not
• Authorization check at service layer
Performance Expectations → Data Structure Selection
Implicit performance requirements influence data structures:
Implicit: I-030 - Search returns results in < 2 seconds
Design impact:
• Book search needs efficient data structure (index on title, author, ISBN)
• In-memory: Hash maps by search field, or trie for prefix search
• Design: BookCatalog class with indexed access methods
Implicit: I-032 - Loan limit check is real-time
Design impact:
• Member needs quick access to active loan count
• Either maintain count attribute or ensure activeLoans collection is efficient
• O(1) count check, not O(n) scan
Every implicit requirement should trace to something concrete in your design: a guard clause, a relationship constraint, an interface method, a state transition. If an implicit requirement has no design manifestation, you haven't designed for it.
Certain domains have predictable implicit requirements. Knowing these patterns accelerates extraction.
Booking/Reservation Systems (Hotels, Flights, Restaurants, Parking):
E-Commerce/Ordering Systems (Shopping, Food Delivery):
Social/Sharing Platforms (Social Media, Ride Sharing):
| Domain | Most Critical Implicit | Design Pattern Response |
|---|---|---|
| Booking | No double-booking | Availability check + atomic reservation |
| Inventory | No overselling | Stock decrement before confirmation |
| Financial | Transactional consistency | ACID operations; saga pattern |
| Gaming | Fair play / anti-cheat | Server-authoritative state |
| Healthcare | Data privacy (HIPAA) | Access control + audit logging |
| Real-time | Low latency | Event-driven; push not poll |
The more you work in a domain, the more implicit requirements you internalize. A hotel booking system expert 'knows' overbooking is a thing to handle. A newcomer might not even consider it. When working in unfamiliar domains, explicitly research common requirements.
Not all implicit requirements are actually required. Some are assumptions that might not apply. Validation ensures you're not overdesigning.
When to Validate vs. Assume:
Assume when:
Validate when:
Validation Techniques:
INTERVIEWER: "Design a parking lot system." CANDIDATE: "Before I proceed, I want to clarify a few implicit assumptions I'm making:" ASSUMPTION CHECK 1 - DOMAIN:"I'm assuming vehicles come in different sizes (car, motorcycle, truck) that require different spot sizes. Is that the case, or is one-size-fits-all acceptable?" INTERVIEWER: "Yes, different sizes matter." ASSUMPTION CHECK 2 - LOGICAL CONSISTENCY:"I'm assuming a spot can hold exactly one vehicle at a time—no sharing. And that a vehicle can only be in one spot. Is that right?" INTERVIEWER: "Correct." ASSUMPTION CHECK 3 - POTENTIALLY VARIABLE:"For payment, I'm assuming we calculate based on duration. But should I include rate variations (weekday vs weekend, tiered pricing, membership discounts)? Or is flat hourly rate sufficient?" INTERVIEWER: "Start with flat rate. Mention how you'd extend for tiered, but don't implement fully." CANDIDATE: "Got it. I'll design the pricing as a strategy pattern so we can swap calculators, but implement only the flat-rate strategy." [Candidate has now validated enough to proceed confidently]Validating everything wastes time and annoys stakeholders. Assuming everything risks wrong designs. The sweet spot: validate implicit requirements that would significantly change your design if wrong. Accept universal implicit requirements without question.
A complete requirements document distinguishes explicit from implicit. This matters for traceability, review, and maintenance.
The Dual-Track Document:
Maintain two parallel tracks:
This makes the invisible visible.
LIBRARY MANAGEMENT SYSTEM - REQUIREMENTS ═══════════════════════════════════════════════════════════════════SECTION A: EXPLICIT REQUIREMENTS (From Problem Statement)═══════════════════════════════════════════════════════════════════ E-001: Members can borrow books from the library Source: Problem statement line 3 E-002: Members can borrow up to 5 books at a time Source: Problem statement line 7 E-003: Loan period is 14 days Source: Problem statement line 8 E-004: Fines are $0.50 per day overdue Source: Problem statement line 9 E-005: Books can be searched by title, author, or ISBN Source: Problem statement line 5 E-006: Reservations are possible for unavailable books Source: Problem statement line 6 E-007: One renewal per loan (if not reserved by another) Source: Problem statement line 8 ═══════════════════════════════════════════════════════════════════SECTION B: IMPLICIT REQUIREMENTS (Derived by Analysis)═══════════════════════════════════════════════════════════════════ DATA INTEGRITY:I-001: BookCopy entity separate from Book (multiple copies per book) Justification: Implicit from "borrow" and "availability" - you borrow copies, not books I-002: All entity relationships maintain referential integrity Justification: Universal data integrity expectation I-003: BookCopy has unique identifier (barcode/ID) Justification: Domain standard for physical item tracking LOGICAL CONSISTENCY:I-010: Can only borrow copies with status "Available" Justification: Logical impossibility of borrowing borrowed item I-011: Return is only by borrowing member Justification: Liability and tracking - standard library policy I-012: Due date is set to future (borrow date + 14 days) Justification: Cannot be due in the past (temporal logic) I-013: Renewal blocked if reservation exists for this book Justification: Stated implicitly via E-007 "if not reserved" SECURITY:I-020: Borrow operation requires authenticated member Justification: Member identification for liability/tracking I-021: Member can only view own loan history Justification: Privacy - standard expectation I-022: Fine waiver requires elevated privileges (librarian) Justification: Financial control - standard expectation PERFORMANCE:I-030: Search returns results in user-acceptable time (<2s) Justification: UX expectation for search functionality I-031: Availability reflects current state (real-time) Justification: Consistency expectation for booking systems ═══════════════════════════════════════════════════════════════════SECTION C: CROSS-REFERENCE - REQUIREMENT TO DESIGN═══════════════════════════════════════════════════════════════════ Member class: - E-002 → Member.MAX_LOANS = 5, validated in borrow() - I-020 → Member identity required for loan creation - I-021 → MemberService.getLoans(member) filters by member Loan class: - E-003 → Loan.dueDate = borrowDate + 14 days - E-007 → Loan.renewalCount <= 1; checkReservation() on renew - I-011 → Loan.returnBook(member) validates member.id == this.member.id Fine class: - E-004 → Fine.calculate() uses $0.50 × daysOverdue - I-022 → FineService.waive() requires librarian authorization BookCopy class: - I-001 → BookCopy entity exists, references Book - I-010 → BookCopy.status enum; borrow() validates AvailableWhy This Documentation Matters:
You won't write formal documents in interviews, but you can verbalize: 'I'm including this validation because of the implicit requirement that members can only view their own loans—a standard privacy expectation.' This shows you're thinking about implicit requirements even without documentation.
The opposite failure mode: inferring requirements that don't exist. This leads to overdesign, unnecessary complexity, and wasted effort.
Signs of Over-Inference:
The YAGNI Principle:
'You Aren't Gonna Need It' (YAGNI) is the counterbalance to implicit requirement extraction. The tension:
The Justification Test:
For every implicit requirement you add, you should be able to answer:
If you can't clearly answer these, you might be over-inferring.
Engineers love to design elegant, feature-rich systems. But in interviews and real projects, designing beyond requirements is a failure—you wasted time on the wrong things. Design what's needed; mention what could be extended. Don't build what isn't asked for.
The distinction between explicit and implicit requirements is fundamental to mature engineering practice. Let's consolidate the key principles:
Module Complete:
You have now completed the four-page journey through Understanding LLD Problem Statements:
Together, these skills form the foundation for all subsequent LLD work. You now possess the framework that Principal Engineers use to ensure they solve the right problem before investing in solutions.
You now possess a complete framework for understanding LLD problem statements. This is the meta-skill that makes all other design skills effective. Apply this to every problem, and you'll never again build an elegant solution to the wrong problem. The next module advances to gathering and organizing requirements into structured, design-ready specifications.