WINDOWS PHONE TAXI CLIENT

SOFTWARE REQUIREMENTS SPECIFICATION

Version 1.0 approved

Scripnic Alexandru
ve Mihai
Palade Drago

TI-141FR

20.01.2017

1
Table of Contents
1. Introduction ........................................................................................................................ 3
1.1
Purpose ........................................................................................................................... 3
1.1
Document Conventions .................................................................................................. 3
1.2
Intended Audience and Reading Suggestions ................................................................ 3
1.3
Project Scope .................................................................................................................. 3
1.4
References ...................................................................................................................... 4
2. Overall Description ............................................................................................................ 4
2.1 Product Perspective ........................................................................................................ 4
2.2 Product Features ............................................................................................................. 4
2.3 User Classes and Characteristics .................................................................................... 5
2.4 Operating Environment .................................................................................................. 5
2.5 Design and Implementation Constraints ........................................................................ 6
2.6 Assumptions and Dependencies ..................................................................................... 6
3. System Features ................................................................................................................. 6
3.1 Device Authorization ..................................................................................................... 6
3.1.1 Description and Priority .......................................................................................... 6
3.1.2 Stimulus/Response Sequences ................................................................................ 7
3.1.3 Functional Requirements ........................................................................................ 7
3.2 Starting point selection ................................................................................................... 8
3.2.1 Description and Priority .......................................................................................... 8
3.2.2 Stimulus/Response Sequences ................................................................................ 9
3.2.3 Functional Requirements ........................................................................................ 9
3.3 Request options selection ............................................................................................. 11
3.3.1 Description and Priority ........................................................................................ 11
3.3.2 Stimulus/Response Sequences .............................................................................. 11
3.3.3 Functional Requirements ...................................................................................... 11
3.4 Request processing ....................................................................................................... 13
3.4.1 Description and Priority ........................................................................................ 13
3.4.2 Stimulus/Response Sequences .............................................................................. 13
3.4.3 Functional Requirements ...................................................................................... 13
4. External Interface Requirements ...................................................................................... 15
4.1 User Interfaces .............................................................................................................. 15
4.2 Hardware Interfaces ..................................................................................................... 17
4.3 Software Interfaces ....................................................................................................... 17
4.4 Communications Interfaces .......................................................................................... 17
5. Other Nonfunctional Requirements ................................................................................. 18
5.1 Performance Requirements .......................................................................................... 18
5.2 Safety Requirements .................................................................................................... 18
5.3 Security Requirements ................................................................................................. 19
5.4 Software Quality Attributes ......................................................................................... 19

2
 1. Introduction

1.1 Purpose

Then purpose of this document is to describe the requirements of a client application for taxi
booking designed for windows phone platform. It will also explain de system constraints, interface
and interactions with external services.

1.1 Document Conventions

Term Definition
Client The application described by this document
User The person who will use the client application
Server The existing system that will communicate with the Client
OpenStreetMap The powerful and free map tools

1.2 Intended Audience and Reading Suggestions

This document is primarily intended to be proposed to our taxi service providers for its approval
and reference for developing the first version of the application.

1.3 Project Scope

The application will allow an easier way of interaction between taxi service providers and
windows phone users. It will allow the clients to specify their location using both the map and GPS
integration or using the text search tool. After specifying the destination and extra options, they will
receive an approximate cost and wait time. Once they will confirm the order, a new request will be
sent to the main server which will eventually return a response.

The server is an existing system that is already integrated with other platforms. It should
provide an API which will be used by the application. The API must contain a set of services that
offer required information for order completion and the actual order placement and fulfillment.

The application only requires internet connection and optionally GPS integration for detecting
the user location. The actual address selection will use the powerful and free OpenStreetMap tools.

3
 1.4 References

1. Microsoft, Windows phone starting guide, https://msdn.microsoft.com/en-

us/library/windows/apps/ff402529(v=vs.105).aspx
2. OpenStreetMap, OpenStreetMap API Documentation, http://wiki.openstreetmap.org/wiki/API

2. Overall Description

2.1 Product Perspective

The system is mainly based

on three components: the mobile
application developed for
Windows Phone platform, the
OpenStreetMap API which will
help integrate all map related tools
in our app and the server API
which allows communication with
the main server.

Both APIs requires internet

connection to access the external services. The user should be aware of this in order to avoid
undesired traffic consumption which usually is taxed by telecommunication providers.

The GPS device is optional and the client should work perfectly without it. When this device
is missing, the application should display the map and allow searching of the location using the
keywords and the map cursor. The only improvement the GPS brings is auto zoom to the user
location.

2.2 Product Features

The user will interact only with the client application. At first it should allow him to
authenticate using the phone number and code confirmation which he will receive through SMS. All

4
of this will be handled by the existing Server and the respective calls should be present in the Server
API. This is a onetime action.

