Software Requirement

Specification
SRS

Cloud Based Maps

Technical Document
 Cloud Based Maps

Table of Contents
Table of Contents .......................................................................................................................... ii
1. Introduction ..............................................................................................................................1
1.1 Purpose ........................................................................................................................................ 1
1.2 Product......................................................................................................................................... 1
1.4 Intended Audience And Reading Suggestion .............................................................................. 2
1.4 Defnitions, acronyms and abbrevation ........................................................................................ 3
1.5 Project Scope ............................................................................................................................... 4
1.6 Objective(s)/Aim(s)/Target(s) ..................................................................................................... 4
1.7 Nature of End Product ................................................................................................................. 5
1.8 Document Convention ................................................................................................................. 5

2. Overall Description ..................................................................................................................6

2.1 Product Perspective .................................................................................................................... 6
2.1.1 Components ofApp………………………………………………………….…8
2.2 Product Features .......................................................................................................................... 9
2.2.1 Developer Portal...............................................................................................…...9
2.2.2 Hardware Host Device………………………………………………………...…10
2.2.3 Data Flow Diagram……….…………………………………………………...…11
2.3 Operating Environment ............................................................................................................. 12
2.4 User Classes and Characteristics ............................................................................................... 12
2.5 Design and Implementation Constraints.................................................................................... 12
2.4.1 Design Constraints...……………………………………………………………..12
2.6 User Documentations ................................................................................................................ 14
2.7 Assumptions and Dependencies ................................................................................................ 15

3. Product Features / Functional Requirements .....................................................................16

3.1 Use-Cases Diagram .................................................................................................................. 16
3.1 Use-Cases Description .............................................................................................................. 18
3.2 Analysis and Modeling of Requirements .................................................................................. 33

4. Technical Architecture ..........................................................................................................37

4.1 Application and Data Architecture ............................................................................................ 37
4.2 User Interfaces ........................................................................................................................... 38
4.3 Data Requirements .................................................................................................................... 38
4.4 Data Refresh Rate ...................................................................................................................... 39
4.5 Creation of map ......................................................................................................................... 39

5. Other Nonfunctional Requirements .....................................................................................40

5.1 Performance Requirements........................................................................................................ 40

Technical Document SRS Page ii

 Cloud Based Maps

1. Introduction
This section gives a scope description and overview of everything included in this SRS

document. Also, the purpose for this document is described and a list of abbreviations and definitions

is provided.

1.1 Purpose
Our purpose is to develop a “Tom Tom Navigation app”. It's basically a platform which is

developed an application for users to create high definition cloud based maps using Apache Spark for

the purpose of feeding detailed location data to in-vehicle smart phones get attach with the vehicle.

The user will be facilitating by many feature with this app. User can select his source and destination

the app before journey and then the high definition cloud based maps will be created according to it.

The map shows the all possible paths from source to destination and also highlights the shortest path as

well. The app will also detect the traffic and road blocks in certain paths and calculate the

approximately time cost for the user to reach from source to destination. During journey the map

clearly identify and show the road lanes, guardrail, ditch, trees, land marks, hazard zone, detour roads

and all other objects.

This document is intended for the developers of this software which will be further use for the

other phases i.e. designing, coding, testing and deployment etc.

1.2 Product
Our product is “TomTom Navigation app”, which will be specifically developed for the smart

phones to get attach it with vehicles. The app will create high definition maps based on the location of

Technical Document SRS Page 1

 Cloud Based Maps

the user. The app will use the GPS sensor to detect the location of the user by which it can also detect

the current location. The App needs both Internet and GPS connection to fetch and display results. All

app information is maintained in a database, which is located on a web-server. The app will facilitate

the users by offline when the internet is not available.

The app also interacts with the GPS-Navigator software which is required to be an already

installed app on the user’s mobile phone app. By using the GPS-Navigator, users can view the map and

be navigated to them. The approximately time will be calculated from the source to destination for all

possible paths. The shortest path will be discovered by the AI module with Dijkstra’s algorithm. This

algorithm works as by comparing all shortest path-cost of all certain points in the path.

The traffic of vehicles on specific path will be detected by the inductive loop detector in which

electronics unit contains the tuning network oscillator. The number of counts of vehicles and certain

objects with their movement will be analyzed and detected. The Lidar sensor will be used for the

detection of the objects during the travelling of the user by the app. The app will show the clear objects

detected by the Lidar sensor.

1.3 Intended Audience and Reading Suggestions

This document is intended for the developers and designers which will develop the High

definition cloud based maps as per the requirements specified in the document.

This document includes the scope of this product. That why we need this app? What is the

purpose is to develop this product? In this document, we mention the features of this product,

functional and non-functional requirements and the environment under which we have to work and

