Complete Agile SDLC Documentation for a Personal Expense Dashboard Web Application

Document control, project overview, and business case

Document control

Project: Personal Expense Dashboard Web Application
Document ID: PED-SDLC-001
Version: 1.0
Selected SDLC model: Agile
Product Owner: Finance Product Owner
Technical Owner: Lead Web Developer
QA Owner: QA Engineer
Business Approver: Project Sponsor

Project overview

The Personal Expense Dashboard is a responsive browser-based web application for individuals who want to record income and expenses, organize transactions, define monthly budgets, and understand spending patterns through a consolidated financial dashboard.

Business problem

Many users track personal finances across spreadsheets, notes, receipts, and unrelated applications. This creates duplicated work and makes it difficult to understand monthly spending, remaining budget, or category trends. The proposed application provides one focused workspace for manual personal-finance tracking.

Business objectives

• OBJ-01: Allow users to securely record and manage personal income and expense transactions.
• OBJ-02: Allow users to establish monthly spending limits and compare actual spending with those limits.
• OBJ-03: Present useful summaries and visual trends that make spending behavior easier to understand.
• OBJ-04: Protect private financial information through authentication, authorization, encrypted transport, and secure development controls.
• OBJ-05: Deliver business value incrementally through reviewed and deployable Agile increments.

Success measures

• Registration, authentication, transaction management, budgeting, filtering, and dashboard reporting pass acceptance testing.
• 100% of release-critical acceptance criteria pass before production approval.
• No open Severity 1 or Severity 2 defects exist at production release.
• Core dashboard responses satisfy NFR-04 under the agreed expected workload.
• Core workflows satisfy the project's accessibility acceptance checks.
• The Product Owner accepts the production release against the approved release backlog.

Key assumptions

• The initial release supports one private account per user.
• Transactions are entered manually.
• Users access the application through supported desktop or mobile web browsers.
• The project team consists of one Product Owner, one UX/UI Designer, one Lead Web Developer, one Web Developer, and one QA Engineer.
• The first production release is targeted after four two-week sprints.

Selected SDLC model: Agile and lifecycle justification

Selected model

The project uses Agile as its single SDLC model.

Required lifecycle sequence

Planning → Requirements/User Stories → Design → Development → Testing → Review → Deployment → Repeat Sprint → Maintenance

Why Agile is appropriate

• Requirements: Core financial workflows are known, but dashboard composition, chart presentation, mobile interactions, and budgeting details may improve after stakeholder review.
• Uncertainty: User experience is a meaningful source of uncertainty. Short sprints allow the team to validate transaction entry, reporting, filters, and budget presentation before investing in later refinements.
• Risk: Financial calculation accuracy, authorization, privacy, performance, and usability require early and repeated testing.
• Team: A small cross-functional team can collaborate continuously with fewer formal handoffs than a sequential model would require.
• Timeline: The eight-week initial release window benefits from prioritizing usable increments every two weeks.
• Compliance and privacy: Security, privacy, and accessibility requirements can be incorporated into each story's Definition of Done.
• Stakeholder feedback: The Product Owner is available for backlog refinement, sprint reviews, and acceptance decisions.
• Delivery constraints: The project can release essential transaction and budgeting capabilities even if lower-priority enhancements must move to a later sprint.

Agile cadence

• Sprint duration: two weeks.
• Initial release plan: four sprints.
• Sprint planning: first working day of each sprint.
• Daily coordination: 15-minute team synchronization.
• Backlog refinement: weekly.
• Sprint review: final working day of each sprint.
• Retrospective: immediately after the sprint review or on the next working day.

Definition of Ready

• User story has a stable ID.
• Business value and acceptance criteria are clear.
• Dependencies and known risks are identified.
• Required UI states or design decisions are available.
• Team can reasonably estimate the work.

Definition of Done

• Acceptance criteria implemented and verified.
• Code reviewed and merged through the approved workflow.
• Automated tests added or updated where appropriate.
• Regression checks pass.
• No unresolved critical security, privacy, or financial-calculation defect remains.
• Responsive behavior and accessibility checks are completed.
• Documentation and traceability records are updated.

Planning, scope, stakeholders, feasibility, and milestones

Planning activity

