By: Team W17-3 Since: Aug 2019 Licence: MIT

1. Introduction

OwlMoney is a command-line based desktop application written in Java 11. It is written in an Object-Oriented Programming (OOP) fashion which provides multiple layers of abstraction for ease of customisability and modularity for future improvements and revisions. Interested in contributing to the OwlMoney project? This guide provides information that will not only help you get started as an OwlMoney contributor, but you’ll find useful to refer to even if you are already an experienced contributor.

2. Setting up

The sub-sections below introduces the prerequisites and steps required to get you started quickly so that you can start developing on this project quickly!

2.1. Prerequisites

  1. JDK 11

    Only JDK 11 is officially supported

  2. IntelliJ IDE

    IntelliJ by default has Gradle plugins installed.
    Do not disable it. If you have disabled Gradle, go to File > Settings > Plugins to re-enable it.

2.2. Setting up the project on your computer

  1. Fork this repo, and clone the fork to your computer

  2. Open IntelliJ (if you are not in the welcome screen, click File > Close Project to close the existing project dialog first)

  3. Set up the correct JDK version for Gradle

    1. Click Configure > Project Defaults > Project Structure

    2. Click New…​ and find the directory of the JDK

  4. Click Import Project

  5. Locate the build.gradle file and select it. Click OK

  6. Click Open as Project

  7. Click OK to accept the default settings

  8. Open a console and run the command gradlew processResources (Mac/Linux: ./gradlew processResources). It should finish with the BUILD SUCCESSFUL message.
    This will generate all the resources required by the application and tests.

2.3. Verifying the setup

  1. Run owlmoney.Main and try a few commands

  2. Run the tests to ensure they all pass.

2.4. Configurations to do before writing code

Before you get down and dirty and start writing code, the configurations below can ease your burden and fix common syntax and styling issues! Configure them and you will notice the benefits in the long run!

2.4.1. Configuring the coding style

This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,

  1. Go to File > Settings…​ (Windows/Linux), or IntelliJ IDEA > Preferences…​ (macOS)

  2. Select Editor > Code Style > Java

  3. Click on the Imports tab to set the order

    • For Class count to use import with '*' and Names count to use static import with '*': Set to 999 to prevent IntelliJ from contracting the import statements

    • For Import Layout: The order is import static all other imports, import java.*, import javafx.*, import org.*, import com.*, import all other imports. Add a <blank line> between each import

Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.

2.4.2. Updating documentation to match your fork

After forking the repo, the documentation will still have the OwlMoney branding.

If you plan to develop this fork as a separate product, you should do the following:

  1. Configure the site-wide documentation settings in build.gradle, such as the site-name, to suit your own project.

  2. Replace the URL in the attribute repoURL in DeveloperGuide.adoc and UserGuide.adoc with the URL of your fork.

2.4.3. Setting up CI

Set up Travis to perform Continuous Integration (CI) for your fork. See UsingTravis.adoc to learn how to set it up.

After setting up Travis, you can optionally set up coverage reporting for your team fork (see UsingCoveralls.adoc).

Coverage reporting could be useful for a team repository that hosts the final version but it is not that useful for your personal fork.

Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).

Having both Travis and AppVeyor ensures your App works on both Unix-based platforms and Windows-based platforms (Travis is Unix-based and AppVeyor is Windows-based)

2.4.4. Getting started with coding

When you are ready to start coding,

  1. Get some sense of the overall design by reading Section 3.1, “Architecture”.

3. Design

The following section explains the design of OwlMoney.

It is described in a top-down approach to start you off with a broader view of the entire application before going into the specific implementations of the individual features.

3.1. Architecture

Architecture
Figure 1. Architecture Diagram

The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.

The .pptx files used to create diagrams in this document can be found in the diagrams folder. To update a diagram, modify the diagram in the .pptx file, select the objects of the diagram, and choose Save as picture.

Main has only one class called Main. It is responsible for,

  • At app launch: Initializes the components in the correct sequence, and connect them up with each other.

  • At shut down: Shuts down the components and invokes the cleanup methods where necessary.

Commons represents a collection of classes used by multiple other components. The following class plays an important role at the architecture level:

  • LogsCenter : Used by many classes to write log messages to OwlMoney’s log file.

The rest of the App consists of four components.

  • UI: The UI of the App.

  • Logic: The command executor.

  • Model: Holds the data of the App in-memory.

  • Storage: Reads data from, and writes data to, the hard disk.

3.2. UI Component

UiComponent
Figure 2. Ui Component Diagram

The Ui is responsible for printing output in a user-friendly manner and prints out changes made to Model by Logic.

3.3. Logic Component

HighLevelLogic
Figure 3. High-Level Logic Diagram

  • The logic package consists of the parser, command and regex packages.

  • The parser package contains classes that are responsible for parsing user commands.

  • The parser classes will make use of the RegexUtil stored in the regex package to verify the correctness of user input and will return a Command object back to Main upon determining the validity of the input which is explained in Figure 4.

3.3.1. Parser

HighLevelLogicParser
Figure 4. General Parser Class Diagram

  • The Logic.parser package consists of Parser, ParseCommand, ParseType, ParseRawData and the abstract Parser classes that more specific parsers will inherit from.

  • The Parser class provides general methods that more specific parser classes will require.

  • The ParseCommand class parses the action from the user input (e.g. /add, /delete, /edit), before passing the user input to the ParseType class for further parsing.

  • The ParseType class will continue to parse the type of user input (e.g. /card, /bank), before passing the user input to a more specific Parser class (e.g. ParseAddCard under the abstract class ParseCard which is not shown here) for further sophisticated parsing.

  • The specific parser classes will then call ParseRawData to extract required parameters based on the Command and Type that was determined earlier in ParseCommand and ParseType previously.

  • The specific parser class will also check the correctness of the extracted parameters by using RegexUtil stored in the regex package which is also part of the logic package as shown in Figure 3. After which, the parser class will proceed to create an instance of the appropriate command class and return it back to Main.

3.3.2. Command

LogicCommandBankPackage
Figure 5. Bank Command Class Diagram

The logic.command.bank package consists of Savings and Investment classes which inherits from the Command class.

Both the Savings and Investments classes have the following common features:

  • Add

  • Edit

  • Delete

  • List

Main will call the specific Savings or Investment command class that will construct the required parameters before calling the Profile class in Model to execute.

LogicCommandBondPackage
Figure 6. Bond Command Class Diagram

The logic.command.bond package consists of Bond classes with the following features:

  • Add

  • Edit

  • Delete

  • List

Main will call the specific Bond command class that will construct the required parameters before calling the Profile class in Model to execute.

LogicCommandCardPackage
Figure 7. Card Command Class Diagram

The logic.command.card package consists of Card classes with the following features:

  • Add

  • Edit

  • Delete

  • List

Main will call the specific Card command class that will construct the required parameters before calling the Profile class in Model to execute.

LogicCommandGoalsPackage
Figure 8. Goals Command Class Diagram

The logic.command.goals package consist of Goals classes with the following features:

  • Add

  • Edit

  • Delete

  • List

Main will call the specific Goal command class that will construct the required parameters before calling the Profile class in Model to execute.

LogicCommandFindPackage
Figure 9. Find Command Class Diagram

The logic.command.find package consist of Find classes with the ability to find any:

  • Bank accounts

  • Cards

  • Bonds

  • Card transactions

  • Bank transactions

  • Recurring Expenditures

Main will call the specific Find command class that will construct the required parameters before calling the Profile class in Model to execute.

LogicCommandTransferPackage
Figure 10. Transfer Command Class Diagram

The Transfer Package under logic.command.transfer consists of the TransferCommand class which inherits from Command.

Main will call the TransferCommand class that will construct the required parameters before calling the Profile class in Model to execute.

3.4. Model Component

ModelComponent
Figure 11. Model Component Diagram

The Model contains multiple packages that are responsible for specifying the structures and constraints of the core functionalities of OwlMoney as well as the storing of data of the application in memory.

In general, the Model contains the following packages:

  • bank → responsible for the savings and investment accounts.

  • bond → responsible for the investment bonds.

  • card → responsible for the credit cards.

  • goals → responsible for financial goals.

  • profile → responsible for the user profile.

  • transaction → responsible for expenditures and deposits which are classified under the umbrella term Transaction.

To execute any command, Main will invoke profile.Profile to execute commands. Profile has access to each individual ArrayList such as CardList, BankList, GoalList that stores objects of cards, bank accounts and financial goals respectively. Both Card and Bank objects each contain a TransactionList which holds records of transactions. If the Card or the Bank objects are deleted, its corresponding TransactionList that contains the records of transactions will be deleted along with it given that it has a composite relationship with TransactionList.

Notice a layer of abstraction on the individual ArrayList that stores objects such as bank, bond, card, etc. The purpose of this extra layer of abstraction is to hide unwanted default ArrayList methods from developers and to provide more extensive checks such as wrapping around when the ArrayList is full which the default methods are unable to do.

3.5. Storage Component

The Storage component:

  • can save user data in .csv format and read it back.

OwlMoney uses OpenCSV during both importing and exporting data when acting on .csv files.

This allows users to see and modify saved data easily, with the use of clearly defined columns.

3.6. Common Classes

Classes used by multiple components are stored in the commons package. For example, the logging feature of OwlMoney has its logging features centralised in owlmoney.commons.

4. Implementation

The following section describes the specific implementation of each feature and how data flows across various objects and methods to obtain a successful execution.

4.1. Parsing Commands in General

GeneralParsingSequenceDiagram
Figure 12. Sequence Diagram of Parsing Commands
The sequence diagram presented above is assumed to be a valid command which will generate in a successful result.

The above sequence diagram depicts the general sequence of parsing user input for all commands in general, before going into the specific Parser classes in ParseTypeMenu.

Depending on the type of command the user enters, the specific parser class invoked will be different (e.g. ParseAddBond, ParseDeleteInvestment) which will return a Command object back to main to prepare for execution.

The execution of commands will be elaborated in subsequent diagrams below.

4.2. Adding Savings

The /add /savings feature aims to provide the user with the ability to add a new savings account into OwlMoney. With this feature, the user will be able to start tracking their expenses. Hence, allowing the user to track their monthly budget and save up effectively.

4.2.1. Current Implementation

The current implementation of adding a savings account requires 2 parameters; amount and income. The ability to track the savings account is enhanced through monitoring the amount, while also being able to update it through any income the user has. Hence, the user will be able to control their spending effectively.

AddSavingCommand
Figure 13. Sequence Diagram of Adding Savings
The sequence diagram presented above is assumed to be a valid command which will generate in a successful result.

The above sequence diagram depicts the interaction between the Logic and Model component for running AddSavingsCommand.

The AddSavingsCommand requires 3 inputs:

  1. Savings Account’s name

  2. Amount

  3. Income