also mention what we have learned during working on this project, different use cases, interfaces, our

Technical Document SRS Page 2

 Cloud Based Maps

objectives which have to be achieved after the completion of this project, challenges we face in order

to complete our product. Last but not least our completeness criteria.

Now, how we are able to complete this document developers gather all requirements in from of

documentation and then they develop this product. The project manager will control the entire project

including his all partners working on this product. Marketing staff advertise this product that how

beneficial this product is and about the ease of product.

1.4 Definitions, acronyms, and abbreviations

Term Definition

User Someone who interacts with the app

GPS Global Positioning App

An installed software on mobile phone which could

provide GPS connection and data, show locations on
GPS-Navigator
map and find paths from current position to defined
destination

AI Artificial Intelligence

Dijkstra's algorithm is an algorithm for finding the

Dijkstra’s Algorithm
shortest paths between nodes in a path.

Inductive Loop Detector Which detects the number of counts of vehicles

Lidar sensors That detects the objects

Technical Document SRS Page 3

 Cloud Based Maps

1.5 Project Scope

The app is developed by the team of Engineers which have the knowledge of hardware,

software, database and graphic engineering. Each module of the app will be developed individually

and merge in the end. The Quality assurance team will determine the functionality and feature of the

apps and find out the bugs, errors and all other flaws that can be produced in future use of the app in

any case. The app will be deployed in the vehicles and smart phones as well. All users having vehicle

can be facilitate with this app.

1.6 Objective(s)/Aim(s)/Target(s)

Following are the objectives we want to achieve:

 Design a simple and interactive graphical interface of the app

 Design and development of maps which will be detected by the GPS sensor

 Implementation of Artificial Intelligence training of Dijkstra’s Algorithm to find out the

shortest path

 Implementation of paths finder from source to destination in map

 Implementation of Inductive loop detector

 Implementation of the Lidar sensors

 Implementation for the calculation of the estimate time cost of paths

 Implementation of databases to store the user’s history of previous locations

 Design and implementation of high display maps on Apache Spark

 Implementation of API’s

 Performance Testing

Technical Document SRS Page 4

 Cloud Based Maps

 Quality testing

1.7 Nature of End Product

The end product will be an app which will be developed for android and iOS platform.

1.8 Document Conventions

The document conventions are as follows:

Font style and Size

o Headings: Times New Roman (18).

o Sub-headings: Times New Roman (14).

o Text: Times New Roman (12).

o Line Spacing 2.0

Technical Document SRS Page 5

 Cloud Based Maps

2 Overall Description
In this portion, product perspective, product features, operating environment, design

constraints, assumptions and dependencies will be explained in detail.

2.1 Product Perspective

Our product is dependent on the GPS sensor, Inductive loop detector, Lidar sensor and internet

to work fully functionally.

 App Interfaces

o High definition graphic display

o App API’s

● Hardware Interfaces

The backend will be agnostic to the exact nature of the hardware it is running on, so long as the

hardware provides at least 8 GB of RAM, 500 GB of disk space and a multicore 2.0 GHz or faster

x8664 processor. To use this app on smart phone then the user should have a smart phone with Internet

data connection on. The user should have at least 5mb of hard drive space to save the application.

● Software Interfaces

The app works with the GPS application in order to get geographical information about where the user

is located and the visual representation of it, and with the database in order to store the previous record of the

user. The communication between the database and the server consists of operation concerning both reading and

modifying the data, while the communication between the database and the app consists of only reading

operations.

Technical Document SRS Page 6

 Cloud Based Maps

● Memory Constraints

The app has some restrictions about the resource allocation. To avoid problems with

overloading the app is only allowed to use 20 megabytes of memory while running the app. The

maximum amount of hard drive space is depending on the user to extend it to 1 terabyte or more.

● Communications Interface

The app will access files from its own memory. It will also interface with a database or external

files from the internet to get the data. The communication between the different parts of the app is

important since they depend on each other. However, in what way the communication is achieved is

not important for the app and is therefore handled by the underlying operating apps for all component

of the app.

Ins-out of the app:

The input of the app will be the selection of the user as the user will give commands to

the app according to his choice and app will perform according to it. The user will attach the smart

phone with the vehicle and get facilitate to the features of TomTom app. The output will be the

information which is displayed on the screen of smart phone.

Technical Document SRS Page 7

 Cloud Based Maps

2.1.1 Components of the App

 Main Block Diagram

Allows GPS Navigator to

Calculate the time
find and create the key
estimation cost of all
points of maps. Find the
paths visible for the user
neighbour points of
from source to destination
location of the user
Show the current location
of the user and paths from
source to destination of
the User

