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.

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.

3. Requirements Phase: Functional and Non-Functional Requirements

Requirements Baseline

All requirements use stable IDs so implementation, test cases, acceptance criteria, and change requests can be traced back to an approved business need.

Functional Requirements

• FR-01 Authentication: the portal shall authenticate users through the approved university identity service.
• FR-02 Role Authorization: the portal shall authorize Student and Registrar roles according to approved permissions.
• FR-03 Course Search: students shall search sections by term, subject, course number, keyword, instructor, and availability.
• FR-04 Course Details: the portal shall display section title, credits, instructor, meeting schedule, location, prerequisites, capacity, and available seats.
• FR-05 Schedule Builder: students shall add candidate sections to a temporary schedule before registration.
• FR-06 Conflict Validation: the portal shall prevent registration when selected sections have overlapping meeting times unless an authorized override exists.
• FR-07 Prerequisite Validation: the portal shall validate required prerequisites before completing registration.
• FR-08 Capacity Validation: the portal shall prevent standard enrollment when a section has reached its enrollment limit.
• FR-09 Registration Window: the portal shall permit registration changes only when the student's assigned registration window and institutional rules allow them.
• FR-10 Register: eligible students shall be able to register for an available section.
• FR-11 Drop: eligible students shall be able to drop a registered section within permitted dates and rules.
• FR-12 Current Schedule: students shall view currently registered sections and total registered credits.
• FR-13 Administrative Override: authorized registrar staff shall apply documented overrides where institutional policy permits.
• FR-14 Section Administration: authorized registrar staff shall review section enrollment and seat availability.
• FR-15 Audit Trail: the system shall record successful and failed registration changes, actor, timestamp, action, affected section, and applicable override reference.
• FR-16 Confirmation: the system shall display a clear success or failure result after each registration or drop request.

Non-Functional Requirements

• NFR-01 Performance: 95% of normal interactive requests shall complete within 2 seconds under the approved expected-load profile.
• NFR-02 Peak Load: the production environment shall support the approved registration-period concurrency target established during capacity planning.
• NFR-03 Availability: monitoring and support procedures shall prioritize portal availability during active registration windows.
• NFR-04 Security: all application traffic shall use HTTPS; authentication tokens and sessions shall follow university security standards.
• NFR-05 Authorization: server-side authorization shall enforce role permissions for every protected operation.
• NFR-06 Privacy: student information shall be limited to authorized users and business purposes defined by institutional policy.
• NFR-07 Auditability: security-sensitive and enrollment-changing operations shall produce tamper-resistant operational logs according to institutional retention requirements.
• NFR-08 Accessibility: primary registration workflows shall support keyboard use, semantic form labels, visible focus indicators, sufficient contrast, and accessible validation feedback.
• NFR-09 Responsive UI: required student workflows shall remain usable at common mobile, tablet, and desktop widths.
• NFR-10 Reliability: registration transactions shall avoid partial enrollment changes when validation or persistence fails.
• NFR-11 Recoverability: database backups and documented recovery procedures shall exist before production launch.
• NFR-12 Maintainability: business rules, API services, UI modules, database migrations, and automated tests shall use documented project conventions.

Business Rules

• BR-01: a student cannot register for the same section twice.
• BR-02: only active sections for the selected academic term may accept enrollment.
• BR-03: completed registration must not exceed defined academic credit restrictions unless an authorized override exists.
• BR-04: registration validation must use authoritative course, section, prerequisite, student, and enrollment records.

Requirements Phase Gate

The Software Requirements Specification, business rules, data definitions, acceptance criteria, and requirement traceability baseline require approval from Registrar Operations, Academic Advising, IT Architecture, Security/Privacy, and the Project Sponsor before Design begins.

4. Acceptance Criteria and Requirements Traceability

Acceptance Criteria

• AC-01 for FR-03: given an active academic term, when a student searches by subject and availability, only matching sections are displayed with essential section details.
• AC-02 for FR-06: given two sections with overlapping meeting periods, when the student attempts to register for both without an approved override, the second registration is rejected with a conflict explanation.
• AC-03 for FR-07: given a course requiring a prerequisite the student has not satisfied, registration is rejected unless an authorized prerequisite override is present.
• AC-04 for FR-08: given a section with zero available seats, normal registration is rejected and seat availability is not reduced below zero.
• AC-05 for FR-09: given a student outside the permitted registration period, add/drop actions are unavailable or rejected by the server.
• AC-06 for FR-10: after successful registration, the enrollment record exists, section availability is updated, the student's schedule includes the section, and an audit event is recorded.
• AC-07 for FR-11: after an eligible drop, the enrollment is removed or transitioned according to the approved data model, capacity is updated, and an audit event is recorded.
• AC-08 for FR-13: only authorized registrar users can create an override, and the action records actor, reason, student, section, type, and timestamp.
• AC-09 for NFR-08: critical registration workflows can be completed with a keyboard and all actionable controls expose understandable labels.
• AC-10 for NFR-10: if registration persistence fails, no partial enrollment or seat-count update remains committed.