When the user executes the AddSavingsCommand, the following steps are taken by the application:

  1. When AddSavingsCommand is executed, it creates a new savings object using the 3 inputs.

  2. After creating the savings object, the AddSavingsCommand will invoke the method profileAddNewBank.

  3. Within the invocation of profileAddNewBank, a method bankListAddBank will be invoked to add the new savings object to an Arraylist containing all bank objects.

  4. Once bankListAddBank is invoked, it will perform the following checks:

    • Check if the bank name specified is unique among all bank accounts in the bank list through the method bankAccountExists.

bankListAddBank will throw an error if the above check fails.

  1. After passing the above checks, bankListAddBank will add the new savings object to the Arraylist which contains all bank objects.

  2. Once the savings object has been added, the details of the new savings object will be displayed to inform the user of the successful addition of the savings object.

4.2.2. Design consideration

This section describes the various design considerations taken when implementing the /add /savings feature.

Aspect: Choice of whether to set the account name as case-sensitive or case-insensitive

Approach Pros Cons

1. Case-insensitive name

  • All banks added have unique names.

  • More intuitive for users as they usually remember the names, and not the capitalisation of each letter.

  • More checks need to be done by trimming and comparing the capitalised newly added bank name to existing bank names

  • Unable to have similar bank names only differing by capitalising letters

2. Case-sensitive name

  • More accurate names

  • Allows for multiple similar name banks (eg. POSB, Posb, POsb)

  • Confusing when there are multiple banks with similar names,

After weighing the pros and cons, approach 1 was taken.

By designing the name to be case-insensitive, it increases the user-friendliness of OwlMoney since bank names are commonly remembered without the exact capitalisation of letters. Also, in the event the user keys in a different capitalised character for the same bank, there is no need for the user to re-enter the command due to the bank account "not existing". Additionally, the case-sensitivity check can also be used with the Card function or with any other case-insensitive model or logic.

4.3. Editing Bonds

The /edit /bonds feature aims to help users update the specific details of the investment bonds that they purchase. This is to enable them to not go through the trouble of deleting and re-adding the bond if they enter the details wrongly by mistake.

4.3.1. Current Implementation

The current implementation of editing bonds only allows for the edition of rate and year where the year parameter can only be changed to a higher integer than the original year currently stored. The reason behind only allowing these 2 parameters to be changed was because we wanted consistency across all records of crediting interest throughout the lifespan of the investment bond.

editBondCommand
Figure 14. Sequence Diagram of Editing Bonds
The sequence diagram presented above is assumed to be a valid command which will produce a successful result.

The sequence diagram presented above depicts the interaction between the Logic and Model component for running EditBondCommand.

The EditBondCommand requires a minimum of 3 and up to a maximum of 4 inputs:

  1. Investment Account’s name

  2. Bond’s name

  3. At least 1 of the 2 inputs:

    1. Rate

    2. Year of maturity

When the user executes the EditBondCommand, the following steps are taken by the application:

  1. When EditBondCommand is executed, it will invoke profileEditBond.

  2. Within the invocation of profileEditBond, a method named bankListEditBond will be invoked.

  3. Once invoked, bankListEditBond will perform the following checks based on the bank name specified:

    • Check for the existence of the investment account containing the bond.

bankListEditBond will throw an error if the above check fails.

  1. After passing the above checks, the method investmentEditBond will be invoked.

  2. Within investmentEditBond, the method named editBond will be invoked.

  3. Once invoked, editBond will perform the following checks:

    • Check for the existence of the bond within the investment account.

    • Check whether the newly specified year of maturity for the bond is more than or equal to the current year of maturity through the method editBondYear.

editBond will throw an error if the above check fails.

  1. After passing all of the above checks, editBond will update the bond details with the new details specified using:

    • editBondRate → edits bond’s interest or coupon rate.

    • editBondYear → edits year of maturity.

  2. Once the bond object has been edited, the updated details of that bond object will be displayed to inform the user of the successful editing of the bond.

4.3.2. Design Considerations

This section describes the various design considerations taken when implementing the /edit /bonds feature.

Aspect: Choice of whether to allow editing of the bond to tie to which investment account as well as its name

Approach Pros Cons

1. Allowing changing of the investment bank account that the bond ties to.

  • More room for customisability from the user’s perspective.

  • Difficult to implement, have to take care of issues such as whether there is enough space to store bonds in the other bank account.

  • All transaction records have to be migrated over to the other bank account and might cause issues such as transaction records not appearing in order.

2. Allowing the changing of bond’s name.

  • Allows the user to change the name of the bond if the user entered it wrongly the first time.

  • If interest has already been credited, it is not feasible to change the names of past records as it might confuse the end-user. This becomes more apparent when the names clash with the name of another investment bond which had expired prior to making this edit. This might confuse users as they might think that they earned much more interest from the same bond.

3. Disallowing the changing of both parameters.

  • Easier to implement in terms of code.

  • Users are less likely to get confused after editing records to become conflicting.

  • Less flexibility for the user.

After weighing the pros and cons, approach 3 was taken.

Firstly, doing so would reduce the coupling and dependencies between transactions and investment banks. Although it may seem restrictive to limit the type and number of parameters that can be changed, it is beneficial both to you, the developer and the user, when developing and using the program. Developing the alternative ideas mentioned would result in a high risk of logic and coding errors, leaving room for bugs to be exploited.

4.4. Deleting Credit Card

The /delete /card feature aims to help users remove credit cards that they no longer wish to store in their profile. This could be because the credit card has expired and they no longer wish to keep track of it.

4.4.1. Current Implementation

The current implementation of deleting card allows users to remove a credit card from their profile by entering the credit card name. Because we allow entering of card name that is case and trailing whitespace insensitive, users do not need to worry about typing the exact card name. Although each credit card has it’s own Universal Unique Identifier (UUID), it is not exposed to the users because UUID is a string of 32 alphanumeric characters and it will be very unintuitive for them to enter it into the command.

DeleteCardCommand
Figure 15. Sequence Diagram for deleting of credit card
The sequence diagram presented above is assumed to be a valid command which will produce a successful result.

The above sequence diagram depicts the interaction between the Logic and Model component for running DeleteCardCommand.

The DeleteCardCommand requires 1 input:

  • Credit Card’s name.

When the user executes the DeleteCardCommand, the following steps are taken by the application:

  1. When DeleteCardCommand is executed, it will invoke profileDeleteCard.

  2. Within the invocation of profileDeleteCard, a method named cardListDeleteCard will be invoked.

  3. Once invoked, cardListDeleteCard will perform the following checks:

    • Check the Arraylist containing all card objects is not empty through the method cardListCheckListEmpty .

    • Check for the existence of the card with the specified name.

cardListDeleteCard will throw an error if any of the above checks fail.

  1. After passing the above checks, cardListDeleteCard will delete the card with the specified name from the Arraylist.

  2. Once the card object has been deleted, the details of the deleted card object will be displayed to inform the user of the successful deletion of the card object.

4.4.2. Design Considerations

This section describes the various design considerations taken when implementing the /delete /card feature.

Aspect: Choice of using which parameters for the deletion of credit cards

Approach Pros Cons

1. Allowing the deletion of credit cards by specifying the card name (case and trailing whitespace insensitive).

  • More intuitive because users typically remember their cards by its name.

  • Users do not need to worry about remembering the exact card name because it is case insensitive.

  • Harder to implement because additional functions are required for the trimming of spaces from card names and also converting it to a common case for comparison.

  • Users cannot have multiple cards with the same name but different cases (e.g. VISA, Visa, ViSa).

2. Allowing the deletion of credit cards by specifying the exact card name (case and trailing whitespace sensitive).

  • It allows for multiple cards to have the same name with different cases (e.g. VISA, Visa, ViSa).

  • Users may forget their exact card name because it is difficult to remember multiple variations of the same names with different cases.

  • Users will be more prone to deleting a wrong card because cards with the same name but different cases may look alike.

3. Allowing the deletion of credit cards by specifying the card’s order number.

  • Easiest to implement because we can directly remove the card from the array list using its index number.

  • Unintuitive for the user because they have to remember the card’s order number. If they forget the order number, they will have to list the credit cards to find out its order number.

4. Allowing the deletion of credit cards by specifying the card’s UUID.

  • Easy to implement because we do not have to worry about case sensitiveness.

  • Unintuitive for the user because they will be unable to remember a random 32 character alphanumeric string.

After careful consideration and weighing of pros and cons, we decided to use approach 1.

Although approach 1 is the hardest to implement, it is the most intuitive for users because they do not need to memorise unnecessary order numbers, random 32 characters alphanumeric string, or the exact name. In addition, we have decided for cards to have case insensitive names, so that users cannot add cards with the same name but different cases. Therefore, since card names are case insensitive, it makes sense for users to expect case insensitive names in the command.

4.5. Finding of Savings Account

The /find /savings feature aims to provide the user with the ability to search for a savings account that matches the keyword specified by the user. This enables the user to have great flexibility to view their savings account details without the need of memorising each of their savings account names within OwlMoney. By allowing the user to search for a specific savings account, it also aids in the operation of editing or deleting of savings account.

4.5.1. Current Implementation

The current implementation of finding savings account only allows the user to search through the name of the account. The reason to only allows the user to search through the account name was that searching through parameters such as income may be inaccurate, as a user’s income may change over time resulting in inconsistency in the search.

FindSequenceDiagram
Figure 16. Sequence Diagram of finding savings account
The sequence diagram presented above is assumed to be a valid command which will produce a successful result.

The sequence diagram presented above depicts the interaction between the Logic, Model and Ui component for running FindBankOrCardCommand.

The FindBankOrCardCommand requires 2 inputs:

  • The name of the account that acts as a keyword for the search.

  • Type of object to be searched (e.g. card, savings or investment)

When the user executes the FindBankOrCardCommand to search for a savings account, the following steps are taken by the application:

  1. When the FindBankOrCardCommand is executed, it will invoke findBankOrCard.

  2. Once invoked, findBankOrCard will perform the following checks:

    • Check the type of object to be searched is either card, savings or investment.

  1. After passing the above checks, findBankOrCard will invoke findBankAccount.

  2. Within the invocation of findBankAccount, it will perform the following checks:

    • Check for matching account name with the keyword among all accounts stored in the ArrayList.

    • Check whether the account that matches the keyword is indeed a savings account.

findBankAccount will throw an error if all bank accounts within the application fail the above checks.

  1. Once the search has been completed, the details of all matching savings account will be displayed to inform the user of the successful matches.

4.5.2. Design Considerations

This section describes the various design considerations taken when implementing the find feature (e.g. /find /savings or /find /banktransaction).

Aspect: Choice of whether the keyword (E.g. ACCOUNT_NAME, DESCRIPTION or CATEGORY) to be searched should be case-sensitive or case-insensitive

Approach Pros Cons

