System Requirements Document for finace-pribadi

1. Introduction

finace-pribadi is a personal finance web application for a single individual who manages their own money. The product's intent is narrow and deliberate: the user records income and expense transactions, and the application performs the financial calculations automatically — totals, balances, and the resulting picture of the user's finances — instead of the user computing anything by hand.

The audience is a self-directed adult tracking their own personal (individual) finances. They want numbers they can believe and a surface that never lies about state. The app is not a shared, team, or business accounting tool; it is a personal ledger with automatic computation at its core.

2. System Overview

finace-pribadi is delivered as a first-party web application with application-owned identity and custom UI. A single accepted human actor — the Personal Finance Tracker — moves through a public entry surface, establishes access to their own durable financial records, and then works in a protected area where they record and maintain income and expense transactions and read automatically computed totals and balances.

Current delivery consists of six pages: Landing (anonymous public entry), Sign Up and Login (anonymous identity-access surfaces), and Dashboard, Transactions, and Transaction Form (protected working surfaces). The backend persists the user's transactions and automatically recalculates totals and balances from the recorded transactions, so the computed figures the user sees are derived from their own records rather than entered by hand.

Narrow exclusions: the app is scoped to personal (individual) finances only — it does not model shared, team, or organizational finances. Calculations are automatic rather than manual; the user is never required to compute totals or balances themselves.

2a. Product Interpretation and Delivery Boundary

The product is a personal instrument, not a marketing surface or a social product. Its defining promise is automatic computation: the user supplies transactions, and the application supplies the arithmetic. Every computed figure the user sees — income total, expense total, net balance, running balance after a pending transaction — is produced by the application from the user's recorded transactions.

Delivery is first-party and web-based. The public entry surface (Landing) is anonymously reachable and explains the app and its automatic calculations. Because the user must privately own and resume durable, actor-specific financial records, the application owns identity: a new user establishes access through self-service enrollment (Sign Up), and a returning user verifies themselves (Login) before reaching their durable records. The protected surfaces — Dashboard, Transactions, and Transaction Form — require that identity to be established; they are not anonymously reachable, and the anonymous entry interactions that establish access live on their own access surfaces rather than inside the protected destinations.

Current scope covers the accepted behavior described in this document. Nothing beyond personal finance tracking with automatic calculation is in current scope; no adjacent account-management, sharing, budgeting, or reporting capabilities are introduced.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Explains that this is a personal finance web app and that calculations are automatic. Presents the product's core promise — the user's money, computed automatically — as a live-looking instrument readout rather than descriptive marketing copy.
• Primary action: Proceed to establish access — begin self-service enrollment (Sign Up) or, for a returning user, verify identity (Login).
• Supporting actions: Read the automatic-calculation demonstration; move between the enrollment and returning-verification entry points.
• Domain entities: None persisted. The displayed figures are an illustrative instrument readout of the automatic-calculation concept (income, expenses, balance), not the user's real records.
• Component responsibilities:
  • Split hero composition: an asymmetric two-column field divided by a single 2px vertical rule.
  • Oversized headline stating that the user's money is calculated automatically, with the automatic-calculation phrase carried in the signal accent colour.
  • A live-computing ledger plate: three hairline-separated label/value rows (income, expenses, balance) whose tabular figures count up on load, with a pulsing status dot labelled as automatically calculated.
  • A circular balance gauge with tick marks and a needle, drawn flat in charcoal and orange.
  • A charcoal-filled primary call to action to begin enrollment, with a hairline-outlined secondary to verify an existing identity.
• States:
  • Loading: Hero and ledger plate render immediately; the ledger figures count up on load.
  • Empty: Not applicable — the landing surface always presents its illustrative instrument readout.
  • Success: The visitor understands the automatic-calculation promise and selects an entry path.
  • Error: If the entry path cannot be reached, the visitor remains on Landing and may retry the entry action.
  • Recovery: The visitor can re-select either entry path at any time from the same surface.

Sign Up

