Waterfall SDLC Documentation for a University Course Registration & Scheduling Web Portal

5. Design Phase: Architecture, Security, Data, and Integration Design

Architecture Overview

The portal uses a browser-based three-tier architecture.

Student / Registrar Browser
        |
        v
Responsive Web Frontend
        |
        v
Application API / Business Services
        |
        +--- University Identity Service
        +--- Student/Course Integration
        |
        v
Relational Application Database
        |
        v
Audit Logs / Monitoring / Backups

Primary Application Modules

• Authentication Module: establishes authenticated university sessions.
• Course Catalog Module: course and section search and details.
• Schedule Builder: temporary schedule selection and conflict preview.
• Registration Rules Service: prerequisite, capacity, conflict, credit, and registration-window checks.
• Enrollment Service: atomic register/drop operations.
• Student Schedule Module: current registration display.
• Registrar Administration: enrollment review and approved overrides.
• Audit Module: registration and privileged-action logging.

Representative API Design

GET    /api/terms
GET    /api/sections?term={term}&query={query}
GET    /api/sections/{sectionId}
GET    /api/students/me/schedule
POST   /api/registrations
DELETE /api/registrations/{registrationId}
GET    /api/registrar/sections/{sectionId}/enrollments
POST   /api/registrar/overrides

Data Model

• User: user_id, university_identity_id, role, status.
• Student: student_id, user_id, program, academic_status.
• Term: term_id, name, start_date, end_date, registration_start, registration_end.
• Course: course_id, subject, course_number, title, credits.
• Section: section_id, course_id, term_id, instructor, capacity, status.
• Meeting: meeting_id, section_id, weekday, start_time, end_time, location.
• Prerequisite: prerequisite_id, course_id, required_course_id, rule_type.
• Enrollment: enrollment_id, student_id, section_id, status, created_at.
• Override: override_id, student_id, section_id, type, reason, approved_by, created_at.
• AuditEvent: event_id, actor_id, action, entity_type, entity_id, result, timestamp.

Transaction Design

The final registration operation must re-check critical eligibility conditions on the server immediately before persistence. Enrollment creation and any authoritative capacity-related update must occur within a transaction so failures do not leave partial state.

Security Design

• University identity provider for authentication.
• Server-side role and permission checks.
• HTTPS for all production traffic.
• Secure session and cookie configuration according to university standards.
• Input validation at API boundaries.
• Parameterized database access or equivalent safe data-access mechanisms.
• Audit logging for registration changes and privileged administrative actions.
• No sensitive student information stored unnecessarily in browser persistence.

Design Phase Gate

Architecture diagrams, API contracts, database schema, transaction strategy, security design, UI specification, and traceability updates must be reviewed by the Technical Lead, Database Engineer, Security Representative, Registrar Business Lead, and QA Lead before Development begins.