Planning establishes the product goal, scope boundaries, stakeholders, feasibility, initial release backlog, sprint schedule, major dependencies, project risks, and approval responsibilities before implementation begins.

In scope

• User registration, login, logout, and password reset.
• Private user profile with preferred currency.
• Create, read, update, and delete income and expense transactions.
• Transaction categories.
• Monthly overall budget.
• Optional category-level budgets.
• Dashboard KPIs for income, expenses, balance, and budget usage.
• Expense distribution by category.
• Monthly income-versus-expense trends.
• Transaction search and filtering.
• Responsive browser support.

Out of scope for release 1.0

• Bank-account synchronization.
• Credit-card integrations.
• Investment and cryptocurrency tracking.
• Shared family or household accounts.
• Native mobile applications.
• Automated tax preparation or filing.

Stakeholders

• Project Sponsor: approves project funding, major scope changes, and final business release.
• Product Owner: owns product objectives, backlog order, acceptance criteria, and sprint acceptance.
• UX/UI Designer: owns user flows, responsive layouts, interaction states, and usability recommendations.
• Lead Web Developer: owns target architecture, engineering standards, security design, and technical reviews.
• Web Developer: implements approved user stories and supporting tests.
• QA Engineer: owns test planning, regression, defect management, and release-quality evidence.
• End Users: provide controlled usability feedback during selected sprint reviews or beta evaluation.

Feasibility

• Technical: Feasible with a conventional browser frontend, server-side web application or API, relational database, and standard authentication mechanisms.
• Operational: Users need only a supported web browser and internet access.
• Economic: Initial hosting, database, monitoring, and development needs are moderate because real-time bank connectivity is excluded.
• Schedule: Four two-week sprints are achievable if release 1.0 remains limited to the approved scope.
• Security: Feasible if authentication, authorization, transport encryption, secure password storage, backups, and secure configuration are treated as mandatory controls.

Release milestones

• M-01: Planning and backlog baseline approved before Sprint 1.
• M-02: Transaction foundation demonstrated at Sprint 1 review.
• M-03: Budgeting and dashboard summary demonstrated at Sprint 2 review.
• M-04: Analytics and usability increment demonstrated at Sprint 3 review.
• M-05: Release candidate approved after Sprint 4 testing and UAT.
• M-06: Production version 1.0 deployed and transitioned to maintenance.

Planning approval gate

G-01: Sprint 1 cannot begin until the Product Owner and Sponsor approve scope, release objectives, team capacity, initial risks, and the use of Agile.

Requirements, user stories, acceptance criteria, and traceability

Functional requirements

• FR-01: The system shall allow a new user to register with name, email address, and password.
• FR-02: The system shall authenticate registered users and restrict private application features to authenticated sessions.
• FR-03: The user shall create income and expense transactions containing amount, transaction type, category, date, and optional note.
• FR-04: The user shall edit and delete transactions they own.
• FR-05: The user shall create or update one overall monthly budget and optional category-level budgets.
• FR-06: The dashboard shall show monthly income, monthly expenses, remaining balance, total budget, amount spent, and budget utilization.
• FR-07: The dashboard shall present expense totals grouped by category.
• FR-08: The dashboard shall present income and expense trends by month.
• FR-09: The user shall search and filter transactions by date range, category, and transaction type.
• FR-10: The user shall update profile settings including preferred currency.

Non-functional requirements

• NFR-01: Every request for private data shall enforce authenticated-user ownership on the server.
• NFR-02: Passwords shall be stored using an approved adaptive one-way password-hashing algorithm.
• NFR-03: Production traffic shall use HTTPS.
• NFR-04: The main dashboard should complete its server response within 2 seconds for at least 95% of requests under the defined initial expected workload.
• NFR-05: Core workflows shall work in current major desktop and mobile browsers supported by the project.
• NFR-06: Core workflows shall target WCAG 2.2 AA practices.
• NFR-07: Automated database backups shall run daily and be monitored for failure.
• NFR-08: Monetary values shall use fixed-precision decimal storage and consistent rounding rules.

User story US-03: Record a transaction

As a user, I want to record an income or expense transaction so that my financial dashboard reflects my activity.

