Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
3.4.3 CLASS DIAGRAM ………………………………………………………………………………………………… 24
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
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.
● [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
● [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.
● [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.
[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.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:
[R15f] The system should prompt the user for the lunch time for 30 minutes each
day (between 1130 – 1430 hours)
● 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.
● 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
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).
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
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
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