Time
Internet estimation
Calculator
GPS
Navigator Count the number of
vehicles to determine the
traffic and road blocks in
the path

Inductive Loop
User Embedded System
Detector

User will use the High

Definition Cloud based
maps embedded system
while driving in-vehicle
and on his smart phone

Dijkstra s
Lidar Sensor
Algorithm

AI Algorithm shows the

To detect and identifies shortest and optimal path
the objects while driving from all given paths of the
on the system display user selection from source
to destination

Figure: Block Diagram of the App

Technical Document SRS Page 8

 Cloud Based Maps

Brief of Block diagram of the app:

The above diagram describes the components and blocks of the TomTom App app. In which

each component perform its specific part as the user perform as an actor to the app. The user will be

the actor who interacts with the app and use the app. User is not the part of app. The internet is the

external component of the app which is the most essential pre-requirement of the app. The five main

components of app are GPS Navigator, Time estimation calculator, Inductive loop detector,

Dijkstra’s Algorithm and Lidar sensor. The functionality of each component has been described in

the diagram.

Technical Document SRS Page 9

 Cloud Based Maps

2.2 Product Features

2.2.1 Developer Portal

Front End

● Onboarding: Activities onboarding new users to the user guide of app usage

● Instructions Management: Manages the creation of maps

● AI Training Engine: AI Training Engine to create the shortest path from all the

maps using Dijkstra’s Algorithm

● Device Management: Interface and communicate to internet and sensors

● Documentation: Provides users all necessary documentations for onboarding,

tutorials, how-tos

● Debugging: Interface to display all logs generated by TomTom App app

● Analytics: Interface to display key statistics from app Client devices and backend

services

● Pricing: Interface to display pricing and allow users to upgrade to paid plans

(monthly subscription Backend)

● AI Decision Making: Engine to determine accuracy & context of paths (coefficients,

errors, data)

Technical Document SRS Page 10

 Cloud Based Maps

2.2.2 Hardware Host Device

● Unboxing & Setup: General setup of the embedded app in-vehicle

● Map Creation: Real time creation of cloud based maps

● GPS Navigator: Applies app to detect the current position of the client or vehicle

● Inductive Loop detector: Calculate the number of vehicle’s count at certain path

● Lidar Sensor: To detect the objects in front of vehicle while driving

Technical Document SRS Page 11

 Cloud Based Maps

2.2.3 Data Flow Diagram

Location Storage Internet

GPS Navigator
Store Previous Check and Find
locations location

Give Current
location

Calculate the time

TomTom of each path
Navigation App

Detect and Time

identify the estimation
objects calculator

Determine the
Optimal and Count the number
shortest path of vehicles at
certain path

Lidar Sensor
Inductive
Loop Detector
Dijkstra s Algo

Figure: DFD of the App

Technical Document SRS Page 12

 Cloud Based Maps

Brief of Data Flow diagram of the app:

The above diagram describes the data flow and the interaction of entities with the TomTom

App app. In which each entity performs specific action to the app. GPS navigator, Internet, Lidar

sensor, Dijkstra’s Algorithm, Inductive loop detector and time estimation calculator are the entities of

the app. The location storage is the database in which the location of each user will be saved. The app

receives the time of every path from the time estimation calculator. Count of each vehicle on a specific

path will be taken from the inductive loop detector. The shortest and optimal path will be determined

from the dijkstra’s algorithm. Lidar sensor is important entity for the app to detect and identify the

objects and obstacles while driving in vehicle. GPS navigator will give the current location to the app.

The app will check and find the location of vehicles from the database.

2.3 Operating Environment

The operating environment is an embedded app which is used in vehicles to show users
high display cloud based maps. Users can operate the app from their smart phones to navigate and to
get facilitate with the app.

2.4 User Classes and Characteristics

Any user at any age can use this app. The design of the interface must be minimal and

user-friendly for anyone to understand. The documentations/walk through must be easy enough for any

user to understand and follow.

2.5 Design and Implementation Constraints

The embedded app is constrained by the interface to the GPS navigation app within the

vehicle. Since there are multiple app and multiple GPS manufacturers, the interface will most likely

Technical Document SRS Page 13

 Cloud Based Maps

not be the same for every one of them. Also, there may be a difference between what navigation

features each of them provide.

The Internet connection is also a constraint for the app. Since the application fetches data

from the database over the Internet, it is crucial that there is an Internet connection for the application

to function.

Both the embedded app and the smart phone will be constrained by the capacity of the

database. Since the database is shared between both modules it may be forced to queue incoming

requests and therefore increase the time it takes to fetch data.

Privacy
The privacy of users will not hurt in the app as the database server will only keep the

previous drives record to save the previous drive experience. The app will save record of drives and