1. Searching of objects based on the keyword is case-sensitive.

  • By restricting the search to be case-sensitive, it provides the user with a more accurate searched result.

  • By having a case-sensitive search, it will cause the /find command to be inflexible. As the user will need to provide the exact capitalisation within the keyword to be able to find the object he/she is searching for.

  • For example, if the description of a transaction record that the user is searching for is "Lunch at KFC". The user will not be able to find the transaction record if he/she provides the keyword as "lunch". This is because of the capitalisation of the first letter within the keyword is "l" and it is different from the transaction record’s description.

2. Searching of objects based on the keyword is case-insensitive.

  • By allowing the search to be case-insensitive, it provides the user with greater flexibility when searching for matching objects.

  • For example, if the description of a transaction record that the user is searching for is "Lunch at KFC". The user will be able to find the transaction record if he/she provides the keyword as "lunch". This is because the capitalisation of the keyword does not matter.

After weighing the pros and cons, approach 2 was taken.

The reason for choosing approach 2 over approach 1 is mainly due to the flexibility that it can provide to a user. Although, searching for the object with case insensitivity might cause more unwanted results being displayed. We felt that the ability to easily match keyword with the object that the user would like to find is more important, as it enhanced the user-friendliness of OwlMoney.

4.6. Adding Goals

The /add /goals feature allows users to add in any financial goals they have in mind to achieve for their future plans. This also aims to encourage users who have yet to have savings to start saving and track their goals.

4.6.1. Current Implementation

The current implementation of adding goals allows users to either manually track their goals or track via an existing saving account. Also, the /amount parameter that users specify should be the total amount they wish to have in their savings account. The reason for providing these two options to users is that we consider that some users may prefer to do manual tracking while others would prefer tracking them using an existing savings account.

AddGoalsCommand
Figure 17. Sequence Diagram of Adding Goals
The sequence diagram presented above is assumed to be a valid command which will produce a successful result.

The sequence diagram presented above depicts the interaction between the Logic and Model component for running AddGoalsCommand.

The AddGoalsCommand requires a minimum of 3 and up to a maximum of 4 inputs:

  1. Goal name

  2. Intended amount to save

  3. Date they wish to achieve the goal by

  4. OPTIONAL input:

    1. Savings Account Name

When the user executes the AddGoalsCommand, the following steps are taken by the application:

  1. When AddGoalsCommand is executed, a new goal object is created with the provided inputs.

  2. After creation of the goal object is created, the AddGoalsCommand will invoke the method profileAddGoals.

  3. Within the invocation of profileAddGoals, a method named addToGoals will be invoked to add the new goal object to an ArrayList containing all goals objects.

  4. Once invoked, addToGoals will perform the following checks:

    • Checks if goal name specified is unique among all goals in the existing list through the method of goalsExist

    • If a savings account was specified, it will check for if the amount of money in the account is lesser than the goals amount specified

    • Checks for the size of goals list through the method of CheckNumGoals

AddGoalsCommand will throw an error if the above check fails.

  1. After passing the above checks,addToGoals will add the new goals object into the existing list containing all goals objects.

  2. Once the goal object has been added, the details of the new goal object will be displayed to inform the user of the successful addition of the goal object.

4.6.2. Design Considerations

This section describes the various design considerations taken when implementing the /add /goals feature.

Aspect: Choice of whether to allow tying of savings account to a goals

Approach Pros Cons

1. Allowing the option of tying of savings account

  • Provides flexibility to users

  • Able to track goals status and progress, know how much more to save

  • Difficult to implement, have to consider several possibilities: what happens to the goals when e.g. if savings account was deleted, if users are allowed to tie and untie savings account, un-tracked goals status would be always false

  • Increases coupling and dependency of savings account

2. Disallow tying of savings account

  • Easier to implement in terms of code

  • Lesser considerations during the implementation of /edit /goals

  • Less flexibility for the users

  • The feature and importance of goals would be less evident

Approach 1 was taken after serious consideration and weighing out the pros and cons.

Firstly, the original intention of goals feature is to model real-life implementation of having goals, encourages users to save and enable an easy yet convenient way of tracking on status of goals. Although it may increase coupling and dependencies, the implementation of goals evidently shows that the pros outweigh the cons despite these trade-offs.

5. Documentation

We use asciidoc for writing documentation. We recommend you to document features that you have done to keep other developers aware of your implementation.

Feel free to modify the documentation of our original features as well!

We chose asciidoc over Markdown because asciidoc, although a bit more complex than Markdown, provides more flexibility in formatting.

5.1. Editing Documentation

See UsingGradle.adoc to learn how to render .adoc files locally to preview the end result of your edits. Alternatively, you can download the AsciiDoc plugin for IntelliJ, which allows you to preview the changes you have made to your .adoc files in real-time.

5.2. Publishing Documentation

See UsingTravis.adoc to learn how to deploy GitHub Pages using Travis.

5.3. Converting Documentation to PDF format

We use Google Chrome for converting the documentation to PDF format, as Chrome’s PDF engine preserves hyperlinks used in webpages.

Here are the steps to convert the project documentation files to PDF format.

  1. Follow the instructions in UsingGradle.adoc to convert the AsciiDoc files in the docs/ directory to HTML format.

  2. Go to your generated HTML files in the build/docs folder, right-click on them and select Open with → Google Chrome.

  3. Within Chrome, click on the Print option in Chrome’s menu.

  4. Set the destination to Save as PDF, then click Save to save a copy of the file in PDF format. For best results, use the settings indicated in the screenshot below.

chrome save as pdf
Figure 18. Saving documentation as PDF files in Chrome

5.4. Site-wide Documentation Settings

The build.gradle file specifies some project-specific asciidoc attributes which affects how all documentation files within this project are rendered.

Attributes left unset in the build.gradle file will use their default value, if any.
Table 1. List of site-wide attributes
Attribute name Description Default value

site-name

The name of the website. If set, the name will be displayed near the top of the page.

not set

site-githuburl

URL to the site’s repository on GitHub. Setting this will add a "View on GitHub" link in the navigation bar.

not set

site-seedu

Define this attribute if the project is an official SE-EDU project. This will render the SE-EDU navigation bar at the top of the page, and add some SE-EDU-specific navigation items.

not set

5.5. Per-file Documentation Settings

Each .adoc file may also specify some file-specific asciidoc attributes which affects how the file is rendered.

Asciidoctor’s built-in attributes may be specified and used as well.

Attributes left unset in .adoc files will use their default value, if any.
Table 2. List of per-file attributes, excluding Asciidoctor’s built-in attributes
Attribute name Description Default value

site-section

Site section that the document belongs to. This will cause the associated item in the navigation bar to be highlighted. One of: UserGuide, DeveloperGuide, LearningOutcomes*, AboutUs, ContactUs

* Official SE-EDU projects only

not set

no-site-header

Set this attribute to remove the site navigation bar.

not set

5.6. Site Template

The files in docs/stylesheets are the CSS stylesheets of the site. You can modify them to change some properties of the site’s design.

The files in docs/templates controls the rendering of .adoc files into HTML5. These template files are written in a mixture of Ruby and Slim.

Modifying the template files in docs/templates requires some knowledge and experience with Ruby and Asciidoctor’s API. You should only modify them if you need greater control over the site’s layout than what stylesheets can provide. The SE-EDU team does not provide support for modified template files.

6. Testing

Testing is integral to the success of OwlMoney. We perform tests regularly during the development of OwlMoney and recommend you to be consistent with this ideology and do so too!

6.1. Running Tests

There are 2 ways to run tests.

Method 1: Using IntelliJ JUnit test runner

  • To run all tests, right-click on the src/test/java folder and choose Run 'All Tests'

  • To run a subset of tests, you can right-click on a test package, test class, or a test and choose Run 'ABC'

Method 2: Using Gradle

  • Open a console and run the command gradlew clean allTests (Mac/Linux: ./gradlew clean allTests)

6.2. Types of tests

We have two types of tests:

  1. System Tests that test the OwlMoney by running base level automated tests on AppVeyor.

  2. Unit tests that test the individual components. These are in test.java package.

  3. Unit tests targeting the lowest level methods/classes.
    e.g. owlmoney.model

  4. Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
    e.g. owlmoney.model.bond.BondListTest

  5. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
    e.g. owlmoney.model.bond.BondListTest

7. Dev Ops

Development and Operations (Dev Ops) is integral to ensure consistent releases and updates are produced to fix bugs and introduce new features to OwlMoney while ensuring existing features do not break. We use multiple tools to automate checks and ensure high levels of consistency across the board.

Below are configurations and services that were used during the development of OwlMoney.

7.1. Build Automation

See UsingGradle.adoc to learn how to use Gradle for build automation.

7.2. Continuous Integration

We use Travis CI and AppVeyor to perform Continuous Integration on our projects.

See UsingTravis.adoc and UsingAppVeyor.adoc for more details.

7.3. Coverage Reporting

We use Coveralls to track the code coverage of our projects.

See UsingCoveralls.adoc for more details.

We use Codecov as well to provide an alternative perspective from coveralls.

See Codecov Quick Start for more details.

7.4. Documentation Previews

When a pull request has changes to asciidoc files, you can use Netlify to see a preview of how the HTML version of those asciidoc files will look like when the pull request is merged.

See UsingNetlify.adoc for more details.

7.5. Making a Release

Here are the steps to create a new release.

  1. Update the version number in build.gradle.

  2. Generate a JAR file using Gradle.

  3. Tag the repo with the version number. e.g. v1.8

  4. Create a new release using GitHub and upload the JAR file you created.

7.6. Managing Dependencies

A project often depends on third-party libraries.

Managing these dependencies can be automated using Gradle.

For example, Gradle can download the dependencies automatically, which is better than these alternatives:

  1. Include those libraries in the repo (this bloats the repo size)

  2. Require developers to download those libraries manually (this creates extra work for developers)

Appendix A: Product Scope

Target User Profile:

  • Undergraduates and fresh graduates

  • Have some form of income in terms of allowance, pocket money or salary

  • Has interest in managing his finances

  • Prefers desktop applications over other types

  • Able to type fast

  • Prefers typing over other means of input

  • Is reasonably comfortable using CLI applications

Value Proposition:

  • Helps the target user manage their finances as they start to take charge of more money

  • Helps the target user budget their expenses based on their goals

  • Automatically reminds you of upcoming bills that are due to pay

  • Automatically deducts or credit to account based on recurring income and expenses monthly

  • See everything from account balances and expenses to give target users a full picture of their financial health.

  • Works offline

Appendix B: User Stories

Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

S/N

Priority Level

As a …​

I can …​

So that I can …​

1

* * *

new user

create my own profile

start keeping track of my finances

2

* * *

user

add saving accounts

categorise my finances

3

* * *

user

add income

calculate my recommended budget

4

* * *

existing user

edit my profile details

keep my details up to date

5

* * *

existing user

edit my saving account

correct any errors

6

* * *

existing user

edit my income

