Product requirements

1. Product overview

EasyReg is a web application for making registrar document services easier to access and manage. Its intended end-to-end experience lets a student request an academic document, understand any fees, follow processing progress, and collect or receive the completed record. Staff need a controlled way to review requests, verify payment, and record fulfillment.

Problem to solve

Document requests handled through disconnected, manual steps can make submission requirements, payment status, ownership, and turnaround difficult to follow. EasyReg aims to provide one understandable and auditable place for those steps.

Product goals

Give students a clear way to submit and track document requests.
Give authorized staff a consistent queue for reviewing and completing work.
Make fees, payment verification, and request status understandable.
Protect personal and academic information with role- and record-scoped access.
Give administrators visibility into account and system activity.

2. Users and roles

User	Need	Product access	Current implementation
Student / requester	Request records, see requirements and status, and know what to do next.	Own profile and requests only.	Public registration and standard-user accounts exist; request screens are not implemented.
Registrar staff	Review request details, update processing status, and record release.	Requests assigned or permitted by office policy.	A dedicated registrar role and processing queue are not implemented.
Cashier	Confirm payment and make the payment state visible to request processing.	Payment details needed for verification.	A dedicated cashier role and payment workflow are not implemented.
Administrator	Manage accounts and review system activity.	System-wide administration, subject to audit.	Administrator dashboard, user management, and audit history exist.

The live application currently authorizes Administrator and Standard User roles. Student, Registrar, and Cashier describe intended product responsibilities, not existing system roles or permissions.

3. Product scope

Status	Capabilities
Available now	Public product overview; account registration and sign-in; secure sessions and role checks; profile management; role-scoped dashboard metrics and activity views; administrator account management and audit history.
Foundation present, workflow not complete	Database structures for records, transactions, and notifications are present, but students and staff do not yet have the document-request, payment, fulfillment, or notification workflows that populate them.
Planned product work	Request submission and validation; fee calculation; payment verification; registrar review and fulfillment; student status tracking; notification delivery; operational backup and system settings.
Not defined in this draft	Online payment processing, integrations with student-information systems, electronic document delivery, service-level commitments, and production deployment policy.

4. Functional requirements

ID	Requirement	Acceptance outcome	Status
FR-01	Users can register and sign in using a verified account flow. Public registration must not grant administrative privileges.	A new account receives only the public-registration role; invalid credentials do not establish an authenticated session.	Implemented for Administrator and Standard User access.
FR-02	Users can view and update permitted fields on their own profile.	A user cannot read or change another account by changing a submitted identifier.	Profile management implemented.
FR-03	A requester can submit a document request with the document type, required copies, and any approved supporting information.	The system validates required inputs, stores the request, assigns a reference, and confirms receipt.	Planned.
FR-04	The system calculates request fees from an office-approved fee schedule and request details.	The requester can review the itemized amount before confirming; the calculation is retained with the request.	Planned; fee schedule and policy need confirmation.
FR-05	Authorized staff can review requests and record processing decisions and status changes.	Each change is attributed to an authorized staff account and appears in the request history.	Planned; staff role and assignment policy need definition.
FR-06	Authorized cashier staff can verify payment or record an approved exception.	Payment status is auditable and clearly distinguished from request approval or document release.	Planned; payment method and exception rules need definition.
FR-07	A requester can follow the progress and next action for their own requests.	The requester sees current status and relevant timestamps but cannot access another user's request.	Planned.
FR-08	The system records request completion and how the document was fulfilled.	Only authorized staff can mark a request released or completed; the event is retained in history.	Planned; collection or delivery policy needs definition.
FR-09	The system can notify users about meaningful request changes.	Notifications are tied to the correct account, respect privacy, and link only to authorized destinations.	Planned; delivery channels need definition.
FR-10	Administrators can manage accounts and inspect relevant audit activity.	Administrative actions are permission-checked and important changes are recorded.	User management and audit views implemented.

5. Quality, privacy, and trust requirements

Authorization: Enforce permissions on every server route and data query; a hidden link is not access control. Standard users can access only their own permitted data.
Data protection: Collect only information needed to process a request. Escape displayed content, use prepared database queries, protect state-changing forms, and avoid exposing secrets or sensitive record details in logs.
Auditability: Retain a trace of request, payment, decision, and fulfillment changes with actor and time, subject to an approved retention policy.
Usability: Explain required information, fees, current status, errors, and next steps in plain language. Provide responsive layouts and keyboard-accessible controls.
Reliability: Distinguish a real zero or empty result from unavailable data and system errors. Do not claim a request or payment succeeded until it is durably recorded.
Operations: Production deployment requires HTTPS, private application secrets, least-privilege database access, tested backups, and monitoring. The local development CAPTCHA is not a production control.

6. Release acceptance

The end-to-end request experience is ready for release when the following outcomes can be demonstrated in a test environment:

A requester can submit a valid request, receive a stable reference, and see its current status.
Fees shown to the requester match the approved fee policy and are recorded consistently.
Cashier verification and registrar decisions are separately permissioned and auditable.
Only the requester and staff authorized by the approved assignment policy can access request details.
Completion or release is recorded and communicated according to the agreed fulfillment policy.
Validation failures, unavailable services, empty queues, and unauthorized access have clear, safe outcomes.
Core user journeys work on supported desktop and mobile browsers and are usable by keyboard.
Backup restoration and operational recovery have been tested before production use.

Numeric service levels and success targets are intentionally not invented here. They should be agreed with registrar-office stakeholders and measured after the request workflows are implemented.

7. Open decisions and assumptions

These items need stakeholder confirmation before the planned workflows are considered implementation-ready:

Which document types, eligibility rules, required fields, and supporting evidence are in scope?
What fee schedule, currency, refund, waiver, and payment-reconciliation rules apply?
Will payments be verified manually, handled by an online payment provider, or both?
How are Registrar and Cashier accounts provisioned, and how are requests assigned across staff?
Are records collected in person, delivered electronically, mailed, or offered through more than one method?
Which notification channels and response-time targets should the product support?
What are the retention, deletion, backup, and access-review policies for personal and academic information?
Which student identity system or institutional data source, if any, must EasyReg integrate with?