• AC-03.1: Amount is required and must be greater than zero.
• AC-03.2: Transaction type must be Income or Expense.
• AC-03.3: Category and transaction date are required.
• AC-03.4: A successfully saved transaction appears in the authenticated user's transaction list.
• AC-03.5: Relevant dashboard totals reflect the saved transaction.

User story US-05: Manage a monthly budget

As a user, I want to define a monthly budget so that I can compare actual spending against my planned limit.

• AC-05.1: The user can define an overall budget for one month and year.
• AC-05.2: Budget must be greater than zero.
• AC-05.3: Dashboard displays budget, spent amount, remaining amount, and utilization percentage.
• AC-05.4: An exceeded budget is identified with text as well as visual styling.

Traceability matrix

OBJ-01 -> FR-03 -> US-03 -> AC-03.1..AC-03.5 -> DES-02/DES-03 -> TC-03A/TC-03B -> Sprint 1
OBJ-02 -> FR-05/FR-06 -> US-05 -> AC-05.1..AC-05.4 -> DES-05 -> TC-05A/TC-05B -> Sprint 2
OBJ-03 -> FR-07/FR-08 -> US-07/US-08 -> DES-07 -> TC-07A/TC-08A -> Sprint 3
OBJ-04 -> FR-02/NFR-01/NFR-02/NFR-03 -> SEC-01 -> TC-SEC-01..04 -> Sprints 1-4

Requirements approval

A story may enter a sprint only after its acceptance criteria are approved by the Product Owner. Security-sensitive stories also require technical review by the Lead Web Developer.

Architecture, UI, data, security, and privacy design

Design activity

Design is performed incrementally for sprint-ready stories while the project maintains a stable target architecture and data model.

System context

User Browser
    |
   HTTPS
    |
Responsive Web Application
    |
Application Services / API
    |
Authentication + Authorization + Business Rules
    |
Relational Database
    |
Backup Storage

Logical components

• DES-01 Authentication: registration, login, logout, password reset, session management, and authorization.
• DES-02 Transactions: CRUD operations, validation, categories, filtering, ownership rules, and persistence.
• DES-03 Dashboard: monthly totals, balance, category summaries, and reporting datasets.
• DES-04 Categories: supported categories, user-defined categories, and transaction-type association.
• DES-05 Budgets: monthly limits, category limits, utilization, and over-budget states.
• DES-07 Analytics UI: category distribution, income/expense trend, responsive charts, loading states, and empty states.

Data entities

• User: id, name, email, password_hash, currency, created_at, updated_at.
• Category: id, user_id or system_scope, name, transaction_type.
• Transaction: id, user_id, category_id, type, amount, transaction_date, note, created_at, updated_at.
• Budget: id, user_id, month, year, overall_limit.
• CategoryBudget: id, budget_id, category_id, amount_limit.

Data integrity rules

• Every transaction belongs to one user.
• Every user-specific query is scoped to the authenticated user's identifier.
• Amounts use fixed-precision decimal storage.
• A user may have only one overall budget for a specific month and year.
• Category deletion is blocked when dependent transactions exist unless a controlled reassignment process is implemented.

Primary UI pages

• Registration.
• Login and password reset.
• Dashboard.
• Transactions list.
• Create/Edit transaction.
• Budgets.
• Categories.
• Profile settings.

UI states

• Loading state while reporting data is requested.
• Empty state when no transactions exist.
• Validation errors associated with relevant fields.
• Over-budget and near-budget status states.
• Responsive table or compact transaction representation on small screens.

Security and privacy controls

• Server-side authorization for every private record operation.
• Server-side validation of all user input.
• Parameterized database access through the approved framework or ORM.
• Secure password hashing.
• Secure production transport using HTTPS.
• Secure session or authentication-token configuration.
• Authentication rate limiting where supported.
• Financial details and credentials excluded from routine logs.
• Only data required for the approved product functionality is collected.

Design gate

G-02: Development begins only when required user flow, UI states, data behavior, validation, security impact, and acceptance criteria are sufficiently defined for the selected story.

Sprint schedule, roles, governance, risks, and change control

Sprint schedule