change it when there are changes to my income.

7

* * *

spendthrift

add expenditures

keep track of my spending

8

* * *

careless user

edit my expenditure

correct my errors.

9

* * *

careless user

delete my expenditure

remove wrongly added expenses

10

* * *

organised user

list my expenditure

have a view of my spending

11

* * *

existing user

search for specific transaction by category, description or date

search and view specific transaction records.

12

* *

existing user

set short and long term financial goals

I can achieve financial stability.

13

* *

indecisive user

edit my existing financial goals

adapt to any changes

14

* *

existing user

undo my last command

revert back to the previous state in the event of a mistake

15

* *

existing user

compare overall expenditure of different month

review my spending

16

* *

credit card user

add new credit cards to my account

credit my spending till the end of the month

17

* *

credit card user

charge my expenditures to my credit card

track my credit card expenses and rebates

18

* *

credit card user

edit my credit card details

update the details when there are changes to my card

19

* *

spendthrift

be warned when I am close to exceeding my budget or have exceeded my budget

reduce my spending

20

* *

existing user

recurring expenditures

relax and not need to enter it repeatedly for each month.

21

* *

user with income

set recurring income

relax and not need to enter it repeatedly for each month.

22

* *

existing user

view recurring expenditure

review it to check for error

23

* *

user with income

view recurring income

review it to check for error

24

* *

existing user

edit recurring expenditure

amend the recurring expenses when it increases or decreases

25

* *

user with income

edit recurring income

I can remove or change it accordingly

26

* *

existing user

be reminded when my payment is due

pay on time without penalties

27

* *

organised user

export to view my expenditures statement

review my expenditure records with ease

28

* *

achievement oriented user

gain achievements when I achieve system pre-defined goals

be motivated to pursue my financial goal

29

* *

achievement oriented user

view different types of achievements

view my achievement that has been attained or yet to be attained

30

* *

achievement oriented user

view the description of an achievement

understand how to achieve it

31

* *

existing user

add investment account (bond)

track my investment bond earnings.

32

* *

existing user

edit my investment account (bond)

amend any errors in my investment bond account

33

* *

existing user

delete my investment account (bond)

sell it before the maturity date.

34

* *

existing user

have my investment account’s (bond) interest being accumulated automatically every half yearly

do not have to go through the hassle of entering it manually

35

* *

existing user

have my money transfer from one bank account to another bank account

I can organize them as investment or saving account for ease in tracking different expenditure

36

* *

credit card user

list my credit card details

have an overview of all my credit card details like card limit and cash back rates.

37

* *

credit card user

list my credit card expenditures

have an overview of my spendings to keep track and to avoid overspending.

38

* *

existing user

search for specific bank account, credit card or bonds

search and view the details of the specific bank account, credit card or bonds with ease.

39

* *

organised user

view my financial details in a user friendly format

so that I can review my expenses with ease.

40

* *

existing user

search for specific recurring expenditure

search and view the details of the specific recurring expenditure.

41

* *

credit card user

delete credit cards from my account

remove unwanted or incorrectly added credit cards.

42

* *

credit card user

edit my credit card expenditures

amend any incorrect expenditures.

43

* *

credit card user

delete my credit card expenditures

remove any unwanted or incorrectly added expenditures.

44

* *

credit card user

add my credit card bill to my savings account

track my credit card bill payments and rebates.

45

* *

credit card user

delete my credit card bill from my savings account

undo the bill payment in order to edit my expenditures or to pay using another savings account.

Appendix C: Use Cases

(For all use cases below, the System is OwlMoney, unless specified otherwise)

Actor: First time user
Use case: UC1 - Create new profile
Main success scenario:

  1. User choose to setup account.

  2. System requests personal details.

  3. User enters personal details.

  4. System requests for bank account details.

  5. User enters bank account details (UC-2).

  6. System requests for income details.

  7. User enters income details (UC-3).

  8. System will setup a profile tied to new bank account with the details specified.

    Use case ends.

Extensions

  • 3a. System detects invalid personal details.

    • 3a1. System requests for the correct personal details.

    • 3a2. User re-enters the personal details.

    • Steps 3a1-3a2 are repeated until the personal details entered are correct.

    • Use case resumes from step 4.

  • 5a. System detects invalid bank account details.

    • 5a1. System requests for the correct bank account details.

    • 5a2. User re-enters the bank account details.

    • Steps 5a1-5a2 are repeated until the bank account details entered are correct.

    • Use case resumes from step 6.

  • 7a. System detects invalid income details.

    • 7a1. System requests for the correct income details.

    • 7a2. User re-enters the income details.

    • Steps 7a1-7a2 are repeated until the income details entered are correct.

    • Use case resumes from step 8.

Actor: User
Use case: UC2 - Add savings account
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to add a savings account.

  2. System requests for savings account details.

  3. User enters details for the new savings account.

  4. System creates a new savings account with the details specified.

    Use case ends.

Extensions

  • 3a. System detects invalid details for the new savings account.

    • 3a1. System requests for the correct savings account details.

    • 3a2. User re-enters the details for new savings account.

    • Steps 3a1-3a2 are repeated until the details for new savings account is entered correctly.

    • Use case resumes from step 4.

Actor: User
Use case: UC3 - Add income
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to add income.

  2. System requests for income details.

  3. User enters income details.

  4. System creates a new income with the details specified.

    Use case ends.

Extensions

  • 3a. System detects invalid income details.

    • 3a1. System requests for the correct income details.

    • 3a2. User re-enters the income details.

    • Steps 3a1-3a2 are repeated until the income details entered are correct.

    • Use case resumes from step 4.

Actor: Existing User
Use case: UC4 - Edit profile details
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to edit his/her profile.

  2. System requests for new profile details.

  3. User enters new profile details.

  4. System update the profile details

    Use case ends.

Extensions

  • 3a. System detects invalid profile details.

    • 3a1. System requests for the correct profile details.

    • 3a2. User re-enters the profile details.

    • Steps 3a1-3a2 are repeated until the profile details entered are correct.

    • Use case resumes from step 4.

Actor: Existing User
Use case: UC5 - Edit savings account details
Preconditions:

  • User has a profile created

  • User has an existing savings account

Main success scenario:

  1. User chooses to edit his/her specific savings account details.

  2. System requests for the savings account and newly specified information of savings account details.

  3. User enters the savings account with new savings account information he/she like to change.

  4. System updates the savings account with new savings account details.

    Use case ends.

Extensions

  • 3a. System detects invalid savings account or invalid new savings account details.

    • 3a1. System requests for the correct savings account and savings account details.

    • 3a2. User re-enters the savings account and new savings account details.

    • Steps 3a1-3a2 are repeated until the savings account and savings account details are entered correctly.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC6 - Edit income
Preconditions:

  • User has a profile created

  • User has an existing income account

Main success scenario:

  1. User chooses to edit his/her income.

  2. System requests new income details.

  3. User enters new income details.

  4. System updates the income details.

    Use case ends.

Extensions

  • 3a. System detects invalid income details.

    • 3a1. System requests for the correct income details.

    • 3a2. User re-enters the income details.

    • Steps 3a1-3a2 are repeated until the income details entered are correct.

    • Use case resumes from step 4.

Actor: Spendthrift
Use case: UC7 - Add expenditures record
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to add new expenditure record.

  2. System requests expenditure details and the account to add the expenditure.

  3. User enters expenditure details.

  4. System adds new expenditure record into the specified account.

    Use case ends.

Extensions

  • 3a. System detects invalid expenditure details or account.

    • 3a1. System requests for the correct expenditure details and the account to add the expenditure.

    • 3a2. User re-enters the expenditure details and the account to add the expenditure.

    • Steps 3a1-3a2 are repeated until the expenditure details and the account to add the expenditure are entered correctly .

    • Use case resumes from step 4.

Actor: Careless user
Use case: UC8 - Edit expenditures record
Preconditions:

  • User has a profile created

  • User has existing expenditure records

Main success scenario:

  1. User chooses to edit expenditure record.

  2. System requests for the new expenditure details and the expenditure to be edited.

  3. User enters new expenditure details and the expenditure to be edited.

  4. System updates the expenditure record.

    Use case ends.

Extensions

  • 3a. System detects invalid expenditure details or expenditure to be edited.

    • 3a1. System requests for the correct expenditure details and expenditure to be edited.

    • 3a2. User re-enters the expenditure details and expenditure to be edited.

    • Steps 3a1-3a2 are repeated until the expenditure details and expenditure to be edited entered are correct.

    • Use case resumes from step 4.

Actor: Careless user
Use case: UC9 - Delete expenditure record
Preconditions:

  • User has a profile created

  • User has existing expenditure records

Main success scenario:

  1. User chooses to delete expenditure record.

  2. System requests expenditure to be deleted and the account to delete the expenditure from.

  3. User specifies the expenditure to be deleted and the account to delete the expenditure from.

  4. System deletes the specified record from the database.

    Use case ends.

Extensions

  • 3a. System detects invalid expenditure to be deleted or account to delete the expenditure from.

    • 3a1. System requests for the correct expenditure to be deleted and the account to delete the expenditure from.

    • 3a2. User re-enters the expenditure to be deleted and the account to delete the expenditure from.

    • Steps 3a1-3a2 are repeated until the expenditure to be deleted the account to delete the expenditure from are entered correctly.

    • Use case resumes from step 4.

Actor: Organized user
Use case: UC10 - List expenditure record
Preconditions:

  • User has a profile created

  • User has existing expenditure records

Main success scenario:

  1. User chooses to list the expenditure record.

  2. System requests the account to list from.

  3. User specifies the account to list from.

  4. System displays the expenditure records specified.

    Use case ends.

Extensions

  • 3a. System detects invalid account to list from.

    • 3a1. System requests for the correct account to list from.

    • 3a2. User re-enters the account to list from.

    • Steps 3a1-3a2 are repeated until the account to list from is entered correctly.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC11 - Search for specific transaction record
Preconditions:

  • User has a profile created

  • User has at least an existing card, savings account or investment account

  • User has existing transaction records

Main success scenario:

  1. User chooses to search for transaction record.

  2. System requests the keywords to be search.

  3. User specifies the keywords to be search.

  4. System displays information found from the search.

    Use case ends.

Extensions

  • 3a. System detects invalid keywords to be search.

    • 3a1. System requests for the correct keywords to be search.

    • 3a2. User re-enters the keywords to be search.

    • Steps 3a1-3a2 are repeated until the keywords to be search is entered correctly.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC12 - Set short or long term financial goal
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to set financial goals.

  2. System requests the type of financial goal to be set.

  3. User specifies the type of financial goal to be set.

  4. System requests information for the financial goal.

  5. User enters the information required for setting the financial goal.

  6. System creates the financial goal.

    Use case ends.

