Technical Requirements Document

1. System architecture

The application is a server-rendered PHP web app organized as page-level PHP controllers, shared include files, and a MySQL/MariaDB relational database. It is designed to run in Apache through XAMPP and does not require a PHP framework.

Authenticated pages load shared session, database, authorization, escaping, CSRF, audit, and duration helpers from includes/functions.php. Shared navigation and page layout are rendered by includes/header.php and includes/footer.php.

2. Technology and runtime requirements

• Server: Apache with PHP supporting PDO and the PDO MySQL driver; configure the timezone to match the school deployment (the documented room-usage behavior uses Asia/Manila).
• Database: MySQL or MariaDB with InnoDB and utf8mb4 support.
• Client: current standards-compliant desktop or mobile browser with JavaScript enabled for live duration display and interactive UI behavior.
• Local development: XAMPP is the documented setup. Database credentials are configured under config/database.php or a deployment-specific local configuration.

3. Application components

• Authentication and shared helpers: includes/functions.php manages sessions, login/admin guards, HTML escaping, CSRF tokens, audit logging, and duration formatting.
• Shared layout: includes/header.php renders role-aware navigation; includes/footer.php includes shared page behavior such as active-duration refresh.
• Counseling workflow: counseling_sessions.php validates scheduling and status actions and stores counseling records.
• Room workflows: rooms.php handles room availability and session start/end; usage.php provides room-use history; dashboard.php summarizes current and recent activity.
• Administrative pages: students.php, reports.php, audit_logs.php, and backup_restore.php provide administrator-facing controls and reporting.
• Help documents: prd.php and trd.php render the public product and technical documentation; signed-in users also have links in the application Help navigation.

4. Data model

The supplied database/schema.sql describes the student_network_db schema. Core tables include the following; counseling_sessions.php also ensures its counseling table exists when the feature is used.

• users: account identifier, name, role, password hash, and creation time. Roles include admin, teacher, student, and staff.
• rooms: room name/number, type, capacity, availability status, and current usage reference.
• room_usage_logs: user and room references, purpose, date, start/end timestamps, duration, and active/completed status.
• scft_counseling_sessions: student, optional counselor, scheduled time, status, creator, and creation time.
• audit_logs: actor, action, details, IP address, and event timestamp.
• devices: user-linked device metadata is represented in the schema; a complete device-management UI is not part of the current application.

5. Core data and request flows

• Login: credentials are checked against the stored password hash; the authenticated user and role are held in the server session.
• Room use: validate the requested room and user state, create an active usage log and update room state; on end, record end time/duration and restore availability. Duplicate active use is prevented.
• Counseling: students can submit future requests; authorized staff select a student and optional counselor and manage supported statuses. Changes are recorded in the audit trail.
• Administration: reporting and backup/restore functions are guarded by the administrator role; backup restore is designed as additive and validates schema compatibility.

6. Security and operational requirements

• Use PDO prepared statements for variable SQL values and escape dynamic HTML output with the shared e() helper.
• Require login for application workflows and enforce administrator checks for administrative tools.
• Use CSRF tokens to verify applicable state-changing form submissions; validate input on the server and report errors to the user.
• Store password hashes, not plaintext passwords. Keep production credentials and personal/student records out of source control and public web paths.
• Keep a verified, separate backup before any schema change. Do not import the sample schema into an existing production database without a reviewed migration plan.
• Use HTTPS and least-privilege database credentials in hosted deployments; restrict direct web access to configuration and database utility files.

7. Deployment, maintenance, and constraints

• Deploy the PHP project under the configured Apache document root, configure the database connection, and ensure the application database has the tables required by the deployed version.
• The current repository uses page-level PHP files rather than a separate API service or frontend build pipeline.
• Email delivery, external calendar integration, centralized identity, and automated monitoring are not currently specified or implemented.
• Backups may contain sensitive school data and must be access-controlled, stored securely, and handled according to school retention and privacy policies.