Requirement Analysis

There are three phases of requirement analysis

• Requirement Elicitation: Meeting with customer and related parties to gather requirements
• Requirement Analysis: Analysis of requirements for conflicts/issues/ambiguity which are then resolved
• Requirement Documentation: Documenting the requirements into convenient forms for easier conversion to development tasks

Phase One: Requirement Elicitation

For this phase, we need to collect an overview of the requirements from the customer. We arranged meetings with our customer and noted down his requirements. Our customer was Dr. Sandro Schulze. During meetings we used a set of guided questions to gauge the requirements from the customer. Instead of using open questions, we tried to use his past experience using other apps, to get a more convenient series of requirements. For example, instead of asking “What information do you want to store?”, we may have asked “If we were to give you a form with several fields, which fields would you want for an entry?”.

After every meeting we combined our notes in group discussion among the team members and generated a list of requirements and key features. Our customer helped us with the prioritization by dividing each requirement into three categories

• Essentials(must be implemented)
• Necessities(must be implemented but app should work without these)
• Desirables(will be implemented if previous two categories are covered)

Following are some points from these three categories collected during our meeting:

• Essential requirements

  • Income and Expense(Transaction Type): This allows user to differentiate the amount we enter as a income or expense to user

  • Payment Type: This allows user to save a type of payment done in an expense .Example cash,credit card…etc

  • Note: This allows user to save a note for every entry soo that user can remember on which category of type he spent the money on

• Necessary requirements

  • Catagories: This allows user to select a specific category in which the data is saved as a expense .Examples travel,food ..etc

  • Icons: These are helpful in identifying the categories

  • Security: A password allows user to lock his app and hide details from others

  • Entry Management: This allows user to enter Data in the form of numbers because application saves data in the form of numbers(income or expence)

• Desirables

  • Backup/Restore: ability to export all entries or restore entries saved previously from a backup file

  • Budgeting: limiting the amount for a given category

We always validated each requirement by asking questions regarding each requirements until what the customer wanted was clarified.

Phase Two: Requirement Analysis

During this phase, we combined all requirements into a comprehensive list of key points and then checked for any ambiguity, issues, missing information or conflicts with other requirements. In cases where issues previously mentioned occured, we discussed these with customer during next meeting to clarify or together workout alternatives. It is vital to solve any issues before moving onto later stages.

In cases where we suspected wrong or false assumptions, we discussed with the customer to iron out any outstanding issues. For example, after our first meeting, one of our member noted that we may need to support all android versions from Android 2.2 till latest. This however stood out as our notes did not agree on this and other team members reported that this topic did not come up during meeting, but if this is required we must clarify that this will involve more complexity by introducing technical limitations and extending required implementation time. Hence we discussed with our customer during next meeting, when he reported that this is not necessary as his requirement is only support from lastest Android API(Nougat/7.x) and one version backward compatibility(Android Marshmallow/6.x).

Phase Three: Requirement Documentation

In this phase, we had a complete comprehensive idea about the requirements and we started splitting each requirement into appropriate usable tasks.

First we split each requirement into user stories.

User Stories

Following are some of the major user-stories derived from our list of requirements:

As a user:

• I want to categorize my expenses so I like to have Different categories to classify a customer, I want to categorize my expenses. So I like to have different categories to classify.

• I like to have privacy to application. So I recommend to have password

• I want to know payment method so that i can calculate the payments through different payment options.

• I want icons in application so that i can identify my categories easily.

• I want the feature ‘Delete’ because sometimes i may enter my expenditure in wrong category. So that i can enter the expenses in correct category

• I want the notes so that i can enter my expenses to which i have spent.

• I like to have graphs for my expenses so that I can track my expenditure easily.

• I want the data must recover if reinstall my application. So that I don’t want to save the data in another place.

• I like to have Budget plan so that i can spend accordingly.

We also made usecase diagrams describing how each user story fits to the overall user interaction. One example of usecase diagram showing where certain options may be available to user is shown below

user case requirements

App Name and Logo

we are naming our App conveniently as Money Tracker