Extensions

  • 3a. System detects invalid type of financial goal to be set.

    • 3a1. System requests for the correct type of financial goal to be set.

    • 3a2. User re-enters the type of financial goal to be set.

    • Steps 3a1-3a2 are repeated until the type of financial goal to be set is entered correctly.

    • Use case resumes from step 4.

  • 5a. System detects invalid information required for setting the financial goal.

    • 5a1. System requests for the correct information required for setting the financial goal.

    • 5a2. User re-enters the information required for setting the financial goal.

    • Steps 5a1-5a2 are repeated until the information required for setting the financial goal is entered correctly.

    • Use case resumes from step 6.

Actor: Indecisive user
Use case: UC13 - Edit existing financial goal
Preconditions:

  • User has a profile created

  • User has a financial goal set up

Main success scenario:

  1. User chooses to edit existing financial goal.

  2. System requests the financial goal to be edited.

  3. User specifies the financial goal to be edited.

  4. System requests the information to be edited.

  5. User enters the information to be updated.

  6. System updates existing financial goal.

    Use case ends.

Extensions

  • 3a. System detects invalid financial goal to be edited.

    • 3a1. System requests for the correct financial goal to be edited.

    • 3a2. User re-enters the financial goal to be edited.

    • Steps 3a1-3a2 are repeated until the financial goal to be edited is entered correctly.

    • Use case resumes from step 4.

  • 5a. System detects invalid information to be updated.

    • 5a1. System requests for the correct information to be updated.

    • 5a2. User re-enters the information to be updated.

    • Steps 5a1-5a2 are repeated until the information to be updated is entered correctly.

    • Use case resumes from step 6.

Actor: Existing user
Use case: UC14 - Undo last command
Preconditions:

  • User has a profile created

  • User entered at least one command in the system

Main success scenario:

  1. User enters the undo command.

  2. System returns to the state before the previous command is entered.

    Use case ends.

Actor: Existing user
Use case: UC15 - Compare overall expenditure of different month
Preconditions:

  • User has a profile created

  • User has at least two previous month expenditure to compare with

Main success scenario:

  1. User chooses to compare overall expenditure of different months.

  2. System requests the months to be compared.

  3. User specifies the months to be compared.

  4. System displays the compared result.

    Use case ends.

Extensions

  • 3a. System detects invalid months to be compared.

    • 3a1. System requests for the correct months to be compared.

    • 3a2. User re-enters the months to be compared.

    • Steps 3a1-3a2 are repeated until the months to be compared is entered correctly.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC16 - Add credit card to account
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to add a credit card to his/her account.

  2. System requests the details for creating credit card.

  3. User enters the details for creating credit card.

  4. System creates the credit card.

    Use case ends.

Extensions

  • 3a. System detects invalid details for creating credit card.

    • 3a1. System requests for the correct details for creating credit card.

    • 3a2. User re-enters the details for creating credit card.

    • Steps 3a1-3a2 are repeated until the details for creating credit card is entered correctly.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC17 - Charge expenditure to credit card
Preconditions:

  • User has a profile created

  • User has credit card added to profile

Main success scenario:

  1. User chooses to charge expenditure to credit card.

  2. System requests the expenditure information and the card to be charged.

  3. User enters the expenditure information and the card to be charged.

  4. System creates the credit card expenditure record.

    Use case ends.

Extensions

  • 3a. System detects invalid expenditure information or card to be charged.

    • 3a1. System requests for the correct expenditure information and card to be charged.

    • 3a2. User re-enters the expenditure information and card to be charged.

    • Steps 3a1-3a2 are repeated until the expenditure information and card to be charged are entered correctly.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC18 - Edit credit card details
Preconditions:

  • User has a profile created

  • User has credit card added to profile

Main success scenario:

  1. User chooses to edit credit card details.

  2. System requests for new credit card details and the credit card to be edited.

  3. User enters new credit card details and the credit card to be edited.

  4. System updates the credit card details.

    Use case ends.

Extensions

  • 3a. System detects invalid credit card details or credit card to be edited

    • 3a1. System requests for the correct credit card details and credit card to be edited.

    • 3a2. User re-enters the credit card details and the credit card to be edited.

    • Steps 3a1-3a2 are repeated until the credit card details and the credit card to be edited are entered correctly.

    • Use case resumes from step 4.

Actor: Spendthrift user
Use case: UC19 - System warns user when exceeding or have exceeded budget
Preconditions:

  • User has a profile created

Main success scenario:

  1. User adds expenditure (UC-7).

  2. System warns user if total expenditure is exceeding or have exceeded budget.

    Use case ends.

Actor: Existing user
Use case: UC20 - Set recurring expenditure
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to set recurring expenditure.

  2. System requests for details of recurring expenditure and the savings account to be charged.

  3. User enters details of recurring expenditure and the savings account to be charged.

  4. System creates recurring expenditure.

    Use case ends.

Extensions

  • 3a. System detects invalid details of recurring expenditure or savings account to be charged.

    • 3a1. System requests for the correct details of recurring expenditure and savings account to be charged.

    • 3a2. User re-enters the details of recurring expenditure and the savings account to be charged.

    • Steps 3a1-3a2 are repeated until the details of recurring expenditure and savings account to be charged are entered correctly.

    • Use case resumes from step 4.

Actor: User with income
Use case: UC21 - Set recurring income
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to set recurring income.

  2. System requests for details of recurring income.

  3. User enters details of recurring income.

  4. System creates recurring income.

    Use case ends.

Extensions

  • 3a. System detects invalid details of recurring income.

    • 3a1. System requests for the correct details of recurring income.

    • 3a2. User re-enters the details of recurring income.

    • Steps 3a1-3a2 are repeated until the details of recurring income is entered correctly.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC22 - View recurring expenditure
Preconditions:

  • User has a profile created

  • User has at least a recurring expenditure.

Main success scenario:

  1. User chooses to view recurring expenditure.

  2. System requests the savings account to be listed.

  3. User enters the savings account to be listed.

  4. System displays all recurring payments.

    Use case ends.

Extensions

  • 3a. System detects invalid savings account to be listed.

    • 3a1. System requests for the correct savings account to be listed.

    • 3a2. User re-enters the savings account to be listed.

    • Steps 3a1-3a2 are repeated until the savings account to be listed is entered correctly.

    • Use case resumes from step 4.

Actor: User with income
Use case: UC23 - View recurring income
Preconditions:

  • User has a profile created

  • User has at least a recurring income.

Main success scenario:

  1. User chooses to view recurring income.

  2. System displays all recurring income in chronological order.

    Use case ends.

Actor: Existing user
Use case: UC24 - Edit recurring expenditure
Preconditions:

  • User has a profile created

  • User has at least a recurring expenditure.

Main success scenario:

  1. User chooses to edit recurring expenditure.

  2. System requests from user the recurring expenditure to be edited and the savings account.

  3. User specifies the recurring expenditure and the savings account.

  4. System requests for the new recurring expenditure details.

  5. User enters the new recurring expenditure details.

  6. System updates the recurring expenditure.

    Use case ends.

Extensions

  • 3a. System detects invalid recurring expenditure or savings account being specified.

    • 3a1. System requests for the correct recurring expenditure and savings account.

    • 3a2. User re-enters the recurring expenditure and savings account.

    • Steps 3a1-3a2 are repeated until the recurring expenditure and savings account are entered correctly.

  • Use case resumes from step 4.

  • 5a. System detects invalid recurring expenditure details.

    • 5a1. System requests for the correct recurring expenditure details.

    • 5a2. User re-enters the recurring expenditure details.

    • Steps 5a1-5a2 are repeated until the recurring expenditure details is entered correctly.

    • Use case resumes from step 6.

Actor: User with income
Use case: UC25 - Edit recurring income
Preconditions:

  • User has a profile created

  • User has at least a recurring income.

Main success scenario:

  1. User chooses to edit recurring income.

  2. System requests from user the recurring income to be edited.

  3. User specifies the recurring income.

  4. System requests for the new recurring income details.

  5. User enters the new recurring income details.

  6. System updates the recurring income.

    Use case ends.

Extensions

  • 3a. System detects invalid recurring income being specified.

    • 3a1. System requests for the correct recurring income.

    • 3a2. User re-enters the recurring income.

    • Steps 3a1-3a2 are repeated until the recurring income entered are correct.

    • Use case resumes from step 4.

  • 5a. System detects invalid recurring income details.

    • 5a1. System requests for the correct recurring income details.

    • 5a2. User re-enters the recurring income details.

    • Steps 5a1-5a2 are repeated until the recurring income details entered are correct.

    • Use case resumes from step 6.

Actor: Existing user
Use case: UC26 - Reminded of due payment
Preconditions:

  • User has a profile created

  • User has at least a recurring expenditure or credit card expenditure

Main success scenario:

  1. User chooses to check for due payment.

  2. System display due payment.

    Use case ends.

Actor: Organized user
Use case: UC27 - Export expenditures statement as CSV
Preconditions:

  • User has a profile created

Main success scenario:

  1. User chooses to make changes to expenditures.

  2. System requests for which expenditure to modify.

  3. User specifies the details of the expenditure and the details to modify.

  4. System exports the expenditure details as CSV.

    Use case ends.

Extensions

  • 3a. System detects invalid months being specified.

    • 3a1. System requests for the correct months.

    • 3a2. User re-enters the months.

    • Steps 3a1-3a2 are repeated until the months entered are correct.

    • Use case resumes from step 4.

Actor: Achievement oriented user
Use case: UC28 - Gain achievement
Preconditions:

  • User has a profile created

Main success scenario:

  1. User meets a predefined achievement criteria.

  2. System informs user that an achievement has been achieved.

    Use case ends.

Actor: Achievement oriented user
Use case: UC29 - View different types of achievements
Preconditions:

  • User has a profile created.

Main success scenario:

  1. User chooses to view achievements.

  2. System requests for types of achievement to view.

  3. User specifies the type of achievement.

  4. System displays all achievements of the specified type.

    Use case ends.

Extensions

  • 3a. System detects invalid type of achievement.

    • 3a1. System requests for the correct type of achievement.

    • 3a2. User re-enters the type of achievement.

    • Steps 3a1-3a2 are repeated until the type of achievement entered are correct.

    • Use case resumes from step 4.

Actor: Achievement oriented user
Use case: UC30 - View description of an achievement
Preconditions:

  • User has a profile created.

Main success scenario:

  1. User chooses to view achievement description.

  2. System requests for which specific achievement to view.

  3. User specifies the achievement.

  4. System displays description of the achievement.

    Use case ends.

Extensions

  • 3a. System detects invalid achievement being specified.

    • 3a1. System requests for the correct achievement.

    • 3a2. User re-enters the achievement.

    • Steps 3a1-3a2 are repeated until the achievement entered are correct.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC31 - Add investment account (bond)
Main success scenario:

  1. User choose to add investment account.

  2. System requests for investment account details.

  3. User enters investment account details.

  4. System creates an investment account.

    Use case ends.

