Use Cases for a Taxi Service Application, Summaries of Computer Science

Download Use Cases for a Taxi Service Application and more Summaries Computer Science in PDF only on Docsity!

Taxi Service

Requirements Specification

Version 1.

Requirements Definition Date: 2012- 11 - 02

Revision History

Date Version Description Author

2012-11-01 0.1 Initial Draft DSD

2012-11-02 0.2 Chapters 1, 2 Draft Marko Coha

2012-11-02 0.3 Chapter 3 Draft Luca Zangari

2012-11-02 0.4 Chapters 5,6 Draft Igor Piljić

2012-11-02 0.5 Chapter 4 Draft Leon Dragić

2012-11-02 1.0 First version finalized Igor Piljić

Requirements Definition Date: 2012- 11 - 02

1. Introduction

1.1 Purpose of this document

This document contains all the requirements for the Taxi service project. It is defined after collecting all the necessary requirements in order to start the implementation process. These requirements may change, or new ones may be added, because of the iterative development process of this project. Any changes should be documented in one of the revisions of the document. All the prototypes and the final product should be based on this document.

1.2 Intended Audience

The requirements document should be used by all team members, the supervisor and the customers. Team members should use the document when implementing any of the features of the system, and all parts of the system should work as is described in this document. Requirements can be changed and new ones can be added, if requested by the supervisor or the customers, and this document should keep track of all the changes.

1.3 Scope

This document will describe all the requirements for the Taxi service project, the characteristics of future users and constraints that can influence implementation of the project. Interaction of the system with users will be described using use cases. Technical and implementation details will not be covered in this document.

1.4 Definitions and acronyms

1.4.1 Definitions

Keyword Definitions

UC Use case

ETA Estimated time of arrival

1.4.2 Acronyms and abbreviations

Acronym or

abbreviation

Definitions

GPS Global positioning system

1.5 References

Taxi service website: http://www.fer.unizg.hr/rasip/dsd/projects/taxi_service

Requirements Definition Date: 2012- 11 - 02

2. Overall Description

2.1 Product Perspective

This product is a standalone system, and, as such, is not a component of a larger system.

2.2 Product Functions

The main purpose of this product is to improve the organization of the taxi service in Milan. Using this product, the customers should be able to order a taxi to their current location, or a location of choice, and receive a confirmation of the order. Taxi drivers should be able to receive an order with a location, and change the status of a taxi accordingly. Taxis should be tracked at all times and put into zones, depending on their current location.

2.3 User Characteristics

There will be several types of users. Customers, or end-users, will use an Android application to order a taxi. This application should be designed in such a way that no educational level, experience and technical expertise will be required for use. Another type of users will be taxi drivers. They will use an Android application to receive orders and act on them. They should be proficient in using the application, so some education will be necessary. However, no technical expertise should be required and the application should be as simple as possible. Finally, the product will also be used by dispatchers. They will have to have some technical expertise and experience to efficiently coordinate all the drivers.

2.4 Constraints

Some limitations that should be taken into consideration are related to security and reliability of the system. The system should be designed in such a way that it’s impossible for a third party to see or change data in any way. Such an intrusion could allow a third party to act as a taxi driver, and could cause significant loss for the taxi organization. Furthermore, the system should be available at all times, and resistant to database, network and other failures. Such an error could cause a loss of communication between taxi drives and dispatchers, and should be treated accordingly.

Requirements Definition Date: 2012- 11 - 02

4. Use Cases

4.1 Taxi UC

4.1.1 Use case “change status”

Use case ID TAXI Name Change status Goal Change current taxi status Participating actors

Taxi and server

Precondition Main scenario 1. A customer stops a taxi which is roaming through the city

_2. A taxi receives an order from the customer

3. A taxi changes its status from available to busy
4. When the order is done, taxi changes status back to free
5. Taxi updates status when is “on duty”
6. When taxi finishes with the working shift, updates status to “off duty”_

Exceptions If there is no internet connection, taxi can’t change its status Extensions Dependent UC

4.1.2 Use case “send current GPS location”

Use case ID TAXI Name Send current GPS location Goal Update the location of the taxi

Requirements Definition Date: 2012- 11 - 02

Participating actors

Taxi and server

