Requirements for the Course Registration System

Let's define what our Course Registration System needs to do. Each requirement is specific enough to drive at least one class, method, or design decision.

1. Course Catalog: The system shall maintain a catalog of courses, each identified by a unique code (e.g., CS301), a name, a description, and a credit-hour value.

2. Sections: Each course can have multiple sections offered in a given semester. Each section has its own instructor, schedule (day-of-week + time slot), location, and maximum capacity.

3. Prerequisites (DAG): A course can declare zero or more prerequisite courses. Prerequisites form a Directed Acyclic Graph — no circular dependencies are allowed. A student must have completed all prerequisite courses before enrolling in a course.

4. Student Enrollment: A student can enroll in a section if and only if: (a) they have satisfied all prerequisite courses, (b) the section has available capacity, (c) the section does not conflict with the student's existing schedule, and (d) enrolling would not exceed the student's credit-hour limit for the semester.

5. Drop Course: A student can drop a section they are currently enrolled in. Dropping frees the seat and makes it available to waitlisted students.

6. Waitlist: When a section is at full capacity, a student who passes all other checks (prerequisites, schedule, credits) can join a waitlist for that section. Waitlists are ordered by arrival time.

7. Waitlist Notification: When a seat becomes available in a full section (due to a drop), the system shall automatically notify the first eligible student on the waitlist.

8. Schedule Conflict Detection: The system shall prevent a student from enrolling in two sections whose time slots overlap on any shared day of the week.

9. Credit Hour Limit: The system shall enforce a maximum number of credit hours per student per semester (configurable, default 18).

10. Enrollment Rules (Pluggable): The system shall support different enrollment strategies — first-come-first-served (default), priority-based (seniors before juniors), and lottery-based — swappable without modifying core registration logic.

11. View Enrollments: A student can view their list of current enrollments for a given semester, including section details and schedule.

Beyond functionality, our design must satisfy these quality attributes:

1. Extensibility (Open/Closed Principle): Adding a new enrollment strategy (e.g., auction-based bidding) must not require modifying the RegistrationService or any existing strategy class. The Strategy Pattern enables this — new rules implement the EnrollmentRule interface and are injected at configuration time.

2. Loose Coupling (Observer Pattern): The enrollment and drop logic must not directly depend on waitlist notification mechanics. When a seat opens, the waitlist is notified through an Observer interface — the registration service doesn't know who is listening or how they respond.

3. Prerequisite Correctness: The prerequisite validation must check the entire dependency chain, not just immediate prerequisites. If CS301 requires CS201 and CS201 requires CS101, enrolling in CS301 requires completion of both CS201 and CS101. The prerequisite graph must also reject cycles at configuration time.

4. Testability: Each subsystem — prerequisite checker, capacity manager, conflict detector, waitlist, enrollment rules — must be testable in isolation. Dependencies should be injected, not hardcoded, enabling mock substitution in unit tests.

In Scope:

• Course catalog with codes, names, credits, and descriptions
• Sections per course per semester with schedule, instructor, and capacity
• Prerequisite graph modeling and full-chain validation
• Enrollment workflow: prerequisite check → capacity check → conflict check → credit check → enroll or waitlist
• Drop workflow with automatic waitlist promotion
• Observer-based waitlist notification
• Strategy-based enrollment rules (FCFS, priority, lottery)
• Schedule conflict detection across enrolled sections
• Credit-hour limit enforcement

Out of Scope:

• Database persistence, ORM mappings, or SQL queries — this is an in-memory OOP design
• REST APIs, HTTP controllers, or frontend interfaces
• Payment processing, tuition billing, or financial aid
• Grade recording, GPA calculation, or transcript generation
• Room scheduling, building maps, or physical space allocation
• Instructor workload balancing or teaching assignment optimization
• Authentication, authorization, or role-based access control
• Distributed systems concerns: horizontal scaling, sharding, or replication

In a real interview, spend 3–5 minutes clarifying requirements before sketching any classes. Ask targeted questions:

• "Can a student enroll in two sections of the same course?" — Typically no. Clarify this early.
• "Are prerequisites transitive? If CS301 requires CS201 and CS201 requires CS101, must the student have completed CS101 too?" — Yes, this drives the DAG traversal depth.
• "How should the system behave when a waitlisted spot opens — auto-enroll or just notify?" — This determines whether the Observer triggers enrollment automatically or sends an invitation.
• "Is there a registration window, or can students enroll anytime?" — This scopes whether time-window logic is in play.
• "Can the credit limit vary per student (honors students get more)?" — This may influence whether the limit lives on the Student or is a system constant.

These questions signal to the interviewer that you think about edge cases and ambiguity before committing to a design.