Extensions

  • 3a. System detects invalid investment account details.

    • 3a1. System requests for the correct investment account details.

    • 3a2. User re-enters the investment account details.

    • Steps 3a1-3a2 are repeated until the investment account details entered are correct.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC32 - Edit investment account (bond)
Main success scenario:

  1. User choose to edit investment account.

  2. System requests for new investment account details and the investment account to be edited.

  3. User enters investment account details and the investment account to be edited.

  4. System updates the investment account.

    Use case ends.

Extensions

  • 3a. System detects invalid investment account details or investment account to be edited.

    • 3a1. System requests for the correct investment account details and the investment account to be edited.

    • 3a2. User re-enters the investment account details and the investment account to be edited.

    • Steps 3a1-3a2 are repeated until the investment account details and the investment account to be edited entered are correct.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC33 - Delete investment account (bond)
Main success scenario:

  1. User choose to delete investment account.

  2. System requests for investment account to be deleted.

  3. User selects the investment account to be deleted.

  4. System deletes the investment account.

    Use case ends.

Extensions

  • 3a. System detects invalid investment account being selected for deletion.

    • 3a1. System requests for the correct investment account to be deleted.

    • 3a2. User re-enters the investment account to be deleted.

    • Steps 3a1-3a2 are repeated until the investment account to be deleted is entered correctly.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC34 - Automatically calculate half yearly interest for investment account (bond)
Main success scenario:

  1. User starts up the program.

  2. System runs the check and calculate the interest accordingly.

    Use case ends.

Actor: Existing user
Use case: UC35 - Transfer money between different bank accounts
Main success scenario:

  1. User choose to transfer money to another bank account.

  2. System requests for sender account, receiver account and amount to transfer.

  3. User enters the sender account, receiver account and amount to transfer.

  4. System transfers the amount to the specified account.

    Use case ends.

Extensions

  • 3a. System detects invalid sender account, receiver account or amount to transfer.

    • 3a1. System requests for the correct sender account, receiver account and amount to transfer.

    • 3a2. User re-enters the sender account, receiver account and amount to transfer.

    • Steps 3a1-3a2 are repeated until the sender account, receiver account and amount to transfer is entered correctly.

    • Use case resumes from step 4.

Actor: Organised User
Use case: UC36 - List card details
Preconditions:

  • User has a profile created

  • User has added a credit card to the profile

Main success scenario:

  1. User choose to list credit card details.

  2. System displays all credit card details.

    Use case ends.

Actor: Organised User
Use case: UC37 - List card expenditures
Preconditions:

  • User has a profile created

  • User has added a credit card to the profile

  • User has expenditure added to credit card

Main success scenario:

  1. User chooses to list the card expenditure record.

  2. System requests name of the card for the expenditure to be listed.

  3. User specifies the name of the card for the expenditure to be listed.

  4. System displays the expenditure records specified.

    Use case ends.

Extensions

  • 3a. System detects invalid name of the card for the expenditure to be listed.

    • 3a1. System requests for the correct name of the card for the expenditure to be listed.

    • 3a2. User re-enters the name of the card for the expenditure to be listed.

    • Steps 3a1-3a2 are repeated until the name of the card for the expenditure to be listed is entered correctly.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC38 - Search for specific bank account, credit card or bonds
Preconditions:

  • User has a profile created

  • User has added a bank account to the profile

  • User has added a credit card to the profile

  • User has added an investment bond tied to his investment bank account

Main success scenario:

  1. User choose to search for specific bank account, credit card or bonds.

  2. System requests for the keywords to be used for searching.

  3. User specifies the keywords to be used for searching.

  4. System displays information found from the search.

    Use case ends.

Extensions

  • 3a. System detects invalid keywords to be used for searching.

    • 3a1. System requests for the correct keywords to be used for searching.

    • 3a2. User re-enters the keywords to be used for searching.

    • Steps 3a1-3a2 are repeated until the keywords to be used for searching is entered correctly.

    • Use case resumes from step 4.

Actor: Organized User
Use case: UC39 - View financial details in a user friendly format
Preconditions:

  • User has a profile created

  • User has existing financial details (e.g. transaction records, goals)

Main success scenario:

  1. User chooses the type of financial details to list.

  2. System requests for the type of financial details to be listed.

  3. User specifies the type of financial details to be listed.

  4. System displays the information in a table format.

    Use case ends.

Extensions

  • 3a. System detects invalid type of financial details to be listed.

    • 3a1. System requests for the correct type of financial details to be listed.

    • 3a2. User re-enters the type of financial details to be listed.

    • Steps 3a1-3a2 are repeated until the type of financial details to be listed is entered correctly.

    • Use case resumes from step 4.

Actor: Existing user
Use case: UC40 - Search for specific recurring expenditure
Preconditions:

  • User has a profile created

  • User has added a savings account to the profile

  • User has added recurring expenditure to the savings account

Main success scenario:

  1. User choose to search for specific recurring expenditure.

  2. System requests for the keywords to be used for searching.

  3. User specifies the keywords to be used for searching.

  4. System displays information found from the search.

    Use case ends.

Extensions

  • 3a. System detects invalid keywords to be used for searching.

    • 3a1. System requests for the correct keywords to be used for searching.

    • 3a2. User re-enters the keywords to be used for searching.

    • Steps 3a1-3a2 are repeated until the keywords to be used for searching is entered correctly.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC41 - Delete credit card from account
Preconditions:

  • User has a profile created

  • User has a credit card in profile

Main success scenario:

  1. User choose to delete credit card.

  2. System requests for credit card to be deleted.

  3. User selects the credit card to be deleted.

  4. System deletes the credit card.

    Use case ends.

Extensions

  • 3a. System detects invalid credit card being selected for deletion.

    • 3a1. System requests for the credit card to be deleted.

    • 3a2. User re-enters the credit card to be deleted.

    • Steps 3a1-3a2 are repeated until the credit card to be deleted is entered correctly.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC42 - Edit credit card expenditures record
Preconditions:

  • User has a profile created

  • User has credit cards in profile

  • User has existing unpaid expenditure records in credit card

Main success scenario:

  1. User chooses to edit credit card expenditure record.

  2. System requests for the new expenditure details, expenditure to be edited and name of card.

  3. User enters new expenditure details, expenditure to be edited and name of card.

  4. System updates the credit card expenditure record.

    Use case ends.

Extensions

  • 3a. System detects invalid new expenditure details, expenditure to be edited or name of card.

    • 3a1. System requests for the correct new expenditure details, expenditure to be edited and name of card.

    • 3a2. User re-enters the new expenditure details, expenditure to be edited and name of card.

    • Steps 3a1-3a2 are repeated until the new expenditure details, expenditure to be edited and name of card entered are correct.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC43 - Delete credit card expenditure record
Preconditions:

  • User has a profile created

  • User has credit cards in profile

  • User has existing unpaid expenditure records in credit card

Main success scenario:

  1. User chooses to delete credit card expenditure record.

  2. System requests expenditure to be deleted and the credit card to delete the expenditure from.

  3. User specifies the expenditure to be deleted and the credit card to delete the expenditure from..

  4. System deletes the specified record from the database.

    Use case ends.

Extensions

  • 3a. System detects invalid expenditure to be deleted or credit card to delete the expenditure from.

    • 3a1. System requests for the correct expenditure to be deleted and the credit card to delete the expenditure from.

    • 3a2. User re-enters the expenditure to be deleted and the credit card to delete the expenditure from.

    • Steps 3a1-3a2 are repeated until the expenditure to be deleted and the credit card to delete the expenditure from are entered correctly.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC44 - Add credit card bill
Preconditions:

  • User has a profile created

  • User has savings account in profile

  • User has credit cards in profile

  • User has existing unpaid expenditure records in credit card

Main success scenario:

  1. User chooses to add new credit card bill.

  2. System requests details for payment of credit card bill.

  3. User enters credit card, savings account, and date for payment of credit card bill.

  4. System adds new credit card bill expenditure record in savings account.

    Use case ends.

Extensions

  • 3a. System detects invalid credit card bill details.

    • 3a1. System requests for the correct credit card bill details.

    • 3a2. User re-enters the credit card bill details.

    • Steps 3a1-3a2 are repeated until the credit card bill details entered are correct.

    • Use case resumes from step 4.

Actor: Credit card user
Use case: UC45 - Delete credit card bill
Preconditions:

  • User has a profile created

  • User has savings account in profile

  • User has credit cards in profile

  • User has existing paid expenditure records in credit card

Main success scenario:

  1. User chooses to delete credit card bill.

  2. System requests details of credit card bill to be deleted.

  3. User enters credit card, savings account, and date of credit card bill to be deleted.

  4. System deletes the specified credit card bill expenditure record from savings account.

    Use case ends.

Extensions

  • 3a. System detects invalid credit card bill details.

    • 3a1. System requests for the correct credit card bill details.

    • 3a2. User re-enters the credit card bill details.

    • Steps 3a1-3a2 are repeated until the credit card bill details entered are correct.

    • Use case resumes from step 4.

Appendix D: Non Functional Requirements

  1. The application should work on any computer running a mainstream OS that has Java 11 installed.

  2. The application should work on both 32-bit and 64-bit environments.

  3. The application should work without requiring any internet access.

  4. The application should work without requiring an installer.

  5. The application should be able to store at least 3500 transactions per year.

  6. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most tasks faster using CLI than GUI.

  7. The application should store relevant user data locally on the filesystem and should be persistent, ensuring that the data can be restored on the next startup of the application.

  8. The application should have good user documentation, which details all aspects of the application to assist new users on how to use this application.

  9. The application should have good developer documentation to allow developers to understand the design of the application easily so that they can further develop it.

  10. The application should be easily testable.

Appendix E: Glossary

Mainstream OS

Windows, Linux, Unix, OS-X

Appendix F: Instructions for Manual Testing

These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.

Test data has been included for your convenience, feel free to deviate from the sample commands during testing.

F.1. Launch and Shutdown

  1. Initial launch

    1. Download OwlMoney-v1.4.jar file and copy into an empty folder.

    2. Open a Command Prompt or Powershell, navigate to the folder where you placed OwlMoney-v1.4.jar in and type java -jar ./OwlMoney-v1.4.jar to start OwlMoney.
      Expected: Shows the CLI stating that a profile cannot be loaded since this is the first time OwlMoney is starting up. Maximise the Command Prompt or Powershell to enjoy the best experience OwlMoney has to offer.

    3. Enter your name to create your profile for the first time. (e.g. john)

F.2. Adding a savings account

  1. Adding a new savings account

    1. Prerequisites: There are currently no savings or investment account with the same name.

      There are less than 7 existing savings account.

    2. Test case: /add /savings /name JunBank Savings Account /amount 15000 /income 5000
      Expected: New savings account is added into the profile.

  2. Adding a duplicate savings account

    1. Prerequisites: A savings or investment account with the same name has already been created.

    2. Test case: /add /savings /name JunBank Savings Account /amount 15000 /income 5000
      Expected: Error saying that there is already an existing bank account with the same name.

