RASD

Introduction

Purpose

This document has the goal of describing all the requirements asked by the customer, showing the constraints and the possible scenarios involving the system. The intended audience of this document are the developers of the system and the customer. For this purpose there will a clear distinction between technical and non-technical parts.

Scope

The “MyTaxiService” is an application born to support an existing taxi company, especially to simplify passengers’ access to the service and guarantee a fair management of taxi queues. In fact it will be GPS-based and will be able to assign a taxi to a certain call, based on the location of the taxi and of the requesting passenger, in order to minimize the waiting time.
It will also provide an option to reserve a taxi in advance and to share the ride with other passengers to save money. All these features will be available via a free download mobile application or a web application.
It will also provide a driver side application, in order to communicate with taxi drivers and to fetch the locations of all the taxi.

Definitions, Acronyms, Abbreviations:

Acronyms & Abbreviations

  • ETA: Estimated Time of Arrival

  • EWT: Estimated Waiting Time

  • DB: Database.

  • DBMS: DataBase Management System.

  • PSP: Payment Service Provider

Definitions

  • Lock: Reserve a taxi for a certain call, and list it as busy.

Reference

Overview

Overall Description

Product perspective

The name of the application is MyTaxiService. The pre-existent taxi service system consists of databases containing taxis and drivers. The users interact with the system from different operating systems both on desktop and mobile devices. Passengers and Drivers using the application must have a GPS-enabled device which is necessary for the system to detect their current positions. Supported mobile devices are only limited to those having one of the following operating systems, screen sizes or browser:

  • Mobile:

    • iOS v.7 to 9 and future versions

    • Android 4.2 to 5 and future versions

    • Screen sizes strating from 4.2’

  • Desktop

    • Browser Chrome (v.46+)

    • Browser Internet Explorer (v.11+ or Edge)

    • Browser Firefox (v. 21+)

Dispatches in case of new taxi request were forwarded to drivers by radio, so the previous system hasn’t got any particular information system. The application will have access to the DBs so it will need an interface with the current DBMS. It will also have an interface for the users and another one for the administrators.

Overall view of MyTaxyService system

Product functions

The application will provide a set of functionalities for the reservation of a taxi and also to save money sharing your ride. It will also be designed to improve the management of the taxi queues and to decrease the waiting time of the customers.

User characteristics

  • Guest: a guest is whoever opens the application without having been authenticated.

  • Passenger: a passenger is an authenticated user who is capable of reserve a ride from a certain location to another. He’s also able to share a ride with other passengers or to look for shared rides.

  • Taxi driver: a taxi driver is an authenticated user who has been granted permission to confirm or not a reservation. In case of confirmation he should lock his availability from incoming reservations aside shared rides.

  • Administrator: an administrator is an authenticated user who has been granted supervising permissions. He’s also able to view, modify reservations’ states and access statistics and aggregated information about the application.

Constraints

Regulatory Policies

MyTaxyService will be released on Google Play Store, Apple App Store and Windows Store and so it must respect their market policies.

Hardware Limitation

MyTaxyService will support only mobile devices newer then 2012. The mobile application will be suitable for devices with screen sizes starting from 4.2’

Interfaces to other applications

MyTaxyService is strongly dependent on MySQL as the main DBMS. It also uses PayPal as the only PSP.

Parallel operation

MyTaxyService must support parallel operations coming from both Taxi Drivers and Passengers on the same DB.

Reliability requirements

Criticality of the application

The application doesn’t have a critical role inside the taxi system, since any of the actions done by MyTaxiService, can by accomplished by phone.

Safety and security considerations

Since the payments are processed externally and the data is handled by an external DBMS, there are no specific security issues.

Assumptions and dependencies

  • Taxi drivers must have a smartphone in order to use the application and to manage incoming calls.

  • A standard user is whoever needs a taxi service, using the new available technology. He must have a smartphone or a device with an internet access so he could use the web application or the application itself.

  • There is an administrator level, which is not specified, but can be useful for checking accesses and statistics.

  • Web application and app have the same functionalities.

  • Users have a GPS-enabled devices.

  • When a passenger requests a taxi, at least one is always available.

  • A shared taxi can be reserved at most for the number of passengers that the car can contain. (forse non qui! )Domain Property

Apportioning of requirements

List of possible future functionalities:

  • Friend list and possibility to share rides with them.