• Sprint 1 — Foundation and Transactions: authentication, base navigation, categories, transaction CRUD, authorization, responsive form foundation.
• Sprint 2 — Budgets and Core Dashboard: monthly budgets, KPI summaries, balance calculations, budget utilization, transaction filters.
• Sprint 3 — Analytics and UX: category distribution, monthly trend reporting, dashboard refinement, mobile usability, accessibility improvements.
• Sprint 4 — Release Hardening: regression, security checks, performance verification, UAT, deployment rehearsal, production release.

RACI-style responsibilities

• Product Owner: Accountable for backlog priority and acceptance.
• Lead Web Developer: Accountable for architecture and technical quality.
• Web Developer: Responsible for implementation and development tests.
• QA Engineer: Responsible for independent verification and regression.
• UX/UI Designer: Responsible for user-flow and interface design.
• Project Sponsor: Accountable for final business release approval.

Risk register

• R-01 Unauthorized data access: Probability Medium, Impact Critical. Controls: ownership checks, authorization tests, code review, least-privilege access.
• R-02 Incorrect monetary calculations: Probability Medium, Impact High. Controls: decimal data types, calculation unit tests, reconciliation tests.
• R-03 Scope expansion: Probability High, Impact Medium. Controls: release boundary, backlog prioritization, formal change IDs.
• R-04 Poor mobile usability: Probability Medium, Impact Medium. Controls: responsive design criteria and testing each sprint.
• R-05 Reporting performance: Probability Medium, Impact Medium. Controls: query indexes, bounded date ranges, aggregation review, performance tests.
• R-06 User-data loss: Probability Low, Impact Critical. Controls: automated backups, restore tests, migration controls.
• R-07 Delayed stakeholder decisions: Probability Medium, Impact Medium. Controls: scheduled reviews and Product Owner decision authority.

Change control

1. Record each new request using a change identifier such as CR-01.
2. Product Owner documents business value and priority.
3. Lead Developer and QA assess technical, security, testing, schedule, and dependency impact.
4. Do not disrupt committed sprint work unless the Product Owner explicitly swaps or cancels scope.
5. Schedule accepted changes into an appropriate future sprint.
6. Update affected requirements, designs, tests, risk records, and traceability entries.

Configuration management

• All source code is maintained in version control.
• Changes require peer review before integration.
• Database migrations are version controlled.
• Release versions receive immutable release tags.
• Secrets and environment-specific credentials are excluded from source control.

Development activity and implementation plan

Development activity

Development converts sprint-ready stories and approved designs into testable increments. Implementation must remain traceable to requirement and user-story IDs.

Implementation workflow

1. Select an approved sprint story.
2. Create a version-control branch referencing the story ID.
3. Implement the required UI, business logic, data changes, and validation.
4. Add or update automated tests.
5. Perform developer-level verification.
6. Submit the change for peer review.
7. Resolve review findings.
8. Merge through the approved integration process.
9. Deploy the integrated increment to the sprint test environment.

Implementation mapping

• US-03 / FR-03: transaction form, validation, persistence, list refresh, dashboard recalculation.
• FR-04: transaction ownership validation, edit flow, delete confirmation, recalculation.
• US-05 / FR-05: monthly budget form, unique month rule, utilization calculations.
• FR-07: expense aggregation by category and chart dataset generation.
• FR-08: monthly income and expense aggregation and reporting dataset.

Coding and review controls

• Financial calculations use the approved fixed-precision approach.
• Private data is never fetched solely by record ID without user ownership validation.
• Validation is not delegated exclusively to the browser.
• Errors must not expose secrets or sensitive internal implementation details.
• Changed UI is reviewed at supported responsive breakpoints.
• New migrations must be tested against representative existing data.

Development exit criteria

• Implementation satisfies the story acceptance criteria.
• Peer code review approved.
• Automated checks pass.
• Required migrations apply successfully in the test environment.
• Feature is deployed to the sprint test environment.

Testing strategy, test cases, defect control, and evidence

Testing activity

Testing occurs during every sprint. Sprint 4 adds full release regression and UAT but does not postpone quality verification from earlier iterations.

Test levels

• Unit: calculations, validation rules, budget utilization, reporting helpers.
• Integration: authentication, persistence, authorization, database queries, reporting aggregation.
• System: complete browser-based workflows.
• Regression: previously accepted features.
• Security: ownership bypass attempts, session behavior, validation, sensitive-data exposure.
• Accessibility: keyboard navigation, labels, focus, status communication, contrast, semantic structure.
• Performance: dashboard and transaction-list behavior under expected initial workload.
• UAT: Product Owner verifies release-critical business scenarios.

