# Project Proposal
## Title
Budget Planner
## Group
21SS_ASE PR_QSE_01
+
## Team members

| Name | Matr. Nr. | Email | Role |
|------------------|-----------|--------------------------------|---------------------|
| Hahnenkamp Klaus | 11775823 | [e-mail] | Frontend manager |
| Sefranek Marek | 11779683 | [e-mail] | Security manager |
| Maier Florian | 01527095 | [e-mail] | Team coordinator |
| Sowula Robert | 11708475 | [e-mail] | CI/build manager |
| Ndou Enrik | 01426910 | [e-mail] | Technical architect |
| Oppel Philipp | 01427026 | [e-mail] | Test manager |

## Project description

Our idea for the project is to create a personal budget web app. Its main features and ideas are outlined in this section.

- In which domain does your project take place?
- Private sector
- Which problems/challenges are solved with it?
1. The main problem solved is the one of exactly knowing about one's budget and having an overview on how much one is still able to spend within the month. This is especially important for people living on a tight budget.
2. Another problem solved is the one of splitting expenses within a group of friends and making paying back as easy and straightforward as possible.
3. A big challenge for potential users we want to overcome is privacy concerns when it comes to budgeting and finance apps. Therefore we will implement an option for the user to have relevant data processed by a zero-knowledge server.
4. Another challenge we are trying to overcome is the lack of motivation to save. Therefore one of our features will be a possibility to compare oneself with other users and compete for who can save the most.
- Which improvements are expected by your project?
- In comparison to existing budgeting and finance applications we want to combine all the best and most relevant features into one, together with a reliable and trustworthy security concept. The user should have their budget, shared budgets, forecasts and social statistics at once.
- Will your product be integrated in an existing system?
- No
- Will your product replace an existing product?
- No
- Features
1. Save and track your personal spendings and profits.
2. Zero-knowledge server: The user shall be able to save their spendings in such a way that the server can't read them. The user shall have a key or password that can locally decrypt the data saved on the backend. This feature will disable a part of, or completely the features 9, 10, and 11.
3. The webpage should be responsive where some tabs that show basic information can be displayed in a mobile phone version.
4. It shall offer the possibility to create a hierarchy of categories. Each category node has only one main parent, but it may have more secondary parent nodes.
5. The categories may be split into yearly, monthly, or daily spendings. (e.g. food is daily, rents and subscriptions are monthly, buying a new laptop or organizing a long vacation, may be calculated as yearly based). Optionally there may be categories which are suited for even longer timespans, e.g. buying a house.
6. For the daily spendings the system shall create a coefficient that shows average spendings for the month. The coefficient can be easily compared with the previous months.
7. Forecasting: The UI shall display some forecasting about the future considering the current and previous spendings.
8. Split budget: The user may open a short-term account, i.e. for a defined period where the spendings are shared within a group. Each member may add new articles in the shared budget and the amount of money paid. The feature may be used in vacations where they can see any time the group spends. The creator of the budget must have an account however it shouldn't be mandatory for the others to have a split-account. They may get a temporary one that is related only to this short-term account. The members who have an account will have a reference of this spending in their personal budget.
- Optional features
1. When listing the (monthly) spendings the UI shall display previous (monthly) data, depending on how large the current spendings are. If they are low then a comparison to the lowest month is displayed in a positive color, e.g. green. If they are higher than they are compared to an average sum and if they are larger than they are compared to the most expensive month displayed in a red color. This feature can be easily hidden and it shall take relatively little space.
2. Comparison with others: Given the profits and spending the user shall see a comparison of their savings with others in %. For example, whether they are in the top 10% of the other unknown users or not.
3. Statistics: The user shall be able to see some visualization for the current spendings (e.g. by categories, time periods, etc).
4. When the user buys something but has no time to save it and adds it to the right category then the app offers the possibility to photograph the bill. The UI shall show a notification until the user organizes the new bill.
- Domain model


- Architecture
- Which type of system will be created?
The application will be a web-based system (consisting of frontend/backend) with emphasis on responsive design for mobile usage.
- Which technologies will be used?
Frontend: Vue.js (2nd version), HTML5, CSS3
Backend: Java, Spring
DBS: PostgreSQL

## Already existing and similar products

