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

2. Planning Phase: Charter, Scope, Stakeholders, Feasibility, Schedule, and Risks

Project Charter

• Project ID: UCRS-WEB-01
• Project Name: University Course Registration & Scheduling Web Portal
• Sponsor: Office of the Registrar
• Product Owner / Business Lead: Registrar Operations Manager
• Technical Owner: University IT Applications Manager
• Target Release: Production-ready before the next approved student registration period.

In Scope

• Student authentication through the university identity service.
• Course and section search.
• Course details, prerequisites, credits, instructor, location, schedule, and seat availability.
• Personal schedule builder.
• Registration, drop, and registration-status workflows.
• Prerequisite, schedule-conflict, capacity, and registration-window validation.
• Registrar administrative controls and approved overrides.
• Enrollment and registration audit logs.
• Responsive desktop, tablet, and mobile browser interface.
• Operational monitoring, backups, rollback, and maintenance procedures.

Out of Scope

• Learning-management-system coursework.
• Tuition payment processing.
• Admissions processing.
• Native Android or iOS applications.
• Faculty grade submission.
• Student transcript generation.

Stakeholder Register

• Project Sponsor: approves budget, scope baseline, and production release.
• Registrar Operations: owns enrollment rules and acceptance criteria.
• Academic Advising: validates prerequisite and registration guidance.
• Students: primary end users represented during usability and acceptance reviews.
• University IT: architecture, integration, infrastructure, support, and operations.
• Security / Privacy Representative: reviews authentication, authorization, logging, and student-data handling.
• QA Team: owns independent system and regression testing.

Feasibility Assessment

• Technical: feasible using an existing university identity provider, relational student/course data, browser frontend, and server-side API.
• Operational: registrar personnel already follow defined registration processes that can be mapped into the application.
• Schedule: feasible if requirements and design are frozen before the development milestone and production readiness is completed before registration opens.
• Economic: expected benefits include reduced manual processing, fewer registration corrections, and improved staff efficiency.
• Security: feasible if least-privilege access, secure sessions, encryption, audit logging, and institutional security review are included.

High-Level Schedule

1. M1 - Planning: Weeks 1-2.
2. M2 - Requirements: Weeks 3-5.
3. M3 - Design: Weeks 6-8.
4. M4 - Development: Weeks 9-16.
5. M5 - Testing: Weeks 17-20.
6. M6 - Deployment: Weeks 21-22.
7. M7 - Maintenance: begins after production acceptance.

Initial Risk Register

• R-01: registration demand exceeds expected load. Probability: Medium. Impact: High. Mitigation: load testing and capacity planning.
• R-02: prerequisite rules are incomplete or inconsistent. Probability: Medium. Impact: High. Mitigation: registrar and advising sign-off on requirements.
• R-03: unauthorized access to student information. Probability: Low. Impact: Critical. Mitigation: university SSO, role-based authorization, audit logging, security testing.
• R-04: integration with student records is unavailable during registration. Probability: Medium. Impact: High. Mitigation: health checks, retries, monitoring, documented incident procedure.
• R-05: production deployment causes enrollment disruption. Probability: Low. Impact: Critical. Mitigation: maintenance window, backups, smoke tests, rollback plan.

Planning Phase Gate

Required approval: Project Sponsor, Registrar Business Lead, and IT Applications Manager approve the charter, scope, feasibility assessment, initial schedule, budget assumptions, and risk register before Requirements begins.