their time cost and suggest the best path option by analyzing all the previous record to get the optimal

path for the users.

Hardware Specifications

Host devices running the app on Client vehicles must run the internet connection and all

sensors working properly.

False Positives

When there is no internet connection available for the app then the app may not work

properly according to the expectation. So the internet connection must be required for this app.

Technical Document SRS Page 14

 Cloud Based Maps

Path Creation Accuracy

All path are created on the display of the app and the optimal path will be discovered by

the Dijkstra’s Algorithm which will be the shortest path as compare to all.

Time Estimation of Paths

The time cost estimation will be calculated by the distance time formula which will be

done by the specific module called cost calculator in the app.

2.6 User Documentations and conditions

Affiliates means any present or future corporation or other Entity that controls, is controlled by

or is under common control with a party where control means

(i) Ownership of more than 50% of the shares, equity interest or other securities

entitled to vote for election of directors, or

(ii) The authority to direct management

API means an application programming interface that TomTom Apps provides or otherwise

makes available to you in connection with the other API Materials or the app Service provided

hereunder.

API Materials means each API and all Documentation and Software, collectively.

Contractor means your independent contractor who develops or distributes a app on your

behalf and who agrees to be bound by the terms of this Agreement.

Technical Document SRS Page 15

 Cloud Based Maps

Documentation means documentation that high display cloud based map provides or

otherwise makes available to you in connection with the Solution.

Entity means any corporation, general partnership, limited partnership, limited liability

partnership, joint venture, estate, trust, Limited Liability Company, firm, association, organization, or

other legal entity.

2.7 Assumptions and Dependencies

One assumption about the product is that it will always be used on embedded app in the

vehicles that have enough performance. If the embedded app does not have enough hardware resources

available for the maps, there may be scenarios where the app does not work as intended or even at all.

Another assumption is that the GPS components in all app work in the same way. If the app has

different interfaces to the GPS, the app needs to be specifically adjusted to each interface and that

would mean the integration with the GPS would have different requirements than what is stated in this

specification.

3 Product Features / Functional Requirements

In this section, we will describe the different use cases which can occur in our case, and also how
user interacts with our software. Following is the use case Diagram of our scenario:

Technical Document SRS Page 16

 Cloud Based Maps

3.1 Use Cases Diagram for User:

Search Map Set Destination

Set Source Give Feedback

View Map

View path time cost

View Map
Sequence
View Tutorials

View Distence Check Shortest /

Optimal Path
Zoom in map
Send location to
Zoom out map smart phone

Refresh Map View Traffic & road

Make Selection blocks
User on Map
View previous
Set Directions locations

View Help View Current

location

View terms &

Conditions
Contact support

Figure: Use Case diagram of User

Technical Document SRS Page 17

 Cloud Based Maps

Brief of Use case diagram of the app:

The use case diagram shown above describes the interaction of user with the app. It describes

the actions of the user with the app. There are 22 use cases determine in which user can interact with

the app. The user can search maps from the app. The User will set his source and destination of the

path on the map. User can View map, tutorials, map sequence, distance, help, terms & conditions,

traffic roads & blocks, previous and current location of vehicle. User can also give feedback about the

app. User can interact with the map as well by zoom-in and zoom-out map. User will also check the

shortest/optimal path above the all paths. User can contact at any time to the contact support in case of

any inconvenient.

Technical Document SRS Page 18

 Cloud Based Maps

3.2 Use Cases Diagram for Developer:

Develop Maps

Update Maps

Update Database

Modification in system

Display Maps

Recieve Feedbaks

Update Tutorials

Developer
Notify User

Give Alerts to user

Add missing places

Figure: Use Case diagram of Developer

Technical Document SRS Page 19

 Cloud Based Maps

Brief of Use case diagram of developer:

The use case diagram shown above describes the interaction of developer with the app.

It describes the actions of the developer with the app. There are 10 use cases determine in which

developer can interact with the app. The developer will develop the maps and will update them with

any new feature and can also do modifications to the app. The developer will update the database when

there is any change found in record. The developer will display the maps when it will be developed.

Developer will receive feedbacks of all users and update the tutorials when new feature were added to

the app. The developer will check and add missing places in the maps. The Developer will notify and

give alerts to the user on the app when new features or functionality were added to the app.

Technical Document SRS Page 20

 Cloud Based Maps

3.3 Use Cases Description

Name Search Map

Identifier UC-1
Purpose Search the map from the app to get paths
Priority High
Pre-conditions User should have internet access
Post-conditions User see map on app display
Typical Course of Action
S# Actor Action App Response
1 Search map from app
2 Display search result
3 Select the desire option
4 Show result against the desire option

Table 1: UC-1

Name View Map

Identifier UC-2
Purpose View map on the app display
Priority High

