Product Requirement Document (PRD)

1. Document overview

This PRD defines the product baseline, intended users, functional expectations, and acceptance criteria for CoinQuest. Implemented means present in the supplied AIA; acceptance checks below still require execution on the release build. It supports the ITAPPDEV 3 final project and does not replace the later instructor-formatted proposal.

2. Product introduction

CoinQuest is a Gamified Personal Expense Tracker for Android, developed using MIT App Inventor. It combines manually recorded income, expenses, savings goals, financial summaries, and motivational game elements. It records money activity; it does not hold or transfer funds.

3. Background and problem statement

Small purchases and irregular income can be difficult to remember. Separate notes make financial summaries and progress toward a savings goal harder to review. CoinQuest brings these records into one app and uses visible milestones to encourage regular tracking. Improved habits are an intended outcome, not a measured or guaranteed financial result.

4. Project objectives

• Provide a clear dashboard for recorded balance, income, expenses, and savings progress.
• Support consistent manual recording with validation and immediate feedback.
• Make transaction review, category spending, and monthly totals accessible.
• Encourage savings through goals, XP, levels, badges, and completion history.
• Provide contextual Help and money tips without requiring a remote account.

5. Target users

Students, allowance recipients, and other Android users who want approachable personal money tracking are intended users. The source uses Philippine peso formatting. Formal audience age classification, accessibility research, and supported distribution regions require confirmation from the developer and Play Console.

6. Product scope

The implemented baseline is a single-device, manually maintained tracker with local TinyDB storage and one active savings quest. Multiple completed goals may be retained as history. Banking integrations, automatic transaction import, accounts, cloud synchronization, financial advice, and real monetary rewards are outside the verified scope.

7. Core features

8. Functional requirements

1. FR-01: Dashboard shall display starting balance + total income − total expenses.
2. FR-02: Users shall save income with source, positive amount, and selected date.
3. FR-03: Users shall save expenses with name, positive amount, category, and selected date.
4. FR-04: Users shall create/update a named savings goal with positive target and nonnegative current savings, and add positive contributions.
5. FR-05: Completed goals shall appear in retained completion history.
6. FR-06: History shall filter saved transactions by type and expense category.
7. FR-07: Reports shall present totals, category spending, monthly activity, and selected month/year net income.
8. FR-08: Eligible savings milestones shall award XP once per claimed milestone and update level/badges.
9. FR-09: Users shall open contextual Help and enable/disable sound effects.
10. FR-10: Users shall install the production app through its official Google Play listing.

9. Non-functional requirements

Required qualities are readable Android layouts, persistent local records across restarts, clear validation messages, and consistent peso formatting. Performance and reliability targets: ordinary actions should respond within one second for a 1,000-record test dataset on the agreed reference device; no crashes or data loss during the core acceptance workflow. These are proposed acceptance targets, not measured results. Accessibility and large-font behavior need device testing.

10. User workflows

1. Install from Google Play → open → complete/skip loading → Start My Quest → Dashboard.
2. Dashboard → Income → enter source/positive amount/date → Save → review income/history/reports.
3. Dashboard → Expenses → enter name/positive amount/category/date → Save → review totals.
4. Dashboard → Savings Quest → create goal → add savings → reach milestones → view celebration → continue → inspect completed-goal history.
5. Dashboard → Reports → choose month/year → review income, expenses, net, and category totals.
6. Any supported screen → ? → contextual Help → Back/Next/Done or Close.

11. User interface requirements

Retain the green-and-gold CoinQuest identity, mascot, illustrated states, and visible progress bars. Labels must identify financial values and required inputs. Distinguish empty lists, errors, saved confirmations, and celebrations. Keep navigation and sound controls discoverable. Website Help must support keyboard-accessible, responsive PRD/TRD dialogs and standalone printable documents.

12. Data management requirements

Persist transaction lists, totals, starting balance, active goal, savings progress, claimed milestones, XP, badges, completion history, and sound preference using TinyDB. Avoid duplicate completion entries and repeated milestone rewards. Financial reports depend on manually recorded entries. No verified export, cloud recovery, or transaction edit/delete workflow is promised. Retention, Android backup, and user-facing deletion procedures require release verification.

13. Privacy and security considerations

Financial entries are sensitive. Source evidence shows local storage and no declared cloud/authentication components in reviewed screens. This alone does not establish encryption, absence of network traffic in a compiled build, or Android backup behavior. Verify the exact release permissions, dependencies, data flows, and Data Safety declaration. The existing privacy policy remains marked draft pending reconciliation; production availability does not resolve that review.

14. Limitations and assumptions

One active goal and manually entered peso records are the verified baseline. Saved transaction descriptions use delimiter-separated strings, which may affect parsing if user text includes the delimiter. The source version matches the developer-confirmed production version, but binary equivalence is not established. Minimum SDK 24 is specified in the AIA; actual device compatibility is determined by the release and Play listing. No separate challenge engine or multi-user system is verified.

15. Acceptance criteria

These criteria are a test plan; source inspection does not mark them as passed.

16. Future improvements

Proposed, not implemented: structured transaction records and migration, editing/deletion, export and optional recovery, stronger accessibility validation, automated regression tests, and separately designed recurring challenges. Any future synchronization, authentication, or analytics requires an architecture and privacy review before being described as available.