Requirements Traceability Matrix

Traceability Rules

1. Every approved functional requirement must map to at least one design component.
2. Every requirement that can be verified must map to one or more test cases.
3. Every change request must identify affected requirement IDs, designs, implementation components, tests, documentation, and schedule impact.
4. No mandatory requirement may be marked complete until its linked tests pass and required acceptance evidence exists.

Requirements Approval Record

The requirements baseline is assigned version SRS-1.0. Any modification after sign-off requires an approved change request rather than an undocumented edit.

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.

6. Design Phase: UI/UX, Pages, Validation, and Accessibility

Primary Student Pages

• Dashboard: registration status, active term, current credits, and upcoming registration window.
• Course Search: filters, result cards/table, availability, and course details.
• Section Details: meeting schedule, instructor, prerequisites, credits, and available seats.
• Schedule Builder: candidate sections arranged by day/time with detected conflicts.
• Registration Review: selected sections, validation results, and final confirmation action.
• My Schedule: enrolled sections, total credits, meeting schedule, and eligible drop actions.

Registrar Pages

• Administrative dashboard.
• Section enrollment view.
• Student registration lookup.
• Override creation and history.
• Registration audit search.

Registration Interaction Flow

1. Student selects an academic term.
2. Student searches and reviews course sections.
3. Student adds sections to the schedule builder.
4. The UI displays preliminary schedule conflicts.
5. Student opens Registration Review.
6. The server performs authoritative eligibility validation.
7. If all required rules pass, the enrollment transaction executes.
8. The portal displays the final result and updated schedule.

Validation Message Examples

• Prerequisite: “You have not satisfied the prerequisite for this course.”
• Conflict: “This section overlaps with a course already in your schedule.”
• Capacity: “This section currently has no available seats.”
• Window: “Registration changes are not available for your account at this time.”

Responsive Requirements

• Desktop navigation may use a persistent horizontal menu.
• Mobile navigation must collapse without hiding required registration actions.
• Wide course tables should become responsive cards or controlled horizontal regions on smaller screens.
• Primary Register, Review, Confirm, and Drop actions must remain clearly visible and understandable.
• Schedule information must remain understandable without relying only on color.

Accessibility Design

• Every form control has an associated text label.
• Error summaries identify failed fields or registration rules.
• Keyboard users can complete all critical workflows.
• Focus moves predictably after important validation or modal interactions.
• Status changes use text, icons, and accessible announcements where appropriate.
• Page headings follow a logical hierarchy.

UI Approval Artifact

The approved UI package is versioned as UI-SPEC-1.0 and includes page wireframes, responsive states, component rules, validation messages, navigation behavior, and registrar workflow screens.

7. Development Phase: Implementation Plan, Standards, Roles, and Change Control

Development Work Breakdown

1. Repository, environments, CI checks, and configuration structure.
2. Authentication and role authorization.
3. Database schema and migrations.
4. Course catalog and section search.
5. Student schedule builder.
6. Registration validation service.
7. Enrollment and drop transactions.
8. Registrar administration and overrides.
9. Audit logging.
10. Responsive UI completion.
11. Automated unit and integration tests.
12. Operational logging and monitoring hooks.

Team Roles

• Project Manager: schedule, risks, approvals, change control, reporting.
• Business Analyst: requirements, process rules, traceability.
• UX/UI Designer: workflows, responsive design, accessibility states.
• Technical Lead: architecture, code standards, technical decisions.
• Frontend Developer: browser UI and client-side behavior.
• Backend Developer: APIs, business rules, transactions, integrations.
• Database Engineer: schema, indexes, migration and recovery support.
• QA Engineer: test planning, system testing, defect management.
• DevOps / Infrastructure Engineer: environments, deployment, monitoring, rollback.
• Security Reviewer: authentication, authorization, data handling, security findings.

Development Standards