Pre-conditions User should have internet access

Post-conditions User see map on app display

Typical Course of Action

S# Actor Action App Response
1 Request to view desire map

2 Display desire map

Table 2: UC-2

Technical Document SRS Page 21

 Cloud Based Maps

Name View Map Sequence

Identifier UC-3
Purpose Manipulation of map
Priority High
Pre-conditions User should have internet access
Post-conditions User see the map sequence on the app
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Manipulate the map
4 Action against the desire option

Table 3: UC-3

Name View Distance

Identifier UC-4
Purpose View Distance of specific path
Priority High

Pre-conditions User should have internet access

Post-conditions See the distance of path against each path

Typical Course of Action

S# Actor Action App Response
1 Request to view the map

2 Display desire map

3 Select option to see the distance
4 Show the distance of each path

Table 4: UC-4

Technical Document SRS Page 22

 Cloud Based Maps

Name Display map

Identifier UC-5
Purpose Display map on the display
Priority High

Pre-conditions Developer built the maps

Post-conditions Successfully display the map on display

Typical Course of Action

S# Actor Action App Response
1 Develop the map

2 Display the map on display

Table 5: UC-5

Name Set Destination

Identifier UC-6
Purpose To select the Final stage of path on map
Priority High

Pre-conditions User should have internet access

Post-conditions User see the selected destination on display

Typical Course of Action

S# Actor Action App Response
1 Make selection

2 Give result
3 Select Destination
4 Destination selected

Table 6: UC-6

Technical Document SRS Page 23

 Cloud Based Maps

Name Give Feedback

Identifier UC-7
Purpose To give feedback on the app performance to developer
Priority High
Pre-conditions User should have internet access
Post-conditions User feedback will be sent to developers
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Select feedback option
4 Give details
5 Give Feedback in text box

Table 7: UC-7

Name View Path time cost

Identifier UC-8
Purpose To see the path estimated time of any path
Priority High

Pre-conditions User should have internet access

Post-conditions User see the estimated time for the desire path on display

Typical Course of Action

S# Actor Action App Response
1 Make selection

2 Give result
3 Select View path time cost
4 Show result

Table 8: UC-8

Technical Document SRS Page 24

 Cloud Based Maps

Name View Tutorials

Identifier UC-9
Purpose To watch tutorials to know how to use the app
Priority High
Pre-conditions User should have internet access
Post-conditions User see the tutorials
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Select view tutorials option
4 Show tutorials

Table 9: UC-9

Name Check Shortest path

Identifier UC-10
Purpose To see the shortest path from all given paths
Priority High

Pre-conditions User should have internet access

Post-conditions User see the shortest path on display

Typical Course of Action

S# Actor Action App Response
1 Make selection

2 Give result
3 Select View shortest path
Highlight and show the shortest path to
4 user

Table 10: UC-10

Technical Document SRS Page 25

 Cloud Based Maps

Name Zoom In
Identifier UC-11
Purpose To view the map more closer
Priority High
Pre-conditions User should open the map
Post-conditions User see the zoom in map on display
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Select to zoom in map
4 Zoom in the map

Table 11: UC-11

Name Zoom out

Identifier UC-12
Purpose To view the map far
Priority High

Pre-conditions User should open the map

Post-conditions User see the zoom out map on display

Typical Course of Action

S# Actor Action App Response
1 Make selection

2 Give result
3 Select to zoom out map
4 Zoom out the map

Table 12: UC-12

Technical Document SRS Page 26

 Cloud Based Maps

Name Send location to smart phone

Identifier UC-13
Purpose To share and view location and map on smart phone
Priority High
Pre-conditions User should have internet access
Post-conditions Successfully send the location and map on smart phone
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Require to send location
4 Send location and map to smart phone

Table 13: UC-13

Name View traffic

Identifier UC-14
Purpose View roadblocks before driving
Priority High

Pre-conditions User should select the path and view map

Post-conditions See the number of vehicles and their movement on specific path

Typical Course of Action

S# Actor Action App Response
1 Request to view the map

2 Display desire map

3 Request to view traffic
Show the number of vehicles on specific
4 path

Table 14: UC-14

Technical Document SRS Page 27

 Cloud Based Maps

Name Refresh map

Identifier UC-15
Purpose Refresh map when map is not clear
Priority High
Pre-conditions User should have internet access
Post-conditions Map successfully refreshd
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Request to refresh the map
Clear map will shown after successfully
4 refresh

Table 15: UC-15

Name Selection on the map

Identifier UC-16
Purpose Wants to interact with the map
Priority High

Pre-conditions User should have internet access

Post-conditions Action will be taken against the desire selection of user

Typical Course of Action

