Politecnico di Milano AA 2017-2018

Software Engineering 2 Project

TRAVLENDAR + 

RASD
Requirement Analysis and Specification Document
Version 1.1 - 07/01/2018

Submitted by
Manasjyoti Bhuyan - 893800
Arnab Dey - 893291
Poornima Jagannathan- 897800

1
Contents
1. INTRODUCTION​ …………….………………………………………………………………………………. 4
1.1 PURPOSE …………………………………………………………………………………………………………………. 4
1.2 SCOPE ……………………………………………………………………………………………………………………… 4
1.3 CURRENT SYSTEM ………………………………………………………………………………………………….. 4
1.4 ACTORS ………………………………………………………………………………………………........................ 4
1.5 GOALS ……………………………………………………………………………………………………………………… 5
1.6 GLOSSARY ……………………………………………………………………………………………………………….. 7

2. OVERALL DESCRIPTION …………………………………………………………………..…… 8

2.1 ASSUMPTIONS ………………………………………………………………………………………………………… 8
2.1.1 USER ………………………………………………………………………………………………………………… 8
2.1.2 DATA CHECKING SYSTEM ………………………………………………………………………………… 8
2.1.3 SYSTEM MANAGER …………………………………………………………………………………………… 8
2.1.4 OTHERS …………………………………………………………………………………………………………….. 8

3. SPECIFIC REQUIREMENTS ………………………………………………………………..…. 9

3.1 REQUIREMENTS ……………………………………………………………………………………………………. 9
3.2 EXTERNAL INTERFACE REQUIREMENTS ………………………………………………………………. 11
3.2.1 USER INTERFACE ……………............................................................................................ 11
3.3 SCENARIOS ……………………………………………………………………………………………………………… 16
3.3.1 SCENARIO 1: REGISTRATION ……………………………………………………………………………. 16
3.3.2 SCENARIO 2: LOGIN ………………………………………………………………………………………….. 16
3.3.3 SCENARIO 3: ADD EVENTS ……………………………………………………………………………….. 16
3.3.4 SCENARIO 4: MODIFY EVENTS …………………………………………………………………………. 16
3.3.5 SCENARIO 5: NOTIFICATION AND DIRECTION OF THE UPCOMING EVENT …….. 16
3.3.6 SCENARIO 6: GUIDANCE WITH TRANSPORTATION …………………………………………. 16
3.3.7 SCENARIO 7: WEATHER FORECAST AND STRIKE DAY……………………………………… 17
3.4 UML MODELS ………………………………………………………………………………………………………….. 18
3.4.1 USE CASE MODEL ……………………………………………………………………………………………… 18
3.4.1.1 REGISTER AN ACCOUNT ………………………………………………………………………. 18
3.4.1.2 LOGIN …………………………………………………………………………………………………… 19
3.4.1.3 EVENTS REGISTRATION ………………………………………………………………………. 20
3.4.1.4 TRANSPORTATION MODE ……………………………………………………………………. 21
3.4.2 USE CASE DIAGRAM ………………………………………………………………………………………….. 22
3.4.2.1 USER …………………………………………………………………………………………………….. 22
3.4.2.2 SYSTEM ………………………………………………………………………………………………... 23

2
 3.4.3 CLASS DIAGRAM ………………………………………………………………………………………………… 24

3.4.4 STATE CHART DIAGRAM …………………………………………………………………………………….. 25

3.4.4.1 EVENT PHASE …………………………………………………………………………………………………. 25

3.4.4.2 USER PHASE …………………………………………………………………………………………………… 25

3.4.5 ACTIVITY DIAGRAMS ………………………………………………………………………………………….. 26

3.4.5.1 REGISTRATION AND LOGIN PHASE ……………………………………………………… 26
3.4.5.2 EVENT PHASE ………………………………………………………………………………………… 27
3.4.5.3 TRANSPORTATION PHASE ……………………………………………………………………. 28

3.4.6 SEQUENCE DIAGRAM …………………………………………………………………………………………. 29

3.4.6.1 REGISRTATION PHASE …………………………………………………………………………. 29
3.4.6.2 LOGIN PHASE ………………………………………………………………………………………… 30
3.4.6.3 EVENT REGISTRAION AND SCHEDULING PHASE ………………………………… 31
3.4.6.4 TRANSPORTATION AND GUIDANCE PHASE …………………………………………… 32

