Agile Modeling and Prototyping for Expenditure Tracking Application

This project report details the design and implementation of an expenditure tracking application aimed at helping users manage their finances and develop better spending habits. The report begins with an introduction and problem statement, highlighting the need for expenditure tracking tools. It outlines the project's scope, objectives, and methodology, which employs an agile approach. The project encompasses requirements gathering and analysis, design, implementation, testing, deployment, and maintenance phases. The report includes a feasibility study, functional and operational requirements, use case modeling, and object-oriented analysis using UML diagrams. It also describes the system design, resources required, and project schedule. The application aims to provide users with interfaces to declare income, add expenditures, and gain insights into their spending patterns, including features like income tracking, expenditure recording, graphical overviews, and financial tips. The project's success hinges on its ability to help users adapt to better spending habits and save money, providing a comprehensive overview of the application's development lifecycle.

8/20/2017
Agile Modelling and Prototyping
Expenditure Tracking Application
Student Name
StudentID

Contents
Table of figures............................................................................................................................................2
1 Introduction..............................................................................................................................................4
2 problem statement...................................................................................................................................4
3 Scope of the project.................................................................................................................................4
3.1 Project objectives..............................................................................................................................4
3.2 Goals of the project...........................................................................................................................5
3.3 Project methodology.........................................................................................................................5
3.3.1 Requirements gathering and analysis.........................................................................................5
3.3.2 Design.........................................................................................................................................6
3.3.3 Implementation..........................................................................................................................6
3.3.4 Testing........................................................................................................................................6
3.3.5 Deployment................................................................................................................................7
3.3.6 Maintenance...............................................................................................................................8
3.4 Resources required............................................................................................................................8
3.5 Budget...............................................................................................................................................8
3.6 schedule............................................................................................................................................8
4 Feasibility study and report......................................................................................................................9
4 Functional requirements..........................................................................................................................9
4.1 Functional process requirements......................................................................................................9
4.2 Data requirements...........................................................................................................................11
4.2.1 Entity relationship diagram.......................................................................................................11
4.2.2 Entity definitions.......................................................................................................................12
4.2.3 Data dictionary.........................................................................................................................12
4.2 Operational requirements...............................................................................................................12
4.2.1 Security.....................................................................................................................................13
4.2.2 Data currency...........................................................................................................................13
4.2.3 Reliability..................................................................................................................................13
4.2.4 System availability....................................................................................................................13
4.2.3 Performance.............................................................................................................................13
5 Use case modelling.................................................................................................................................13
5.1 use case description........................................................................................................................14

UC-1...................................................................................................................................................14
Uc-2...................................................................................................................................................15
Uc-3...................................................................................................................................................16
Uc-4...................................................................................................................................................16
Uc-5...................................................................................................................................................17
Uc-6...................................................................................................................................................18
Uc-7...................................................................................................................................................18
6 Object-oriented analysis using UML.......................................................................................................19
6.1 Overview..........................................................................................................................................19
6.2 Types of UML diagrams...................................................................................................................19
7 System design.........................................................................................................................................23
8 conclusion...............................................................................................................................................23
9 References..............................................................................................................................................23
Table of figures
Figure 1: Agile testing and continuous integration......................................................................................7
Figure 2: Gantt chart....................................................................................................................................9
Figure 3: Data flow diagram......................................................................................................................10
Figure 4: Entity relationship diagram.........................................................................................................12
Figure 5: Use case diagram........................................................................................................................14
Figure 6: class diagram..............................................................................................................................19
Figure 7: sequence diagram......................................................................................................................20

1 Introduction
This document discusses the design and implementation of a spending application which will help its
users to track usages of their incomes to facilitate better spending habits and money saving habits. The
document discusses the problem statement as well as presenting a feasibility study report to show and
justify whether the project is feasible or not. The document also shows different models of the system
which can be used to give both a conceptual and in depth view of the proposed application and at the
final stages it discusses the possible design for the proposed application including the factors to consider
while designing the application.
2 problem statement
In the current times, many people do not keep track of their expenditures and income. This can be
attributed to the fact that income is not as often as expenditures thus many people get an income for
example every month but the expenditures that go in between the month from the day the person is
paid until the time they get the next income are very many. Expenditures happen almost every moment
of our life ranging from the smallest expenditures that require very little money to big expenditures that
require a large amount of money. Due to lack of a tracking tool which people can use to track their
expenditures people end up not knowing where their income is going except for the big projects which
are easy to remember. When a person is not tracking their expenditures, it’s very hard for that person to
save money and they end up using more money than they should use as a result of impulse buying and
adapting spendthrift behaviors. An expenditure tracking application can help people who have a
problem with spending money get an insight on where most of their money is going thus help them to
adapt better spending behaviors and in the long run help the users to save some of their income.
3 Scope of the project
3.1 Project objectives
The following will be the objectives of the project;
 Provide users with an interface when they can declare their source of incomes and what each
