Requirements

Our project, ‘Got home safely’ have crossed the requirements analysis phase. Here you will see how the requirements were gathered, analyzed and validated.

Requirements elicitation

Team gathered requirements through the following methods:

1. Interview with the customer.
2. Questionnaire.

From the first interview with the customer, we collected as much information about the requirements as possible. Each team member had noted down this information from his own perspective. All members then converted their notes to simple one-line statements and uploaded them to our project folder.

Requirements analysis

Through focus groups, we consolidated all our notes. By going through all the statements, we identified and removed all ambiguities that were present and refined the requirements into a list of clear simple statements.

In the second interview with the customer, he was presented with our consolidated requirement statements. These were then reviewed by the customer; an additional requirement was added and a few tweaks to existing requirements were made.

At this stage we had all the requirements set and clear.

Requirements specification

You can see the final requirement statements below. This will act as our requirements specification throughout the project.

Essential Requirements:

1. App should be installed in both the user’s and the followers’ phones.
2. Notifications should be delivered via push messages on the follower’s phone.
3. User initiates the return home in the app after a party or night out just before returning home from the aforementioned activity.
4. User selects the people to be notified (followers) from contacts in the phone. (No registration for the app, user assumes that the selected contact has the app installed on their phone.)
5. To initiate a ‘return home’ user has to enter the destination and estimated time required to reach the destination.
6. Option to save destinations as favorites should be present and the history of previously enter destinations should be present.
7. When entering destination autocomplete feature should be present.
8. User settings should have the following options:
   • Specify how often the GPS position is pulled.
   • Battery level threshold below which a ‘battery saving mode’ of the app will be enabled.
   • Time threshold for not moving, above which notification will be send to followers.
   • Enable or disable SMS communication in case data connection is down.
9. When the ‘return home’ is initiated the follower should receive the notification ‘user has started the journey home.
10. When the user reaches the destination within the specified time required, followers should receive a notification that ‘user arrived home’.
11. If the user has not reached the destination within the specified time (plus a margin set by the user), followers should get a notification saying that the user has not reached home.
12. If the user is not moving for more than a set time (set in user settings), app should ask the user if everything is okay, if the user doesn’t respond within a set time, followers should receive a notification saying that user has not moved for x minutes.
13. After the ‘return home’ is initiated, user should have the option to pause or cancel it with a brief reason, which will then be notified to the followers.
14. App should have an emergency function which could be operated by a single button that is timed for 2 seconds.
15. If the emergency button is pressed and held for 2 seconds:
    • App should ask the user is there is any additional information, if yes option to add photo and text should be presented, if not:
    • All followers should be notified saying that user is in an emergency with the current location of the user, with photo and text if applicable.
16. If internet is not available to the user after ‘return home’ is initiated, app should have an option to notify the followers through SMS the following:
    • Data connection for user is down.
    • If the user reached home then that the user reached home
    • if the emergency button is pressed then that the user is in an emergency.
17. Followers should have the option to customize what notifications they receive as follows:
    • Followers will always receive arrival and emergency notifications as long as they have not unfollowed the user.
    • Follower can choose to disable notifications for delays, not moving and changes to the return home.
    • Followers should be able to unfollow a user and when unfollowed user should receive a notification that the said follower has unfollowed the user. In this case follower will no longer receive any notification.
18. Follower should have a page showing all the users who are being tracked.
19. If a user is no longer communicating, it should be displayed in the above said page by using color and a notification saying ‘communication down for user’.
20. Ideally the App should be used only for short trips i.e. within a city or town.
21. App should be backward compatible till android 7.0.
22. App requires several permissions from the user like accessing to contact, location access, etc. Then app should be able to handle failure cases when certain permission is not given.
23. A follower might be following more than one user.

Optional features:

1. Live tracking for select followers, whom can be selected by the user.
2. Automatic calculation of time required to reach the destination.

User Stories

From the requirements, we created user stories, making sure that each story fulfills a requirement statement or a part of it. From these, themes were identified and stories were mapped accordingly. Stories were then classified into essential and optional features.

In each theme, user stories are arranged according to their priority, with top story being the highest priority and bottom one being the lowest priority.

We have used the following terminology in our user stories:

• User: Who is using the app to notify his peer(s) that he/she got home safely.
• Follower: Who gets notified about the user’s journey home.
• Return home: The journey of the user to his destination (home) with the app initiated.
• Outing: The activity from which the user is returning home.

In the user story map below, you can see that each story has an identifier in brackets, which links it to one of the requirement statements. The estimated time required to implement each story is given inside square brackets.

Use case diagram

The following use case diagram illustrates the core features of the return home function.

Requirements Validation

In the third meeting with the customer, we presented our final requirement statements and user stories. The Customer approved the requirement statements and user stories stating that it matches all his requirements.

Wrong Assumptions

• We had wrongly assumed that the app should support long distance journeys, but from the requirements elicitation, it was clear from the customer that this is not what the app is intended for and the app should not explicitly support long distance journeys.
• Another assumption that we had was that the user initiates the app when he/she leaves for a night out or party. This was proved wrong by the customer as he wants the user to initiate the app just before he/she is returning home from a party or night out.

Estimated time required

Estimated time for the whole project ≈ 200 hours.

We estimated the time it will take to complete each user story through meetings and understanding the amount of technical work required for each user story. We have also considered the team velocity factor as 0.7. (which covers team productivity, unexpected delays, holidays, etc.) After few sprints we will adjust our velocity factor based on previous sprint’s burndown charts.

Moving Forward

With the first milestone of the project complete, we will be moving forward to the system design phase.

See you in the next blog!