3.5 ALLOY MODELS …………………………………………………………………………………………………………. 33

3.5.1 REGISTRATION AND LOGIN MODEL ……………………………………………………………………. 33
3.5.1.1 DATATYPE DEFINITION …………………………………………………………………………. 33
3.5.1.2 SIGNATURES …………………………………………………………………………………………… 34
3.5.1.3 FACTS ……………………………………………………………………………………………………… 35
3.5.1.4 PREDICATES ……………………………………………………………………………………………. 36
3.5.1.5 ASSERTIONS ……………………………………………………………………………………………. 37
3.5.1.6 RESULTS …………………………………………………………………………………………………. 38
3.5.1.7 GENERATED WORLD ………………………………………………………………………………. 39

3.5.2 EVENT MODEL

3.5.2.1 DATATYPE DEFINITION ………………………………………………………………………….. 40
3.5.2.2 SIGNATURES …………………………………………………………………………………………… 41
3.5.2.3 FACTS ……………………………………………………………………………………………………… 44
3.5.2.4 PREDICATES …………………………………………………………………………………………… 45
3.5.2.5 ASSERTIONS …………………………………………………………………………………………… 46
3.5.2.6 RESULTS …………………………………………………………………………………………………. 47
3.5.2.7 GENERATED WORLD ………………………………………………………………………………. 48
4. TOOLS USED ……………………………...……………………………………………………………. 49
5. HOURS OF WORK ……………………………………………………………………………………. 50

3
 
1. ​Introduction 

1.1. Purpose
This document represents the Requirement Analysis and Specification Document
(RASD). Goals of this document are to completely describe the system of an application
in terms of functional and nonfunctional requirements.

This document has a detailed analysis about the domain of the system, goals,
assumptions, and then requirement themselves, which is followed by a graphic
representation of all these through ‘Use Cases diagram’, ‘Class diagram’, ‘State Charts
diagram’ and ‘Sequence Diagram’ and finally the! model! verification! through Alloy.

We will also analyze the real needs of the customer in order to model the system, show
the constraints and the limit of the application and indicate the typical use cases that
will occur after the release of the software. This document is inscription to the software
developers who have to implement or execute the requirements and bring it out as a
real-world application.

1.2. Scope

Description of the given problem

Travlendar+ is a day-to-day life event management mobile application software. The

system allows Users to manage his everyday schedule by adding his day to day events in
daily/weekly/monthly basis or by registering his e-mail id and by allowing access to his
phone SMS.

The mobile app helps the user by giving prior notification of the daily events along with
guiding him/her with the event’s destination routes, durations. The user can accept or
reject an event and also, he can edit the events if he/she wants. The app automatically
identifies the user’s position and guide him/her with the nearby modes of available
transportations and ticket counters. It also provides them with the weather forecast.

The main purpose of the system is to assist the users in their daily meetings and events.

4
1.3 Current System

Travlendar+ is totally a new system. So, it is required to create the whole system.

1.4 Actors

● User:​ a registered user can access all the system functionalities after login.

● App:​ the app consists of many features like getting prior event notifications,
guiding user with transportations, ticket reservation, weather forecast, etc.

● Data Checking System:​ this module checks user’s data to validate registration.

● System Manager: ​this manages the events including overlaps, along with
guidance to transportations, directions, duration and redirection to other
third-party apps (tickets bookings, shared car/bikes)

1.5 Goals

● [G1] Allows a user to register and become a Registered User after providing
Credential.

● [G2] Allows a user to create/edit events

[2.1] Create events in daily, weekly or monthly basis.

[2.2] Create events by accessing the user’s e-mail id and phone SMS.
[2.3] Modify or delete less important events

● [G3] Allow user to select preferred mode of transportation options among the
available options.

● [G4] System will Schedule the timings for the appointments with
destinations and other details.

● [G5] System will find the overlaps for a day and choose the events provided
by the user and ask the user in the morning which are the events from the
overlaps they want to attend.

5
● [G6] System will notify the user 30 mins before every event.

● [G7] At the same time the application will access the user's current location
and
calculate the distance, travel time, mobility option. according to that application
will show most efficient option and other options also.
● [G8] Mode of transportations

[8.1] Allows user to find the different types of pre-selected mode of

transportations.
[8.2] Locate user’s current location and find him/her the available mode of
transportations with a certain radius.