source is generating within a given timeframe. This sources of income will automatically add the
declared amount of income after every timeframe is reached.
 Provide users with an interface where they can add unofficial sources of income; for example
money earned by the user and was not planned for.
 Provide users with an interface where they can add expenditures in a very easy way as
expenditures are very frequent.
 Provide the users with an overview of how he or she is using their money. This can be a graph
showing income against expenditure.
 Give users tips on how to save their money.
 Study user spending habits then use this data to predict if the user is overspending money thus
generate a notification warning the user thus that they are going over their normal spending
rates in a given timeframe. For example if a user spends approximately
 Show reports to the user of where most of the money is going to thus giving them a chart
showing which activities are using up more money and which activities are using the least
money.

3.2 Goals of the project
The project is designed to help the user manage their income by providing a tool through which the
users can declare their sources of income and record every expenditure in order to track the
expenditure of the user. The application will help the user get an overview of how they are using their
money. After a few months of using the application, the application should be able to learn how the user
spends money by analyzing their spending patterns so as to provide recommendations when the user is
using up more money than they should.
3.3 Project methodology
Project methodology is the approach that will be used to implement the project. For this project Agile
approach will be used. Agile approach is a methodology where the application is developed in
increments and delivered to the users in increments. The project will have the following stages. These
stages can be thought of as the stages of the life cycle of the project.
 Requirements gathering and analysis
 Design
 Implementation
 Testing
 Deployment
 Maintenance
3.3.1 Requirements gathering and analysis
Requirements gathering and analysis is the process of gathering requirements through use of various
methods of research like observation and interviews and then doing an analysis on the requirements to
come up with the project specifications (Kossiakoff and Sweet, 2003)). Requirements gathering can be
divided into;
 Requirements engineering- this is the collection of requirements. This stage includes of research
to come up with user stories. An example of a user story for this project could be as follows;
 As a user of the application I want to be able to record all my sources of income
 As user of the application I want to be able to record all my expenditures easily
 As user of the app I would like to be able to see where my money is going by seeing
which activities are using which amount of money. This can be done by use of a chart to
show each activity against the money used within a given timeframe.
 As a user I want to be able to get notifications if am using more money that I usually use
in a given timeframe as a tip to help me rethink my spending habits
 As user of the application I want to be able to get tips when am using the application to
help me with my expenditures and my savings.
 Requirements analysis- This is process of analyzing the data collected either from user stories or
observation or even other methods of doing research to come up with a specification
documents. The specifications document is then used to in the design stage of the application.

3.3.2 Design
The design stage of the project uses the specifications document gotten from the fist stage of the
project life cycle. The specifications document guides the team of developers to come up with a design
based on the specifications derived from user requirements
3.3.3 Implementation
This stage can also be called the coding stage. This is the stage where the actual implementation of the
application is done. Coding means provide a backend functionality to all the designs achieved in the
design stage of the project life cycle.
For this project the implementation method to be used is scrum. Scrum is a methodology of
development where the program is divided into smaller programs and the smaller programs sub divided
into smaller parts called sprints. Each sprint is supposed to take a certain amount of time to develop. A
sprints are given to members of the team where by each member can “scrum” for the sprint which they
are comfortable with and are they are sure they will be able to handle. For scrum to work, the team of
developers have to ensure a high degree of communication. The communication should not only be high
but very effective to make sure the sprints are implemented properly where by different sprints need to
communicate with each other. For example a team member can be assigned a method which
communicates with another method assigned to another team member. Because the two methods are
communicating the two developers have to ensure communication for the two methods to be
developed successfully.
3.3.4 Testing
The testing stage is used to test the implemented increments delivered as increments. Testing is done to
make sure the increment performs according to its requirements before it’s released (Pittet, 2015).
Testing in agile methodology involves testing every increment before it’s delivered. The following
diagram shows the testing process in agile methodology where continuous integration is the key for
agile development.
Figure 1: Agile testing and continuous integration

The types of testing done are;
 Unit testing
 Integration testing
 System testing
 Regression testing
 Performance testing
 Usability testing
 Acceptance testing
