Requirements

Imagine you're building a smart locker system, like those found in apartment complexes or parcel delivery services. These aren't your old school gym lockers. They need to be flexible, secure, and able to handle different users (residents, delivery drivers, admins), various package sizes, and potential integrations with other building management systems. This problem focuses on the core logic of managing these lockers: allocating them, storing packages, and ensuring only authorized users can access the contents. We need a robust, extensible design that can adapt to future requirements like temperature-controlled lockers or more sophisticated access control mechanisms. # Requirements ## Functional Requirements 1. **Locker Creation:** The system must support creating lockers of various sizes (Small, Medium, Large). 2. **User Management:** The system should manage users with different roles (Resident, Delivery Driver, Admin). Each role should have a defined set of permissions. 3. **Locker Allocation:** * Residents can request the system to allocate them an available locker. The system should prioritize lockers of the appropriate size based on resident preference (if any) and availability. * Delivery Drivers can request the system to allocate them a locker to deposit a package for a specific resident. The system should automatically choose a suitable, available locker. 4. **Package Deposit:** Delivery Drivers can deposit a package into an allocated locker. The system should record package details (size, delivery date/time, recipient). 5. **Package Retrieval:** Residents can retrieve their packages from allocated lockers using a secure method (e.g., PIN code, QR code, RFID). 6. **Locker Deallocation:** Once a package is retrieved, the locker should be deallocated and become available for reuse. 7. **Locker Status:** The system should track the status of each locker (Available, Occupied, Out of Service). 8. **Locker Reservation Timeout:** If a locker is allocated but the package is not deposited within a certain time frame (e.g., 1 hour), the allocation should expire, and the locker should become available again. 9. **Reporting/Admin Functions:** Admin users should be able to: * View locker availability. * View package history. * Mark lockers as "Out of Service" for maintenance. * Generate reports on locker usage. 10. **Notification:** (Optional, but good to consider). When a package is deposited, the system should be able to notify the resident (e.g., via email or SMS – the actual notification mechanism is outside the scope of this problem, but the design should accommodate it). ## Non-Functional Requirements 1. **Thread Safety:** The system must be thread-safe to handle concurrent requests from multiple users and delivery drivers. Consider scenarios where multiple delivery drivers are simultaneously trying to deposit packages or multiple residents are trying to retrieve them. 2. **Extensibility:** The system should be designed to easily accommodate new locker sizes, user roles, access control mechanisms, and notification methods without requiring significant code changes. The design should promote Open/Closed Principle. 3. **Modularity:** The system should be composed of loosely coupled modules to improve maintainability and testability. 4. **Testability:** The code should be designed in a way that makes it easy to write unit tests and integration tests. Consider dependency injection and mocking. 5. **Error Handling:** The system should handle errors gracefully and provide informative error messages. 6. **Scalability (Limited Scope):** While full-blown distributed scaling is not the focus, the design should consider potential scalability issues if the number of lockers and users grows significantly. Think about data structures and algorithms that could become bottlenecks. 7. **Security:** While we won't implement full-blown authentication and authorization, the design should consider security aspects, especially around package retrieval and access control. Avoid hardcoding credentials. ## Core Entities 1. **Locker:** Represents a physical locker with properties like size, ID, and status. 2. **LockerSize:** An enum or class representing the different sizes of lockers (Small, Medium, Large). 3. **User:** Represents a user of the system, with properties like ID, name, and role. 4. **UserRole:** An enum representing the different roles of users (Resident, DeliveryDriver, Admin). This dictates what actions a user is allowed to perform. 5. **Package:** Represents a package stored in a locker, with properties like size, delivery date, and recipient. 6. **Allocation:** Represents the assignment of a locker to a user (either a resident permanently or a delivery driver temporarily). This entity helps track which locker is assigned to whom and for how long. 7. **LockerManager:** The core class responsible for managing lockers, allocations, deposits, and retrievals. It coordinates the interactions between other entities. 8. **AccessControlService:** An interface (or abstract class) that defines the access control mechanism for lockers. Implementations could include PIN code, QR code, RFID, etc. This promotes extensibility. 9. **NotificationService:** An interface (or abstract class) that defines how users are notified when packages are deposited. This promotes extensibility and allows for different notification channels.

Design a locker

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content