● [G9] Suggest the travel means to the user depending upon the location and
distance of appointment from current location i.e., the app suggests the users
either to go for a car, a bike or a bus.

● [G10] Guidance in providing the tickets.

[10.1] Public transportation tickets (either use metro card (day/week/season

pass) /bus/ tram ticket)
[10.2] Redirects to online ticket booking or vehicle reservation sites.

● [G11] The app gives Warning Notification to the user for the meetings that
are
created at locations that are unreachable in the allotted time by any mode of
transport.

● [G12] It provides suggestion to the user –

[12.1] Consider the car in the morning because strike day will not be doable
via public transportation.
[12.2] Forecast the weather and suggest avoiding biking during the rainy
or snowy days.

● [G13] The app also provides user with an addition feature: Allocation of
lunch
break for 30 minutes between 1130 to 1430 hours.

6
1.6 Glossary

1. Account: It is a record into the system that identifies each user and contains all
his/her personal credentials.
2. Registration phase: ​This is a procedure that starts with a new user that sends
the required data and ends on receiving userID and a password back from the
system that can be used to login into the application to and access all the
functionalities.
3. User: ​Any person who, has completed of the registration phase and has received
back the userID and password from the system and is able to login and have
access to all the system functionalities.
4. Login: ​It is the procedure with which a user (already registered), by inserting
his/her userID and password, can accesses into the system in order to use all the
provide functionalities.
5. Events: ​These are the entities (meetings, works, etc.) of the user’s schedule that
the user adds into the system, so that he/she can manage his/her every work or
meeting or job’s time in a smooth way.
6. Transportation-guidance: ​This is a function of the application, that helps the
user by providing the details of the nearby transportations available to the
destination event. It also guides the user in reserving tickets.
7. Data Checking system: ​This is the system that checks the validity and
completeness of the user’s data. The feedback is positive if and only if the inserted
data are completed with respect to the required ones.
8. System manager: ​This module helps the user by managing the events, along
with guidance to transportations, directions, duration and redirection to other
third-party apps (tickets bookings, shared car/bikes).

7
2​. ​Overall Description
2.1. Assumptions
2.1.1. User:
For the registration phase the user will have provide information regarding:
• Personal data (i.e. name, e-mail id, phone number)
• Permanent locations (i.e. home location and work location)
• Transport preference (i.e. public transport, car and bike (own/shared))
• Allow access to his/her phone SMS.
• Select his/her break time

2.1.2 Data checking system

This is a third-party system that checks whether the data inputs given by the user during
the registration process is valid or not. Validation is done mainly for the e-mail id and
the phone number provided by the user.
It is supposed to check the data in at most 5 seconds from data’s reception.

2.1.3 System Manager

This manages the events, along with guidance to transportations, directions, duration
and redirection to other third-party apps (tickets bookings, shared car/bikes)

2.1.4 Others
Once the user has the set the transportation preference is set by the user, it can be
changed anytime from the app settings.

8
3. Specific Requirements
​3.1 Requirements
​Requirements are divided into functional and non-functional

[R01f] The system should allow the users to insert all the data required for the
registration.

[R02f] System should allow the user to enter the important location’s address like
home
and work (not mandatory).

[R03f] The data inserted by the user should be checked by the data checking system.
If
The data are correct then the system will send the password to the user’s provided
email
Id. Else the system will notify the wrong field.

[R04f] The system should allow the user to insert the credentials (email and
password)
and check the inserted login credentials (in the database) in order to allow the user to
access the system functionalities.

[R05f] System should ask for permission to access email and phone SMS.

[R06f] System should ask for permission to access the user’s location through GPS.

[R07f] System should allow users to select the event insertion mode
(i.e. day/month/year)

[R08f] System should allow users to select their preferred mode of transports (i.e.
walking, driving (own/shared), biking (own/shared), or public transports)

[R09f] ​System should allow to select events importance from 1 to 5 (1 refers to the
most
Important one). Importance will show by colors.

9
 [R010f] System should schedule the timings for the appointments with destinations
and other details.

[R11f]​ ​System should find the overlaps of the events for a day and ask the user to
choose the important events out of the overlaps in the morning.

[R12f] System should notify the user 30 mins before every event.

[R13f] Subsequently the system should access the user's current location and
calculate
the distance, travel time, mobility option for that event. According to that application
should show most efficient option and along with the other options.