TC-03A — Create valid expense

1. Authenticate as User A.
2. Open Add Transaction.
3. Enter Expense, amount 75.50, category Food, a valid date, and optional note.
4. Save.

Expected result: One transaction is created for User A and the selected month's expense total increases by 75.50.

TC-03B — Reject zero transaction amount

Input: Amount = 0.
Expected result: Save is rejected and an accessible validation error explains that the amount must be greater than zero.

TC-05A — Calculate budget utilization

Precondition: Monthly budget = 1,000.00 and qualifying expenses = 650.00.
Expected result: Dashboard displays 650.00 spent, 350.00 remaining, and 65% utilization.

TC-05B — Identify exceeded budget

Precondition: Monthly budget = 1,000.00 and expenses = 1,050.00.
Expected result: Dashboard identifies an exceeded budget with text and displays 105% utilization.

TC-SEC-01 — Prevent cross-user transaction access

Precondition: User A owns transaction T100 and User B is authenticated.
Action: User B requests T100 directly.
Expected result: Access is denied and User A's transaction data is not returned.

TC-08A — Verify monthly trend calculations

Expected result: Income and expense totals displayed for each month exactly match the underlying qualified transactions.

Defect severity

• Severity 1: data loss, security breach, or application unavailable.
• Severity 2: core financial workflow unusable or materially incorrect.
• Severity 3: significant degradation with a practical workaround.
• Severity 4: minor usability or cosmetic defect.

Testing exit criteria

• All committed acceptance criteria have corresponding verification evidence.
• No open Severity 1 or Severity 2 defects remain.
• Regression suite passes.
• Security-critical test cases pass.
• Release-critical accessibility checks pass.

Sprint review, approvals, feedback, and repeat sprint cycle

Review activity

Each sprint ends with a review of working software. The team demonstrates completed stories against their approved acceptance criteria and presents supporting QA evidence.

Review inputs

• Sprint goal.
• Completed stories.
• Acceptance-test evidence.
• Open defects.
• Updated risks.
• Change requests.
• Updated release forecast.

Story decisions

• Accepted: Acceptance criteria and Definition of Done satisfied.
• Accepted with follow-up: Story is acceptable, but a separate non-blocking improvement enters the backlog.
• Rejected: Story fails one or more required acceptance criteria and returns to the backlog.

Example sprint approval record

Sprint: 2
Goal: Deliver budgeting and core dashboard reporting
Stories: US-05, US-06, US-09
QA Status: Passed
Severity 1-2 Defects: 0
Product Owner Decision: Accepted
Change Request: CR-03 - Improve mobile budget presentation
Release Impact: None

Retrospective

The team reviews delivery process, technical friction, test effectiveness, collaboration, and defects. Improvement actions receive identifiers such as IMP-01.

Repeat Sprint activity

After review and retrospective, the Agile lifecycle repeats:

Planning → Requirements/User Stories → Design → Development → Testing → Review → Deployment

New feedback, defects, risks, technical improvements, and approved change requests are reprioritized into the backlog before the next planning activity.

Deployment, release approval, rollback, and production verification

Deployment activity

Deployment promotes an approved release candidate into the intended environment. Early sprint increments may be deployed only to staging, while Sprint 4 produces the planned production version 1.0.

Release readiness checklist

• Release scope approved.
• Required acceptance criteria pass.
• No open Severity 1 or Severity 2 defects.
• Database migrations tested.
• Production backup completed before migration.
• Production secrets and environment configuration verified.
• HTTPS verified.
• Error monitoring enabled.
• Rollback procedure reviewed.
• Release notes prepared.

Deployment procedure

1. Create the approved release version and source-control tag.
2. Verify the latest valid production backup.
3. Enable maintenance protection when required.
4. Deploy the tested application build.
5. Apply approved database migrations.
6. Run production smoke tests.
7. Review application errors, response times, and database connectivity.
8. Disable maintenance protection.
9. Record deployment result, version, approvers, and timestamp.

Production smoke tests