Precondition The taxi needs to be “on duty” Main scenario 1. Taxi will send its GPS coordinates to the server every several seconds Exceptions Extensions Dependent UC

4.1.3 Use case “apply for taxi registration”

Use case ID TAXI Name Apply for taxi registration Goal Add new taxi to the system Participating actors

Taxi and server

Precondition Main scenario 1. Before starting to work as taxi, taxi needs to apply for taxi registration Exceptions Taxi is already registered in the system Taxi registration is rejected Extensions Dependent UC

Requirements Definition Date: 2012- 11 - 02

Name Determine taxi zone Goal Assigns taxi to the appropriate zone Participating actors

Server and taxi

Precondition Taxi has sent its GPS location Main scenario 1. Server receives the GPS location of the taxi

2. Server determines the zone in which taxi currently is
3. Server sends the zone number to the taxi Exceptions Extensions Dependent UC TAXI

4.2.3 Use case “determine customer location”

Use case ID SERVER Name Determine customer location Goal Determine the city zone of the customer Participating actors

Server

Precondition Customer has made an order for the taxi Main scenario 1. Server receives the customer order

2. Server determines the zone of the customer Exceptions Extensions Dependent UC CUSTOMER

4.2.4 Use case “ assign a taxi to the customer order ”

Use case ID SERVER Name Assign a taxi to the customer order Goal Dispatch the first taxi in the queue to the customer Participating actors

Server and taxi

Precondition The server has determined the customer zone Main scenario 1. Server sends the customer order to the first taxi of the appropriate queue Exceptions Taxi refuses to take the order There is no taxis in the queue Extensions Dependent UC SERVER

4.2.5 Use case “ send taxi info ”

Use case ID SERVER Name Send taxi info Goal Inform the customer about the taxi which will pick him up Participating actors

Server and customer

Precondition The order has been assigned to a taxi Main scenario 1. Server sends the information about taxi and ETA to the customer Exceptions Extensions

Requirements Definition Date: 2012- 11 - 02

Dependent UC SERVER

4.2.6 Use case “ update taxi status ”

Use case ID SERVER Name Update taxi status Goal Update the status of the taxi on the server Participating actors

Server

Precondition Taxi changed its status Main scenario 1. Server receives the status change from taxi

2. Server updates the queue Exceptions Extensions Dependent UC TAXI

4.2.7 Use case “ register a taxi ”

Use case ID SERVER Name Register a taxi Goal Add new taxi to the system Participating actors

Server

Precondition Taxi had sent the application for registration Main scenario 1. Server receives the application

2. Server adds taxi to the system Exceptions The taxi is already in the system The application is rejected Extensions Dependent UC TAXI

Requirements Definition Date: 2012- 11 - 02

Use case ID CUSTOMER Name Order a taxi Goal Order a taxi to customer location Participating actors

Server and customer

Precondition Main scenario 1. Customer uses web application to select his/hers position on the map

2. The position is sent to the server

Exceptions Extensions Dependent UC

Requirements Definition Date: 2012- 11 - 02

5. Requirements Definition

5.1 Requirement Group Definitions

Identification Requirement Group Rem.

CA Customer application

TA Taxi application

SER Server

NFR Non-functional requirements

5.2 Requirement Sources

Source Description Rem.

CTM Customer

SYS System

DEV Developer

Requirements Definition Date: 2012- 11 - 02

Requirement status: I = initial (this requirement has been identified at the beginning of the project), D = dropped (this requirement has been deleted from the requirement definitions), H = on hold (decision to be implemented or dropped will be made later), A = additional (this requirement was introduced during the project course).

Requirement priority: 1-high priority 2-medium priority 3-low priority

5.3.1 Change Log

Identity

Acti

on

Date Comments

Requirement status: D = dropped (this requirement has been deleted from the requirement definitions), H = on hold (decision to be implemented or dropped will be made later), A = added (this requirement was introduced during the project course). R = resurrected (dropped or on hold requirement was reactivated)

6. Future Development

Initial version of product will consist only of features needed for core functionality. Additional features were considered and discussed, but will be added after the main goals are accomplished. Some of these additional features are: Taxi sharing Advertisement system Customer registration Keep statistics about taxis and customers Show directions to taxi driver Connect applications with social networks

Final product could be developed for other operating systems besides Android, such as iOS or WP7.