Goals:

  • [G1] Allow Visitor to become a registered user (“Passenger”).

  • [G2] Allow Taxi drivers and passengers to log in into the application.

  • [G3] Allow Passengers to request a taxi.

  • [G4] Allow Passengers to see the code and the ETA of the incoming taxi.

  • [G5] Allow Taxi drivers to accept or refuse a call.

  • [G6] Allow Passengers to reserve a taxi for a certain time and place (origin and destination).

  • [G7] Send a confirm notification to the Passenger and lock a taxi at least 10 minutes before the reservation time.

  • [G8] Allow a Passenger to choose a shared ride.

  • [G9] Allow a Passenger to share a ride.

Scenarios

Scenario 1: Usage of the app

Timmy needs a taxi to go back to his hotel in Sesame Street. So he picks up his phone and opens the “MyTaxiService” app. He is asked to allow the application to use his position and after that, he’s asked to pick a destination. He writes “Serame Street”, but the application doesn’t recognize this place and suggests “Were you looking for ”Sesame Street“ perhaps?”. He chooses “yes” and then he is asked to wait a moment. After few seconds, a popup appears on the screen containing the taxi code, the EWT for the taxi, the ETA to home and the expected far. He waits for the taxi to arrive and after he’s back home, he’s notified of the fare which is directly drawn from his credit card.

Scenario 2: Taxi reservation

Bob is abroad on holiday and is going to take a plane to go back to his city, but he realizes that no one can take him back home from the airport, so he decides to book a taxi ride. His smartphone is dead so he turns on his laptop, connects to airport’s wi-fi and opens the mytaxiservice.com website. He signs in with his credentials and opens the “New Ride” view. He selects the starting place(the airport), the destination (“21st avenue”), and chooses the departing time. During his flight he charges his mobile phone so when he lands he turns his mobile phone on and receives all the information about his reservation. At the booked time the taxi arrives and brings him home. The taxi driver communicates him the ride fare and he pays in cash.

Scenario 3: Shared ride

Alice bought a ticket to go to the theater tonight for a new musical. She decides to go with a taxi but she wants to save money because she has already spent a lot for the show ticket. So she opens the myTaxiService application and chooses a shared ride for the theater. In the meanwhile Bob realizes he has to go to a restaurant near the theater for a dinner with his colleagues but his car is broken. So he picks up his mobile phone and opens the myTaxiService app. He decides to choose a shared ride to save some money so he selected the option and confirms. Both Alice and Bob receive the informations of the same taxi for their ride. The taxi first stops at Bob’s house and the taxi driver tells Bob that his ride his shared and he will stop to take another passenger. The taxi stops after a few minutes at Alice’s house and then it takes them to their destination. Once arrived the taxi driver tells them their respectively fares and they pay.

Scenario 4:

Carl, a taxi driver for the myTaxiService company, is driving along “Main Street” when he receives a notification from the taxi application for a shared ride. He accepts the request and goes at the first address given to take the first passenger. After driving for a few minutes he stops to take other two passengers and his car is now full. So he drives to the first destination and tell the passenger the fare that will be charged on his Paypal account. Then he drives to the last stop and leaves the last passengers, takes the payment in cash and terminate the current ride on the app.

Scenario 5: Taxi driver notifications

Jack is a taxi driver and he has to put myTaxiService onto his mobile. He is bottled up in traffic due to a car accident. He receives a notification for a new passenger but he would take too many time to reach the client so he decides to decline the request. After some time he finally has open road and he receives another request for a shared ride. He accepts the request and follows the GPS.

Specific requirements

External interface requirements

User interfaces

Web registration page
Login Page for mobile application
New Ride Page
Rides informations
Taxi Driver Interface

Hardware interfaces

Software interfaces

Communication interfaces

Functional requirements

User 1 - Guest

  1. Registering
    A guest can register into the application by compiling the registration form.

    Restrictions:

    1. Guest must enter a valid email.

    2. Guest must enter a valid phone number.

    3. Guest must be adult in order to register.

User 2 - Passenger

  1. Connect to PayPal
    A passenger can connect his account to PayPal. The application will ask permission to use passenger’s PayPal account.

  2. Retrieve his password
    A passenger can retrieve his account’s password. The application will send the an email to the user with his password.

  3. Request a new taxi ride
    A passenger can ask for an immediate ride. He will have to fill the following input informations: starting point (automatically filled if GPS is enabled) and destination.
    There are some special cases:

    1. Request a new shared taxi ride
      A passenger can ask for a shared taxi ride in order to save money or have company.

    2. Book a new taxi ride
      A passenger can ask for a future ride. He will also have to add a date. The starting point’s auto-fill is disabled.

