Requirements for the ATM

Let's define what our ATM system needs to do. Each requirement is specific enough to drive a design decision — a class, an attribute, a method, or a relationship in our final design.

1. R1: Card Authentication — The ATM shall accept a bank card (identified by card number) and initiate a user session. Only one session can be active at a time.
2. R2: PIN Validation — The ATM shall prompt the user for a PIN and validate it against the account's stored PIN. The system shall support configurable PIN length (default: 4 digits).
3. R3: PIN Attempt Limit — The ATM shall allow a maximum of 3 PIN entry attempts per session. After 3 consecutive failures, the card shall be retained (blocked) and the session terminated.
4. R4: Transaction Menu — After successful authentication, the ATM shall display a menu with the following transaction types: Withdraw Cash, Deposit Cash, Check Balance, and Transfer Funds.
5. R5: Balance Inquiry — The ATM shall retrieve and display the current account balance for the authenticated user.
6. R6: Cash Withdrawal — The ATM shall allow the user to withdraw a specified amount. The system shall validate that: (a) the requested amount does not exceed the account balance, (b) the ATM has sufficient physical cash, and (c) the amount is dispensable using the available denominations.
7. R7: Multi-Denomination Dispensing — The ATM shall dispense cash using the largest denominations first (e.g., $100, then$50, then $20, then$10). Each denomination has a finite bill count. The system shall use a chain-based approach where each denomination handler dispenses what it can and passes the remaining amount to the next handler.
8. R8: Cash Deposit — The ATM shall accept a cash deposit, validate the amount, and credit the user's account balance.
9. R9: Fund Transfer — The ATM shall allow the user to transfer funds to another account by specifying the destination account number and the amount. The system shall validate sufficient balance before executing.
10. R10: Transaction Record — Every completed transaction (withdrawal, deposit, balance inquiry, transfer) shall be recorded with a unique transaction ID, timestamp, transaction type, amount, and the account involved.
11. R11: Session Management — After completing a transaction, the user shall be given the option to perform another transaction or end the session. Ending the session ejects the card and returns the ATM to idle.
12. R12: ATM Cash Inventory — The ATM shall maintain an inventory of cash per denomination. Operators can restock the ATM with specific denomination quantities. The ATM knows the total cash it holds at any time.
13. R13: State-Driven Behavior — The ATM shall be in exactly one operational state at any time. User actions that are invalid for the current state shall be rejected with an appropriate message (e.g., cannot select a transaction before PIN authentication).

Beyond functionality, our ATM design must satisfy:

1. Transaction Integrity — A withdrawal must be atomic: either the account is debited AND cash is dispensed, or neither happens. Partial failures (debited but no cash) are unacceptable. Our design must make this guarantee structurally clear.
2. Extensibility (Open/Closed Principle) — Adding a new transaction type (e.g., bill payment, mobile top-up) should require creating a new class, not modifying existing transaction handling code. Similarly, adding a new denomination should only require adding a handler to the chain.
3. Testability — Each component (PIN validation, cash dispensing chain, individual states) must be testable in isolation. State classes should not have hidden dependencies.
4. Security Considerations — While we won't implement encryption or network security (out of LLD scope), our design should make PIN handling encapsulated — the PIN should not leak through public interfaces or log outputs.
5. Single Responsibility — Each class should have one reason to change. The state management logic, cash dispensing logic, account management logic, and transaction recording logic should live in separate classes.

In Scope:

• Card-based authentication and PIN validation with attempt limits
• Four transaction types: Withdraw, Deposit, Balance Inquiry, Transfer
• Multi-denomination cash dispensing using Chain of Responsibility
• State machine governing the ATM's operational lifecycle
• Transaction recording with unique IDs and timestamps
• ATM cash inventory management (per-denomination tracking and restocking)
• Session management (start, multi-transaction, end)

Out of Scope:

• Network communication with the bank's core banking system — we model accounts locally for simplicity. In a real system, balance checks and debits happen via an API call to the bank.
• Hardware drivers — card reader, keypad, cash dispenser motors, receipt printer. We model the logical operations they perform, not how the hardware works.
• Encryption and security protocols — real ATMs use end-to-end encryption (DES/3DES) for PIN blocks. We model PIN validation as a simple comparison, noting that production systems would encrypt.
• Multi-ATM networks — we design a single ATM instance.
• Graphical user interface — we expose methods, not screens.
• Fraud detection, daily withdrawal limits per account, and regulatory compliance.

Every requirement must map to at least one element in our design. Here's a preview of how requirements drive the class structure:

Requirement	Design Element
R1: Card authentication	ATM.insertCard(), Card class, BankAccount association
R2: PIN validation	BankAccount.validatePin(), ATMState.enterPin()
R3: PIN attempt limit	ATM.failedAttempts counter, guard in CardInsertedState
R4: Transaction menu	TransactionType enum, ATMState.selectTransaction()
R5: Balance inquiry	BalanceInquiry transaction class
R6: Cash withdrawal	Withdrawal transaction class, balance + ATM cash guards
R7: Multi-denomination dispensing	CashDispenser with Chain of Responsibility (DenominationHandler)
R8: Cash deposit	Deposit transaction class
R9: Fund transfer	Transfer transaction class
R10: Transaction record	Transaction base class with id, timestamp, type, amount
R11: Session management	ATM.endSession(), state transitions back to Idle
R12: ATM cash inventory	CashDispenser.denominationInventory map
R13: State-driven behavior	ATMState interface, concrete state classes

We'll build this mapping rigorously in the Class Diagram tutorial. Every box in the diagram traces back to a requirement in this table.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Good clarifying questions for the ATM problem:

• "Should the ATM support multiple card types (debit and credit), or just debit?" — This affects whether you need a Card type hierarchy.
• "How many PIN attempts before lockout? Is this configurable?" — This defines a constant or config parameter.
• "Which denominations does the ATM stock?" — This determines the chain configuration.
• "Should the ATM work offline if the bank's network is down?" — This dramatically changes the design (typically out of scope for LLD interviews).
• "After a transaction completes, can the user do another transaction without re-authenticating?" — This clarifies session management.
• "Is the amount for withdrawal always a multiple of the smallest denomination?" — This determines whether the chain can fail gracefully.

Notice how each question maps to a specific design decision. Interviewers want to see that you think critically about requirements before coding.