TMCACSA
Time Management Challenges Among College Student-Athletes
Product Requirement Document
Version 1.0
Document Control
| Field | Value |
|---|---|
| Document | Product Requirement Document (PRD) |
| Product | TMCACSA - student-athlete time-management and wellbeing portal |
| Version | 1.0 |
| Generated | November 7, 2026 |
| Prepared by | Student Name |
| Course / Subject | Final Project |
| Status | Implementation-aware requirements baseline; delivery status is recorded in Section 13. |
1. Introduction
1.1 Purpose
This PRD defines the intended users, scope, user outcomes, functional behavior, quality expectations, business rules, and release milestones for TMCACSA. It is an implementation-aware product baseline: requirements taken from the project activity are stated as requirements, while Section 13 identifies what the current code actually implements.
1.2 Scope of this document
The document covers the PHP and MySQL web application for athlete accounts and administrator accounts. Its product areas include account access, weekly schedules, actual time logs, tasks, the academic survey, role-specific dashboards, athlete administration, survey summaries, reporting, account settings, audit-event storage, and the public Help document. It does not assert that every activity requirement has shipped.
1.3 Intended audience
- Student-athletes who record commitments, activity, tasks, and voluntary survey responses.
- Administrators, including a coach or researcher acting within the administrator role.
- The project owner, course evaluator, and future maintainers responsible for reviewing scope and implementation.
1.4 Product language
An athlete owns their schedules, time logs, tasks, and survey responses. An administrator reviews program-level data and manages athlete accounts. A generated hours field is calculated by MySQL and is not written by the application. A stated requirement is not evidence that the feature is present; the implementation-status tables are the source of delivery truth.
2. Product Overview
2.1 Problem statement
College student-athletes coordinate training, games, travel, classes, study, recovery, and personal obligations. When these commitments are recorded in separate places, it is difficult for the athlete to see how actual time is distributed or for a program administrator to review workload patterns consistently. TMCACSA provides one web application for recording those activities and presenting summaries.
2.2 Product vision
Provide a practical, role-aware view of a student-athlete's planned week, recorded time, academic tasks, and self-reported survey answers, while giving administrators aggregate information for review.
2.3 Goals and objectives
- Let athletes create an account and securely return to their own workspace.
- Represent recurring commitments separately from dated, actual time logs.
- Help athletes organize due dates and see status and priority at a glance.
- Collect voluntary responses with informed-consent language and required five-point rating answers.
- Summarize activity and task data for athletes, and survey/workload data for administrators.
- Provide filtered tabular reports and exportable CSV files for project review.
2.4 Measurable success metrics
The project activity specifies features but does not set numeric adoption, response-time, or quality targets. The following measures are therefore proposed indicators; a course owner or project sponsor must set targets after obtaining a baseline. No values are presented here as observed results.
| Indicator | Measurement | Target status |
|---|---|---|
| Registration completion | Successful athlete registrations divided by started registrations during a defined evaluation period. | Target to be set after baseline. |
| Time-log usability | Share of test participants who can add and edit a dated log and see the generated duration. | Target to be set by evaluator. |
| Survey completion | Completed response sets divided by athletes who begin the survey; report only in aggregate. | Target to be set by study owner. |
| Report correctness | Compare selected report rows and totals against the corresponding database query results. | Acceptance is correct results for the agreed test dataset. |
| Security-flow correctness | Verify role denial, CSRF rejection, lockout behavior, password verification, and logout behavior through tests. | All agreed test cases pass before release. |
2.5 Data entities and reporting views
| Database object | Product purpose | Current use |
|---|---|---|
| users | Account identity, unique username, optional unique email, password hash, role, athlete sport/year/course, and registration timestamp. | Authentication, settings, athlete management, dashboards, reports. |
| categories | Controlled activity categories. | Schedule, time log, dashboard, report, and profile grouping. |
| schedules | User-owned weekday commitment with category, time range, and optional description. | Athlete weekly grid and today's dashboard schedule. |
| time_logs | User-owned dated activity with category, start/end, notes, and MySQL-generated hours. | Time-log CRUD, dashboards, athlete profiles, administrator metrics, and CSVs. |
| tasks | User-owned title, due date, priority, status, and creation timestamp. | Athlete task list/dashboard and report pending-task summary. |
| survey_questions | Question text, type, and domain. | Athlete survey and administrator results. |
| survey_responses | One row per user/question pair, with nullable rating or text answer and submission timestamp. | Survey upsert, respondent counts, averages, distributions, anonymous text results, and CSV export. |
| login_attempts | Username, IP, success flag, and attempt timestamp. | Login throttling and expired-attempt cleanup. |
| activity_logs | Actor identifiers, role, action, optional details, request metadata, and timestamp. | Selected events are written through the shared logger; no view page exists. |
| v_weekly_balance | Per-athlete training, study, and rest totals for its trailing-week calculation. | Administrator overload table and average-rest metric. |
| v_survey_averages | Average Likert score and response count by question/domain. | Administrator survey results. |
| v_hours_per_category | Category totals grouped by user, name, and sport. | Present in the database; the current pages perform their own category aggregates. |
3. Target Users and Personas
3.1 Athlete
| Attribute | Description |
|---|---|
| Goals | Record weekly commitments and actual activity, keep deadlines visible, understand time distribution, and optionally contribute to the academic survey. |
| Pain points | Training, competition, travel, study, classes, and recovery compete for time; a schedule alone does not show actual hours or due-task status. |
| Capabilities | Register and log in; create and delete owned schedule entries; create, edit, filter, and delete owned time logs; manage task details and status; submit or update survey responses after consent; view their dashboard; edit their profile and password. |
| Data boundary | Record queries and mutations are scoped to the signed-in user for the athlete-owned modules. |
3.2 Administrator (coach or researcher)
| Attribute | Description |
|---|---|
| Goals | Review program totals, identify workloads that meet the current warning rule, find athlete records, inspect category totals, and export filtered project data. |
| Pain points | Program-level review is difficult when logs and survey data are not summarized consistently; interpretation must retain respondent privacy. |
| Capabilities | View administrator metrics and charts; search and filter athlete records; view a selected athlete's category-hour profile; delete an athlete account; inspect survey averages, rating distributions, and anonymous text answers; generate filtered CSV exports; change profile and password. |
| Data boundary | Administrator views are role-protected. Open-text survey results omit names and display sport and year level; the administrator can still access separate athlete management data. |
4. Scope
4.1 In scope
- Username-based authentication, athlete registration, first-admin setup, session protection, CSRF checks, CAPTCHA, and login-attempt lockout.
- Weekly fixed schedules and dated time logs, including category association and database-generated duration.
- Task title, due date, priority, status, filtering, and overdue presentation.
- Voluntary survey participation, Likert and text answers, answer updates, domain summaries, and aggregate reporting.
- Athlete/admin dashboards; admin athlete search, demographic filters, profile category totals, and athlete deletion.
- Filterable report tables and CSV export, shared print layout, account settings, and public PRD Help access.
4.2 Out of scope or not established
- Native iOS/Android applications, external calendar synchronization, wearable integrations, or automated schedule imports.
- Medical, psychological, or clinical diagnosis; workload alerts are rule-based prompts, not professional advice.
- Automated study recruitment, ethics-board approval, consent versioning, or proof of consent persistence; the current survey checks consent at submission but has no consent column in the response schema.
- A dedicated administrator Activity Log screen, database backup execution, or restore workflow; the audit table and backup constants alone do not provide those screens or operations.
- A production domain, certificate provisioning, or enforced HTTPS deployment; HTTPS enforcement is configurable and disabled in the current configuration.
- Guaranteed uptime, response-time objectives, accessibility conformance certification, or formal cross-browser certification.
5. User Stories
Acceptance criteria below describe observable behavior. Stories for modules that are absent or partial remain product requirements and are identified again in Section 13.
| ID | As a | I want | So that | Acceptance criteria | Priority |
|---|---|---|---|---|---|
| US-01 | Prospective athlete | Register with a username and profile details | I can use the athlete workspace | Valid fields, username uniqueness, password rules, and CAPTCHA are checked before an athlete row is created. | Must |
| US-02 | Returning user | Log in with my username and password | I reach the dashboard for my role | Valid credentials establish a session; invalid credentials receive a generic error. | Must |
| US-03 | User | Be challenged and temporarily limited after repeated failed logins | Automated guessing is less practical | CAPTCHA is addition-only; repeated failures trigger the configured account/IP lockout. | Must |
| US-04 | Athlete | Record a fixed weekly schedule item | I can see recurring commitments by weekday | Category, weekday, start, end, and optional description are saved for my account. | Must |
| US-05 | Athlete | Be warned when a schedule item overlaps | I can decide whether to keep the conflict | The overlap warning is shown and the valid item remains saveable. | Should |
| US-06 | Athlete | Delete one of my schedule entries | I can remove an obsolete commitment | Confirmation is requested and deletion is constrained by schedule ID and my user ID. | Must |
| US-07 | Athlete | Record actual hours on a date and category | I can compare activity with my plan | End time must follow start time; MySQL calculates hours. | Must |
| US-08 | Athlete | Edit one of my time logs | I can correct recorded details | The form is prefilled and the update is constrained by log ID and my user ID. | Must |
| US-09 | Athlete | Filter and page through my logs | I can focus on a date range and category | Filters apply to my logs, 10 rows are shown per page, and total hours cover the filtered set. | Must |
| US-10 | Athlete | Track tasks by deadline and priority | I can plan work around my commitments | New tasks start Pending and show title, due date, priority, and status. | Must |
| US-11 | Athlete | Change a task status, edit it, or delete it | I can keep my task list current | Actions mutate only rows owned by my user ID; status filtering works. | Must |
| US-12 | Athlete | See overdue tasks distinctly | I can notice unfinished past-due work | Tasks with a past due date and non-Done status are marked overdue. | Should |
| US-13 | Athlete | Review the study consent before answering | I can make a voluntary participation choice | The consent paragraph is shown and agreement is required to submit. | Must |
| US-14 | Athlete | Answer rating and open-text questions | I can share structured and written responses | Each Likert answer is 1-5 and required; text answers are optional. | Must |
| US-15 | Athlete | Update prior survey answers | I can correct my response set | Existing answers prefill and each user/question row is inserted or updated. | Must |
| US-16 | Athlete | See time, tasks, schedule, and charts together | I can review my current patterns | Dashboard shows weekly totals, task counts, upcoming tasks, today's schedule, and last-seven-day charts or an empty state. | Must |
| US-17 | Athlete | Receive a balance prompt when configured thresholds are crossed | I can consider recovery and workload trade-offs | The prompt is based on logged training/class hours or average rest, and is omitted when no hours are logged. | Should |
| US-18 | Administrator | Review program totals and category hours | I can monitor submitted data | Dashboard counts athletes, logs, respondents, average rest, and charts category hours. | Must |
| US-19 | Administrator | Find an athlete by search, sport, or year | I can locate the relevant record | Filters constrain the results and the table includes logs, survey completion, and registration date. | Must |
| US-20 | Administrator | Review an athlete's category hours | I can inspect an individual summary | Selecting an athlete name opens a profile section with category totals. | Should |
| US-21 | Administrator | Remove an athlete account when authorized | I can clean up an account | CSRF and confirmation are required; only a user with athlete role is deleted. | Must |
| US-22 | Administrator | Review question averages and rating distributions | I can summarize survey responses | Questions are grouped by domain and show averages and counts for ratings 1-5. | Must |
| US-23 | Administrator | Read written survey answers without names | I can preserve respondent anonymity in results | Open-text results display question, response, sport, and year level only. | Must |
| US-24 | Administrator | Filter reports and export CSV data | I can review or analyze selected records | Sport/year/date filters are honored; exports contain headers and a UTF-8 BOM. | Must |
| US-25 | Administrator | View an activity log and perform backup/restore | I can audit and recover operations | A protected screen and tested backup/restore operation are available. | Should |
| US-26 | Signed-in user | Update profile or password | I can keep account information current | Profile fields are validated; password changes verify the current password and are logged without password values. | Must |
| US-27 | Guest or signed-in user | Open product help and print or copy the PRD | I can understand and reuse product documentation | Help remains public; print and rich-text copy controls work without inline JavaScript. | Should |
6. Functional Requirements
“Implemented” means the current code contains the behavior. “In progress” means a related part exists but the stated product capability is incomplete. “Planned” means the required application feature is absent.
6.1 Authentication and registration
| ID | Requirement | Current status |
|---|---|---|
| FR-AUTH-01 | The system shall register an athlete using full name, username, optional email, sport, year level, course, and password, validate fields, and assign the athlete role. | Implemented |
| FR-AUTH-02 | The system shall enforce the 4-30 character username rule and reject case-insensitive duplicates before insert. | Implemented |
| FR-AUTH-03 | The system shall authenticate by username, verify the stored password hash, and return a generic invalid-credentials message. | Implemented |
| FR-AUTH-04 | The system shall create a session containing user ID and role, regenerate the session ID after authentication, and route the user to the matching dashboard. | Implemented |
| FR-AUTH-05 | The system shall protect athlete and administrator routes using role checks and reject cross-role access. | Implemented |
| FR-AUTH-06 | The system shall permit one-time bootstrap of an administrator when no administrator exists. | Implemented |
| FR-AUTH-07 | The system shall end a session through a CSRF-protected POST logout action. | Implemented |
6.2 CAPTCHA and login-attempt lockout
| ID | Requirement | Current status |
|---|---|---|
| FR-CAP-01 | The login and registration forms shall display an addition question made from two random integers from 1 through 10; the answer shall be one-time session data. | Implemented |
| FR-CAP-02 | The system shall validate the submitted CAPTCHA before credential or registration processing and create a replacement only when redisplaying a failed form. | Implemented |
| FR-CAP-03 | The login form shall accept answer values in the range 2-20 and server-side validation shall reject blank or non-numeric answers. | Implemented |
| FR-CAP-04 | The system shall count failed login attempts by username and IP, apply the configured limit/window, and report remaining lockout time. | Implemented |
6.3 Weekly schedule
| ID | Requirement | Current status |
|---|---|---|
| FR-SCH-01 | The athlete shall add a category, weekday, start/end time, and optional description to their own fixed weekly schedule. | Implemented |
| FR-SCH-02 | The system shall reject an end time that is not later than the start time. | Implemented |
| FR-SCH-03 | The system shall warn about a same-user, same-day overlap without blocking an otherwise valid save. | Implemented |
| FR-SCH-04 | The system shall show Monday through Sunday, with entries ordered by start time and visually associated with their category. | Implemented |
| FR-SCH-05 | The system shall confirm deletion and delete only a row matching both schedule ID and session user ID. | Implemented |
6.4 Actual time log
| ID | Requirement | Current status |
|---|---|---|
| FR-LOG-01 | The athlete shall create a dated category log with start/end time and optional notes; the database-generated hours field shall not be inserted or updated by PHP. | Implemented |
| FR-LOG-02 | The system shall validate date and time values and require end time later than start time. | Implemented |
| FR-LOG-03 | The athlete shall edit and delete only their own log rows using log ID and session user ID constraints. | Implemented |
| FR-LOG-04 | The system shall filter logs by date range and category and show date, category, times, generated hours, notes, and actions. | Implemented |
| FR-LOG-05 | The system shall paginate at 10 rows and calculate total hours for the entire filtered result, not only the visible page. | Implemented |
6.5 Tasks
| ID | Requirement | Current status |
|---|---|---|
| FR-TASK-01 | The athlete shall create a task with title, due date, and Low/Medium/High priority; new rows use the database Pending default. | Implemented |
| FR-TASK-02 | The task list shall sort by Pending, In Progress, Done, then due date, and support status filtering. | Implemented |
| FR-TASK-03 | The athlete shall edit, update status, and delete only tasks matching task ID and session user ID. | Implemented |
| FR-TASK-04 | The interface shall visually flag a task whose due date is before today while its status is not Done. | Implemented |
6.6 Athlete survey
| ID | Requirement | Current status |
|---|---|---|
| FR-SURV-01 | The page shall present the stated voluntary-participation consent paragraph and require agreement before accepting a submission. | Implemented |
| FR-SURV-02 | The system shall load survey questions in domain/question order and group them under domain headings. | Implemented |
| FR-SURV-03 | Each Likert question shall require one of five labeled responses, 1 Strongly Disagree through 5 Strongly Agree; text questions shall accept optional text. | Implemented |
| FR-SURV-04 | The system shall prefill a user's existing answers and upsert one response per user/question inside a transaction. | Implemented |
| FR-SURV-05 | The survey page shall report progress based on answered questions. | Implemented |
| FR-SURV-06 | The system should persist the consent decision and applicable consent-text version for later audit. | Planned |
6.7 Athlete dashboard
| ID | Requirement | Current status |
|---|---|---|
| FR-ADASH-01 | The dashboard shall show this week's total, training, study, and rest hours and pending/overdue task counts for the signed-in athlete. | Implemented |
| FR-ADASH-02 | The dashboard shall chart hours per category over the last seven days and daily totals stacked as Training, Study, Rest, and Other where applicable. | Implemented |
| FR-ADASH-03 | The dashboard shall show up to five upcoming non-Done tasks and today's schedule in start-time order. | Implemented |
| FR-ADASH-04 | The dashboard shall provide a friendly no-data state and show a balance alert when logged week data exceeds its configured workload/rest rules. | Implemented |
6.8 Administrator dashboard
| ID | Requirement | Current status |
|---|---|---|
| FR-ADASH-05 | The administrator dashboard shall show athlete count, time-log count, distinct survey respondents, and average weekly rest from the balance view. | Implemented |
| FR-ADASH-06 | The administrator dashboard shall chart total athlete hours per category. | Implemented |
| FR-ADASH-07 | The administrator dashboard shall identify athletes meeting the configured high training-plus-study and low-rest conditions using the weekly-balance view. | Implemented |
6.9 Athlete management
| ID | Requirement | Current status |
|---|---|---|
| FR-ATHM-01 | The administrator shall search athlete name, email, sport, or course and filter by sport and year level. | Implemented |
| FR-ATHM-02 | The table shall show name, email, sport, year, course, time-log count, survey completion, and registration date. | Implemented |
| FR-ATHM-03 | Selecting a name shall show a profile section with hours by category. | Implemented |
| FR-ATHM-04 | The administrator shall create, edit, and delete athlete records through controlled CRUD operations. | In progress; registration creates athlete accounts and admin can delete, but admin-side create/edit forms are absent. |
6.10 Survey results
| ID | Requirement | Current status |
|---|---|---|
| FR-RESULT-01 | The administrator shall view respondent count and Likert average by question using the survey-average view. | Implemented |
| FR-RESULT-02 | Questions shall be grouped by domain and display horizontal average-score charts and counts for values 1 through 5. | Implemented |
| FR-RESULT-03 | Open-text answers shall be displayed without respondent names, with sport and year level only. | Implemented |
6.11 Reports and print preview
| ID | Requirement | Current status |
|---|---|---|
| FR-RPT-01 | The administrator shall filter the report by sport, year level, and date range. | Implemented |
| FR-RPT-02 | The report shall summarize each athlete's time-log count and category hours for the selected date range, alongside current pending-task count and survey-completion state. | Implemented; task counts and survey-completion state are not date-filtered. |
| FR-RPT-03 | The administrator shall export time logs, survey responses, and athlete summaries as CSV using fputcsv and a UTF-8 BOM. | Implemented |
| FR-RPT-04 | The report shall support print preview/PDF through the shared print query mode and print stylesheet. | Implemented through shared print mode; no report-specific preview button is present. |
6.12 Filtering
| ID | Requirement | Current status |
|---|---|---|
| FR-FILT-01 | Athletes shall filter time logs by date range and category, and tasks by status. | Implemented |
| FR-FILT-02 | Administrators shall filter/search athlete records by text, sport, and year level. | Implemented |
| FR-FILT-03 | Administrators shall filter reports by sport, year level, and date range, with selected filters preserved on export. | Implemented |
6.13 Activity log
| ID | Requirement | Current status |
|---|---|---|
| FR-AUD-01 | The application shall record relevant account actions with action, optional details, actor identity when available, request metadata, and timestamp. | In progress; a shared logger and table exist for selected actions. |
| FR-AUD-02 | An administrator shall be able to view and filter audit entries through a protected Activity Log page. | Planned; no Activity Log page exists. |
| FR-AUD-03 | Audit details shall never include passwords, password hashes, or secret values. | Implemented for current authentication/settings log messages. |
6.14 Backup and restore
| ID | Requirement | Current status |
|---|---|---|
| FR-BACK-01 | An administrator shall initiate a database backup to an access-controlled destination. | Planned; configuration constants exist, but no backup implementation or page exists. |
| FR-BACK-02 | An authorized administrator shall restore a verified backup with a documented recovery process. | Planned; no restore implementation exists. |
| FR-BACK-03 | Backup retention, integrity checking, and restore testing shall be documented and verifiable. | Planned. |
6.15 Settings and profile
| ID | Requirement | Current status |
|---|---|---|
| FR-SET-01 | Any authenticated user shall view and update full name and optional email; username shall be displayed but immutable. | Implemented |
| FR-SET-02 | Athletes shall edit sport, year level, and course; profile writes shall be constrained by session user ID. | Implemented |
| FR-SET-03 | Password change shall verify the current password, enforce the current length/character rule, hash the new password, and regenerate the session ID. | Implemented |
| FR-SET-04 | Profile and password changes shall be logged without recording password material and shall use CSRF and PRG. | Implemented |
6.16 Help pages
| ID | Requirement | Current status |
|---|---|---|
| FR-HELP-01 | Guests and authenticated users shall have a Help menu with a public PRD link; a TRD link shall appear only when its file exists. | Implemented by the shared header and file guards. |
| FR-HELP-02 | The PRD shall be reachable without calling require_login and shall document requirements separately from current implementation status. | Implemented by this public page. |
| FR-HELP-03 | Documents shall offer print/save-as-PDF, rich-text copy, back navigation, and print-specific pagination styles. | Implemented for this PRD; TRD remains planned. |
7. Non-Functional Requirements
| Area | Requirement | Current evidence or gap |
|---|---|---|
| Security | Use password hashing/verification, prepared statements for variable SQL values, session and role checks, CSRF protection on state-changing forms, escaped HTML output, and a restrictive Content Security Policy. | These controls appear in the current PHP code. HTTPS is configurable, not forced in the current development configuration. |
| Performance | Routine pages should use bounded queries, indexes, aggregate views, and pagination where result sets may grow. | Time logs are paginated; current tables/views have indexes and aggregates. No response-time objective or load test is defined. |
| Usability and responsiveness | Use labeled controls, understandable validation, empty states, responsive layouts, and role-appropriate navigation. | Existing pages use semantic forms and responsive CSS; browser/device acceptance thresholds have not been formally specified. |
| Reliability and recovery | Database failures should not silently produce false data; backups should be protected, retained, and restorable. | PDO exceptions are enabled. A backup directory/retention setting is present, but backup and restore operations are not implemented. |
| Maintainability | Shared authentication, escaping, session, and logging behavior should stay in shared includes; pages should follow table and role conventions. | Procedural PHP with shared includes and explicit tables/views; no automated test suite or migration framework is present. |
| Browser compatibility | Support current browsers with HTML5 form controls, CSS Grid, JavaScript event listeners, and Chart.js. | Chart.js is loaded from a CDN. A supported-browser matrix and offline chart fallback are not defined. |
| Accessibility | Provide semantic headings, visible labels, keyboard-operable controls, focus behavior, and meaningful accessible names for charts and menus. | Several labels/ARIA names are present. No WCAG conformance audit or automated accessibility test is recorded. |
| Data privacy | Limit athlete data to authorized roles, scope athlete records to their owner, minimize identity in survey reporting, and avoid logging credentials. | Owner filters and role guards exist; survey result text omits names; logs avoid password values. The general athlete admin table and time-log report intentionally identify athletes. |
| Research ethics | Participation must be voluntary, consent language must be clear, and reported survey text must not display respondent names. | Consent copy/checkbox and anonymous text-result display exist. Consent is not persisted as a separate response field; institutional ethics approval is outside the codebase. |
8. Business and Validation Rules
| Rule | Definition | Source/behavior |
|---|---|---|
| Roles | A user is an athlete or administrator; protected pages require the matching role. | The users role enum and require_role checks. |
| Username | 4-30 ASCII letters, digits, or underscores; no spaces; unique case-insensitively at registration. | Registration/admin form validation and username lookup. |
| Password | Registration and password change require at least eight characters with at least one letter and one digit; stored values are password hashes. | Current server-side form validation and password_hash/password_verify. |
| CAPTCHA | Two whole numbers, each 1-10, addition only; answer range 2-20; session answer is single-use. | Shared generation/verification helper and login/register form controls. |
| Login throttling | Configured account failure cap is five over the 15-minute window; IP failures are capped at 20 in that same window. | Current config and login_attempts queries. A future configuration change must be reflected in the documentation. |
| Session inactivity | The configured idle timeout is 30 minutes. First request does not expire a session that has no prior last-activity value. | Shared session initialization and config. |
| Time ordering | For schedules and time logs, end time must be strictly later than start time; overnight intervals are not accepted by current validation. | Server-side time validation. |
| Schedule overlap | Overlap is checked for the same user and weekday where the new start precedes an existing end and the new end follows an existing start; it warns but does not block. | Schedule POST behavior. |
| Time-log duration | Hours are stored as a generated database value derived from time-log fields; PHP inserts and updates do not name the hours column. | MySQL schema metadata and time-log queries. |
| Task status and overdue | Statuses are Pending, In Progress, Done. A task is overdue when due_date is before today and status is not Done. | Task query/display logic. |
| Survey rating | Each Likert response must be one integer in 1-5; all Likert questions are required. Text answers may be blank. | Server-side validation and survey form. |
| Survey uniqueness | At most one stored response exists for each user/question pair; re-submission updates the existing row. | Unique database key and upsert transaction. |
| Survey anonymity | Survey results and survey-response CSV omit names; text-result rows show sport and year level only. | Admin results query and survey export columns. |
| Dashboard alert | Athlete warning applies when current-week Training plus Class exceeds 50 hours or average Rest / Sleep is below six hours per elapsed day; no alert is shown with no time data. | Athlete dashboard calculations. |
| Admin overload table | An athlete meets the displayed condition when training plus study exceeds 50 hours and rest is below 42 hours in the view's trailing-week window. | Administrator dashboard query against v_weekly_balance. |
| Report dates | From/to filters are ISO dates and the start must not follow the end. | Admin report validation. |
9. Assumptions, Constraints, and Dependencies
9.1 Assumptions
- Categories and survey questions are seeded in the MySQL database before use.
- The institution or project owner determines whether the consent wording and study protocol are sufficient for its research requirements.
- Administrators have legitimate authority to view identified athlete management information and delete athlete accounts.
- PHP and MySQL server clocks/time zones are configured consistently for dates, due dates, and generated timestamps.
9.2 Constraints
- The app is a procedural PHP application and directly depends on the named MySQL tables, enums, unique keys, generated column, and views.
- The workspace does not contain a SQL dump. A supplied schema/data export must be imported separately.
- There is no dedicated Activity Log UI, backup/restore implementation, or configured production domain in the current tree.
- HTTPS enforcement is controlled by FORCE_HTTPS and is false in the current development configuration.
- The report and category labels use the seeded category names, including Training, Class, Study, and Rest / Sleep.
9.3 Dependencies
- PHP with PDO and PDO MySQL support; current code uses PHP 8 language features.
- MySQL with the application schema, indexes, unique constraints, generated time-log hours, and reporting views.
- Chart.js is loaded from jsDelivr for dashboards and survey visualizations.
- A configured web server/document root and correct BASE_URL for deployment context.
10. Risks and Mitigations
| Risk | Impact | Mitigation / action | Current status |
|---|---|---|---|
| Missing or mismatched database export | Pages can fail because tables, indexes, generated columns, or views are missing. | Version and distribute the schema/data dump; validate it against the live database contract before deployment. | Dump is absent from this workspace; external project export required. |
| HTTPS is not enabled in deployment | Credentials and session cookies may be exposed on an unencrypted connection. | Provision TLS, configure FORCE_HTTPS, and verify secure-cookie behavior before public deployment. | HTTPS support exists as a configuration option; not enabled by default. |
| No backup/restore workflow | Accidental deletion or database loss may be unrecoverable. | Implement access-controlled backup, retention, integrity checks, and restore drills before production. | Planned; constants alone do not execute backups. |
| Audit entries have no administrator viewer | Recorded events cannot be reviewed through the application. | Build a protected, filterable Activity Log page and define retention/access policy. | Table and logger exist; UI is absent. |
| Consent is not persisted separately | The application cannot demonstrate which consent text/version a respondent accepted. | Store consent decision, timestamp, and text version with an appropriate schema change after protocol approval. | Checkbox is validated per submission; no dedicated consent field exists. |
| External chart CDN unavailable | Charts may not render even when dashboard data loads. | Use a pinned/managed asset or add a clear non-chart data-table fallback. | Current charts depend on CDN availability. |
| Aggregate thresholds are interpreted as health advice | Users may treat rule-based warnings as clinical guidance. | Keep copy supportive, transparent, and non-diagnostic; validate thresholds with the institution before use. | Current messages are friendly prompts, not clinical advice. |
| Report exports contain identifiable activity data | CSV redistribution may expose athlete records. | Limit administrator access, disclose export contents, store files securely, and share only with authorized reviewers. | CSV exports are available to administrators. |
11. Release Plan
The milestones follow the project phases. No calendar dates or deployment commitments were supplied, so none are invented here.
| Milestone | Scope | Evidence in current project | Release gate |
|---|---|---|---|
| Phase 1 - Foundation and authentication | PHP/MySQL connection, shared helpers, registration, login, logout, role sessions, admin bootstrap, and entry page. | Config, includes, auth pages, dashboards. | Guest, athlete, and administrator routing works; credentials use hashes. |
| Phase 2 - Schedule and time log | Weekly fixed schedule and actual date-based logs. | Athlete schedule and time-log pages. | Ownership checks, time validation, generated hours, filters, totals, pagination. |
| Phase 3 - Tasks and survey | Task lifecycle and consent-backed survey. | Athlete task and survey pages. | Required Likert validation, upsert behavior, ownership, and progress display. |
| Phase 4 - Athlete dashboard | Weekly summaries, balance warning, schedule/task summaries, and charts. | Athlete dashboard and shared chart script. | Correct date windows, empty state, and chart categories. |
| Phase 5 - Administrator views | Program dashboard, athlete management, survey results, and CSV reports. | Four administrator pages and chart script. | Role access, anonymous text results, filtering, CSV contents/encoding. |
| Phase 6 - Testing, security, and polish | Project-wide review, directory-listing block, setup documentation, and manual verification. | Shared security helpers, .htaccess, README, and current UI. | PHP/JS checks and the manual test checklist pass. |
| Help documentation - PRD | Public product requirements, Help menu, document copy, and print layout. | This page and shared Help/document controls. | Guest and authenticated access, copy, print layout, and status accuracy verified. |
| Future - Operational readiness | Administrator audit viewer, backup/restore, consent persistence, TLS/domain deployment, and formal browser/accessibility testing. | Not present or not enabled in current code. | Requires design approval, implementation, and operational verification. |
12. Final Project Activity Compliance
The map below uses the Final Project Activity items listed in the request. “Implemented” means source code exists for the described behavior; “In progress” means only a subset is present; “Planned” means it is not implemented. A configuration switch is not proof of deployment.
| Activity requirement | Feature and page/evidence | Status and qualification |
|---|---|---|
| Login | Username/password authentication in auth/login.php; protected routes use the shared role/session helpers. | Implemented. |
| Dashboard with statistics and charts | Athlete weekly statistics and last-seven-day charts in athlete/dashboard.php; program metrics and category chart in admin/dashboard.php. | Implemented; charts require the Chart.js CDN. |
| CRUD | Athletes manage schedules, time logs, tasks, and survey answers; administrator can view/delete athlete records. | In progress as a broad CRUD requirement: athlete modules have create/edit/delete where specified, while administrator athlete-side create/edit is absent. |
| Reports with print preview | Filtered report and CSV buttons in admin/reports.php; shared layout honors ?print=1 and print media rules. Time totals honor date filters; pending-task counts and survey-completion state are current/all-time. | Implemented through shared print mode; no report-specific preview control or template exists. |
| Filtering | Date/category filtering for time logs, status filtering for tasks, search/sport/year filtering for athletes, and sport/year/date report filters. | Implemented. |
| CAPTCHA | Addition-only challenge on auth/login.php and auth/register.php backed by shared generate/verify helpers. | Implemented. |
| Attempt limit | login_attempts table and lockout helper used by auth/login.php; configured account threshold is 5, with a separate IP threshold. | Implemented using current configuration; thresholds are configurable. |
| Password hashing | password_hash/password_verify in registration, login, admin creation, and settings. | Implemented. |
| Audit trail | activity_logs table and log_activity calls in selected login, registration, logout, profile, and password actions. | In progress: event storage exists, but an administrator Activity Log page and comprehensive event coverage do not. |
| Backup and restore | Only backup configuration constants are present; no backup/restore page or operation is present. | Planned. |
| SSL | FORCE_HTTPS and HTTPS cookie/header logic exist in config/shared auth. | In progress: FORCE_HTTPS is false in the current configuration; no certificate provisioning is shown. |
| Deployment on a domain | README documents local PHP built-in server and XAMPP/MAMP setup; no production domain is configured in the project. | Planned. |
13. Current Implementation Status
This inventory reflects the files and schema present in the workspace at document generation time. It does not imply a feature is production-ready merely because a route exists.
| Module | Status | Current evidence |
|---|---|---|
| Guest landing page | Implemented | index.php and shared guest navigation. |
| Authentication and registration | Implemented | auth/login.php, auth/register.php, auth/logout.php, create_admin.php, shared auth functions. |
| CAPTCHA, lockout, CSRF, session checks | Implemented | includes/auth.php, includes/functions.php, login and registration handlers. |
| Athlete schedule | Implemented | athlete/schedule.php. |
| Athlete time log | Implemented | athlete/timelog.php; hours are generated by MySQL. |
| Athlete tasks | Implemented | athlete/tasks.php. |
| Athlete survey | Implemented | athlete/survey.php; consent is checked at submit but not stored in a separate schema field. |
| Athlete dashboard | Implemented | athlete/dashboard.php and assets/js/charts.js. |
| Administrator dashboard | Implemented | admin/dashboard.php and v_weekly_balance. |
| Athlete search/profile | Implemented | admin/athletes.php. |
| Administrator athlete create/edit | Planned | Admin directory currently supports list/search/profile/delete, not admin-side create/edit forms. |
| Survey results | Implemented | admin/survey_results.php and v_survey_averages. |
| Filtered reports and CSV exports | Implemented | admin/reports.php exports time logs, survey responses, and athlete summary. |
| Shared print mode | Implemented | Header print query flag and global print CSS; no report-specific preview button. |
| Activity event storage | In progress | activity_logs table and shared log_activity calls exist. |
| Administrator Activity Log screen | Planned | admin/activity_log.php does not exist; its sidebar link is file-guarded. |
| Backup and restore | Planned | No implementation page or execution path exists; configuration constants alone are not backup functionality. |
| Profile and password settings | Implemented | auth/settings.php. |
| PRD Help page | Implemented | help/prd.php; public and linked from the Help menu. |
| TRD Help page | Planned | help/trd.php is absent; the Help link is conditional on file existence. |
| Production HTTPS and domain deployment | In progress | HTTPS enforcement can be configured, but is off; no production domain is configured here. |
14. Glossary
| Term | Meaning |
|---|---|
| Administrator | Application role authorized to review program data and manage athlete records. |
| Athlete | Application role that owns schedule entries, time logs, tasks, and survey responses. |
| Balance alert | Supportive dashboard message triggered by current workload/rest rules; not medical advice. |
| CAPTCHA | A simple addition question used to check a login or registration submission. |
| CSRF | Cross-site request forgery; POST forms include a session-bound token checked by the server. |
| Generated column | A database column whose value is computed by MySQL; time_logs.hours is generated. |
| Likert response | A rating from 1 (Strongly Disagree) to 5 (Strongly Agree). |
| PRD | Product Requirement Document; this page. |
| PRG | Post/Redirect/Get; a successful form submission redirects to avoid accidental resubmission. |
| Session | Server-maintained state identifying the authenticated user and role across requests. |
| Time log | A dated record of actual activity with category, start/end time, optional notes, and generated hours. |
| Weekly schedule | A recurring weekday commitment, distinct from a dated time log. |
| v_survey_averages | Database view that summarizes average Likert score and response count by question. |
| v_weekly_balance | Database view that summarizes training, study, and rest hours for its trailing-week window. |