Requirements for the Meeting Scheduler

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

User & Calendar Management:

1. R1: Manage user accounts. The system shall support users with a unique ID, name, and email. Each user owns exactly one personal Calendar that stores all their meetings.
2. R2: View calendar. A user shall be able to view all meetings on their calendar for a given date or date range, including meetings where they are the organizer and meetings where they are an invitee who has accepted.

Meeting Creation:

3. R3: Create a one-time meeting. A user (the organizer) shall be able to create a meeting with a title, start time, end time, optional description, optional location or meeting room, and a list of invitee emails.
4. R4: Create a recurring meeting. The organizer shall be able to create meetings that repeat on a schedule — daily, weekly (on specific weekdays), or monthly (on a specific day of the month). The recurrence generates individual occurrences, each with its own start/end time.
5. R5: Cancel a meeting. The organizer shall be able to cancel a meeting. Cancelling removes the meeting from all participants' calendars and sends a cancellation notification.

Conflict Detection:

6. R6: Detect calendar conflicts. Before confirming a meeting, the system shall check the organizer's calendar for time overlaps. Two meetings conflict if their time intervals overlap (i.e., one starts before the other ends and vice versa).
7. R7: Check participant availability. The system shall provide a way to check whether all invitees are available during the proposed meeting time by querying each invitee's calendar for conflicts.

Room Booking:

8. R8: Book a meeting room. The system shall maintain a set of meeting rooms, each with a name and capacity. When creating a meeting, the organizer can optionally request a room. The system shall verify the room is available during the requested time slot.
9. R9: Find available rooms. The system shall allow the organizer to query for rooms available during a specific time interval, optionally filtered by minimum capacity.

Invitation Lifecycle:

10. R10: Send invitations. When a meeting is created, the system shall send an invitation to each invitee. Each invitation tracks a response status: Pending, Accepted, Declined, or Tentative.
11. R11: Respond to invitations. An invitee shall be able to accept, decline, or tentatively accept a meeting invitation. Accepting adds the meeting to the invitee's calendar. Declining removes it (or prevents it from appearing).
12. R12: Notify organizer of responses. When an invitee responds to an invitation, the system shall notify the organizer of the response.

Notifications:

13. R13: Send meeting reminders. The system shall support configurable reminders (e.g., 15 minutes before, 1 hour before) that notify participants of upcoming meetings.
14. R14: Notify on meeting changes. When the organizer updates the meeting time, location, or cancels the meeting, the system shall notify all participants of the change.

Beyond functionality, our design must support:

1. Extensibility (Open/Closed Principle): Adding a new recurrence pattern (e.g., bi-weekly, yearly) should require adding a new class — not modifying the existing recurrence logic. Similarly, adding a new notification channel (SMS, push notification) should not change the meeting or invitation code. This is why we'll use the Strategy Pattern for recurrence and the Observer Pattern for notifications.
2. Testability: Each component — Calendar conflict detection, Recurrence expansion, Room availability, Invitation management — should be testable in isolation. No god-class that handles everything.
3. Data Consistency: A meeting room cannot be double-booked for the same time slot. An invitee's calendar must not show a meeting they declined. Conflict detection must be deterministic — the same time interval query always returns the same result.
4. Separation of Concerns: The meeting creation logic should not know about notification delivery details. The calendar should not know about room availability. Each subsystem has a clear responsibility boundary.

In Scope:

• User accounts with individual calendars
• One-time and recurring meeting creation (daily, weekly, monthly)
• Calendar conflict detection using interval overlap checks
• Meeting room booking with availability queries
• Invitation lifecycle (send, accept, decline, tentative)
• Notification triggering for invitations, responses, reminders, and changes
• Meeting cancellation with participant notification

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
• Timezone conversion — we assume all times are in the same timezone for simplicity
• Authentication/authorization — we model user roles, but not login/session management
• Calendar sync protocols (CalDAV, iCal export/import) — we design the core scheduler, not sync infrastructure
• Video conferencing integration — we model meeting metadata, not the actual conferencing platform
• Complex scheduling optimization (e.g., "find the best time for 10 people") — we support availability queries, but not AI-driven slot suggestions

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

Requirement	Drives Which Class/Pattern
R1 (User accounts)	User, Calendar
R2 (View calendar)	Calendar.getMeetings(date)
R3 (Create one-time meeting)	Meeting, MeetingScheduler.scheduleMeeting()
R4 (Recurring meetings)	RecurrencePattern hierarchy (Strategy Pattern)
R5 (Cancel meeting)	MeetingScheduler.cancelMeeting()
R6-R7 (Conflict detection)	Calendar.hasConflict(interval), availability query logic
R8-R9 (Room booking)	MeetingRoom, RoomManager
R10-R12 (Invitation lifecycle)	Invitation, InvitationStatus enum
R13-R14 (Notifications)	NotificationService (Observer Pattern)
R3 complex construction	MeetingBuilder (Builder 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 recurring meetings, and if so, what recurrence types?" — This determines whether you need a RecurrencePattern hierarchy — a significant addition to the class model.
• "How should conflicts be handled — block creation or warn the user?" — This affects whether conflict detection is a hard constraint or a soft recommendation.
• "Do we need meeting rooms, or just participant scheduling?" — Room booking adds an entire subsystem (RoomManager, room-level conflict detection).
• "What happens when an invitee declines — does the meeting still happen?" — This scopes the invitation lifecycle and whether the organizer is notified.
• "Should the system find the optimal meeting time for all participants?" — This is a much harder algorithmic problem (availability intersection) — clarify whether it's in scope.

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