• Code changes require peer review before merge.
• Database changes use versioned migrations.
• Secrets are stored outside source code.
• Server-side validation is mandatory for enrollment rules.
• Authorization is enforced on the server even when the UI hides unauthorized controls.
• New modules include appropriate automated tests.
• Logging must not expose unnecessary sensitive student data.
• Requirement IDs should be referenced in implementation tasks where practical.

Environment Strategy

Local Development
      ↓
Development Environment
      ↓
Integration / QA Environment
      ↓
User Acceptance Environment
      ↓
Production

Change-Control Process

1. A stakeholder submits a Change Request with ID format CR-###.
2. The Business Analyst identifies affected FR, NFR, BR, and acceptance criteria.
3. The Technical Lead evaluates architecture and implementation impact.
4. The QA Lead identifies required test changes and regression scope.
5. The Project Manager evaluates timeline and delivery impact.
6. The Change Control Board approves, rejects, or defers the request.
7. Approved changes update baselined documents before implementation.

Example Change Request

CR-004: Add waitlist functionality. Impact: FR-08, database schema, section UI, registration workflow, notifications, test plan, and deployment migration. Because the capability is not required for the initial release, the board may defer it to a later approved project version.

Development Phase Gate

Development is complete only when all approved baseline requirements are implemented, code review is complete, build and automated test pipelines pass, known defects are documented, and the release candidate is accepted by the Technical Lead for formal Testing.

8. Testing Phase: Strategy, Test Cases, Defects, and Exit Criteria

Test Strategy

Testing validates functional requirements, business rules, integrations, security controls, accessibility, reliability, and performance before the production deployment gate.

Test Levels

• Unit Testing: validation rules, utilities, data transformations, and service functions.
• Integration Testing: API, database, identity, and student/course record interactions.
• System Testing: complete browser-based workflows.
• Regression Testing: previously passed critical workflows after defect fixes.
• Performance Testing: expected and peak registration demand.
• Security Testing: authentication, authorization, input handling, session behavior, and privilege boundaries.
• Accessibility Testing: keyboard operation, labels, focus behavior, status messaging, and representative assistive-technology checks.
• User Acceptance Testing: registrar and student-representative validation against approved acceptance criteria.

Representative Test Cases

• TC-03 Course Search: search by subject and availability. Expected: only matching active sections appear.
• TC-06 Schedule Conflict: register for overlapping sections. Expected: second conflicting enrollment is rejected.
• TC-07 Prerequisite: register without required prerequisite. Expected: registration rejected with prerequisite message.
• TC-08 Capacity: register for full section. Expected: enrollment rejected and capacity remains valid.
• TC-09 Registration Window: attempt registration outside allowed period. Expected: operation rejected.
• TC-10 Successful Registration: eligible student registers for available section. Expected: enrollment saved, schedule updated, audit entry created.
• TC-11 Drop Course: eligible student drops enrolled section. Expected: schedule and enrollment state update correctly and audit entry is created.
• TC-13 Unauthorized Override: Student role calls registrar override endpoint. Expected: access denied and no override created.
• TC-21 Keyboard Workflow: complete course search and registration using keyboard navigation. Expected: workflow remains operable with visible focus.
• TC-22 Transaction Failure: force persistence failure during registration. Expected: no partial enrollment transaction remains.
• TC-23 Concurrent Seat: simultaneous requests compete for the final seat. Expected: at most the allowed number of enrollments succeeds.
• TC-24 Peak Load: execute approved concurrency scenario. Expected: performance meets agreed thresholds without data corruption.

Defect Severity

• Critical: data corruption, unauthorized student-data exposure, widespread inability to register, or incorrect enrollment transaction.
• High: major required workflow fails with no acceptable workaround.
• Medium: requirement partially fails but a reasonable workaround exists.
• Low: minor visual or usability issue that does not block the workflow.

Testing Exit Criteria

• 100% of mandatory requirements have executed test coverage.
• All Critical and High defects are closed or formally accepted under documented release exception authority.
• Required regression suite passes.
• Performance test meets the approved registration-load target.
• Security review has no unresolved release-blocking finding.
• Registrar UAT signs off the critical registration and administrative workflows.
• Traceability matrix is updated with final test evidence.

Testing Phase Gate

The QA Lead, Registrar Business Lead, Security Representative, Technical Lead, and Project Manager sign the Test Completion Report before Deployment.

9. Deployment Phase: Release, Migration, Verification, and Rollback

