Requirements:

Gathering Requirements

The requirements were gathered during the regular weekly meetings that are held with the customer. The weekly interrogative sessions helped us come up with a finalised set of requirements. The frequent communication among team members through Trello and Whatsapp also made collecting the requirements more efficient. The requirements of the Money control app include,

1. Homescreen: The homescreen should contain the 5 most recent transactions, the total balance and a button to add expense or income
2. Add new expenses and history: Add expenses should have the following fields Amount(Only number), date, category, payment method and notes(optional). Show expenses should have a filter to view particular transactions.
3. Add new income and history: Similar to how expenses works
4. Visual stats: Based on the categories or split ups, the overall expense as well as expenses per category must be illustrated with a pie chart
5. Settings: A settings button is required in order to either add or alter a category based on user requirement and also to change pin if pin option is activated

Analysing Requirements

Our team iteratively updated the requirements based on three categories

1. Basic Requirements

2. Essential Requirements

3. Nice-to-have Requirements.

With these classifications and communication among team members, the requirements were easily structured.

Mapping requirements to user stories

Requirement specification was carried out by adhering to the specifications given by the customer and the classifications created by us. With the customer requirements and effective ordering of these requirements in the respective classification, we as a team were able to come up with a design of the entire app.

We divided the basic requirements into five main epics. Each epic would handle one basic requirement. From there we started distributing each essential requirement into corresponding epics as individual user stories. Since we already had the layout of the application in mind, we were able to formulate structured user stories covering all the requirements.

Use case diagram was created based on the functionality of the entire app and thereby establishing the relationship between the user(actor) and the respective tasks to be performed for using the app.

Wrong Assumptions

• We mistook user stories and sprint planning to be the same. Upon clarification, we understood the differences.

• We thought that the app was a multi-user app. But later, during the meeting with the customer we understood that the app is a single-user app

• We thought of authenticating the user through PIN/Pattern system but we are planning to add it as part of settings tab. Totally upto the user’s preference.

• Exit option is not required for these kind of apps so had to remove it.

• Only Show expense was initially planned for display, but a summary of total balance and expense has to be displayed in a gist in “Summary” tab.

User Stories

Development Strategy

We first worked together to create the navigation layout. Once the layout was ready we assigned each story to a task in the trello app. Everyone in our group plays the developer role at some point. So we distributed the epic and user stories accordingly to each such that one work can be completed simultaneously as each of them would be working in a different tab of the application. We use different modes of communication and direct meeting to make sure task are completed on time.

User case diagrams

Use Case diagrams draw a relationship between the user and the tasks he has to perform. So in short, a use case diagram describes a particular functionality of the Android application.

The below use case diagrams summarizes two main functionalities of the app.

1. Add new transaction

2. See history of transaction

The above use case diagram depicts the user would first have to choose whether it is a income or expense fragment while entering a new transaction. Then the user needs to fill the necessary data such as Amount, Date, Category, Mode of payment, Recurrence setting and Notes(Optional) manually. The user has an option to add new category/mode of payment.

The above use case diagram depicts the user would again first have to choose whether it is a income or expense fragment while selecting to show history of transactions based on some filter. The user would need the option to select one particular transaction and delete/update it if required.

Activity diagram

1. Add new transaction

1. See history of transaction

Class diagram

MainActivity MainActivity class of the application

mDrawerLayout is the attribute for the navigational layout

SummaryFragment A class for summary tab calculating balance, total income and expense AddFragment A class for adding a new transaction

AddFragment A class for adding a new transaction

ShowFragment A class for showing history of transactions

SettingFragment A class for ssettings option

VisualFragment A class filtering and visualizing data

DatabaseFHelper Database helper class for connecting with SQLlite database

Amount stores the amount as integer datatype

Date stores the date as integer datatype

Category stores the category as text datatype

Account stores the mode of payment as integer datatype

Recurrence stores the recrurrence as text datatype

Notes stores the notes as text datatype

Application downloadable link

Try our basic prototype by downloading the apk file by clicking this link

ScreenShots of the application

1. Add new transaction, Amount(Only numbers), Date(Calender)

1. See history of transactions, Update/Delete after selecting a transaction

1. Others - (Summary tab, Visual tab)