F.3. Editing a savings account

  1. Editing the name of a savings account

    1. Prerequisites: There is an existing savings account to be edited.

    2. Test case: /edit /savings /name JunBank Savings Account /newname BunBank Savings Account
      Expected: Updated name of the savings account being displayed after being edited.

  2. Editing the amount of a savings account

    1. Prerequisites: There is an existing savings account to be edited.

    2. Test case: /edit /savings /name BunBank Savings Account /amount 21000
      Expected: Updated amount of the savings account being displayed after being edited.

F.4. Deleting a savings account

  1. Deleting the savings account with the specified name

    1. Prerequisites: There is an existing savings account to be deleted.

    2. Test case: /delete /savings /name JunBank Savings Account
      Expected: Details of the deleted savings account being displayed after being deleted.

If you have previously changed the savings account name from JunBank Savings Account to BunBank Savings Account, you might want to change it back to JunBank Savings Account or you can choose to delete BunBank Savings Account directly.

F.5. Adding an investment account

  1. Adding a new investment account

    1. Prerequisites: There are currently no investment or savings account with the same name.

      There are less than 3 existing investment accounts.

    2. Test case: /add /investment /name DBB Vickers Account /amount 20000
      Expected: New investment is added into the profile.

  2. Adding a duplicate investment account

    1. Prerequisites: A savings or investment account with the same name has already been created.

    2. Test case: /add /investment /name DBB Vickers Account /amount 20000
      Expected: Error saying that there is already an existing bank account with the same name.

F.6. Editing an investment account

  1. Editing the name of an investment account

    1. Prerequisites: There is an existing investment account to be edited.

    2. Test case: /edit /investment /name DBB Vickers Account /newname BBB Vickers Account
      Expected: Updated name of the investment account being displayed after being edited.

  2. Editing the amount of an investment account

    1. Prerequisites: There is an existing investment account to be edited.

    2. Test case: /edit /investment /name BBB Vickers Account /amount 21000
      Expected: Updated amount of the investment account being displayed after being edited.

F.7. Deleting an investment account

  1. Deleting the investment account with the specified name

    1. Prerequisites: There is an existing investment account to be deleted.

    2. Test case: /delete /investment /name DBB Vickers Account
      Expected: Details of the deleted investment account being displayed after being deleted.

If you have previously changed the investment account name from DBB Vickers Account to BBB Vickers Account, you might want to change it back to DBB Vickers Account or you can choose to delete BBB Vickers Account directly.

F.8. Adding an investment bond

  1. Adding a new investment bond tied to an existing investment account

    1. Prerequisites: There is an existing investment account to tie the bond to.

      There is enough money in the investment account to add the bond.

    2. Test case: /add /bonds /name test SSB /amount 1000 /rate 1.65 /year 7 /date 1/10/2019 /from BBB Vickers Account
      Expected: New details of the test SSB bond being displayed after being added.

If you have previously deleted BBB Vickers Account, you might want to add it back before proceeding.

F.9. Editing an investment bond

  1. Editing the rate of an existing investment bond tied to an existing investment account

    1. Prerequisites: There is an existing bond tied to an existing investment account.

    2. Test case: /edit /bonds /from BBB Vickers Account /name test SSB /rate 1.90
      Expected: Updated rate of the test SSB bond being displayed after being edited.

  2. Editing the years of an existing investment bond tied to an existing investment account

    1. Prerequisites: There is an existing bond tied to an existing investment account.

    2. Test case: /edit /bonds /from BBB Vickers Account /name test SSB /year 10
      Expected: Updated year of the test SSB bond being displayed after being edited.

If you have previously deleted BBB Vickers Account, you might want to add it back before proceeding.

F.10. Deleting an investment bond

  1. Deleting an existing investment bond tied to an existing investment account

    1. Prerequisites: There is an existing bond tied to an existing investment account.

    2. Test case: /delete /bonds /from BBB Vickers Account /name test SSB
      Expected: Details of the deleted bond being displayed after being deleted.

If you have previously deleted BBB Vickers Account, you might want to add it back before proceeding.

F.11. Adding a bank expenditure transaction

  1. Adding a new bank expenditure to a savings account

    1. Prerequisites: There is an existing savings account to add the expenditure to.

      There is enough money in the savings account to add the expenditure.

    2. Test case: /add /bankexpenditure /from JunBank Savings Account /desc Bubble Tea /amount 4.30 /date 02/11/2019 /category Food and Drinks
      Expected: New details of the Bubble Tea expenditure being displayed after being added.

If you have previously deleted JunBank Savings Account, you might want to add it back before proceeding.

  1. Adding a new bank expenditure to a savings account with insufficient money

    1. Prerequisites: There is an existing savings account to add the expenditure to.

      There is not enough money in the savings account to add the expenditure.

    2. Test case: /add /bankexpenditure /from JunBank Savings Account /desc car /amount 80000 /date 01/11/2019 /category Transport
      Expected: Error saying the bank account cannot have a negative amount.

F.12. Editing a bank expenditure transaction

  1. Editing the amount of an existing bank expenditure tied to an existing savings account

    1. Prerequisites: There is an existing expenditure tied to an existing savings account.

      There is enough money in the savings account for the change of amount.

    2. Test case: /edit /bankexpenditure /from JunBank Savings Account /transno 1 /amount 3.70
      Expected: Updated the amount of the expenditure in index 1 of the transaction list in JunBank Savings Account being displayed after being edited.

  2. Editing the description and category of an existing bank expenditure tied to an existing savings account

    1. Prerequisites: There is an existing expenditure tied to an existing savings account.

    2. Test case: /edit /bankexpenditure /from JunBank Savings Account /transno 4 /desc Top Up EZLink Card /category Transport
      Expected: Updated the description and category of the expenditure in index of the transaction list in JunBank Savings Account being displayed after being edited.

If you have do not have at least 4 transactions in JunBank Savings Account, you might want to add more expenditures before proceeding.

F.13. Deleting a bank expenditure transaction

  1. Delete an existing bank expenditure in a savings account.

    1. Prerequisites: There is an existing expenditure tied to an existing savings account.

    2. Test case: /delete /bankexpenditure /from JunBank Savings Account /transno 1
      Expected: Details of the expenditure in index 1 of the transaction list in JunBank Savings Account being displayed before being deleted.

F.14. Adding a deposit transaction

  1. Adding a new deposit to a savings account

    1. Prerequisites: There is an existing savings account to add the deposit to.

    2. Test case: /add /deposit /to JunBank Savings Account /desc FREELANCE /amount 300 /date 29/10/2019
      Expected: New details of the FREELANCE deposit being displayed after being added.

F.15. Editing a deposit transaction

  1. Editing the amount and date of an existing deposit tied to an existing savings account

    1. Prerequisites: There is an existing deposit tied to and existing savings account.

      There is enough money in the bank account to change the amount.

    2. Test case: /edit /deposit /from JunBank Savings Account /transno 5 /amount 200 /date 30/10/2019
      Expected: Updated amount and date of the deposit in index 5 of the transaction list in JunBank Savings Account being displayed after being edited.

If you have do not have at least 5 transactions in JunBank Savings Account, you might want to add more deposits before proceeding.

F.16. Deleting a deposit transaction

  1. Delete an existing bank deposit in a savings account.

    1. Prerequisites: There is an existing deposit tied to an existing savings account.

    2. Test case: /delete /deposit /from JunBank Savings Account /transno 1
      Expected: Details of the deposit in index 1 of the transaction list in JunBank Savings Account being displayed before being deleted.

F.17. Adding a recurring bank expenditure transaction

  1. Adding a new bank expenditure to a savings account

    1. Prerequisites: There is an existing savings account to add the expenditure to.

    2. Test case: /add /recurbankexp /from JunBank Savings Account /desc Netflicks /amount 10.98 /category Entertainment
      Expected: New details of the Netflicks recurring expenditure being displayed after being added.

F.18. Editing a recurring bank expenditure transaction

  1. Editing the amount of an existing bank expenditure tied to an existing savings account

    1. Prerequisites: There is an existing expenditure tied to an existing savings account.

    2. Test case: /edit /expenditure /from JunBank Savings Account /transno 1 /amount 49.90
      Expected: Updated the amount of the recurring expenditure in index 1 of the transaction list of recurring expenditures in JunBank Savings Account being displayed after being edited.

  2. Editing the description and category of an existing bank expenditure tied to an existing savings account

    1. Prerequisites: There is an existing recurring expenditure tied to an existing savings account.

    2. Test case: /edit /recurbankexp /from JunBank Savings Account /transno 4 /desc Phone bill /category Bills
      Expected: Updated the description and category of the recurring expenditure in index 4 of the transaction list of recurring expenditures in JunBank Savings Account being displayed after being edited.

If you have do not have at least 4 recurring expenditures in JunBank Savings Account, you might want to add more recurring expenditures before proceeding.

F.19. Deleting a recurring bank expenditure transaction

  1. Delete an existing bank recurring expenditure in a savings account.

    1. Prerequisites: There is an existing recurring expenditure tied to an existing savings account.

    2. Test case: /delete /recurbankexp /from JunBank Savings Account /transno 1
      Expected: Details of the recurring expenditure in index 1 of the transaction list of recurring expenditure in JunBank Savings Account being displayed before being deleted.

F.20. Adding a credit card

  1. Adding a new card

    1. Prerequisites: There are currently no card with the same name.

    2. Test case: /add /card /name POBB Tomorrow Card /limit 10000 /rebate 1.5
      Expected: New card is added into the profile.

  2. Adding a duplicate card

    1. Prerequisites: There is currently a card with the same name.

    2. Test case: /add /card /name POBB Tomorrow Card /limit 10000 /rebate 1.5
      Expected: Error saying that there is already an existing card with the same name.

F.21. Editing a credit card

  1. Editing the name of the card

    1. Prerequisites: There is an existing card to be edited and there must be no unpaid card expenditures.

    2. Test case: /edit /card /name POBB Tomorrow Card /newname JunBank GoodVibes Card
      Expected: Updated name of the card being displayed after being edited.

  2. Editing the limit of the card

    1. Prerequisites: There is an existing card to be edited and there must be no unpaid card expenditures.

    2. Test case: /edit /card /name JunBank GoodVibes Card /limit 10000
      Expected: Updated limit of the card being displayed after being edited.

F.22. Deleting a credit card

  1. Deleting a card that exist

    1. Prerequisites: The card to be deleted exist.

    2. Test case: /delete /card /name JunBank GoodVibes Card
      Expected: Deleted card details will be displayed after being deleted.

  2. Deleting a card that do not exist

    1. Prerequisites: The card to be deleted does not exist.

    2. Test case: /delete /card /name POBB Tomorrow Card
      Expected: Error saying card to be deleted does not exist.