User 3 - Taxi driver

  1. Accept a regular ride notification
    A taxi driver can accept a regular ride notification. The application will send the taxi data to the passenger and will prevent the driver to receive any other notification (lock).

  2. Accept a shared ride notification
    A taxi driver can accept a shared ride notification. The application will send the taxi data to the passenger and will enable just the receiving of other shared ride (shared lock).

  3. Decline a ride
    A taxi driver can decline a ride request.

User 4 - Administrator

  1. Access the statistics
    An administrator can access to all statistics data about the taxi service.

  2. Manage the accesses
    An administrator can manage the access levels of the users.

\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% {-2.5ex\@plus -1ex \@minus -.25ex}% {1.25ex \@plus .25ex}% {\normalfont\normalsize\bfseries}} \setcounter{secnumdepth}{4} % how many sectioning levels to assign numbers to \setcounter{tocdepth}{4} % how many sectioning levels to show in ToC \subsection{Use Cases} \subsubsection{Visitor registration} \begin{tabular}{| l | l |} \textbf{Actor} & Visitor \\ \textbf{Goal} & [G1]\\ \textbf{Input Condition} & \\ \textbf{Event Flow} & \\ \textbf{Output Condition} & Visitor successfully registers and become a Passenger. From now he can log in to the application\\ \textbf{Exceptions} & Visitor already registered, One or more mandatory fields are empty, Username already in use, Password doesn't respect the constraints. \end{tabular} \end{table}

UNDER DEVELOPMENT

1. Specific Requirements In this section detailed descriptions of the functional and quality requirements will be presented together with explicit features requested. a. External Interface RequirementsIn the paragraphs below an analysis of inputs to and outputs from the system will be presented both from the user and software perspectives. i. User InterfacesThe first view an user should see is the Sign In page both from mobile and web apps.Then, if it’s their first time within the application, the user should move to the sign up page, in order to begin the registration process.

If however they already have an account, after the sign in process:

- If the user is a passenger, they will se the Home page which contains a brief history of previous rides and an option to do a new ride.

- If instead the user is a taxi driver they will directly see the Driver page which shows recent notifications and a map with the route to the next destination. - If

ii. Hardware InterfacesSince the application is compliant to modern standards, there is no specific limitation on the hardware itself. The only limitation to use the app is that it must be used from a GPS enabled device. iii. Communication Interfaces Since both the front-end and the back-end are being developed from scratch, there are no specific restrictions on the communication between system components except from the underlying data layer which will be discussed later.

Audience:

  • City Government : burocratic

  • Developers : technician

  • Management : business

Init Notes

Global Aim:

Optimizing a large city’s taxi service.

Detailed Aims:

  1. Simplify passengers’ access to the service

  2. Guarantee a fair management of taxi queues

Domain Details:

  • Requests are made via Web/Mobile App

  • Responses contain Taxi Code and Waiting Time

  • Taxi drivers publish their availability / confirmation via a Mobile App

  • Queue Algorithm (Original quote:)

    In particular, the city is divided in taxi zones (approximately 2 km2 each). Each zone is associated to a queue of taxis. The system automatically computes the distribution of taxis in the various zones based on the GPS information it receives from each taxi. When a taxi is available, its identifier is stored in the queue of taxis in the corresponding zone. When a request arrives from a certain zone, the system forwards it to the first taxi queuing in that zone. If the taxi confirms, then the system will send a confirmation to the passenger. If not, then the system will forward the request to the second in the queue and will, at the same time, move the first taxi in the last position in the queue.

  • Public API (Note: Not really a “domain detail”)

  • Part 2: A user can reserve a taxi by specifying origin and destination. A reservation( \( r:O \rightarrow D \)):

    • MUST occur at least 2 hours before.

    • Is confirmed to the user by the system, which allocates a taxi 10 mins before.

  • Part 3: A sharing option must be available, which:

    • It gives the possibility to share the reservation and the costs.

    • It requires the user to specify the destination of all rides it wants to share.

    • The system will find other users in the same zone, calculate the fee and notify the users.

[Someone else is editing this]

You are editing this file