Course Registration System

Phase 1: Requirements & Use Cases

Interviewer: "Design a university course registration system."

Candidate: "Let me establish scope before modeling anything. I'm thinking of the core registration domain: students browse a course catalog, register for course sections, drop courses, join waitlists when sections are full, and view their schedule. Professors manage the courses they teach and submit grades. An admin or registrar manages the catalog, enforces prerequisites, and generates transcripts. Does that match your intent?"

Interviewer: "Yes. What else do you need to pin down?"

Candidate: "Several things. First — is this a single-term system or does it manage multiple academic terms simultaneously? Second — do we need real-time seat-count accuracy, meaning two students could race for the last seat, or is eventual consistency acceptable? Third — are prerequisites purely course-based (must have taken CS101) or also grade-based (must have earned a B or better)? Fourth — do cross-listed courses share enrollment counts across departments? Fifth — are we covering the UI layer, persistence, or just the domain model?"

Interviewer: "Multi-term. Treat concurrent registration as something you must handle correctly. Prerequisites are course-based only. Cross-listed courses are an extension — defer it. Domain model only, no persistence layer."

Candidate: "Perfect. Actors: Student — browses catalog, registers, drops, views schedule, checks transcript; Instructor — views roster, submits grades; Registrar — manages catalog, creates course sections, enforces enrollment rules, generates transcripts; Admin — creates courses, assigns instructors, sets prerequisites. Core use cases: (1) browse course catalog — filter by department, term, or availability; (2) register for a course section — validate prerequisites, check capacity, check…