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

1. Project Overview, Business Case, and Waterfall Model Selection

Project Overview

The University Course Registration & Scheduling Web Portal is a browser-based application that allows authenticated students to search available courses, review prerequisites and seat availability, build a schedule, register or drop courses during permitted periods, and review their final enrollment. Faculty and registrar staff receive administrative functions for course offerings, enrollment controls, registration windows, overrides, and operational reporting.

Business Problem

The university currently depends on fragmented spreadsheets, manual approvals, and separate scheduling processes. This creates duplicate data entry, delayed registration decisions, limited visibility into available seats, schedule conflicts, and significant administrative workload during enrollment periods.

Business Objectives

• Provide one browser-based registration workflow for students and registrar staff.
• Reduce manual enrollment processing and duplicate data entry.
• Prevent invalid registrations caused by prerequisites, schedule conflicts, closed sections, or registration-window restrictions.
• Provide timely seat counts and registration status information.
• Maintain auditable records of registration changes and administrative overrides.
• Release the portal before the university's next approved registration cycle.

Selected SDLC Model: Waterfall

This project will use the Waterfall model in the required order:

Planning
→ Requirements
→ Design
→ Development
→ Testing
→ Deployment
→ Maintenance

Why Waterfall Fits This Project

• Requirements: core registration rules, academic calendars, prerequisites, enrollment limits, and registrar procedures are established institutional processes that can be documented before development.
• Uncertainty: the project has moderate technical complexity but relatively low uncertainty in its primary business workflow.
• Risk: incorrect enrollment, unauthorized access, lost registration changes, and schedule conflicts require formal reviews and documented controls.
• Team: responsibilities are divided among university stakeholders, analysts, designers, developers, testers, infrastructure staff, and registrar representatives, making documented handoffs important.
• Timeline: deployment must occur before a fixed academic registration window, so each phase needs a defined completion gate.
• Compliance: student records require institutional privacy, access-control, audit, and retention controls that benefit from documented requirements and approvals.
• Stakeholder feedback: registrar, academic advising, IT security, and student-services representatives can formally review requirements and designs before implementation.
• Delivery constraints: production release cannot be treated as a continuous experiment because registration periods have fixed operational dates and high user volume.

Waterfall Governance Rule

A phase may begin only after required deliverables from the previous phase are reviewed and approved. Approved baselines may still change, but changes must follow the formal change-control process defined later in this document.