Once the user confirmed his device using the phone number he can choose the current
location using the map tools. OpenStreetMap API offers a large set of utilities for that like address
searching using keywords and reversed geo location which returns the address for a specific set of
world coordinates.

After the location was selected the client has to complete his order by specifying the
destination which should be a selection from a predefined list stored on the server. Additionally, he
can specify extra options like arriving time and the type of car.

The application should check the approximate price after each option change. The calculation
itself will be handled by the server and an appropriate endpoint is available in its API. After the
order is completed a final request is sent to the server.

The server should return an immediate response with approximate search time and the order
identification number. The client will show a countdown watch starting with the time received from
the server and in background will check if the order was accepted using the identification number.
Once the order was confirmed by any driver the server should return a successful response with the
details about the car.

2.3 User Classes and Characteristics

The application is designed only for windows phone users. It provides a user interface for this
specific platform.

2.4 Operating Environment

The application will be developed for Windows Phone platform. It should be considered the
fact that mobile phones are still a low end device which has hardware limitations, especially battery
usage.

5
 2.5 Design and Implementation Constraints

The application is dependent on two external services and should block the features dependent
on them or prohibit the user from running the application. In case of OpenStreetMap, the user
should still be able to specify the location manually, but in case of Server maintenance it should
display a friendly error message and quit.

2.6 Assumptions and Dependencies

We should take into consideration the fact that our application is built on a foreign platform
which is still growing and improving. As result some of the features we could use might not be
available any longer after a few years.

The application uses OpenStreetMap which is also a tool not developed by our team and is
changed dynamically in runtime. Our team should follow their changelog and prepare for future
changes from their side.

The order fulfillment process can be interrupted by various technical issues for example lost
internet connection. This kind of issues should be detected using the ping pong mechanism and
should be handled manually be the taxi service providers.

3. System Features
This section includes the requirements that specify all the fundamental actions of the
application.

3.1 Device Authorization

3.1.1 Description and Priority

The first time when the user starts the application he must authorize the device using SMS
confirmation.

Priority: Medium

6
 3.1.2 Stimulus/Response Sequences
1. User opens the application for the first time
2. The application requires the user to confirm his phone number
3. When the user confirms the number, the application sends a request to the server
containing the phone number and device id
4. The server should generate a confirmation number
5. The confirmation number should be sent back through an SMS
6. The user must enter the confirmation number in the application
7. The application will check with the server if the confirmation is valid and start the
actual main interface or display a friendly error message

3.1.3 Functional Requirements

REQ-1:

Title Permission request

Description When a user runs the application for the first time he should confirm that
he agrees to let the application use the following tools:
the internet connection;
read phone identifier;
read phone number;
GPS.
Reason We must make sure that the users lets us use all the above tools in order for
the application to run properly
Dependencies None

REQ-2:

Title Confirm phone number

Description The application should read the phone number and confirm from the user
that the phone number is correct. If the user response negatively, The
application should let him fix the number.
Reason We must be sure that we have the correct number so we could send and
SMS.
Dependencies REQ-1

7
 REQ-3:

Title Send phone number for confirmation

Description Once the phone number was confirmed by the user. We should notify the
server and ask it to send a confirmation number by SMS.
Reason The server will make sure to send the SMS number so we could confirm
the ownership.
Dependencies REQ-1, REQ-2

REQ-4:

Title Verify confirmation number

Description After user confirmed his number we should display a text box which will
let him write the number received by SMS.
Reason We should allow the user to input the number received by SMS
Dependencies REQ-1

REQ-5:

Title Send confirmation number to the server

Description When the user writes the confirmation number we should verify it by
sending a message to the server. Depending on the server response the
following action should be done:
If the confirmation number was correct, start the main application
If the confirmation number was wrong, display a friendly errors message
Reason We should confirm the confirmation number the user wrote by
communicating with the server
Dependencies REQ-1, REQ-4

3.2 Starting point selection

3.2.1 Description and Priority

First step of making a request for a taxi cab should be the selection of starting point. This can
be achieved either by using map tools or writing it down manually.

Priority: High

8
 3.2.2 Stimulus/Response Sequences
1. When user confirms his number or runs the application for the second time
2. The application should show a map by default
3. The application should use the details obtains using GPS and show the current location
on the map
4. Using map tools, the application should display current address
5. The user can go to the next step where he can manually edit or fix the address
6. The user should also have an option to choose from a previously used list
7. Once the user finishes to set the starting address he will confirm it and go to the next
step

3.2.3 Functional Requirements

REQ-6:

Title Display map

Description When the user starts the app or finishes device confirmation a map should
be displayed.
The map should be centered on the users location which is obtained using
GPS device.
Reason The user should be able to see his current location on the map
Dependencies None

REQ-7:

