SOEN490 Capstone Software Engineering Design Project: Budget Lens
Budget Lens
2. Project description and requirements
After a terse two years since the beginning of the COVID-19 pandemic, it is inevitable that inadvertent disruptions have been introduced to the way many businesses operate. Consequently, supply-chain and logistics have been impacted, which have subsequently worsened inflation [1]. One of the accruing costs of businesses is the cost of manufacturing receipts; retailers in the United produces over 4 billion pounds of CO2 and 302 million pounds of solid waste every year [2].
Moreover, these oftenly foot-long papers that are left pressed onto the corners of shopping bags are also costing us our health. They are not only receipts, but they are thermal papers laced with a chemical called bisphenol A - more commonly abbreviated as BPA. BPA has been proven to transfer from thermal paper to the skin [3].
Additionally, physical receipts tend to fall victim to negligence and human error. Over 37% of customers reportedly throw away or lose paper receipts, and they have counted an average of at least 5 times a month where they lost or threw out a receipt that they intended to keep [5]. Those away over time. This, commensurate with technological advances being enforced in everyday life, surfaced the awareness to shift to digital receipts.
That being said, physical receipts are very far from being obsolete. While some places offer digital corporations, are still the main method of transaction documentation. As consumers, we are left scouring for our receipts, which are both physically and digitally obtained. Therefore, another problem arises - budgeting with this duality.
Therefore, we birthed Budget Lens to tackle the aforementioned problems, with our long-term goal focused on eradicating the use of thermal physical papers entirely - and conserving this explosive physical receipts into one medium, and assist with budgeting by allowing
Requirements
A. Users - making a space for a user to store their data into.
1. Create user accounts for consumers.
2. Users can add other users of the app as their friend and friend requests can get
accepted/rejected.
3. Invite friends to join the app.
B. Importing physical receipts into the app - transforming users’ physical receipts into digital ones to combat human error and health risks, and improve portability and accessibility.
- Scan/upload the picture of a physical receipt as input from the user.
- View/store the physical receipt digitally in the user’s account.
- Each item on the receipt is categorized in the user’s account. Therefore, similar items on
- Supports receipts in English.
- Reads common receipts printed at retail stores in Montreal.
C. Manually inputting receipts into the app - to uplift the morales’ of users to not miss an expense and maintain consistency with their budgeting, users can manually enter the receipt if they don’t have a copy for whatever reason.
D. Migrating digital receipts into the app - importing digital receipts into the app to standardize referring to receipts in one medium.
10. Users can forward their electronic receipts from their email to store in the app. E. All receipts - improving searchability and categorization of receipts.
- Search receipts by date, time, and location.
- Stores receipts and its items on the app for an infinite duration of time, until deleted by the user.
F. Splitting expenses - for those who share expenses with others, users can share the expenses with others who have the app or can precisely register how much they spent from the bill for their own budgeting.
- The user can directly share expenses or split a receipt. This can be with a friend on the app or individually to accurately denote how much the user spent from the total amount on the receipt.
- The user can also split a receipt without needing to have the other person on the app. The user simply specifies how much they paid from the bill, and that exact amount will be reflected onto his budget with the corresponding receipt items.
G. Item categorization - helping users categorize their spending to simplify budgeting.
- Flag receipts for any potential important date, such as return date or end of warranty date for each receipt item.
- Send notifications to the user when the flagged date nears. The default reminder is 14 days prior, but can be customized to user preference.
- The app can learn and remember from those inputs and apply it in the future when a user submits a similar receipt item.
- (Maybe) Send reminders when the app thinks there is a refill needed for an item.
H. Budgeting - calculating spending patterns to provide to users as data that reflects their consumer behavior.
- Based on the user’s spending behavior, the app estimates how much (in terms of $) the user will spend in the coming week/month - forecasted budget.
- Displays to the user when they are going over/under their forecasted budget/desired budget.
- Users can set financial goals - for example, paying off debt/buying a house - and the app can forecast a budget with their spending behavior that is most ideal to achieving their goal.
3. Tools and Technology
Technology/To ol | Justification | |
Development Platform | PyCharm, Android Studio, VS Code | PyCharm was used as the main code editor for the SOEN 390 project and it was fairly easy to use with great integration solutions when used with the Django framework. VS Code can also be used for Django development based on user preference. It has an extensive plugin library allowing it to be on par with PyCharm for backend development. Android Studio will be used to develop the mobile application. It is based on IntelliJ IDEA, but focuses more on Android development. All of us have had experience with IntelliJ, so there should not be a massive learning curve for Android Studio. |
Programming Language | Django, Kotlin | ● Front-End through University. Kotlin uses the JVM and is interoperate with Java. The learning curve is very minimal and is the best option to develop an Android application. ● Back-End framework. Most of us have experience using Django for creating web apps in previous projects. One big feature we wanted was ORM as it gives the ability to write queries to reduce development time and cost. Python is also an easy language to pick up for those with less experience. |
Agile Project management | Asana | Asana allows for an easy way to create user stories and track bugs. Most of us have used Asana during our job internships. It is easy to learn and integrates well with Github. |
Source code management | Github | We’ve all used Github in all our projects throughout our University degree and are very familiar with how it works. |
Unit testing | Django (unittest library), JUnit | Django uses a Python library, unittest, to unit test code easily. Android Studio has JUnit to test unit tests locally on the project. |
System testing | Github Actions, Django REST Framework API Test | Github Actions can be used to run these unit tests when code is pushed to Github to ensure they all pass. Django has a rest framework with built in test case classes to test any REST API routes. |
Database | PostgreSQL, Android Room | ● PostgreSQL large amounts of potential data and is highly scalable. Combined with Django ORM, it does not require heavy sql syntax to write code making it easier on people who are not familiar with it. ● Android Room which will function as a cache layer allowing the application to view data even while offline. |
UI prototyping | Figma | Figma was used during SOEN 357, so some team members are familiar with how it functions which is an advantage. If some team members do not remember or are completely new to how it works, the learning curve is very small. |
Code quality/ Linter | Pylint-django, Android Studio Github Actions | Django has a library called pylint-django which is a static analyzer for code to ensure a code standard. We’ve all used linters built into our IDEs, but these ones described will ensure a universal code standard throughout the project using Github Actions. |
4. Preliminary risk analysis
- Limits risk: Merchants may resist and block usage of this app and its implementation in certain scenarios since it is not in their best monetary interest to give up the sole control of their side of the bargain. Furthermore, we have to communicate with the merchants on time when the usage is blocked, and see what they can solve on their side.
- Data Hijacking: There is a possibility of ill-intentioned actors/hackers trying to penetrate our infrastructure and hijack our users’ data. In this case, we must make sure all the sections of our app are end-to-end encrypted so that in the rare case of such an attack, the customers’ data aren’t at risk.
- Technology Risk: The precision of the result from the scanner might be hard to control due to the different clarity of the receipts. While implementing the scanner, we have to fold cross validation method as an optimizer to help the app itself learn how to distinguish and read the receipts with acceptable accuracy.
- Communication Risk: As we have eleven members in total in this project development, it will be a challenge to ensure that we have a regular meeting time every week. Failure to communicate effectively and promptly may result in lost data or incorrect information,
- Device Risk: Outmoded devices may face software compatibility issues in contrast to recent models. Consequently, this may affect the accuracy of the scanner in recognizing the minimum standard of the devices’ versions to ensure the clarity of the receipts’ pictures. By doing so, we could make sure the accuracy of the result is not being affected.
Risk | Probability of Loss | Size of Loss (weeks) | Risk Exposure (weeks) |
access limits | 30% | 6 | 8 |
data hijacking | 80% | 12 | 15 |
technical difficulties | 25% | 5 | 12 |
communication risks | 25% | 6 | 8 |
device risks | 25% | 4 | 5 |
5. Competitive solutions
Search terms: Receipt Scanner, Expense Manager Total competitors examined: 6
Splitwise
Pros:
● Organized expense sharing
● Easy and quick addition of expenses
● Focus on individual use rather than business use
Cons:
● Presence of ads in the core features
● Paywall: must pay to scan receipts, remove ads, have access to expense history charts and graphs, etc.
● Lack of budget planning and expense forecasting in both the core and paid features
Fetch
Pros:
● Easy and good receipt scanning feature for both paper and electronic receipts
● Unified ecosystem for the implementation of retail/culinary monetary value/rewards
Cons:
● Only available in the US
● Only supports two languages: English and Spanish
EcoReceipt
Pros:
● Easy and good digital receipt sharing
● Focus on individual use rather than business use
● Digital receipt scanning through QR codes
Cons:
● Only useful when dealing with merchants with digital receipts
● Lack of paper receipt sharing and scanning which is the problem at the root/center of this app
● Lack of accurate AI budget forecasting
6. Product Owner and Stakeholder
Product Owner
The product owner of this application is Amir Sadeghi since he was the one who proposed this idea to the team in the first place. He has invested these last 5 years in building and evolving this idea to this point. According to him, he has done numerous case studies and networking sessions with other industry professionals to give life to this idea. He is a software developer with 8 years of experience in the industry and is currently working as a software developer at GoTo (formerly LogMeIn) on various products, including voice and meeting experiences.
Stakeholder
The stakeholder of this project is Michael Madan. Michael Madan is currently the Central Technology Director of Square Enix Montreal. He has over 20 years experience in software development. In his career, he has experienced different roles in the production of software applications such as developer, software development consultant, analyst, architect, and development manager. Therefore, he has a full-scale understanding from different perspectives of the whole software development process working in teams which is a useful skill to be able to translate to a group of our size.