[R14f] The system should provide guidance with transports ticketing/booking system
as follows:

● Public transportation tickets (nearest ticket counter or online booking site)

● Redirect to shared car or bike reservation apps.

[R15f] The system should prompt the user for the lunch time for 30 minutes each
day (between 1130 – 1430 hours)

[R16f] System should provide warning messages for:

● Meetings that are created at locations that are unreachable in the allotted
time in any mode of transport.
● Suggest the travel means depending on the appointment i.e., suggest the
users either for car/bike/bus.

[R17f] System should provide notification for some uncertain situations:

● Consider the car in the morning because strike day will not be doable via
public transportation.
● Forecast the weather and ask the user to avoid biking during the rainy/snowy
days.

10
3.2 External interface requirements

3.2.1 User interfaces

Here we present a set of mockups that represents the interface provided to the user on
mobile application.

● Registration: This mockup shows the interface the user must interact with
during the registration phase by mobile app.

11
● Login​: ​This mockup shows the interface that the user has to interact with after
the registration phase.

12
 ● Setup​:

The user will be redirected to the setting, where he/she may allow access to his
location, email, SMS and notification sound.

This is the interface where the user has to setup his ‘Home’ and ‘Work’ address/location
along with his transportation preferences. He/she can also set his break time.

13
● Add events​: ​In this interface the user can add events in basis of
day/week/month.

● Notification​: ​In this interface the user will get notification for the upcoming
events along with the events’ priority as set by the user.

14
● Direction/Suggestion​: ​This mockup interface will guide the user with
direction to the upcoming event. It will display various mode of transportations
available nearby the user and also suggest the best and quickest transport option
to the destination.

In this interface the user is guided to the nearest ticket booking counters or
online booking systems.

15
3.3 Scenarios
3.3.1 ​Scenario 1: Registration
Mr. X is a business man, and he has to attend a lot a meeting and has to visit various
events in his daily life. There is high chance that he may miss or left out few meeting or
events, which may become a trouble for him. So, in order to maintain his daily schedule,
to get reminded for his upcoming meeting and schedule and to reach those on time he
needs some app in his smartphone. And that leads him to register an account on the
Travlendar+. For this, he must install the app and then will be asked to fill in the
registration form, where he has to provide his email-id and personal data (first name,
last name, phone number and password).

​3.3.2 ​Scenario 2: Login

Now, Mr. X open the app and logged in providing email and password. There he has to
give the app to access his location, email, phone SMS, notification. Next, he will provide
his ‘Home’ and ‘Work’ location. Then he will setup his transportation preferences and
his break time.

​3.3.3 ​Scenario 3: Add Events

After the completion of this setup, Mr. X can add his upcoming events in daily, weekly
or monthly basis. The events will also be added from his email and phone SMS by the
system automatically.
3.3.4 Scenario 4: Modify Events
After the addition of the events, the app system manager will notify Mr. X with the
overlapping event for that day. Mr. X now can choose the important events from the
overlaps. He can also delete some events (not overlapped ones) if those are not
important for him.
3.3.5 Scenario 5: Notification and direction to the upcoming event
Everything are set. Now Mr. X gets notification of his very next upcoming event 30
mins prior to the event’s starting time. The app shows Mr. X the distance and direction
from his current location to the event (destination) and also the time required to reach
the destination.
3.3.6 Scenario 6: Guidance with transportation

16
The app is then showing him the nearby available mode of transportation (Mr. X’s
preferred) to the destination so that he can attend the event on time. Mr. X can also see
an option ‘Tickets reservation’. This option leads him to ‘Ticket counter’ and ‘Online
reservation’. ‘Ticket counter’ will lead Mr. X to the nearby ticket counter and ‘Online
reservation’ will to some third-party ticket reservation apps.
Mr. X chose ‘‘Ticket counter’ and the app is guiding to the nearest ticket reservation
counter within a radius of 1 km.
3.3.7 Scenario 7: Weather forecast and Strike day
Meanwhile, the app also gets the weather forecast of the day. So, if it is going to rain,
then the system will suggest Mr. X not to use bike.
The app will acquire the details if there is going to a strike day. In this case, Mr. X is
getting a suggestion notification that he has to take his own car, bike, etc. to the
upcoming events.

