Product Requirements Document

Neemias

1. Purpose

Neemias is an attendance application for small teams and school-like environments that need fast, reliable presence tracking for 3 to 5 concurrent users. The product is designed as a progressive web app that works in mobile and desktop browsers, can operate offline, and syncs changes when connectivity returns.

This document is the product-level source of truth. It defines the problem, the intended users, the product boundaries, and the business rules that must not be violated by implementation choices.

2. Product Vision

The product must make attendance tracking extremely simple for non-technical users while remaining safe, auditable, and easy to extend.

The system must:

• Default to Brazilian Portuguese for all users.
• Allow additional languages to be added later without redesigning the application.
• Remain modular so future features such as reports, workflows, and student management can be added cleanly.
• Support offline usage without losing user actions.
• Prioritize accessibility and immediate visual feedback.
• Enforce least privilege and LGPD requirements.

3. Problem Statement

Current attendance workflows are often slow, error-prone, and difficult for non-technical users. The product must reduce friction at the point of attendance capture, while also protecting personal data and preserving a reliable history of changes.

4. Target Users

Role	Primary Need	Typical Access
Roll-caller	Mark present and absent quickly	Attendance only
Report user	Review attendance reports	Reports only
Data entry	Add students and maintain student records	Student creation only
Admin user	Manage students, attendance, reports, and users	Full operational access

5. Product Goals

Goal	Description
Fast attendance capture	A user should be able to identify a student and record attendance with minimal steps.
Immediate recognition	Student photos must appear immediately during search to support visual identification.
Offline continuity	Users must continue working when the internet is unavailable.
Reliable sync	Changes made offline must sync safely when connectivity returns.
Simplicity	The interface must be easy for users with little software experience.
Accessibility	The experience must satisfy WCAG Level AA.
Compliance	The product must comply with LGPD wherever applicable.
Extensibility	The architecture must support future features without major redesign.

6. Scope

In scope

• Attendance marking for present and absent states.
• Student creation and maintenance.
• Student directory browsing with alphabetical ordering and a profile/details view.
• Report access for authorized users.
• Search with immediate photo visibility.
• Offline operation and later synchronization.
• Audit history for student and attendance actions.
• Role-based access control.
• Localization architecture with Brazilian Portuguese default.
• Deletion justification for admin-only student removal.
• Visual and auditory feedback for successful and failed actions.
• Admin-only user lifecycle management (create, update, reset password, deactivate).
• Import and export of student and class data.

Out of scope for now

• Mobile app store distribution.
• Native applications.
• Complex enterprise identity integrations unless explicitly added later.
• Formal regulatory traceability matrix.
• Multi-organization tenancy unless introduced later.

7. Core Users and Permissions

Action	Roll-caller	Report user	Data entry	Admin user
Mark attendance	Yes	No	No	Yes
View reports	No	Yes	No	Yes
Add students	No	No	Yes	Yes
Edit students	No	No	No	Yes
Delete students	No	No	No	Yes, with justification
View users	No	No	No	Yes
Create users	No	No	No	Yes
Edit users	No	No	No	Yes
Reset user password	No	No	No	Yes
Deactivate users	No	No	No	Yes, with safeguards
Search students	Yes	Yes	Yes	Yes
View student photo	Yes	Yes	Yes	Yes

8. Business Rules

1. Admin actions supersede any conflicting lower-privilege actions.
2. Student removal is admin-only and requires a justification text field.
3. Student history and attendance history must be retained for audit purposes.
4. The product must support least privilege wherever applicable.
5. Any change to user-visible data must be double-checked before being committed.
6. The product must remain usable offline and preserve unsynced work until sync can occur.
7. Search results must surface student photos immediately to support identification.
8. Student browsing should be predictable, with alphabetical ordering and a visible profile/details view for stakeholder review.
9. User deactivation is soft only and never physically deletes user history.
10. Self-deactivation is blocked.
11. Deactivation of the last active Admin user is blocked.
12. User management actions must always produce immutable audit events.

9. Open Architectural Decisions

Because this is an open-source project, the following are intentional open decisions rather than fixed implementation choices:

Decision Area	Required Constraint
Hosting	Must remain cloud-hostable without hard lock-in to a specific vendor.
Authentication	Must support offline-aware session validation and re-authentication after expiration.
Encryption	Must use web-standard security primitives where possible.
Database storage	Must allow offline operation via local fallback for 3 to 5 concurrent users when the backend is unreachable.
Internationalization	Must be designed so more languages can be added without rewriting screens.

Status: All decisions above have been implemented. See the ADRs in docs/architecture/adr/ for details. This section will be removed in the next PRD revision.

10. Success Criteria

• A new user can understand the app purpose and roles from the documentation alone.
• Attendance can be recorded with minimal steps and clear feedback.
• Users can keep working when offline and sync later without losing actions.
• Admin-only deletion behavior is obvious and enforceable.
• The product remains small, modular, and contributor-friendly.