3.3.4.1 Unit testing
Unit testing involves testing every unit before it is integrated with other units to form a component. In
agile using scrum approach, the unit can be the sprints allocated to every team member which have to
be tested before integration is done.
3.3.4.2 Integration testing
Integration testing is testing on the integration of units to make sure the units have been integrated
successfully without any error. For example integration testing between two methods communicating
between themselves can involve testing the parameters to determine of the data passed matches with
the type of parameters.
3.3.4.3 System testing
System testing involves testing the whole system for bugs. Testing is done on all components to make
sure that they have been integrated properly to from the whole system.
3.3.4.4 Regression testing
Regression testing involves running the system through tests to identify bugs. Regression testing is
testing the system to fail so that the bugs can be identified before the system is deployed. Regression
testing can be simulated with actual user data to see if the system will pass all the tests.
3.3.4.5 Usability testing
Usability testing is testing done to see whether the system is usable to the end users. Usability testing
can use real users who will be using the application as subjects who will be using the application as a
beta.
3.3.4.6 Usability testing
Acceptance testing involves testing to see whether the application is acceptable by the end users. This
type of testing can be done by releasing a beta version of the application and asking for users using the
application to provide feedback about their views of the application.
3.3.5 Deployment
Deployment of the system is the release of the application to be used by end users. The proposed
application will be an Android so it can be deployed by publishing it on the play store where users can
download and install the application. The application can also be posted on a website designed
specifically for the application where users can download the application from the website.

3.3.6 Maintenance
After the application is deployed, maintenance is done on the ready deployed application. Maintenance
can involve releasing updates and patches of the application and also releasing consequent builds which
have no bugs. The bugs can be identified by users while using the application thus the team of
developers has to remove the bug and release a new update of the application.
3.4 Resources required
The resources required to undertake the project are physical resources that are going to be used to
undertake the project. The resources range from labor and the physical resources like computers that
will be used to do the implementation. The labor required should have the technical knowhow of what
is required to undertake the project. For this project the design will have to be very good thus a team
member who has skills of material design. The backend of the project will be done using Java thus the
project requires more than one team member competent in java who will be in charge of the backend
development. The project also requires a testing specialist who will be able to conduct all types of test.
One of the team members will have to be delegated the role of quality assurance to ensure everything
that is done is done to perfection.
3.5 Budget
The budget of the system is the estimated amount of money that will be used. The money includes the
money for acquiring the resources that will be used during the development and the labor cost. For the
proposed application the estimated budget is $5000.
3.6 schedule
The schedule of the project is the total amount of time that will be used and how it will be allocated
(Makar, 2016). The following is the schedule for the proposed week.
Event Estimated time Deliverable
Requirement gathering and
analysis
1 month Requirements analysis
document and software
specifications document.
Design 1 months A design of the system
Implementation 5 months Fully working system
Testing 1 month Test document
Deployment 1 week Fully working application
Maintenance Onwards Updates and patches

Gantt chart
Figure 2: Gantt chart
4 Feasibility study and report
Feasibility study is the process of investigating whether the project is viable to be undertaken or not.
Feasibility study involves doing a cost/benefit analysis to determine whether the benefits of the system
weigh more than the cost of the system (MacDonough, 2013). This in other hand means analyzing to
determine whether the cost of the project is worth the benefits of the project. There are different types
of feasibility studies done for this project;
 Technical feasibility- this type of feasibility study is aimed at establishing whether the company
has the technical capability to undertake the project. This includes investigating whether the
company has the technology necessary to undertake the project. For the expenditure tacking
application technical feasibility analysis shows that the company has the technical capability to
undertake the project.
 Schedule feasibility- this type of feasibility aims at establishing whether the company has
enough time and resources to undertake the project. For the proposed application, schedule
was not a problem since the application was not a contract by a customer.
 Economic feasibility- Economic feasibility focuses on cost/benefit analysis where by an analysis
of the benefit s of the system are done to see whether the benefits of the system are worth the
cost. The benefit for the proposed application is the return on investment.
4 Functional requirements
Functional requirements describe the core functionality of the proposed application. There are two
types of functional requirements;
 Functional process requirements
 Data requirements
4.1 Functional process requirements
Functional process requirements describe what the project is intended to do especially for the end user
(Constantinides, 2014). The following are the functional requirements of the proposed expenditure
tracking application.
Functional
requirement ID
Requirement description
1 Register

2 Login
3 Enter sources constant sources of income
4 Add expenditures
5 View income vs expenditure report and get a conceptual view through a graph
6 Enter other sources of income
7 Get notifications on expenditure usage if expenditure exceeds the limit
8 Get tips on expenditures
The following diagram shows the data flow diagram better illustrating the functional requirements of
the system.
Figure 3: Data flow diagram

4.2 Data requirements
Data requirements describe the data the proposed application will deal with by showing how the data
will be stored by showing tables and the structure of the database (Bahil and Dean, 1997). The database
will be a relational diagram where by objects with different attributes are related to each other.
4.2.1 Entity relationship diagram