F.23. Adding a card expenditure

  1. Adding a card expenditure into a card.

    1. Prerequisites: Card expenditure must be added into a card that exist and that month’s expenditures
      must be unpaid.

    2. Test case: /add /cardexpenditure /from POBB Tomorrow Card /amount 300 /date 01/11/2019 /desc Chicken Rice
      Expected: Card expenditure successfully added into card.

  2. Adding a card expenditure into a card which exceeds the monthly card limit.

    1. Prerequisites: Card expenditure must be added into a card that exist and expenditure amount must
      be above card limit.

    2. Test case: /add /cardexpenditure /from POBB Tomorrow Card /amount 1200 /date 02/11/2019 /desc Fried Rice
      Expected: Card expenditure failed to be added because amount has exceeded monthly card limit.

F.24. Listing card expenditures

  1. Listing card expenditure from a card.

    1. Prerequisites: Card expenditure must exist inside card.

    2. Test case: /list /cardexpenditure /from POBB Tomorrow Card
      Expected: Paid and unpaid card expenditure are being listed.

F.25. Deleting a card expenditure

  1. Deleting a card expenditure from a card.

    1. Prerequisites: Card must be contain the expenditure to be deleted and expenditure must be unpaid.

    2. Test case: /delete /cardexpenditure /from POBB Tomorrow Card /transno 1
      Expected: Card expenditure #1 successfully deleted from card.

F.26. Adding a card bill

  1. Adding a card bill to savings account.

    1. Prerequisites: Card expenditure for the particular month and savings account must exist.

    2. Test case: /add /cardbill /card POBB Tomorrow Card /date 11/2019 /bank JunBank Savings Account
      Expected: Card bill with total amount spent for the specified month added into savings expenditure and total rebates added into savings deposit. When listing card expenditures with /list /cardexpenditure /from POBB Tomorrow Card, expenditures for that particular month will be transferred from unpaid to paid.

F.27. Deleting a card bill

  1. Deleting a card bill from savings account.

    1. Prerequisites: Card bill for the particular month must exist in savings account.

    2. Test case: /delete /cardbill /card POBB Tomorrow Card /date 11/2019 /bank JunBank Savings Account
      Expected: Card bill expenditure and deposit in savings account will be deleted. When listing card expenditures with /list /cardexpenditure /from POBB Tomorrow Card, expenditures for that particular month will be transferred from paid to unpaid.

F.28. Transferring fund

  1. Transferring fund between bank account (sufficient fund for transfer)

    1. Prerequisites: There are at least two existing bank accounts, and the sender account have sufficient fund for the transfer.

    2. Test case: /transfer /fund /from JunBank Savings Account /to POBB Savings Account /amount 500 /date 1/1/2019
      Expected: Fund successfully transfers between the bank account with the transaction being displayed.

  2. Transferring fund between bank account (insufficient fund for transfer)

    1. Prerequisites: There are at least two existing bank accounts, and the sender account does not have sufficient fund for the transfer.

    2. Test case: /transfer /fund /from JunBank Savings Account /to POBB Savings Account /amount 500 /date 1/1/2019
      Expected: Error saying that the sender account has insufficient funds to be transferred.

F.29. Finding savings accounts

  1. Searching for existing savings account

    1. Prerequisites: There is at least one existing savings accounts.

    2. Test case: /find /savings /name Jun
      Expected: Found matching savings account and displays the results.

  2. Searching for non-existing savings account

    1. Prerequisites: There are currently no existing savings accounts.

    2. Test case: /find /savings /name Jun
      Expected: Error saying that there is no savings account found.

F.30. Finding investment accounts

  1. Searching for existing investment account

    1. Prerequisites: There is at least one existing investment accounts.

    2. Test case: /find /investment /name Vickers
      Expected: Found matching investment account and displays the results.

  2. Searching for non-existing investment account

    1. Prerequisites: There are currently no existing investment accounts.

    2. Test case: /find /investment /name Vickers
      Expected: Error saying that there is no investment account found.

F.31. Finding cards

  1. Searching for existing card

    1. Prerequisites: There is at least one existing card.

    2. Test case: /find /card /name POBB
      Expected: Found matching card and displays the results.

  2. Searching for non-existing card

    1. Prerequisites: There are currently no existing card.

    2. Test case: /find /card /name POBB
      Expected: Error saying that there is no card found.

F.32. Finding bonds

  1. Searching for existing bond

    1. Prerequisites: There is at least one existing bond within the investment account.

    2. Test case: /find /bonds /name SSB /from DBB Vickers Account
      Expected: Found matching bond and displays the results.

  2. Searching for non-existing bond

    1. Prerequisites: There are currently no bond within the investment account.

    2. Test case: /find /bonds /name SSB /from DBB Vickers Account
      Expected: Error saying that there is no bond found.

F.33. Finding bank transactions

  1. Searching for existing transaction records based on the description

    1. Prerequisites: There is at least one transaction record and the bank to be searched must exist.

    2. Test case: /find /banktransaction /name JunBank Savings Account /desc bubble tea
      Expected: Found matching bank transaction record and displays the results.

  2. Searching for existing transaction records based on category

    1. Prerequisites: There is at least one transaction record and the bank to be searched must exist.

    2. Test case: /find /banktransaction /name JunBank Savings Account /category food
      Expected: Found matching bank transaction record and displays the results.

F.34. Finding card transactions

  1. Searching for existing transaction records based on the description

    1. Prerequisites: There is at least one transaction record and the card to be searched must exist.

    2. Test case: /find /cardtransaction /name POBB Tomorrow Card /desc bubble tea
      Expected: Found matching card transaction record and displays the results.

  2. Searching for existing transaction records based on category

    1. Prerequisites: There is at least one transaction record and the card to be searched must exist.

    2. Test case: /find /cardtransaction /name POBB Tomorrow Card /category food
      Expected: Found matching card transaction record and displays the results.

F.35. Finding recurring expenditure in a savings account

  1. Searching for existing recurring expenditure based on the description

    1. Prerequisites: There is at least one recurring expenditure and the savings account to be searched must exist.

    2. Test case: /find /recurbankexp /name JunBank Savings Account /desc spotif
      Expected: Found matching recurring expenditure in savings account and displays the results.

  2. Searching for existing recurring expenditure based on category

    1. Prerequisites: There is at least one recurring expenditure and the savings account to be searched must exist.

    2. Test case: /find /recurbankexp /name JunBank Savings Account /category bills
      Expected: Found matching recurring expenditure in savings account and displays the results.

F.36. Adding new goals

  1. Add new goals by specifying the date, name and amount to achieve

    1. Pre-requisites: There are currently no goals with the same name

    2. Test case: /add /goals /name GRAD TRIP /by 10/11/2020 /amount 3000
      Expected: New details of goal displayed

  2. Add new goals by specifying number of days, name and amount

    1. Pre-requisites: There are currently no goals with the same name

    2. Test case: /add /goals /name GRAD TRIP /amount 3000 /in 365
      Expected: New details of goal displayed

  3. Add new goals by specifying number of days, name and existing saving accounts

    1. Pre-requisites:

      • A savings account with specified name should exist

      • There are no goals with the same name

      • Total amount in savings account specified is less than goals amount specified

    2. Test case: /add /goals /name GRAD TRIP /from JunBank /amount 3000 /in 365
      Expected: New details of goal displayed

  4. Add new goals by specifying number of days, name and existing saving accounts (sufficient amount in account)

    1. Pre-requisites:

      • A savings account with specified name should exist

      • There are no goals with the same name

      • Total amount in savings account specified is more than goals amount specified

    2. Test case: /add /goals /name GRAD TRIP /from JunBank /amount 3000 /in 365
      Expected: New details of goal displayed

  5. Add duplicate goals

    1. Test case: /add /goals /name GRAD TRIP /amount 3000 /in 365
      Expected: Error showing that there is already a goal with the same name: GRAD TRIP

F.37. Edit goals

  1. Edit goals name

    1. Pre-requisites: Goal with specified name must exist, and there are currently no goals with the same name as the new intended name

    2. Test case: /edit /goals /name GRAD TRIP /newname KOREA GRAD
      Expected: New edited details is displayed

  2. Edit goals name

    1. Pre-requisites: Goal with specified name must exist, and there is currently a goal with the same name as the new intended name

    2. Test case: /edit /goals /name GRAD TRIP /newname KOREA GRAD
      Expected: There is already a goal name: KOREA GRAD

  3. Edit goals amount

    1. Pre-requisites: Goal with specified name must exist

    2. Test case: /edit /goals /name GRAD TRIP /amount 5000
      Expected: New edited details is displayed

  4. Edit goals date

    1. Pre-requisites: Goal with specified name must exist

    2. Test case: /edit /goals /name GRAD TRIP /in 300
      Expected: New edited details is displayed

  5. Edit goals date using both /in and /by parameters

    1. Test case: /edit /goals /name GRAD TRIP /in 300 /by 20/10/2020
      Expected: Error saying "/by and /in cannot be specified concurrently when editing goals"

  6. Edit the saving account tied to goals (can either add / edit / delete)

    1. Pre-requisites: Goal with specified name must exist and name of saving account specified must exist

    2. Test case: /edit /goals /name GRAD TRIP /from JunBank
      Expected: New edited details is displayed

  7. Mark un-tracked goals as done

    1. Pre-requisites: Goal with specified name must exist, goals must not have a saving account tied to it

    2. Test case: /edit /goals /name GRAD TRIP /mark 1
      Expected: New edited details is displayed

  8. Mark un-tracked goals as done with savings account tied

    1. Pre-requisites: Goal with specified name must exist and savings account tied

    2. Test case: /edit /goals /name GRAD TRIP /mark 1
      Expected: You cannot mark a goal that is linked to a saving account!

  9. Edit goal when goal is achieved

    1. Pre-requisites: Goal with specified name must exist and goal has already been achieved

    2. Test case: /edit /goals /name GRAD TRIP /mark 1
      Expected: Sorry, you cannot edit a goal that’s already achieved! Try creating a new goal instead!

F.38. Delete goals

  1. Delete existing goals

    1. Pre-requisites: Goal specified should exist

    2. Test case: /delete /goals /name GRAD TRIP
      Expected: Details of goal deleted being displayed

  2. Delete a non-existent goals

    1. Test case: /delete /goals /name GRAD TRIP 1
      Expected: There are no goals with the name: GRAD TRIP 1

F.39. List goals and achievement

  1. List goals

    1. Pre-requisites: Goals list must not be empty

    2. Test case: /list /goals
      Expected: Details of goals being displayed

  2. List goals when list is empty

    1. Test case: /list /goals
      Expected: There are no goals set!

  3. List achievements

    1. Pre-requisites: There are some achievements

    2. Test case: /list /achievement
      Expected: Details of achievement being displayed