- Do any similar products exist?
Yes, similar products do exist. A popular self-hosted example that is kind of similar to our idea is [firefly](https://demo.firefly-iii.org/) – an open-source project with nice web-overview and some different charts to represent statistics. There is also a [list on github](https://github.com/awesome-selfhosted/awesome-selfhosted#money-budgeting-and-management) for open-source self-hosted projects to manage personal budgeting and money in general.
Also most of the current banking user interfaces have some sort of budget overview and money management (e.g. George by Erste, N26, Raiffeisen, ...) inside the mobile app as well as on the website. Another similar product would be the vast amount of different finance-planning apps on the mobile app stores. There are too many to mention them all, but [here](https://financer.com/de/finanztipps/haushaltsbuch-app/) is a list of 10 famous ones in Europe. For the US there are also many different ones, but they cannot be used in Europe because they have to be connected to a bank account and they only support American banks ([here](https://www.nerdwallet.com/article/finance/best-budget-apps)).
- What are the reasons for the redevelopment in comparison to using the existing product?
Although there are many solutions out there, our approach is to combine the best features of different apps into one, especially the bill splitting ability. Also there is a huge focus on the security aspect, as mentioned earlier we will implement homomorphic encryption for client-server communication. Another reason for redevelopment is the usability. Our application will be intuitive to use and we attach particular importance to simple data entry.

## Stakeholders

- User
- The user's main focus will be on using the application in their web client. The user will rely on the developers that stored data is secured and all calculations are meaningful and correct.
- Developer
- The developers' responsibility will be to deliver correct and secure code on time. They must be able to rely on the product owner for supplying them with user stories they can implement.
- Product owner
- The product owner's responsibility is to supply the developers with use cases and guidance. Furthermore the whole project must be overseen and potential risks be identified. They must be able to rely on the developers for delivering the product on time and must provide all possible guidance to ease and support the development process.
- Server operator
- The server operator runs the servers our website is hosted on. They are responsible for assuring the servers' stability, uptime, performance, and security. Alternatively, our website can be hosted locally.

## Legal Environment

As our project is security focused we chose to open-source our code to establish trust.
The source-code will be licensed under either MIT or AGPL.
As we are unsure in what context we will continue the development of this project, we will finalize the license decision at the end of the project.

## Cost estimation (working hours)

Our general goal is to achieve an average workload of 150 hours per team member. However, should any of the essential features take longer than expected, or should there be any other unexpected events in the development process, we can extend this workload to up to 200 hours per team member.

- Tentative cost estimation:
- 72h jour fixes (=6 * 12 * 1h)
- 180h team meetings (=6 * 15 * 2h)
- 54h management reviews + preparation (=6 * [3 * 1h + 3 * 2h])
- 9h project proposal (=6 * 1.5h)
- 30h project contract (=6 * 5h)
- 60h learning new technologies (=6 * 10h)
- 480h implementation (including QA + testing) (=6 * 80h)
- 15h documentation (=6 * 2.5h)
- 900h total (=6 * 150h)

## Risks

In general, our website operates on highly sensitive user data, so assuring best possible security is essential for our project's success and one of our main goals. This includes rigorous analysis and usage of best-practice security solutions such as HTTPS, option for 2-factor authentication, hashing passwords, etc. The following lists the major potential risks that might occur during our project:
1. Successfully implementing homomorphic encryption might pose a challenge. For this reason, we have already looked into available libraries (our current choice is Microsoft SEAL) and how to integrate them into our project's architecture. This is also the reason why our website's full-privacy mode is optional and fully independent of the normal mode of operation (without homomorphic encryption), allowing us to mitigate potential conflicting dependencies during the development process.
2. Another risk with homomorphic encryption is its performance, which according to Microsoft SEAL's library documentation should be acceptable. However, the actual overhead of homomorphic encryption in our use case can only be determined once implemented in practice. This is why we intend to benchmark the performance of our application and fine-tune the respective security parameters of the underlying homomorphic encryption scheme to achieve the optimal configuration.
3. A team member could drop out of the project due to unexpected events such as illness or private reasons. In this case, we would have to redistribute the tasks that person was responsible for among the remaining team members and potentially cut some non-essential features.
4. Wasting resources on non-essential features could lead to not meeting the deadline (aka "over-engineering"). A solution to this, is to precisely define the scope of each feature while also categorizing features into different priority categories (such as must-have, should-have and nice-to-have/optional). Also, we will include a time buffer for unexpected work load in our project plan.
5. The necessary libraries could turn out to be unavailable or non-free. This can be ruled out by checking the availability and license of needed libraries already during writing the project contract. As such, we have already done our research on libraries for homomorphic encryption (Microsoft SEAL).
6. To solve potential differences in opinion within the team when it comes to choices during the project, we always decide collectively and try to find a mutual agreement. Should there be any dissent we discuss the issue, weighing up the pros and cons. Should this still not lead to an agreement, we resort to voting on the issue.