*It may be worth noting that for weeks, we had no data or even rough idea of the shape of the data, so we had to deviate slightly from the MoSCoW list, and thus implements other features we could whilst we waited for data. (Prototype 1)
| ID | Requirements | Priority | State | Contributor |
|---|---|---|---|---|
| 1 | Data Visualisation | Must | Lib Kai | |
| 2 | Framework for interaction between database and front-end | Must | Raghib | |
| 3 | Budgeting Function (Setting Caps) | Must | Raghib, Lib Kai | |
| 4 | Financial Overview Display | Must | Raghib, Yuheng | |
| 5 | Connect and Select Multiple Bank Accounts | Must | Raghib, Yuheng | |
| 6 | NoSQL database, hosted on Azure which stores customer banking data | Must | Yuheng | |
| 7 | Readable Number formatting for tables and graphs | Must | Lib Kai | |
| 8 | Readable Date formatting | Must | Lib Kai | |
| 9 | Data processing for individual user and re-upload to NoSQL database | Should | Yuheng | |
| 10 | Create login, register and forgot password functionality - Rudimentary login system not for security but to show off ability for different users to connect their own bank account IDs |
Should | Raghib | |
| 11 | "Help" feature on the web app to help with user queries - implemented a form which sends an email | Should | Raghib | |
| 12 | Add a "Profile" page for the user so they can store their email, upload an image, etc. | Should | Raghib | |
| 13 | Categorical Spending | Should | Raghib | |
| 14 | Bill reminders | Should | Yuheng, Lib Kai | |
| 15 | Ability to predict user going into overdraft | Should | Yuheng | |
| 16 | Add credit card info and calculate the amount a user should pay for each card | Should | Yuheng | |
| 17 | Functionality to allow user to view transactions between certain date ranges | Should | Raghib | |
| 18 | Pagination and search function for tables | Should | Raghib, Lib Kai | |
| 19 | HyperCube Data Structuring | Could | - | |
| 20 | Report Generation | Could | - | |
| 21 | Algorithm to analyse of spending patterns and/or fraudulent payment | Could | Partially Completed | Raghib, Yuheng |
| 22 | Sophisticated Natural Language Processing which looks at more than keywords and categorises data more deeply | Could | Not in Use |
Raghib |
| 23 | Creation of saving pots | Could | - | |
| 24 | Creation of Dummy data (JSON format) | Could | Yuheng, Lib Kai | |
| 25 | Deployment of Django webapp (Apache) | Could | Raghib, Yuheng | |
| 26 | Set up a domain for deployed webapp and enable HTTPS only using SSL Certificate | Could | Raghib | |
| Key Functionalities (Must have and Should have) | 100% Completed | |||
| Optional Functionalities (Could have) | 60% Completed | |||
| ID | Bug Description | Priority |
|---|---|---|
| 1 | The help page sends an email to our admin gmail on localhost. However, it causes an error on the domain uclproject.co.uk | High |
| 2 | Data safety and privacy | Medium |
| 3 | App does not require bank account authentication. This needs to be changed if we are using real data. | Medium |
| Work Packages | Raghib | Yuheng | Lib Kai |
|---|---|---|---|
| Client Liaison | 33% | 37% | 30% |
| Requirement Analysis | 32% | 30% | 38% |
| Research | 35% | 30% | 35% |
| UI Design | 50% | 10% | 40% |
| Front-end Coding | 35% | 10% | 55% |
| Programming | 65% | 30% | 5% |
| Testing | 40% | 50% | 10% |
| Bi-weekly Report | 30% | 40% | 30% |
| Website Editing | 15% | 35% | 50% |
| Poster Making | 5% | 5% | 90% |
| Video Editing | 40% | 55% | 5% |
| Overall Contribution | 36% | 32% | 32% |
| Roles | Back-end Developer (Framework) | Back-end Developer (Database) | Front-end Developer |
| ID | Criteria | Score | Description |
|---|---|---|---|
| 1 | User Interface / User Experience | 10/10 |
Using Bootstrap and Chart.js, we've made our UI very clean and pleasant to the eye.
The UI for the website is also very easy to user since our target audience ranges from teens to the elderly. Therefore creating a simple yet useful application is one of our main objectives for this project. |
| 2 | Functionality | 9/10 |
The wep app provides various functions for our users, e.g. having their own profile,
having a help page, setting caps, view all or categorical transactions, current
account or credit-card transactions and many more. This provides the users with
various possibilities on what they would like to know regarding their financial
information.
If given more time, more functionalities such as report generation, saving pots etc could be implemented. |
| 3 | Stability | 8/10 | The web app is stable in general. Overall the functionalities and UI of the web app
works fine. The web app has undergone multiple stress test as we try to find flaws
to our web app. However, it is worth noting that there could be errors not found
during the development phase and the web app is still prone to error. But so far
everything works as intended.
One main concern is the reliability of the Azure servers, if Azure services are down this would mean that our virtual machine as well as the MarkLogic database hosted on Azure would be down, which means we would not be able to use our web app. But after thorough consideration, Azure is usually a very reliable service so our web app would probably be very stable. |
| 4 | Efficiency | 8/10 | Since we re-upload each account data back to our MarkLogic database, instead of
retrieving a large JSON file filled with accounts we only retrieve accounts relevant
to the user, this in turn reduces the time taken to retrieve the data and overall
the responses are very fast. MarkLogic also contributes to the efficiency of our web
app since MarkLogic has exceptional performance even at industrial scales, therefore
overall our web app is very efficient.
Though initially, the web app would be less efficient when new accounts are connected, this is because our web app would then have to filter through a large dataset, retrieving the relevant account data and create a new JSON file which is re-uploaded back to the database. |
| 5 | Compatibility | 9/10 | Since we're using Bootstrap, this allows for responsive design, allowing the user to use our web app on multiple devices. Bootstrap elements are also compatible with most browsers so our web app is fairly compatible on different devices and browsers. |
| 6 | Maintainability | 7/10 |
Throughout our project duration, we have run out of credits relatively early. The
costs of hosting a MarkLogic database could now be considered quite expensive, even
though we chose the cheapest option, we still ran out of credits, therefore
maintaining the use of our web app could become very costly.
In terms of our web app, it is generally very easy to maintain. The Python code in utils.py (Where all the data processing happens) is well commented and easy to understand, while our front-end is quite self explanatory. |
| 7 | Project Management | 9/10 | Generally, we were able to work alongside each other very well. We kept each other
up to date and generated a Gantt Chart to continuously monitor our progress.
Alongside the Gantt Chart we were also doing the bi-weekly report to not only update
our clients on our progress but to also have a written document on what we've done
and what we plan to do. We would also have frequent meetings to update each other on our individual progress and discuss our plans moving forward. We would each work in sprints to complete the projects to adapt to our companys' Agile development method. Other than frequent meetings, we would keep each other up to date on our progress through WhatsApp and discuss obstacles faced and come up with possible solutions or alternatives. We scheduled bi-weekly meetings with our clients to update progress and also make sure that we were on the right track. Emails were also sent to our clients to seek guidance and possible alternatives for the requirements that were set for us if we were unable to meet said requirements. We have also split up our tasks and assigned them to each respective teammate. This gives each teammate their own respective roles and tasks to work on, therefore improving efficiency. At the start of the project up to January, we were trying to find sample Open Banking datasets online but we couldn't find any. We emailed our clients asking for datasets to be provided to us, to which they contacted their Italian team to possibly provide us with such data but due to P&C issues we were unable to obtain data from our client. Knowing this we immediately started to research Open Banking data formats and start generating our own set of dummy data to use in place of actual Open Banking dataset. We could've researched the format for Open Banking data earlier on and generate a sample dataset ourselves but we were hoping to obtain a proper set of data to work with. Since we had no data we deviated from our initial “Open banking data analytics” project to building a web app to display our data analysis in the future. We’ve developed use cases with our clients to stay on track and complete our assigned task. |
We definitely hope to gain access to real data. Real data reflects users' spending pattern and contains more valuable
information. They are also great test cases that could help further test our app.
A large amount of data is also essential to other important algorithms in our project. These includes:
Machine Learning for categorisation requires a large amount of data for higher accuracy.
The forecasting tool Prophet also works better with a larger time series which have strong seasonal effects and several seasons of historical data.
Therefore our dataset generated does not meet these requirements.
Currently, our app does not ask financial institutions for authentication regarding user accounts. This is bad for a FinTech web app. Authentication is essential and is
usually sent through Open Banking API to various different banks. So if we have access to Open Banking API, we could definitely obtain authentication for extra security.
Blockchain is another area we could look into. It also improves security regarding financial data and thus protect users' privacy and sensitive information.