• Information/state: Anonymous identity-access surface. Collects the information needed to establish a new personal account so the user can privately own and resume their own financial records.
• Primary action: Submit enrollment to create the account and enter the protected area.
• Supporting actions: Move to Login if the user already has an account; correct invalid or incomplete entries.
• Domain entities: Account identity (the user's own credentials/identity record).
• Component responsibilities:
  • Enrollment form with labelled fields and inline validation.
  • Submit control that establishes the account.
  • Link to the returning-verification surface.
• States:
  • Loading: Submit control shows an in-progress state while enrollment is processed.
  • Empty: Form presented with empty fields and no errors.
  • Success: Account established; the user is taken into the protected area with their own records available.
  • Error: Invalid or incomplete entries are reported inline against the offending field; the form retains entered values so the user can correct and resubmit.
  • Recovery: The user corrects the reported fields and resubmits, or switches to Login if they already have an account.

Login

• Information/state: Anonymous identity-access surface. Verifies a returning user before granting access to their durable personal financial records.
• Primary action: Submit verification to reach the protected area.
• Supporting actions: Move to Sign Up if the user has no account; correct rejected entries.
• Domain entities: Account identity (the user's own credentials/identity record).
• Component responsibilities:
  • Verification form with labelled fields.
  • Submit control that verifies the returning user.
  • Link to the enrollment surface.
• States:
  • Loading: Submit control shows an in-progress state while verification is processed.
  • Empty: Form presented with empty fields and no errors.
  • Success: Identity verified; the user reaches their own durable records.
  • Error: Rejected verification is reported without exposing whether a specific account exists; the form retains the entered identifier so the user can retry.
  • Recovery: The user retries verification or switches to Sign Up.

Dashboard

• Information/state: Protected working surface. Displays the automatically computed personal financial totals and balances derived from the user's recorded transactions: income total, expense total, and net balance, plus the computed-balance gauge.
• Primary action: Read the automatically computed financial picture.
• Supporting actions: Navigate to Transactions to review or maintain records; navigate to Transaction Form to record a new transaction.
• Domain entities: Computed income total, computed expense total, computed net balance, and the underlying recorded transactions that produce them.
• Component responsibilities:
  • Left navigation rail marking the active item with a flush accent bar and small-caps label.
  • A three-up row of aligned label/value plates for income, expenses, and net balance, each split by a hairline with a small-caps label above and a tabular figure below.
  • A circular balance gauge with tick marks, a needle, and a numeric readout in the centre as the primary computed-balance display.
  • A full-width transaction ledger below the plates with right-aligned numeric columns.
  • An automatically-calculated status indicator confirming the ledger has been recalculated.
• States:
  • Loading: Plates and gauge show a loading state while computed figures are retrieved.
  • Empty: With no recorded transactions, computed totals and balance read as zero and the ledger shows an empty state with ruled grid/dot-grid texture and a prompt to record the first transaction.
  • Success: Computed totals, balance, gauge, and ledger reflect the user's current records; figures count in when a calculation resolves.
  • Error: If computed figures cannot be retrieved, the surface reports the failure and offers retry rather than showing stale or fabricated numbers.
  • Recovery: Retry retrieval; if the failure persists, the user can still navigate to Transactions to review records.

Transactions

• Information/state: Protected working surface. Provides a revisitable overview of the user's recorded income and expense transactions, with the figures that the application computes from them.
• Primary action: Review and maintain the user's transaction records.
• Supporting actions: Filter the ledger; open a transaction for editing in Transaction Form; start a new transaction in Transaction Form; delete a transaction.
• Domain entities: Individual income and expense transactions (amount, type, date, and descriptive details), and the computed totals/balances derived from them.
• Component responsibilities:
  • Dense ruled transaction table with small-caps column headers over a 2px rule, hairline row separators, and right-aligned tabular numerals.
  • Inline filter bar reading like a device control strip.
  • Row-hover treatment revealing a thin accent left edge.
  • Controls to open a transaction for editing, delete a transaction, and start a new transaction.
• States:
  • Loading: Table shows a loading state while records are retrieved.
  • Empty: No recorded transactions — the table shows an empty state with ruled grid/dot-grid texture and a prompt to record the first transaction.
  • Success: The table lists the user's transactions with computed figures consistent with the Dashboard.
  • Error: If records cannot be retrieved, the surface reports the failure and offers retry.
  • Recovery: Retry retrieval; a failed delete or edit leaves the record unchanged and reports the failure so the user can retry.

Transaction Form

• Information/state: Protected focused workspace for creating or editing a single income or expense transaction. Shows a live computed preview of the balance after the pending transaction.
• Primary action: Save the transaction (create or update).
• Supporting actions: Cancel and return without saving; edit an existing transaction's values; observe the live computed preview as values are entered.
• Domain entities: A single income or expense transaction (amount, type, date, and descriptive details) and the computed running balance after that transaction.
• Component responsibilities:
  • Two-column label-left/value-right form grid, max 640px.
  • Field controls with small-caps labels and inline validation.
  • Sticky computed-preview strip showing the balance after this transaction, updating live as the amount is typed, with the delta rendered in the signal accent for income and the brick signal for expense.
  • Save and cancel controls.
• States:
  • Loading: When editing, the form shows a loading state while the existing transaction is retrieved.
  • Empty: New-transaction mode presents empty fields with the computed preview reflecting the current balance.
  • Success: The transaction is saved; the computed preview and the user's totals/balances update automatically, and the user can continue to Transactions or Dashboard.
  • Error: Invalid entries are reported inline against the offending field; a failed save preserves the entered values and reports the failure so the user can retry.
  • Recovery: Correct the reported fields and resubmit, or cancel to return without saving.

3. Functional Requirements

FR-1 — Personal finance web app (explicit). As a Personal Finance Tracker, I should use a web application dedicated to my personal (individual) finances, so that I have a single place for my own money records.

• Trigger/input: The user opens the application in a web browser.
• Observable result: The application presents a personal-finance surface scoped to the individual user.
• Access state: Public entry is anonymously reachable; personal records require established identity.
• Failure/recovery: If the application cannot be reached, the user retries loading it.
• Continuation: The user proceeds to establish access or, if already verified, to their records.
• Scope constraint: Personal (individual) finances only — not shared, team, or organizational finances.

FR-2 — Automatic calculation (explicit). As a Personal Finance Tracker, I should have the application compute my financial figures automatically, so that I never calculate totals or balances by hand.

• Trigger/input: The user records, edits, or deletes a transaction, or opens a surface that displays computed figures.
• Observable result: Totals and balances are computed by the application from the recorded transactions and displayed to the user.
• Access state: Computed figures are shown on protected surfaces after identity is established.
• Failure/recovery: If computation or retrieval fails, the surface reports the failure and offers retry rather than showing stale or fabricated numbers.
• Continuation: The user reads the computed figures and continues recording or maintaining transactions.
• Scope constraint: Calculations must be automatic rather than manual.

FR-3 — Self-service enrollment (required_inference). As a Personal Finance Tracker, I should be able to establish my own account without an invitation or provisioning step, so that I can begin keeping my personal records.

• Trigger/input: The user selects the enrollment entry path from the public entry surface and submits their enrollment information.
• Observable result: An account is established for the user, and they enter the protected area with their own records available.
• Access state: The enrollment interaction is anonymously reachable; the protected area is not.
• Failure/recovery: Invalid or incomplete entries are reported inline; the form retains entered values so the user can correct and resubmit.
• Continuation: The user proceeds into the protected area to record their first transaction.

FR-4 — Returning verification (required_inference). As a Personal Finance Tracker, I should verify myself when I return, so that I can continue accessing my own durable financial records.

• Trigger/input: The returning user selects the verification entry path and submits their identity information.
• Observable result: Identity is verified and the user reaches their own durable records.
• Access state: The verification interaction is anonymously reachable; the protected area is not.
• Failure/recovery: Rejected verification is reported without exposing whether a specific account exists; the user can retry or switch to enrollment.
• Continuation: The user resumes work on their records.

FR-5 — Record an income or expense transaction (explicit). As a Personal Finance Tracker, I should record individual income and expense transactions, so that my ledger reflects what actually happened.

• Trigger/input: The user starts a new transaction and enters its amount, type (income or expense), date, and descriptive details.
• Observable result: The transaction is saved and appears in the user's records.
• Access state: Requires established identity.
• Failure/recovery: Invalid entries are reported inline; a failed save preserves entered values and reports the failure so the user can retry.
• Continuation: The user continues to Transactions or Dashboard, where the computed figures reflect the new record.

FR-6 — Maintain existing transactions (required_inference). As a Personal Finance Tracker, I should edit or delete a transaction I previously recorded, so that my records stay accurate when something changes or was entered incorrectly.

• Trigger/input: The user opens an existing transaction from the ledger and changes its values or deletes it.
• Observable result: The record is updated or removed, and the computed totals and balances recalculate automatically.
• Access state: Requires established identity.
• Failure/recovery: A failed edit or delete leaves the record unchanged and reports the failure so the user can retry.
• Continuation: The user returns to the ledger and reads the recalculated figures.

FR-7 — Review the transaction ledger (required_inference). As a Personal Finance Tracker, I should review a revisitable overview of my recorded transactions, so that I can see and maintain my records over time.

• Trigger/input: The user opens the transactions overview, optionally applying a filter.
• Observable result: The user's transactions are listed with the figures computed from them.
• Access state: Requires established identity.
• Failure/recovery: If records cannot be retrieved, the surface reports the failure and offers retry.
• Continuation: The user opens a transaction to edit it, deletes one, or starts a new one.

FR-8 — Read automatically computed totals and balances (required_inference). As a Personal Finance Tracker, I should see my income total, expense total, and net balance computed automatically from my recorded transactions, so that I have an up-to-date picture of my personal finances without doing arithmetic.

• Trigger/input: The user opens the dashboard, or a transaction is created, edited, or deleted.
• Observable result: The computed income total, expense total, and net balance are displayed, with the balance shown on the computed-balance gauge; figures count in when a calculation resolves.
• Access state: Requires established identity.
• Failure/recovery: If computed figures cannot be retrieved, the surface reports the failure and offers retry rather than showing stale or fabricated numbers.
• Continuation: The user navigates to the ledger to review or maintain the underlying records.

FR-9 — Live computed preview while entering a transaction (required_inference). As a Personal Finance Tracker, I should see the balance after the transaction I am entering update live as I type the amount, so that I can confirm the effect of a record before saving it.

• Trigger/input: The user types or changes the amount (and type) on the transaction form.
• Observable result: The computed preview of the balance after this transaction updates live, with the delta rendered in the signal accent for income and the brick signal for expense.
• Access state: Requires established identity.
• Failure/recovery: If the preview cannot be computed, the form reports the failure and the user can still save or cancel.
• Continuation: The user saves the transaction or cancels without saving.

FR-10 — Backend persistence and automatic recalculation (required_inference). As a Personal Finance Tracker, I should have my transactions persisted and my totals and balances recalculated from them automatically, so that my computed picture stays correct across sessions and devices.

• Trigger/input: The user creates, edits, or deletes a transaction, or opens a surface that displays computed figures.
• Observable result: Transactions are stored durably against the user's own account, and totals and balances are recomputed from the stored records.
• Access state: Persistence and recalculation operate for the verified user's own records.
• Failure/recovery: If persistence or recalculation fails, the affected surface reports the failure and offers retry; no stale or fabricated figures are shown.
• Continuation: The user's next visit reflects the persisted records and recomputed figures.

4. User Personas

Personal Finance Tracker

Product context. The Personal Finance Tracker is an individual managing their own personal finances. They are the sole owner of the records in the app and the only human actor in the product. They came to finace-pribadi because they want their money tracked without doing the arithmetic themselves: the app's promise of automatic calculation is the reason they use it rather than a spreadsheet or a notebook.

Primary goal. To keep an up-to-date, self-computed picture of their personal finances — income, expenses, and net balance — by recording their transactions and letting the application compute the figures.

Distinct accepted responsibilities.

• Establishing their own access to their private financial records: enrolling themselves without an invitation or provisioning step, and verifying themselves when they return.
• Recording individual income and expense transactions with their amount, type, date, and descriptive details.
• Maintaining those records over time — editing or deleting a transaction when something changes or was entered incorrectly.
• Reviewing the ledger of their recorded transactions, including filtering it to find what they need.
• Reading the automatically computed totals and balances, and confirming the effect of a pending transaction through the live computed preview before saving it.

Relevant inputs or decisions. The transaction details they enter (amount, income-or-expense type, date, description); the decision to save, edit, or delete a record; the decision to enroll or to verify an existing identity; the decision to filter the ledger.

Interactions with other accepted participants. There are no other accepted human participants. The Personal Finance Tracker interacts with the application itself, which performs the automatic computation and persistence on their behalf. Their records are private to them; no other human sees or acts on them.

Observable success. The user's ledger reflects what actually happened, and the totals and balances shown are computed automatically from those records — an up-to-date, self-computed picture of their personal finances that they did not have to calculate by hand.

What makes this role's work different. This is not a bookkeeper, an accountant, or a finance team member: there is no reconciliation against external statements, no approval chain, no shared ledger, and no reporting to anyone else. The role's work is the private, recurring act of keeping one's own records current so that the automatic computation stays accurate — and the role's defining expectation is that the arithmetic is never theirs to do.

5. Core User Flows

Flow A — First-time user establishes access and records a first transaction

1. Starting context: The user has no account and opens finace-pribadi in a web browser.
2. On Landing, the user reads the product's promise — their money, calculated automatically — presented as a live-computing ledger plate whose figures count up on load, alongside the circular balance gauge.
3. The user selects the charcoal primary call to action to begin enrollment and arrives at Sign Up.
4. On Sign Up, the user enters their enrollment information and submits.
5. Observable result: The account is established and the user enters the protected area with their own (currently empty) records available.
6. Failure/recovery: If entries are invalid or incomplete, the form reports them inline against the offending field and retains the entered values; the user corrects and resubmits. If the user already has an account, they switch to Login instead.
7. The user arrives at Dashboard, where the computed income total, expense total, and net balance read as zero and the ledger shows an empty state with a prompt to record the first transaction.
8. The user navigates to Transaction Form and enters the amount, type (income or expense), date, and descriptive details of their first transaction.
9. Observable result: The sticky computed-preview strip shows the balance after this transaction updating live as the amount is typed, with the delta rendered in the signal accent for income and the brick signal for expense.
10. The user saves the transaction.
11. Observable result: The transaction is saved and the computed figures recalculate automatically; the user continues to Transactions or Dashboard and sees the new record reflected in the ledger and in the computed totals and balance.
12. Failure/recovery: If the save fails, the entered values are preserved and the failure is reported; the user retries or cancels without saving.

Flow B — Returning user verifies and reviews their computed picture

1. Starting context: The user has an existing account with recorded transactions and returns to finace-pribadi.
2. On Landing, the user selects the hairline-outlined secondary action to verify an existing identity and arrives at Login.
3. On Login, the user submits their identity information.
4. Observable result: Identity is verified and the user reaches their own durable records.
5. Failure/recovery: If verification is rejected, the failure is reported without exposing whether a specific account exists; the user retries or switches to Sign Up.
6. The user arrives at Dashboard and reads the automatically computed income total, expense total, and net balance, with the balance shown on the circular computed-balance gauge; the figures count in as the calculation resolves and the automatically-calculated status indicator confirms the ledger has been recalculated.
7. Failure/recovery: If the computed figures cannot be retrieved, the surface reports the failure and offers retry rather than showing stale or fabricated numbers.
8. Continuation: The user navigates to Transactions to review the underlying records, or to Transaction Form to record a new one.

Flow C — User maintains an existing transaction and reads the recalculated result

1. Starting context: The user is verified and is reviewing their records on Transactions.
2. The user optionally applies a filter in the inline filter bar to narrow the ruled ledger to the records they want.
3. The user opens an existing transaction for editing and arrives at Transaction Form.
4. The user changes the transaction's values.
5. Observable result: The sticky computed-preview strip shows the balance after this transaction updating live as the amount is typed.
6. The user saves the change.
7. Observable result: The record is updated and the computed totals and balances recalculate automatically; the user returns to the ledger and reads the recalculated figures, which are consistent with Dashboard.
8. Failure/recovery: If the edit fails, the record is left unchanged and the failure is reported; the user retries or cancels without saving.
9. Continuation: The user may delete another record (with the same failure/recovery guarantee: a failed delete leaves the record unchanged) or start a new transaction.

Flow D — User records a new transaction from the ledger

1. Starting context: The user is verified and is on Transactions, reviewing their records.
2. The user starts a new transaction and arrives at Transaction Form.
3. The user enters the amount, type, date, and descriptive details.
4. Observable result: The computed preview of the balance after this transaction updates live as the amount is typed.
5. The user saves the transaction.
6. Observable result: The transaction is saved, the ledger on Transactions reflects it, and the computed totals and balance on Dashboard recalculate automatically.
7. Failure/recovery: If entries are invalid, they are reported inline against the offending field; if the save fails, entered values are preserved and the failure is reported so the user can retry.
8. Continuation: The user continues reviewing the ledger or returns to the dashboard.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Dieter Rams, and the headline direction is "Less, but better — a personal ledger with Braun-grade functional clarity." The register is trust, calm control, and precision: the feeling of a well-made instrument on a desk, not a consumer fintech toy.

Colour tokens (light mode).