Title Display current address

Description The application should search the current address based on the coordinates
obtained from GPS. If any relevant information is present it should be
displayed to the client.
Reason This will help the user to fulfill the details about his starting point
Dependencies REQ-6

9
 REQ-8:

Title Select different address on the map

Description The application should take into consideration that the GPS might not be
precise or could not work properly. As result it should allow the user to
select his address on the map by moving it using a touch gesture.
There will be a crosshair in the middle of the map which should represent
his location. Each time the user ends the touch gesture, the application
should try to update the address details
Reason This will help the user to select the correct address in case of a bad GPS
result
Dependencies REQ-6, REQ-7

REQ-9:

Title Edit address details

Description After the user selected an address on the map he will be available to update
all the details. The fields will be filled based on the selected address. The
following fields should be displayed and available for correction:
Region
Street
Building number
Fraction
Entrance
Any notes for the driver
Once the user finished to complete the address he will be able to go to the
next step
Reason The map tools might not give precise address. As result we should allow
the user to edit it or write it entirely by hand.
Dependencies REQ-7

REQ-10:

Title Select address from history

Description Once the user is able to edit the address he should also gain the availability
to select one of already used addresses. The list should be displayed on a
separate page or tab. It should contain only used addresses that ended
successfully.
Reason Usually users visit same address multiple times, like home or work place.
This feature will help them specify the address much quicker when using
the app for the second time.
Dependencies REQ-9

10
 3.3 Request options selection

3.3.1 Description and Priority

After the user selected his starting point he should be able to select the options of the request.
The following options should be available for him to change:

Destination the location he intends to arrive

Arriving time when the cab should arrive at the starting point
Type of car this will let him decide the comfort rate of the car. This also affects the
pay amount
Approximate price this is a read only field which returns an approximate value that
the customer will have to pay. This field should be updated each time any of the above
values are changed.

Priority: High

3.3.2 Stimulus/Response Sequences

1. When user confirms his starting point
2. The application should show a list of options that he can change
3. The user should be able to change any option
4. The approximate pay should be updated on any change

3.3.3 Functional Requirements

REQ-11:

Title Destination option

Description The user should be able to select a destination. This will be done by
selection a micro region from a specific list. The list will be obtained from
the server.
Reason The user should be able to select the destination
Dependencies None

11
 REQ-12:

Title Arriving time

Description The user can pre-order a cab for later so he could make sure that a cab will
definitely be available at that exact time. By default, the value it is now
which means as fast as possible. Otherwise the user can select a date and a
time.
Reason This will help the user to pre-order a cab
Dependencies None

REQ-13:

Title Type of car option

Description The user should be able to select the level of comfort which will directly
affect the price. The list of available types of car will be retrieved from the
server. This will ensure that the list is up to date.
Reason This will help the user to select the level of comfort
Dependencies None

REQ-14:

Title Approximate price

Description Each time the user changes an option this field should be updated in order
to display the approximate price. The value will be retrieved from the
server by making a request that will contain all the collected information.
Reason This field will help the user understand how much he will have to pay for
the service.
Dependencies REQ-11, REQ-12, REQ-13

REQ-15:

Title Finish option selection

Description Once the user finish to select the options he want the app will switch to the
next step which represents the actual request being sent to the server
Reason The server should be notified about a new request
Dependencies REQ-11, REQ-12, REQ-13, REQ-14

12
 3.4 Request processing

3.4.1 Description and Priority

Once the user finish selectin his options a request will be sent to the server. Then the server
will take care to notify all the drivers about it. The application should constantly check for any
updates and notify the user accordingly.

Priority: High

3.4.2 Stimulus/Response Sequences

1. When user finishes to select his options
2. The application should send all the accumulated details to the server
3. The server should take care of notifying the drivers and make sure the order is
accepted
4. The application should verify constantly if any updates were done to the order
5. A countdown should be displayed with the orders time out.
6. Based on the number of available cabs there are 2 results the order can achieve:
7. No driver accepted the request and the time out passed. In this case the user will
receive a friendly message and will let him either retry or close the application
8. A driver accepted the request. In this case the user will be notified about the car who
will pick him up also the approximate arrival time.

3.4.3 Functional Requirements

REQ-16:

Title Send request to the server

Description The application should send the following details to the server:
Device identifier
Phone number
Starting point
Destination
Arriving time
Type of car
The server should create an order based on the above details and send back
an identifier which will later be used to check updates.
Reason The server should be notified about any new requests
Dependencies None

13
 REQ-17:

Title Countdown
Description After the request was sent to the server a countdown of 5 minutes should
be started and displayed in the UI.
Reason This will let the user know when his order times out.
Dependencies REQ-16

REQ-18:

Title Check for updates

