Personal Finance Manager Introduction (Part One)



This tutorial will demonstrate how to develop a java based application for managing your personal finances. It will illustrate how to employ a number of common technologies that are used within industry and are fast becoming defacto standards.

The technologies demonstrated within this tutorial are: -

  • Maven
  • Automated Testing (JUnit)
  • Automated Reporting
  • Hibernate, Spring
  • JQuery, Ajax, Web 2

Once completed the reader will have a fully functioning database driven web application.

Product Statement

The importance of having a product statement cannot be over stated. By writing down what you are expecting as a finished product helps you to keep focussed on the job at hand and can be used as a contract with yourself and your expectations. Especially important if you are supplying a third party. If you are working as part of a team then the product statement should be visible to everyone on the team. This way everyone is aligned as to what it is you are going to produce.

Personal Finance Manager is a software product for managing personal finances. It will allow the user to enter bank accounts and transactions, provide categories and reports to show the status of the managed personal finances.
Quite a simple product statement and of few words. Of all the steps you will take to develop any product for yourself or a customer you must keep the statement simple and to the point. You should read back any statement over and over and ensure it is agreed with by your customer so that there is no doubt about what the deliverable is. Getting this step wrong would be a catastrophy so make sure its correct!


There are a number of methodologies for collecting requirements but you will find that requirements fall into two main categories.

Functional Requirements

These will be collected from the stakeholder and will be the goals of the product and the Use Cases usually known as the Business Requirements. Think of these as the behaviour of the product and its scope, or the Features of the product. It is best to write down each functional requirement as it is identified, in the Agile/Scrum world these are called the User Stories.

Non Functional Requirements

These are about how the system will operate such as performance, or how simple the system can be adapted for new features, it includes technical specification requirements, such as specifying access to the product via the Web (web application).

Requirements Engineering is a subject matter all of its own and is out of scope for the purposes of this tutorial, if you would like to find more about this topic you may refer to the following list of resources.

  • Alexander, Ian and Beus-Dukic, Ljerka. Discovering Requirements: How to Specify Products and Services. John Wiley, 2009.
  • Goldsmith, Robin F. Discovering Real Business Requirements for Software Project Success. Artech House, 2004.
  • Miller, Roxanne E. The Quest for Software Requirements. Mavin Mark Books, 2009. Sommerville, Ian and Sawyer, Pete. Requirements Engineering: A Good Practice Guide. John Wiley, 1997.
For the purpose of this project the requirements will be collected at each iteration of the product and worked on in turn.


It is important to agree with your stakeholders the timelines of your new product, when you will be delivering the first version, and to set milestones to measure your progress. This is important even if you are developing something for yourself and there is no third party involved.

This project will use short interations with weekly timelines to develop each major feature, in the Agile/Scrum world these are called sprints. The next section discusses the Agile/Scrum methodology.

Agile Development

Agile software development is not new, an article in the Harvard Business Review called 'The New New Product Development Game" (Takeuchi & Nonaka 1986) describes how Honda, Canon and Fuji-Xerox produced world-class results using what are now concepts being employed in an Agile methodology called 'Scrum'.

So what is Agile & Scrum? Well in essence it is to tackle the problem in a systematic common sense way and nothing else. To get as early as possible a working version of what you are going to develop. Show the customer and then go around and around adding features, testing and showing the customer each new feature to see that you understand more clearly his requirements. Essentially an iterative approach that evolves into the finished product.

So how is this different to other methodologies? Well for instance in the Waterfall approach the process is very structured and sequential and runs in this order.


It's not difficult to see why its called waterfall, it is my experience that for software projects this approach just does not work. I have worked in organisations where it is used and projects always seemed to run over budget and burn money needlessly, rarely were the stakeholders happy with the outcome, which was only seen at the end of the project.

So how does Agile/Scrum differ? Take a look at this diagram..
Can you see what is happening here? The process is iterative and consists of short development cycles with a potentially shippable product at each stage. The product is evolving into what the stakeholders expect. After each iteration a product is created with an agreed amount of features/requirements being included and ready for the stakeholder to test. Any disagreements or misunderstandings are found early and can be rectified during the next cycle. Pretty simple but very effective!

Next we will create a product backlog of work that will be assigned to Sprints representing the requirements for our Personal Finance Manager Product, henceforth refered to by the acronym 'PFM'.

Part Two

Date Entered2014-06-08