Once we have established our team up and running, the next procedure is to set up goals. The goals with respect to the Android app was to ask our customer (Dr. Sandro Schulze). For this, we arranged our first official meeting and noted down his requirements.
There are five phases of Requirements Analysis
- Requirements Elicitation: Discussing with customer and concerned members to gather requirements
- Requirements Formulation: Comprehend the ideas and develop a rough blueprint
- Requirements Analysis: Case study of requirements for conflicts/issues/ambiguity which are then overcome
- Requirements Validation: Check the consistency and realistic approach with respect to budget and technology
- Requirements Management: Clear cut materializing the requirements into compatible forms for easier access
Phase one : Reqirements Elicitation
Essential Requirements
- Activity summary
- Monitor activities
- Add or delete activity
- Analyse time spent on each activity
- Categorize activities
- Filter activities
- PIN authentication
Necessary Requirements
- Color code categories
- Add activity description
- Define core day
- Include main category as Public/Private
- Graphical view
- Repeating activities
- Weekly email update
Desirable Requirements
- Export the data
- Reminder for activities
- Share to social networks
Phase two : Requirements Formulation
To understand the requirements of our customer, the team arranged and met at regular intervals. We analysed the requirements and made calculations to followup. Time constraint - ability to complete and submit the app to our customer within the agreed time was our first priority. Feasibility with respect to application features and the team’s skillset was also taken into consideration. We made sure that we were properly equipped to complete the app.
Phase three : Requirements Analysis
Requirements are part of the developer perspective. However, User stories are part of the end user perspective. A typical User story denotes why an User would download/use the app for.
User stories
-
As an User I would like to monitor my activites
-
As an User I would want to analyse the time spent on each activity
-
As an User I should be able to add or delete activites as I wish
-
As an User I might ask to view the activites as a graphical representation
-
As an User I could categorize the activites into different types
-
As an User I would like to view the activites as a formal summary
-
As an User I might filter the activities based on its types
-
As an User I need safety over my account and data
-
As an User I could add a brief description for each activity
-
As an User I could color the categories depending on its type
-
As an User I would want to receive weekly updates over emails
-
As an User I should be able to export the data for other apps/later use
-
As an User I shall connect to social accounts to share with friends/family
-
As an User I might like to get reminded of my frequent activities
Use Case Diagram
The above figure denotes a typical use case diagram. When an user ‘adds a new activity’, the ‘include’ command is invoked which takes into consideration another interdependant activity ‘add activity details’. Similarly if an user ‘reviews the data’, the ‘extend’ is invoked which means its not necessary that the user ‘shares the data’.
Phase four : Requirements Validation
To validate the application requirements, we created a rough outline of the various requirements. Next we downloaded other similar mobile applications that served the same purpose. Then we compared our requirements to the facilities provided by other apps. This helped us to understand the practical way to follow. This also gave us a realistic approach.
Phase five : Requirements Management
This blog and this page in particular would serve as the documentation of the various requirement stages of our mobile application.
Wrong Assumptions
As with every story, our requirement phases too suffered from misconceptions. Our customer’s requests were wrongly understood by us and below are some of the few -
Requirement levels -
First major hurdle that we had to overcome was understanding the different requirements and where they would fit. There were few requirements that confused us with categorizing it under Essential or Necessary or Desirable levels.
Requirements versus User stories -
Next point to be understood was the different perspectives related to the application. Requirements were from a developer perspective and they had to be gathered and analysed as such, whereas User stories were from a basic user perspective.
Calendar feature -
We requested our customer if a calendar facility could be appended within the app. A calender with day-to-day summary would give the user an option to add events. However, our customer cleared us on the concept that adding a calendar option would rob the approach of a activity monitoring app and diverse the intention of the app towards an event managing application.
Sources:
- 1> http://www.problab.com/hire-android-app-developer
- 2> https://www.questionpro.com/blog/pt-br/como-o-marketing-pode-transformar-sua-empresa/
- 3> https://thetechladder.com/story/the-difference-between-manual-automated-testing/the-difference-between-manual-amp-automated-testing/
- 4> https://www.viftech.com/android-development/