REQUIREMENTS

Requirements

We got our requirements in the first meeting with the customer and the requirements were further analyzed and user stories and use case diagram was prepared and validation of those where done in the third meeting with the customer. This blog is about the requirements and wrong assumptions, in deep requirements is divided into following.

Requirements gathering :

Our team gathered the requirements in the meetings with the customer , we interviewed the customer and even gave some requirement ideas. From the meetings with customer we got lot of requirements from the customer and each member has noted them down so that everyone can figure out what are the requirements and work effectively in analyzing the requirements.

Figure1 [1]

Requirements analysis :

The requirements given by the customer were consolidated at this stage, the requirements noted down were being checked for errors and ambiguities and corrected according to the needs of the customer. All requirements were noted down in a systematic order in simple understandable manner. Then the user stories were prepared by all the team members This was all done after the first meeting.

In the second meeting the we presented the user stories to the customer. These were checked by the customer and the customer added more requirements and with this the requirements gathering and analysis stage was done successfully.

Figure2. [2]

Requirements specification :

The requirements given by the user were consolidated and divided into two categories as follows

1.Essential Requirements

2.Optional Requirements.

Figure3. [3]

Essential Requirements:

• The user should see date and payment method for every transaction.

• The user should see what money was spent on.

• The user should categorize his/her spending.

• The user should edit transactions like mistaken entry, returns etc.

• The user will compare two or more time periods (I.e. weeks, months etc).

• The user will see the output in graphical format in a more interesting way.

• The user should be provided with predefined categories so that his time is saved.

• User should be able to set pin and password to protect personal data.

• User should have a budget finances for every month and track how much is left.

• User should be able to search transactions by categories, payment method, date ranges, and different boundary conditions.

• User should be able to set automatic payment for recurring transactions.

• User should be able to set the payment as recurring payment.

• The user should be able to view and change the currency.

• The user should get the notification of extended budget.

Optional Requirements:

• The user should be able to use the application with minimum knowledge of technology.

• The user should get reminders for monthly or weekly bill payments.

• The user should receive a notification after the automatic payments.

• The user should be able to save his cards, payment method I application.

User stories :

The user stories were created from the requirements to identify the essential and optional requirements. And the user stories cover all the requirements and all the requirements are shown in following way.

The user stories are divided according to the priority in the following representation. In the user stories the customer is the user to manage the flow of money using our application.

Table 1

Requirements Validation :

The consolidated requirements, that are the final requirements, user stories and use case diagrams were presented to the customer in the third meeting, after going through them the customer approved the final requirements and the use case diagrams.

Figure4. [4]

Use case diagram :

The use case diagram was prepared according to the requirements needed and the functions to be done by the application. Figure5. [5]

Wrong Assumptions :

• We assumed that the recurring transactions should be automatically detected by the application and be marked as the recurring transaction but according to requirements there should be option to every transaction to make it as a recurring transaction.

• We also assumed that the data given by the user should be stored in an external data base, but but after meeting with customer we got to know that it should be stored in the device which the application is installed.

Estimated time required :

We roughly estimated time needed by considering the customer requirements, list of the activities we identified in the order in which they need to happen. We would required around approximately 200 hours. But that is only an estimation and may vary slightly .

That’s all for this blog , the next blog will be about the System Design

Resources

[1] - https://www.cleo.com/blog/requirements-gathering-for-integration-projects/

[2] - https://www.invisionapp.com/design-defined/user-stories/

[3] - http://www.nexvistech.com/our-services/requirement-analysis/

[4] - https://www.shortformapps.com/new-jeresy-auto-loans/poor-credit-auto-loan-approval-in-lakewood-nj/