S# Actor Action App Response
1 Make selection

2 Give results
Action on the desire selection will be
3 taken by app

Table 16: UC-16

Technical Document SRS Page 28

 Cloud Based Maps

Name Set direction

Identifier UC-17
Purpose Set direction on the specific path
Priority High
Pre-conditions User should see the map
Post-conditions Directions selected according the user choice
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Set direction on desire path
Path will be selected according to the
4 user choice

Table 17: UC-17

Name View Help

Identifier UC-18
Purpose View help in case of any difficulty
Priority High

Pre-conditions User should have internet access

Post-conditions Help will be shown to user

Typical Course of Action

S# Actor Action App Response
1 Make selection

2 Give result
3 Request to view help
4 Help shown to the user

Table 18: UC-18

Technical Document SRS Page 29

 Cloud Based Maps

Name View terms and conditions

Identifier UC-19
Purpose View the app preferences and terms
Priority High
Pre-conditions User should have internet access
Post-conditions User see the terms and conditions
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Select terms and conditions
4 Terms and condition shown on display

Table 19: UC-19

Name View Current location

Identifier UC-20
Purpose View the present location on the map
Priority High

Pre-conditions User should have internet access

Post-conditions See the current location by highlight point

Typical Course of Action

S# Actor Action App Response
1 Make selection

2 Give result
3 Make selection to view current location
4 Show current location on the map

Table 20: UC-20

Technical Document SRS Page 30

 Cloud Based Maps

Name Contact support

Identifier UC-21
Purpose User contact in case of any inconvenient
Priority High
Pre-conditions User should have internet access
Post-conditions User successfully contact to the support
Typical Course of Action
S# Actor Action App Response
1 Make selection
2 Give result
3 Select to contact support
4 Successfully contact to the support

Table 21: UC-21

Name Develop Maps

Identifier UC-22
Purpose Developer develop the map which are missing
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions Path successfully developed

Typical Course of Action

S# Actor Action App Response
1 Search map

2 Not found
3 Develop the map
4 Map developed

Table 22: UC-22

Technical Document SRS Page 31

 Cloud Based Maps

Name Update Maps

Identifier UC-23
Purpose Update map in case of any change
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions Path successfully updated

Typical Course of Action

S# Actor Action App Response
1 Search map

2 Map changed
3 Update the map
4 Map updated

Table 23: UC-23

Name Update Database

Identifier UC-24
Purpose Update user database record
Priority High
Pre-conditions Developer logged in the database as Administrator

Post-conditions Database updated

Typical Course of Action

S# Actor Action App Response
1 Analyze any change in user record
2 See the changes
3 Required to update database
4 Database updated by the developer

Table 24: UC-24

Technical Document SRS Page 32

 Cloud Based Maps

Name Modification in app

Identifier UC-25
Purpose Modify the app in up gradation
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions App successfully modified

Typical Course of Action

S# Actor Action App Response
Modify the app in any up gradation to
1 provide new feature of the app
2 App modified

Table 25: UC-25

Name Update Maps

Identifier UC-26
Purpose Update map in case of any change
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions Path successfully updated

Typical Course of Action

S# Actor Action App Response
1 Search map

2 Map changed
3 Update the map
4 Map updated

Table 26: UC-26

Technical Document SRS Page 33

 Cloud Based Maps

Name Update tutorials

Identifier UC-27
Purpose Modify the tutorials for user on new features
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions Successfully updated the tutorials

Typical Course of Action

S# Actor Action App Response
1 Modify the tutorials

2 Tutorials updated for user

Table 27: UC-27

Name Notify user

Identifier UC-28
Purpose Notify user for any alert
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions User see the notification on app display

Typical Course of Action

S# Actor Action App Response
1 Notification sent to the user
Successfully send notification to user’s
2 display

Table 28: UC-28

Technical Document SRS Page 34

 Cloud Based Maps

Name Receive feedbacks

Identifier UC-29
Purpose Receive all feedbacks of users
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions Successfully get all the feedbacks

Typical Course of Action

S# Actor Action App Response
1 Get feedbacks of all users

2 All feedback send to the developer

Table 29: UC-29

Name Add missing places

Identifier UC-30
Purpose Add missing places in the map
Priority High

Pre-conditions Developer set the environment of Javascript and API’s

Post-conditions Place added in the map successfully

Typical Course of Action

S# Actor Action App Response
1 Add new places in the map

2 Place added in the map

Table 30: UC-30

Technical Document SRS Page 35

 Cloud Based Maps

3.4 Analysis and Modeling of Requirements

 Sequence Diagrams

TomTom App GPS Internet

Request to view current

location

Get Current Location

Check connections and key points

Allow Access

Give current location

Display Current Location