Deployment Objective

Release the approved application version to production before registration opens while preserving the ability to return safely to the previous stable state if release verification fails.

Pre-Deployment Checklist

• Approved release candidate identified by version.
• Production infrastructure and configuration validated.
• Database backup completed and recovery procedure verified.
• Database migrations reviewed and tested in the acceptance environment.
• Production secrets and identity integration configured.
• Monitoring, logs, health checks, and alerts enabled.
• Support and registrar teams informed of the deployment window.
• Rollback artifacts and responsible personnel available.
• Change ticket and production approval completed.

Deployment Procedure

1. Announce the approved maintenance or release window.
2. Confirm latest backups and monitoring health.
3. Deploy production database migrations.
4. Deploy backend services.
5. Deploy frontend application assets.
6. Restart or refresh required application services.
7. Execute production health checks.
8. Execute smoke-test scenarios.
9. Open the service to approved users.
10. Observe logs, errors, response times, and registration transactions during the heightened monitoring period.

Production Smoke Tests

• SM-01: authenticated test student can sign in.
• SM-02: active-term course search returns expected records.
• SM-03: test student's current schedule loads.
• SM-04: controlled registration transaction succeeds.
• SM-05: controlled drop transaction succeeds.
• SM-06: registrar test account can access authorized administration pages.
• SM-07: audit events appear for controlled changes.

Rollback Triggers

• Authentication unavailable for a significant portion of users.
• Registration transactions produce incorrect or partial data.
• Unexpected authorization exposure is detected.
• Critical database migration failure occurs.
• Error rate or response time exceeds the agreed emergency threshold and cannot be stabilized quickly.

Rollback Procedure

1. Stop or restrict new registration transactions if required.
2. Notify the incident and release teams.
3. Restore the previous application release.
4. Reverse the database migration only when the approved migration plan confirms reversal is safe; otherwise restore from the approved recovery method.
5. Run previous-version smoke tests.
6. Reopen service when system integrity is confirmed.
7. Document the incident and schedule corrective work.

Deployment Approval

Production release requires approval from the Project Sponsor or delegated release authority, Registrar Business Lead, IT Operations, Technical Lead, and QA Lead.

10. Maintenance Phase: Operations, Support, Monitoring, Backup, and Changes

Operational Ownership

After production acceptance, the portal enters Maintenance. University IT owns technical operations while Registrar Operations owns registration rules and business-process decisions.

Monitoring

• Application availability and health endpoints.
• API latency and error rate.
• Authentication failures.
• Registration success and failure rates.
• Database connectivity and resource utilization.
• Unexpected authorization failures or suspicious privileged actions.
• Infrastructure capacity during registration peaks.

Support Priorities

• P1 Critical: widespread outage, incorrect enrollment state, security incident, or data corruption. Immediate escalation.
• P2 High: major registration function unavailable to a significant user group. Urgent response.
• P3 Medium: limited functional defect with workaround.
• P4 Low: cosmetic issue, minor enhancement, or documentation correction.

Backup and Recovery

• Backups follow the university's approved production database policy.
• Recovery procedures identify restore responsibilities and validation steps.
• Restore capability is tested periodically in a non-production environment.
• Critical registration-period changes receive heightened monitoring and operational review.

Maintenance Categories

• Corrective: defect and incident fixes.
• Adaptive: updates required by infrastructure, browser, identity, or institutional platform changes.
• Perfective: approved usability, performance, and workflow improvements.
• Preventive: dependency updates, refactoring, monitoring improvements, and security hardening.

Post-Release Change Workflow

1. Record the issue or enhancement.
2. Classify operational priority.
3. Evaluate requirement and design impact.
4. Approve through the applicable maintenance change process.
5. Implement and review the change.
6. Test affected and regression scenarios.
7. Deploy through the controlled release procedure.
8. Update documentation and traceability records.

Registration-Period Operations

During major registration windows, the support team uses heightened monitoring, defined escalation contacts, limited-risk production changes, and rapid coordination with Registrar Operations. Non-essential releases should be avoided during the highest-risk enrollment periods.

11. Project Controls: Risks, Decisions, Reviews, Approvals, and Deliverables

Detailed Risk Controls