17
3.4 UML Models
3.4.1 Use case model
3.4.1.1 Register an account

USE CASE NAME:

● Register an account
PARTICIPATING ACTORS:
● User
● Data checking system
FLOW OF EVENTS:
● Entry condition: The User open the app and goes to the signup page.
● The user inserts all the required data.
● The user also inputs to his/her email id and phone.
● The Data checking system verifies the details.
● Notification of successful registration.
EXCEPTIONS:
● If the email-id and phone number is found to be invalid by the data checking
system, the signup process fails. Then the user is requested to modify the wrong
fields
SPECIAL REQUIREMENTS:
● Option available on the mobile application.

18
3.4.1.2 Login
USE CASE NAME:
● Login
PARTICIPATING ACTORS:
● User
FLOW OF EVENTS:
● Entry condition: The User (one who has already registered) goes to the login
page.
● The user allows access to his/her email and phone SMS.
● The user also allows access to ‘location’ and ‘notification’.
EXCEPTIONS:
● If the user does not allow access to ‘email id’ and ‘location’ then a ‘recommended’
notification pops up
SPECIAL REQUIREMENTS:
● Login option available on the mobile application.

19
3.4.1.3 Events Registration
USE CASE NAME:
● Event register
PARTICIPATING ACTORS:
● User
● System Manager
FLOW OF EVENTS:
● Entry condition: a user, once logged-in, opens the calendar.
● The user adds all his upcoming events either in daily, weekly or monthly basis.
● Events are also imported from user’s e-mail id and phone SMS.
● The user can also modify, edit or delete events.
● The user can add a break between 1130 to 1430 hours.
EXCEPTIONS:
● If there is any overlaps with the events, a notification will pop up asking user to
select the important ones.
SPECIAL REQUIREMENTS:
● Page available on the mobile application.

20
3.4.1.4 Transportation mode
USE CASE NAME:
● Mode of transport
PARTICIPATING ACTORS:
● User
FLOW OF EVENTS:
● Entry condition: The user can find the various available mode of transports
available nearby him/her (user’s preferred).
● The system displays and guide the user to the nearest ticket counters.
● The system also redirects the user to other third part online ticket booking apps
or websites.
EXCEPTIONS:
● Shows no bikes in a rainy weather.
SPECIAL REQUIREMENTS:
• Page available on the mobile application.

21
3.4.2 Use case diagram
3.4.2.1 User use case diagram

22
3.4.2.2 System use case diagram

23
3.4.3 Class diagram

24
3.4.4 State Chart diagram
​3.4.4.1 Event phase

​3.4.4.2 User phase

25
3.4.5 Activity Diagrams
3.4.5.1 Registration and Login phase

26
3.4.5.2 Event phase

27
3.4.5.3 Transportation phase

28
3.4.6 Sequence Diagrams
3.4.6.2 Registration phase

29
​3.4.6.2 Login phase

30
3.4.6.3 Event Registration and Scheduling phase

31
3.4.6.4 Transportation and Guidance phase

32
3.5 Alloy Models
The alloy models that are mentioned below are available in GitHub
repository as (.als) files. The alloy models are divided into ‘Registration and
login’ , ‘Events’, ‘Transportation’
3.5.1. Registration and Login model
3.5.1 .1 Datatype Definition

33
3.5.1 .2 Signatures

34
3.5.1.3 Facts

35
3.5.1.4 Predicates

36
3.5.1.5 Assertions

37
 3.5.1.6 Result

This is the result of the given Alloy Analyzer about the consistency of this part of
the model.

38
 3.5.1.7 Generate World
This is the generated world given by the Alloy Analyzer

39
3.5.2. Event Management model
3.5.2 .1 Datatype Definition

40
​3.5.2 .2 Signatures

41
42
3.5.2.3 Facts

43
3.5.2.4 Predicates

44
​3.5.2.5 Assertions

45
​3.5.2.6 Result

46
47
3.5.2.7 Generated World
This is the generated world given by the Alloy Analyzer

48
4. Tools used:
● Microsoft word​: for document redaction
● Alloy analyzer​: for model consistency analysis
● Visual Paradigm​: for the sequence diagram realization
● Draw.io​: for use case diagram, UML, state-chart and class diagram
● Gimp​: for some image modification
● Pencil​: for mockup realization
● Microsoft Excel​: for hours counting

49
6. Hours of Work

50