Figure: Sequence Diagram of view current location

Technical Document SRS Page 36

 Cloud Based Maps

Brief of Sequence Diagram of view current location:

The sequence diagram shows the activity flow and interaction of the components in

sequence. The above sequence diagram shows the sequence diagram for user to view the current

location. To accomplish this activity there should be 1 user and 3 entities required as the user requested

to the app to view the current location and then the app will get the current location from the GPS

navigator. The GPS navigator required the internet connection that must be available. When the

internet connection is available the GPS navigation will give the current location to the embedded app

and then it will display the current location to the user.

Technical Document SRS Page 37

 Cloud Based Maps

Path Cost Inductive loop

TomTom App
Calculator Detector

View the time estimation

of path

Get time estimation of

path

Calculate and give time

Display time of paths

Count number of vehicles at

certain path

Give total count of vehicles

Display Current Location

Figure: Sequence Diagram of view estimation path cost and traffic

Technical Document SRS Page 38

 Cloud Based Maps

Brief of Sequence Diagram of view estimation path cost and traffic:

The sequence diagram shows the activity flow and interaction of the components in

sequence. The above sequence diagram shows the sequence diagram for user to view the current time

estimation against each path and the traffic. To accomplish this activity there should be 1 user and 3

entities required as the user requested to the app to view the time for each path the user will select the

option on the app to get the time. The app will send the request to the time estimation calculator and it

will return the time to the app. After getting time against each path the app will display it to the user.

To determine the traffic the app will send request to the inductive loop detector. The detector will give

the count of all vehicles on the specific path to the app and then app will display it.

Technical Document SRS Page 39

 Cloud Based Maps

Inductive loop
TomTom App GPS Lidar sensor
Detector

View shortest path

Get all paths

Get Shortest Path

Give shortest Path

Display and adjust shortest

path

View objects

Request to view objects

Show objects

Display objects

Figure: Sequence Diagram of view shortest path and objects

Technical Document SRS Page 40

 Cloud Based Maps

Brief of sequence diagram of view shortest path and objects:

The sequence diagram shows the activity flow and interaction of the

components in sequence. The above sequence diagram shows the sequence diagram for

user to view the shortest path among all paths and the objects. To accomplish this activity

there should be 1 user and 3 entities required as the user requested to the app to view the

shortest path the user will select the option on the app to get the shortest. The app will send

the request to the Dijkstra’s Algorithm and it will return the shortest path to the app. After

getting the shortest path the app will display it to the user. To view and identify the objects the

app will send request to the Lidar Sensor. The Lidar Sensor will detect and identify the

objects and obstacles then app will display it.

Technical Document SRS Page 41

 Cloud Based Maps

 Abstract Class Diagram

Figure: Abstract Class

Technical Document SRS Page 42

 Cloud Based Maps

Brief of Abstract class diagram of the app:

The above diagram describes the class diagram of TomTom app. Each class has its

specific attributes and behavior. As the user class is highly prioritize above all class which is the actor

class. The user can search, interact and get facilitate with all functionality from the app. The app

display will show the map on screen, display paths, shortest paths, and traffic on the screen and objects

on the app. Internet is the external class which allows the app’s component to work correctly. GPS

navigator will give the current location of the vehicle to the app. Lidar sensor will detect and identify

the objects and obstacles which come in front of app while driving. Dijkstra’s algorithm shows the

shortest and optimal path above all paths to the user on app display. Inductive loop detector class will

count the vehicles and roadblocks on the app display. The time estimate calculator class will calculate

the time of each path and display it against that specific path.

Technical Document SRS Page 43

 Cloud Based Maps

4. Technical Architecture
4.1 Application and Data Architecture

 Component Diagram

Interact TomTom app Uses

User Internet

Allows

Uses
GPS
Time estimate Navigator
calculator

Uses

Saves
Location
Data API’s

Interact

Interact
Inductive Lidar sensor
Loop Detector

Figure: Component Diagram

Technical Document SRS Page 44

 Cloud Based Maps

Brief of Component diagram of the app:

The above diagram describes the components and blocks of the TomTom App

app. In which each component perform its specific part as the user perform as an actor to the app. The

user will be the actor who interacts with the app and use the app. User is not the part of app. The

internet is the external component of the app which is the most essential pre-requirement of the app.

The five main components of app are GPS Navigator, Time estimation calculator, Inductive loop

detector, Dijkstra’s Algorithm and Lidar sensor. The functionality of each component has been

described in the diagram.

4.2 User Interfaces

User will directly access the embedded app in the vehicle as every user will have the dashboard

and Sensors options which will be used to recognize objects and current location for the users and

vehicles. There is an option to search the source and destination to get the path. User will set the source