• R-01 Peak Load: Owner: Infrastructure Lead. Trigger: sustained utilization or latency above warning threshold. Response: scale according to approved capacity procedure.
• R-02 Incorrect Rules: Owner: Business Analyst. Trigger: disagreement between implemented behavior and registrar-approved rule. Response: stop affected release, review SRS baseline, submit change if needed.
• R-03 Unauthorized Access: Owner: Security Lead. Trigger: unauthorized record access or privilege bypass. Response: initiate security incident process and restrict affected functionality.
• R-04 Integration Failure: Owner: Technical Lead. Trigger: authoritative student/course service unavailable. Response: protect enrollment integrity, surface controlled error, escalate dependency incident.
• R-05 Deployment Failure: Owner: Release Manager. Trigger: failed smoke test or critical error after release. Response: invoke rollback decision procedure.

Decision Log Examples

• DEC-01: server-side registration validation is authoritative even when equivalent checks are shown in the browser.
• DEC-02: enrollment transactions must be atomic.
• DEC-03: student authentication uses the university identity service rather than portal-specific passwords.
• DEC-04: waitlist capability is excluded from release 1 unless separately approved through change control.

Phase Deliverables

Planning
- Project Charter
- Business Case
- Scope Statement
- Feasibility Assessment
- Initial Schedule
- Stakeholder Register
- Risk Register

Requirements
- Software Requirements Specification
- Business Rules Catalog
- Acceptance Criteria
- Traceability Matrix

Design
- Architecture Specification
- Data Model
- API Contract
- Security Design
- UI/UX Specification
- Deployment Architecture

Development
- Source Code
- Database Migrations
- Automated Tests
- Build Artifacts
- Technical Documentation

Testing
- Test Plan
- Test Cases
- Defect Register
- Performance Report
- Security Review
- UAT Evidence
- Test Completion Report

Deployment
- Release Package
- Deployment Checklist
- Rollback Plan
- Production Verification Record

Maintenance
- Operations Runbook
- Monitoring Plan
- Support Procedures
- Backup/Recovery Procedure
- Maintenance Change Records

Formal Review Gates

1. G1 Planning Approval: authorize Requirements.
2. G2 Requirements Baseline: authorize Design.
3. G3 Design Baseline: authorize Development.
4. G4 Build Complete: authorize formal Testing.
5. G5 Test Acceptance: authorize Production Deployment.
6. G6 Production Acceptance: transfer the system into Maintenance.

12. Closure Criteria and Final SDLC Traceability Summary

Project Closure Criteria

The implementation project may be formally closed when all of the following conditions are satisfied:

• The approved production release is operating successfully.
• Mandatory functional and non-functional requirements are accepted or have documented approved exceptions.
• Production smoke tests and post-release verification are complete.
• No unresolved Critical release defect remains.
• Registrar Operations formally accepts the delivered registration workflows.
• Operations staff receive the runbook, monitoring procedures, backup/recovery instructions, and escalation contacts.
• Source code, release artifacts, database migrations, design documents, test evidence, and approvals are stored in approved repositories.
• Outstanding enhancements are transferred to the maintenance backlog or a separately approved project.
• Final project risks and lessons learned are documented.
• The Project Sponsor approves closure.

Waterfall Lifecycle Traceability

Planning
  Charter + Scope + Feasibility + Risks
        ↓ Approved at G1
Requirements
  FR/NFR + Business Rules + Acceptance Criteria
        ↓ Approved at G2
Design
  Architecture + Data + API + UI + Security
        ↓ Approved at G3
Development
  Code + Migrations + Automated Tests
        ↓ Approved at G4
Testing
  System + Integration + Security + Performance + UAT
        ↓ Approved at G5
Deployment
  Release + Verification + Rollback Readiness
        ↓ Approved at G6
Maintenance
  Operations + Support + Fixes + Controlled Enhancements

Example End-to-End Trace

Business need: prevent invalid enrollment when two sections overlap.

1. Requirement: FR-06 Conflict Validation.
2. Acceptance Criterion: AC-02.
3. Design: Registration Rules Service plus schedule-conflict UI feedback.
4. Implementation: server-side meeting-overlap validation.
5. Test: TC-06 Schedule Conflict.
6. Release evidence: passed test result in Test Completion Report.
7. Operational control: validation failures recorded through application monitoring and applicable audit logging.

Final Deliverable Set

The completed documentation package gives the project team a reviewable chain from business case through production maintenance. Every major requirement, design decision, implementation component, test, release control, and operational responsibility has an identifiable owner or artifact.

Final Approval

The Project Sponsor signs the Project Closure Record after receiving confirmation from Registrar Operations, University IT, QA, and Operations that production acceptance and handover criteria have been satisfied.