Requirements for the Library System

Let's define what our Library Management System needs to do. Each requirement is specific enough to drive a class or method in our design.

Book & Catalog Management:

1. R1: Manage a catalog of books. The system shall maintain a catalog where each book record has a title, author(s), ISBN, subject, and publication date. A single book title can have multiple physical copies — each tracked individually.
2. R2: Add and remove books. A Librarian shall be able to add new books (with one or more copies) to the catalog and remove books or individual copies.
3. R3: Search the catalog. Members and Librarians shall be able to search for books by title, author, or ISBN. The search mechanism should be extensible — adding a new search criterion (e.g., by subject) should not require modifying existing search code.

Member Management:

4. R4: Register and manage members. The system shall support member registration with a unique ID, name, and email. Each member has an account with a status (Active, Suspended, Closed) and a configurable maximum borrowing limit (e.g., 5 books).
5. R5: Support two actor types. The system shall distinguish between Members (can search, borrow, return, reserve) and Librarians (can additionally add/remove books, register/block members, and view all overdue loans).

Checkout & Return (Circulation):

6. R6: Checkout a book. A Member shall be able to check out an available copy of a book. The system creates a Loan record with the issue date, a calculated due date (e.g., 14 days from issue), and marks the copy as checked out.
7. R7: Return a book. A Member shall be able to return a borrowed book copy. The system marks the copy as available, records the return date on the Loan, and calculates any overdue fine.
8. R8: Enforce borrowing limits. The system shall prevent a Member from checking out more books than their maximum borrowing limit allows.

Reservation System:

9. R9: Reserve a book. When all copies of a book are checked out, a Member shall be able to place a reservation (hold). Reservations are queued in FIFO order per book.
10. R10: Fulfill reservations on return. When a checked-out copy is returned and there are pending reservations for that book, the system shall notify the first member in the reservation queue and hold the copy for them for a limited period.

Fine Calculation:

11. R11: Calculate overdue fines. When a book is returned past its due date, the system shall calculate a fine based on the number of overdue days. The fine calculation strategy should be swappable — e.g., flat rate per day, tiered rates, or grace period policies — without modifying the return logic.

Notifications:

12. R12: Send notifications. The system shall notify members about: (a) upcoming due dates, (b) overdue reminders, and (c) reservation availability. The notification mechanism should support multiple channels (email, SMS) and be extensible.

Beyond functionality, our design must support:

1. Extensibility (Open/Closed Principle): Adding a new search criterion, fine policy, or notification channel should require adding a new class — not modifying existing ones. This is why we'll use the Strategy Pattern for search and fines.
2. Testability: Each component — Catalog, Loan management, Fine calculation, Reservation queue — should be testable in isolation. No god-class that does everything.
3. Data Consistency: A book copy cannot be simultaneously checked out to two members. A reservation queue must maintain FIFO ordering. Fine calculations must be deterministic.
4. Separation of Concerns: The checkout logic should not know about fine calculation details. The catalog should not know about reservations. Each subsystem has a clear responsibility boundary.

In Scope:

• Book catalog with multi-copy tracking
• Member and Librarian roles with distinct privileges
• Checkout/return circulation with due dates
• FIFO reservation queue with notification on availability
• Overdue fine calculation with swappable strategies
• Notification triggering (not delivery infrastructure)
• Catalog search by title, author, ISBN

Out of Scope:

• Database persistence — we model in-memory objects (persistence is a system-design concern)
• REST API endpoints — we design the domain layer, not the transport layer
• Authentication/authorization — we model roles, but not login/session management
• Physical barcode/RFID scanning — we assume book copies are identified by ID
• Inter-library loan networks — we design a single library
• Payment processing for fines — we calculate fines but don't process financial transactions

Every requirement will map directly to our design. Here's a preview of how requirements drive classes:

Requirement	Drives Which Class/Pattern
R1 (Catalog of books with copies)	Book, BookCopy, Catalog
R2 (Add/remove books)	Library facade methods
R3 (Search by title/author/ISBN)	SearchStrategy interface (Strategy Pattern)
R4 (Member accounts)	Member, Account, AccountStatus enum
R5 (Two actor types)	Member, Librarian hierarchy
R6-R7 (Checkout/Return)	Loan, Library.checkoutBook(), Library.returnBook()
R8 (Borrowing limits)	Validation in Library.checkoutBook()
R9-R10 (Reservations)	Reservation, reservation queue in Book
R11 (Overdue fines)	FineStrategy interface (Strategy Pattern)
R12 (Notifications)	NotificationService (Observer Pattern)

We'll trace these mappings precisely in the Class Diagram tutorial.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Ask questions like:

• "Should the system support multiple copies of the same book?" — This fundamentally changes the data model (Book vs. BookCopy distinction).
• "What happens when all copies are checked out — can members reserve?" — This introduces the reservation queue, which is a significant design addition.
• "How are fines calculated — flat rate or tiered?" — This determines whether you need a Strategy Pattern for fines.
• "Are there different member types with different borrowing limits?" — This affects whether Account needs a configurable limit or a member-type hierarchy.
• "Should the system send notifications, or just calculate when they're needed?" — This scopes the Observer Pattern usage.

These questions show the interviewer that you think about edge cases and design trade-offs before coding — exactly what senior engineers do.