and destination and submit the information to the app and then all possible paths will be shown to the

users. There is an option to show shortest and optimal path from all paths. The app will use the

Dijkstra’s Algorithm to find the shortest and optimal path to the user on the app display. The time

estimation calculate option will be visible against each path to the user. There is an option to check the

traffic and number of vehicles in the path. Documents and tutorials are also visible on the app help

through which user can understand and learn that how he can interact with the app. There is a support

provided in the site in which user can directly connect to the developers in case of trouble or any in

conveniently.

Technical Document SRS Page 45

 Cloud Based Maps

4.3 Data Requirements

The app doesn’t use much data at all when navigating. It’s about 5 MB per hour of driving.

Zooming in and out of the map doesn’t use as much data as one might suspect it would. Most of maps

data use is incurred when initially searching for the destination and charting a course, which you can

do on Wi-Fi. Besides that, there are ways to ensure app doesn’t use any data at all when driving. So,

the app only doesn’t need much data to get you where you need to go. That’s good news; for how

useful the service is, you might expect it to use much more than the miserly 5 MB per hour.

You’ll note we said navigation; if you pull over en route to search maps for, say, somewhere to

go for lunch, you’re obviously going to be using more than the approximate 5 MB per hour.

4.4 Data Refresh Rate

When the user is searching the maps view, user may notice that location details are not always

up-to-date. App uses the same real time data as on Earth. Although these images update regularly, you

typically won't see live changes, and there may be a lag of up to a few years between the map image

you see on your screen and the way a location looks in real life.

4.5 Creation of maps

The Maps JavaScript API lets you customize maps with your own content and imagery for

display on app and smart phone. The Maps JavaScript API features four basic map types (roadmap,

satellite, hybrid, and terrain) which you can modify using layers and styles, controls and events, and

various services and libraries.

The Maps JavaScript API has been designed to load quickly and work well on app in-vehicle

and smart phone. In particular, we have focused on development for advanced app and smart phone

Technical Document SRS Page 46

 Cloud Based Maps

such as Android and iOS handsets. Mobile devices have smaller screen sizes than typical browsers on

the desktop. As well, they often have particular behaviour specific to those devices (such as "pinch-to-

zoom"). If you wish to have your application work well on mobile devices

You can localize your Maps JavaScript API application by changing the default language

settings and by specifying a region code, which alters the map's behavior based on a given country or

territory.

The Maps JavaScript API team regularly updates the API with new features, bug fixes, and

performance improvements. You can indicate which version of the API to load within your app by

specifying it in the parameter of the Maps JavaScript API bootstrap request.

5. Other Nonfunctional Requirements

5.1 Performance Requirements
The requirements in this section provide a detailed specification of the user interaction with the

software and measurements placed on the app performance.

5.1.1 Prominent search feature

ID: QR1

TITLE: Prominent search feature

DESC: The search feature should be prominent and easy to find for the user.

RAT: In order to for a user to find the search feature easily.

DEP: none

Technical Document SRS Page 47

 Cloud Based Maps

5.1.2 Usage of the search feature

ID: QR2

TITLE: Usage of the search feature

DESC: The different search options should be evident, simple and easy to understand.

RAT: In order to for a user to perform a search easily.

DEP: none

5.1.3 Usage of the result

ID: QR3

TITLE: Usage of the result

DESC: The results displayed in the view should be user friendly and easy to understand.

RAT: In order to for a user to use the app and view easily.

DEP: none

5.1.4 Usage of the result in the map view

ID: QR4

TITLE: Usage of the result in the map view

DESC: The results displayed in the map view should be user friendly and easy to understand.

Selecting a pin on the map should only take one click.

RAT: In order to for a user to use the map view easily.

DEP: none

Technical Document SRS Page 48

 Cloud Based Maps

5.1.5 Usage of the information link

ID: QR5

TITLE: Usage of the information link

DESC: The information link should be prominent and it should be evident that it is a usable

link. Selecting the information link should only take one click.

RAT: In order to for a user to use the information link easily.

DEP: none

5.1.6 Response time

ID: QR6

TAG: ResponseTime

GIST: The fastness of the search

SCALE: The response time of a search

METER: Measurements obtained from 1000 searches during testing.

MUST: No more than 2 seconds 100% of the time.

WISH: No more than 1 second 100% of the time.

5.1.7 App Dependability

ID: QR8

TAG: App Dependability

GIST: The fault tolerance of the app.

SCALE: If the app loses the connection to the Internet or to the GPS device or the app gets

some strange input, the user should be informed.

Technical Document SRS Page 49

 Cloud Based Maps

METER: Measurements obtained from 1000 hours of usage during testing.

MUST: 100% of the time.

Technical Document SRS Page 50