OFFICIAL BLOG ARTICLE 2: REQUIREMENTS ANALYSIS
Hey guys, this is our second official blog article and its about the requirements analysis. The main purpose of this short blog is to give you a comprehensive overview about all software-features, which will be implemented in our activity tracking application. Furthermore, we will give you a short insight in our work so far. So, lets get started with our gradually gathered user stories, describing the requirement from the users point of view:
User Stories
- As a user I want to have some brief description about my activity, so that I can recall the details of the particular category.
- As a user I want to have a start and end time for an activity, so that I can plan my activities over a period of time.
- As a user I want a activity-pie-chart, whereby I have a visual and percentage overview over the categories occupying my time in a day.
- As a user I want to have a textual overview, so that i can monitor my longterm (weak / month) activities of a category in a statistical way.
- As a user I want to have a basic security setting in my application, so that I can avoid unauthorised access to my data.
- As a user I want my categories to be assigned to different colours, so that I can distinguish them, while putting them all together.
- As a user I want to delete my history, so that I can manage my storage space and save only what I need.
Use Case Diagram
Important Questions
-
How did your team gather requirements?
We did a short survey among our team mates, where we used different activity monitoring applications such as google fit, amazon echo etc. Furthermore, by weekly interaction with the customer we listed few basic common requirements and came up with this summary. -
How did your team analyze requirements?
By the end of the last meeting with the customer we prioritised his requirements into 3 categories: Mandatory, Necessary, Desirable. Hereupon, we had team meetings every week to check the compatibility of each category. -
How did your team specify requirements?
After the regular meetings with the customer in order to specify requirements we had to be very much peculiar with the requirements. Consequently, we were able to categorize into the main screen of the application. -
How did you map requirements to user stories/use case?
After gathering the requirements from the customer we started to build the use case diagram, than we build epics which on further when discritized gave user stories that’s how we mapped requirements to user stories / use case diagram. -
How did your team identifies wrong assumptions?
In order to enable user a security pin we thought, that we might need a database but it’s just a security system related to the local storage. Moreover, we thought, that we are supposed to develop an online based application but the end product is an offline application, consequently we don’t need any server interaction. Subsequently, we assumed, that we have to build an application that synchronises with calender and works in tandem but there is no need of such synchronization.
Hopefully, you enjoyed reading our second blog article, so be excited of our next one.
Your Team myTimeTrackers