• Login succeeds for a valid test account.
• Dashboard loads correctly.
• A transaction can be created and retrieved.
• Budget information displays correctly.
• Authorization blocks another user's record.
• Logout invalidates the authenticated session.

Rollback triggers

• Authentication unavailable for normal users.
• Unauthorized financial-data access detected.
• Materially incorrect financial calculations introduced by the release.
• Database migration failure.
• Sustained severe application failures after deployment.

Rollback procedure

1. Stop exposure to the faulty release when necessary.
2. Restore the previous known-good application version.
3. Reverse migrations only when a tested rollback exists.
4. Restore a database backup if required by the incident assessment.
5. Run production smoke tests.
6. Record and investigate the failed release as an incident.

Release approval gate

G-03: Production release requires QA release recommendation and Product Owner approval. The Project Sponsor provides final business authorization for version 1.0.

Operations, maintenance, support, and future Agile increments

Maintenance activity

After production deployment, the application enters controlled maintenance. Corrective, adaptive, preventive, and perfective changes return to the Agile backlog and follow the same sprint lifecycle when implementation is required.

Operational monitoring

• Application availability.
• Server and application errors.
• Authentication failures and suspicious patterns.
• Database health and storage.
• Dashboard response time.
• Backup job status.

Support priorities

• P1: Security incident, confirmed data loss, or complete application outage.
• P2: Core authentication, transaction, or budget functionality unavailable.
• P3: Partial functionality degraded with workaround available.
• P4: Minor defect or enhancement request.

Maintenance categories

• Corrective: repair production defects.
• Adaptive: update dependencies, infrastructure, supported browsers, or runtime configuration.
• Perfective: improve usability, analytics, maintainability, or performance.
• Preventive: refactoring, test expansion, dependency upgrades, backup validation, and security hardening.

Backup and recovery controls

• Run automated backups daily.
• Alert on failed backup jobs.
• Perform periodic restore tests.
• Record restore ownership and procedure in the operations runbook.

Maintenance change intake

1. Record the defect, enhancement, or operational improvement.
2. Classify priority and risk.
3. Product Owner adds approved work to the backlog.
4. Security-sensitive maintenance receives technical review.
5. Selected work follows the next Agile sprint cycle.

Examples of future backlog items

• CSV transaction import.
• Recurring transactions.
• Additional reporting periods.
• Exportable monthly reports.
• Shared household budgeting, subject to separate privacy and authorization design.

Closure criteria, final handover, and lifecycle traceability

Project closure

The initial development project closes after version 1.0 is accepted and transferred to operational maintenance. Closure does not end the product lifecycle; future changes continue through new Agile sprints.

Closure criteria

• Version 1.0 production deployment completed successfully.
• Product Owner accepts the approved release scope.
• Project Sponsor confirms business objectives for the initial release are satisfied.
• No unresolved Severity 1 or Severity 2 release defects remain.
• Monitoring and alerting are operational.
• Backup and recovery procedures are documented.
• Support ownership is assigned.
• Architecture and deployment documentation are current.
• Known deferred features and defects are recorded in the backlog.
• Final release notes and handover documents are complete.

Handover package

• PED-SDLC-001 lifecycle documentation.
• Approved product backlog and release history.
• Functional and non-functional requirements.
• User stories and acceptance criteria.
• Requirements traceability matrix.
• Architecture and data-model documentation.
• Risk register and architecture decision records.
• Test cases and release evidence.
• Deployment and rollback procedures.
• Operations and support runbook.
• Known issues and future backlog.

Final traceability example

Business Objective: OBJ-02
Functional Requirements: FR-05 / FR-06
User Story: US-05
Acceptance Criteria: AC-05.1 - AC-05.4
Design Component: DES-05
Implementation Sprint: Sprint 2
Verification: TC-05A / TC-05B
Review Evidence: Sprint 2 Review
Release Version: 1.0
Maintenance Owner: Application Support

Lifecycle completion statement

The Personal Expense Dashboard follows the complete Agile activity sequence: Planning → Requirements/User Stories → Design → Development → Testing → Review → Deployment → Repeat Sprint → Maintenance. Requirements, implementation decisions, tests, approvals, releases, risks, and maintenance work remain traceable throughout the lifecycle.