Product Requirements Document

1. Product summary

The system provides a shared online workspace for student counseling support. Students can manage permitted profile information, request appointments, ask for additional support, and submit service feedback. Counseling administrators can coordinate student records and requests, track appointment decisions, review feedback, monitor activity, and produce operational reports.

Product boundary: This document describes the current web application and its intended MVP behavior. The application is a prototype; it does not replace emergency services, clinical judgment, or institution-approved case-management procedures.

2. Problem and opportunity

Student support work can span intake, appointment coordination, case follow-up, and service feedback. When these activities are handled across disconnected records, staff may have difficulty seeing current status and students may not know whether a request has been reviewed.

The product brings these workflows into one role-based interface, making requests and their statuses easier to review while giving administrators tools to manage records and understand service activity.

3. Goals and measures

• Give students a clear way to submit and revisit appointment and support requests.
• Help authorized administrators maintain student, case, appointment, and feedback records in one workspace.
• Make request status and administrative follow-through visible to the relevant users.
• Support operational review through dashboard summaries, filtered reports, and activity history.

Suggested success measures

Track request completion and status-update rates, appointment request volumes and outcomes, feedback submission and review rates, and the time between request creation and first administrative action. Establish baselines and targets with the counseling office before production use; the current prototype does not define service-level targets or instrument these measures as a formal analytics program.

4. Users and permissions

Users must sign in with an account appropriate to their role. Administrator accounts require approval; account requests are managed by the main administrator.

5. Scope

Included in the current product

• Separate student and administrator sign-in, account registration, and approved-account access.
• Student profile viewing and editing, appointment requests and history, support requests, and counseling-service feedback.
• Administrative student directory, case/referral management, appointment review, reminders status, feedback review, and account approvals.
• Overview metrics and charts, searchable/filterable reports with CSV export and print-to-PDF, and read-only activity logs.
• Database backup, backup history/download, and controlled restoration of server-created backups.

Not included or not represented as available today

• Emergency dispatch, clinical diagnosis, treatment recommendations, or crisis monitoring. Immediate danger requires local emergency services.
• Automated email or SMS reminders; reminders are a status-tracking feature only.
• Anonymous feedback, student email verification, password recovery, or uploaded-file management.
• Real-time chat, external calendar synchronization, or automated appointment matching.

6. Functional requirements

Priority labels describe the product baseline, not a promise that every deployment is production-ready. Current report filters and administrative actions depend on the chosen report and the user's permissions.

7. Quality requirements

• Privacy: Restrict student and counseling information to authenticated, authorized users. Feedback is not anonymous.
• Security: Protect credentials and sessions; use role checks for administrative operations; require confirmation for destructive or restoring actions.
• Usability: Use clear labels and status language, provide form validation and action feedback, and support keyboard focus visibility.
• Accessibility: Use semantic headings, labeled controls, accessible dialog names, and responsive layouts. Validate against the institution's accessibility standard before deployment.
• Data integrity: Keep student, appointment, referral, and feedback records linked to their owner; preserve closed-case history; prevent unsafe deletion of students with linked counseling history.
• Operational resilience: Provide backup and restore workflows and document that restoration replaces current records. Configure and test scheduled backups for any operational deployment.
• Compatibility: Serve through a configured PHP/MySQL environment such as XAMPP and test supported browsers and screen sizes before release.

Concrete availability, response-time, retention, recovery-point, and recovery-time targets must be set by the deploying institution; they are not currently specified by the application.

8. Key user journeys

Student requests an appointment

Sign in → complete appointment date, time, counseling type, and reason → submit → see the pending request in appointment history → review the administrator's resulting status.

Student requests additional support

Sign in → describe the support needed and choose urgency → submit → revisit My Support Requests to check status and administrator updates.

Administrator follows up

Sign in → review overview or incoming cases/appointments → open the relevant record → update assignment, status, or decision → verify the record and student-facing status where applicable.

Student shares service feedback

Sign in → select a rating and provide comments → submit → authorized administrator reviews the entry and marks it reviewed.

9. Data and privacy

The application stores student and administrator accounts, profile details, appointment requests, counseling referrals, feedback, account approvals, and activity records. Student records include identifiers and academic information; counseling requests and feedback may contain sensitive personal information.

• Collect and access only information needed to deliver and administer counseling support.
• Use institution-approved hosting, access control, retention, consent, and incident-response policies before entering real student data.
• Keep backups in a private location and limit access to authorized operators. A restore replaces current records.
• Follow applicable institutional and legal privacy requirements; this prototype does not define a retention schedule or provide a compliance certification.

10. Release acceptance

The current product baseline is acceptable for a controlled prototype evaluation when the following can be demonstrated in a test environment:

• Student and administrator sign-in are separate, and protected administrative actions require authorized access.
• A student can update permitted profile information, submit an appointment, submit a support request, and submit feedback.
• An administrator can review the related records, act on appointment and referral statuses, and review student feedback.
• Students can see their appointment and support-request history without accessing another student's records.
• The main administrator can process administrator account approvals.
• Reports and logs can be reviewed using available filters, and backup/restore behavior is verified against disposable test data.
• Forms and core pages remain usable with keyboard navigation and on narrow screens; errors are presented without silently indicating success.

Production gate: Before real student data is used, complete institution-led privacy, security, accessibility, backup/restore, and operational-readiness reviews. The prototype status is not a production approval.

11. Constraints and risks

• The current deployment is a PHP/MySQL web application that requires the server and database to be configured and maintained.
• Reminder delivery is not automated; staff must use the reminders workspace as a tracking aid.
• Students cannot self-serve password recovery and registration does not verify student email addresses.
• Feedback is visible to authorized administrators and must not be presented as anonymous.
• The current system does not replace emergency services or define counseling office response-time commitments.
• Backup restoration is a consequential operation and must be tested carefully; backups need private storage and a defined retention policy.

12. Future considerations

Potential follow-on work, subject to institutional approval and user research, includes password recovery, verified contact channels, configurable reminder delivery, accessibility conformance testing, formal retention and audit policies, calendar integrations, and operational service-level reporting. These are not commitments or current product capabilities.