Requirement Elicitation
SmartBucks is an android application that is used to save you from running out of money or hold you from falling off the ledge when you are about to be bankrupt. It is always important see the progress when we are building an application. And the very important stage in this creation is the Basic Prototype that satisfies the customer where he/she could see his product come to life. The development of the application starts only when we know what are the building blocks needed for it and here the requirements by the customer act are the fundamental building blocks for the application that we are creating. Requirements Elicitation was done by conducting interviews with the customer Dr.Sandro Schulze.
Initial Requirements
Dr.Sandro Schulz who is our customer for the android application gave us an overview of the application that he is looking forward to acquire at the end as a product. His initial requirements are as follows:
- It should be a simple application to maintain by expenses and check my savings.
- The home screen of the application must be used to display the expenses done so far and the savings that is available.
- It was also mentioned that instead of creating a user account, he opted for a password protected application since the app will be used only by a single user.
These were the basic requirements provided by Dr.Schulze.
Further Requirements
The application created can never be useful if it does not satisfy the customer and his requirements. In the process of analysing the requirements it is important as a team to understand the nuances of the application that can be a hindrance during the developmental phase of the project.
So to avoid this we asked further questions regarding the nuances of the application. The following were the requirements:
- Should we have a statistical chart display for the expenses and saving? - Yes, there should be a simple chart that represents the saving and then alerts the user when he/she goes beyond the budget.
- What are the categories do you prefer to be added in the expenses column? - The list should not be lengthy. It must contain only 5 to 6 categories such as food, leisure, travel, medicine, shopping.
- Would you like to have an additional income tab present in the income activity? - Yes, that would be helpful when someone needs to add an extra income that he/she might not have constantly. Eg. When someone sells something that extra money can be added to the additional income tab.
- How would you like to enter the numbers? A number pad is necessary or a qwerty keypad will do? - As we do not have anything to type in this application other than the numbers, it is better to have a number pad that makes the input easier for the users.
- Which options do you prefer for password protection? Either a PIN or a alphanumeric password? -It is better to have a PIN as it is easy and less time consuming.
Analysis
Based on the analysis given by the customer Dr.Schulze we all had a basic understanding of how the application must be built. With these requirements at hand we had brainstorming session on how to combine these requirements into working application that satisfies the money control objective of the user.
The provided requirements at this stage seems to be complete, unambiguous, scalable and changeable.
Each of us had different ideas on proceeding further on the workflow of the model. After long hours of discussion we have arrived on a functional workflow of the application.
So the basic prototype will be built on the following requirements.
-
The application requires the user to sign up only once when the app is installed.
-
The user has to create his account details in which the PIN , basic income and stable expenses are added.
-
The homepage of the application will display the budget and saving along with a chart that represents the expenses and the budget.
-
The user can enter the expenses in one of the 5 categories which are already mentioned in the application.
-
The numbers entered in the application will be done through a number pad.
It is important to formulate the requirements with the above requirements in mind.
The workflow of the application was discussed during the brainstorming and this is what we managed to end up with.
As you see, this by itself had the ability to turn us crazy. So to stop ourselves from misery we started implementing the “methodologies” and “terminologies” introduced to us in the lecture.
Please move on to the next blog post to know more on how we simplified the above mess to start our application development.
Source:
http://mohamedelgendy.com/blog/business-needs-vs-requirements.html