project-proposal-2025

SpendSmart – Simple Expense Tracker for University Students

Abstract

It is wise to track your expenses to be aware of your own spending patterns and direct more money into what truly matters for your university life. However, the process can be confusing with the sheer number of numbers to track, and that is excluding what each of those numbers mean! Being a university student, that is a lot to track on top of your studies and other things in life. The good news is, SpendSmart is here to make expense tracking easier for all university students!

SpendSmart, a cloud-based web application, lets university students like you record your expenses quickly and conveniently, typically less than two minutes per expense. SpendSmart keeps all your expenses online, so you can check them anytime on any device, talking about convenience! That is not all though, as SpendSmart also analyses your expenses to show how you spend your money and whether you are overspending on some things, as well as giving you ideas on how to save money. So, what are you waiting for? Start using SpendSmart to spend smartly in your university life!

Author

Name: Brendan Siah

Student number: 48550495

Functionality

SpendSmart is a simple application designed for university students to track their expenses. The application aims to help students manage their spendings by allowing them to record expenses, filter and compare expenses, display general expense trends and patterns, as well as providing tips to reduce or optimise their future expenses.

The application should have the following features:

• User Account Management:

  • Users should be able to provide basic information, such as name, institution, contact information, etc.
  • Users can also set their password and personalise the application theme.

• Expense Management:

  • Users can record an expense they made.
  • Details such as title, category, description, amount, date and time are used to record an expense.
  • Expenses can be pinned to indicate their significance.
  • Users can update an expense’s details or delete an expense.

• Expense Searching and Filtering:

  • A form-based interface that displays a list of user expenses.
  • Expenses can be searched using text, number and date and time fields.
  • Users can filter their expenses by category or pin.

• Expense Statistics:

  • Users can view information about their total expenses within a date or time range in tables.
  • Options to view total expenses for one or multiple categories.
  • Colour indicators show if the expenses increased or decreased compared to before.

• Spending Tips and Recommendations:

  • Users are provided with ideas to reduce or optimise their expenses based on their spending patterns.
  • The ideas can be from a preloaded list or generated using AI analysis.

Scope

The minimum viable product (MVP) should have the following features:

• User Account Management:

  • Users can create an account with basic information, such as name, institution, email and phone number.
  • Users can also set their password.

• Expense Management:

  • Users can record an expense they made by providing title, category, description, amount, date and time.
  • Expenses can be pinned.
  • Users can update an expense’s details or delete an expense.

• Expense Searching and Filtering:

  • A form-based interface that displays a list of user expenses.
  • Expenses can be searched using text, number and date and time fields.
  • Users can filter their expenses by category or pin.

• Expense Statistics:

  • Users can view information about their total expenses within a date or time range in tables.
  • Options to view total expenses for one or multiple categories.
  • Colour indicators show if the expenses increased or decreased compared to before.

• Spending Tips and Recommendations:

  • Users are provided with ideas to reduce or optimise their expenses from a preloaded list.

Quality Attributes

Extensibility

SpendSmart must be extensible in a sense that new features can be added to the application with minimal time and disturbance to other parts of the application. As the application started out with basic functionalities, it is highly likely that new features will be requested as the userbase grows. For this reason, the application should always be ready to support additional features over its lifespan. To ensure this, the application will be developed with an interface that simplifies the inclusion of extra features.

Modularity

SpendSmart needs to be developed modularly in a way that each service works independently to deliver their functionality. As the application will have many services working together to deliver user functionalities, it is crucial to handle the failure of one or more services gracefully rather than outright crashing the entire application. To achieve this, the services of the application will be designed as components to have minimal reliance on each other for easier application maintenance and updates.

Scalability

SpendSmart must be able to handle high amounts of active requests and users, while also optimising resource usage by removing redundancy during low usage periods. The number of concurrent users may change depending on the time of the year. Therefore, the application should be designed to scale up or down to handle varying usage with optimal performance and resource usage. To realise this, horizontal scaling will be used to change the number of concurrent application instances to handle different levels of usage.

Evaluation

Extensibility

Extensibility will be determined by how the application reacts to adding new features and tools, such as displaying expense statistics as visual line, bar or pie charts. The addition of new features and tools should have none or minimal disruption to the base application architecture and performance and ideally be deployed live within an hour. Test cases will also be run after adding the new features and tools to ensure at least 90% of test cases passed.

Modularity

Modularity will be evaluated by reviewing the purpose, structure and external relationship of each component. The application logic should ideally consist of at least 85% components, and each component must have only one function. Unit tests will be performed on individual components to ensure they perform their functions correctly, aiming for a testcase passing rate of 90% or above. The relationships between components must be none or minimal to ensure loose coupling.

Scalability

Scalability will be tested by simulating application usage of 3 to 1000 concurrent users. Resource usage will be monitored to ensure the application can scale resources up or down accordingly to fluctuating user numbers. Ideally, the application must maintain a response time of less than one second and an error rate of less than 5%, especially during peak usage. Additionally, the application should maintain all the previous benchmarks with a 99% uptime.