Description After the request was sent to the server an order id should be stored in the
session. Using this id, the application will repeatedly check for updates
with a configurable threshold. Based on the updates received from the
server the application will trigger the specific actions corresponding to
them.
Reason This will make sure that the user is up to date about his order.
Dependencies REQ-17

REQ-19:

Title Order time out

Description When the countdown finishes a final update check request should be done
to confirm that the request failed. A friendly error message should be
displayed and the user should be able to choose between closing the app or
trying again.
Reason This will let the user know when no drivers are available to pick him up
Dependencies REQ-17, REQ-18

REQ-20:

Title Order accepted by driver

Description Once a driver accepts the driver and this event is captured by the checker
from the up then the countdown stops and the client should display all the
details obtained from the server:
Company number
Car model
Car color
Car number
Approximate arrival time
Reason The user should know when a driver accepted his request also what car will
pick him up
14
Dependencies REQ-17, REQ-18

4. External Interface Requirements

4.1 User Interfaces

A first-time user of the mobile application should see the "Terms and Conditions" as in Figure
1. If the user accepts them he will have to confirm his number as represented in Figures 2 and 3.

Figure 1 Terms and Figure 2 Phone confirmation Figure 3 SMS confirmation

Conditions page page number page

If the user is not a first-time user, or he/she confirms the number, then a map page should be
displayed where the user can choose his starting point. Also on the second tab of this page he should
have the ability to choose one of the previously used addresses.

15
 Figure 4 Map tool Figure 5 Previous used location tools

After the user chooses his starting point using the map or previous location tools, he can change or
confirm it as in Figure 6. Afterwards he will have the change to select his destination and other options
using the fields from Figure 7.

Figure 6 Change address page Figure 7 Select order details page

16
 When the user makes a request a loading window will pop up which will should a timer that
displays how long he will have to wait for a response. If the order was accepted by a cab driver the page
from Figure 9 will pop up.

Figure 8 Waiting for response page Figure 9 Order accepted page

4.2 Hardware Interfaces

Since neither the mobile application nor the web portal have any designated hardware, it does not
have any direct hardware interfaces. The physical GPS is managed by the GPS application in the mobile
phone.

4.3 Software Interfaces

The application will use two 3rd party applications. First is the OneStreetMap which has a
documented and public API. The second is the taxi management server. This server is of REST type and
uses a well-known and used HTTP technology.

4.4 Communications Interfaces

All 3rd party application use HTTP which is an application protocol for distributed, collaborative,
and hypermedia information systems. HTTP is the foundation of data communication for the World
Wide Web. Hypertext is structured text that uses logical links (hyperlinks) between nodes containing

17
text. HTTP is the protocol to exchange or transfer hypertext. The transfer of data between the client and
the server is going to be done using a REST model. Representational state transfer (REST) or RESTful
Web services are one way of providing interoperability between computer systems on the Internet.
REST-compliant Web services allow requesting systems to access and manipulate textual
representations of Web resources using a uniform and predefined set of stateless operations.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

As this is a mobile application on the most important factor is the battery consumption. It should
use minimum required resources like CPU, RAM, GPS and internet connection. All the repeating
processes should be run with a maximum available threshold time.

Most comfortable and easy to use option for selecting a starting point should be the map and GPS
analysis. These tools should let the customer instantly pick the address without requiring any manual
edits.

All response notification from the server should be almost instantly. For example, when a driver
accepts the request, the client should be immediately notified about this.

5.2 Safety Requirements

There are two risk components that can affect the usual work flow:

1. Internet connection loss This can happen at any time when the customer used the
application. In case if this happens before he makes a request than no risk is involved as he
just wont be available to use the app any longer. If this happens after he made a request,
we must make sure that the client is served. This can be achieved by notifying the user
about the connection loss and sending all the actions either through SMS or call. Both of
them will be handled outside of the application scope.
2. Dead battery This is the most critical thing that can happen as all ways of communication
are lost. If this happens before the request was done, then the client wont be served.
Otherwise if a car accepts it, then the request will be served under a risk that he might not
be waiting at the starting point.

18
 5.3 Security Requirements

First security issue is for the server to process fake requests. In order to avoid this, we will
authorize all clients and block them after a specific number of invalid commands.

Another security measure that should be handled by the application is to use secured connection.
As all the 3rd party are web services we must use HTTPS connection instead of unsecured HTTP.

5.4 Software Quality Attributes

The application should have the following attributes:

1. Compatibility The application should run properly and without any lags on lower
devices. This will let a bigger client base to use it.
2. Interoperability The communication with the server should be lightweight in order to
avoid traffic loss which usually is paid by our customers
3. Availability - The application should work 99% of the time
4. Reliability All the client requests should be received by the server and processed as
result
5. Correctness When displaying approximate values like time or money it should be as
correct as possible
6. Localized The application supports multiple languages

19