Product Requirement Document (PRD)

Document status and purpose

This public-safe summary describes implemented source reviewed on 5 November 2026, not a separately approved stakeholder specification or a live-site certification. The owner reports a deployed application. Newly prepared local changes and live Instructor access still require owner verification.

ClassSignal helps students check instructor-published class status before commuting. It provides a shared place to follow sections, review current and past status posts, and receive in-app notifications. It is an advisory decision-support system; the institution and its instructors remain the authority for class decisions.

Users and goals

Students register with a name, email, School ID, and password; wait for administrator approval; discover sections; request membership; and, after approval, review those sections' schedules, instructor details, status updates, and history. They can review and mark their own in-app notifications as read.

Instructors register and await approval, create and manage their own sections, maintain the class schedule and room, review student join requests, and publish status changes for approved members. They can update or remove their own section's status-post notes/history subject to the application rules.

Administrators review account registrations, approve or decline eligible accounts, manage account access, inspect system activity, view the administration dashboard and reports, and operate the protected backup and recovery screens.

Configured demo Student and Instructor accounts support grading when demo mode is enabled. They use the same role permissions as their account type, but server-side rules make their identity and password read-only and disable password recovery. There is no public demo administrator.

Primary workflow

1. Register and sign in. Students and instructors create accounts; new accounts remain pending until an administrator approves them. The sign-in form accepts registered email or School ID, asks for the session CAPTCHA, and checks that the selected portal agrees with the account's stored role. Admin accounts are created privately, not through public registration.

2. Follow a section. A student discovers sections on their dashboard and sends a join request. The responsible instructor approves or declines it. Student access to protected section details and history requires approved membership; the management directory is not a Student page.

3. Publish a class status. An instructor selects one of the supported states: Face-to-face, Asynchronous, Delayed, or Cancelled. The post may include a short note and, when applicable, a delayed-until time. The application records the post and creates in-app notifications for approved members.

4. Check and catch up. Students review their followed sections, schedules, current status, notifications, and available history. Reports provide a print preview or PDF for the report types allowed to that role.

5. Administer and recover. Administrators review pending accounts and use the audit, report, backup, and restore tools. Database and logo restoration require explicit confirmation and current administrator credentials; a restore ends sessions and has a documented recovery journal procedure.

Implemented product requirements

PR-01 — Account lifecycle: public registration is limited to Student and Instructor roles. Registration requires a globally unique normalized email, a valid School ID, and a confirmed password of at least 12 characters. New accounts start pending; administrator approval assigns the account ID from a per-role sequence.

PR-02 — Authentication: users sign in by email or School ID with password and CAPTCHA. Portal selection is enforced against the stored account role. Login attempts are throttled, and removed, suspended, pending, declined, or disabled-demo accounts cannot use ordinary authenticated access.

PR-03 — Section access: instructors manage their own sections; protected Student views require approved membership. Admin and the owning Instructor can read the approved-student roster. Publishing and membership decisions remain owner-only. Removing a section uses confirmation and retains its history; Admin can restore the original section only when its owner is eligible, without approving memberships or reviving individually removed posts.

PR-04 — Status notices: instructors publish the supported class status values, optional note, and optional delay time. New posts are retained as history. Approved section members receive an in-app notification; notification read state belongs to its recipient.

PR-05 — Administration: administrators can approve/decline new non-admin accounts, suspend/reactivate and manage account records, review activity, and use administrator-only backup/restore operations. Public admin registration and public demo-admin credentials are not provided.

PR-06 — Reports: administrators have the full configured report catalog. Instructors have transaction and personal-activity reports; students have approved-section status-history and personal-activity reports. Reports validate filters, apply access scoping, use consistent local date/time labels, and can render HTML print views or PDF subject to configured resource limits.

PR-07 — Passwords and sessions: password recovery uses the registered email, expiring broker tokens, generic public responses, throttling, and session/remember-me revocation after a successful reset. Users can change their password in Profile subject to current-password and password-policy checks. Demo users cannot change or recover shared credentials.

PR-08 — Continuity: administrators can create verified database backups and a files ZIP containing the logo plus a reference-only settings snapshot. Database restore is schema-checked and transactional for database changes; logo restore stages and verifies the image and uses compensation/journaling for filesystem changes. Neither operation is a substitute for an independent host backup.

PR-09 — Auditability: significant authentication, account, section, status, report, and backup/restore actions are recorded in the activity log with identity snapshots where applicable. Pages, searches, and previews that are defined as read-only do not create success audit entries.

PR-10 — Usability: the interface supports role-specific navigation, responsive layouts, visible keyboard focus, accessible field feedback, reduced-motion preferences, and print/PDF report layouts. Dates and schedule labels use the same local clock throughout the application.

Scope boundaries and known limitations

The implemented notifications are in-app records. Source inspection does not establish SMS, browser push, mobile applications, attendance taking, grading, room booking, timetable import, or an integration with an external institutional student-information system; these are not described as current features.

A published status is an instructor-provided notice, not an automated determination that a class is cancelled or that a student should travel. The implementation does not state an availability SLA or guarantee that users see an update immediately; the instructor must publish it and the user must access the application.

Scheduled automatic backups are deferred. Restore is deliberately restricted to administrators and has operational recovery requirements. A conventional phpMyAdmin SQL export is a separate recovery artifact from the application's signed backup format.

Items requiring confirmation

Deployed-site verification is pending for this document: confirm the deployed code revision, Help links, role access, actual cPanel PHP/web settings, database engine/version, enabled extensions, HTTPS and email delivery, filesystem ownership/locking, and recovery storage. The owner's statement confirms that a deployment exists, but this code inspection did not sign in to or verify the live site.

The product owner should confirm the campus-approved status terminology, who is responsible for publishing each update, the response expectations for a change, retention requirements, and any required institutional privacy or accessibility policy. Those policy approvals cannot be inferred from the source code.