Functional Requirements Document -Use Cases-

(1)

EUROPEAN COMMISSION

DIRECTORATE GENERAL JRC JOINT RESEARCH CENTRE

Cyber-security & New Technologies for Combating Fraud (CSCF) Institute for the Protection and Security of the Citizen (IPSC)

Evangelos Kotsakis, Michalis Ketselidis

Joint Research Centre (JRC)

November 2001

“EYE IN THE SKY” (ISKY)

Functional Requirements Document

-Use Cases-

(2)

List of Figures

Figure 1 Use case diagram of the ISKY system... 6

List of Tables

Table 1 Actors in ISKY system ... 5

(3)

Acronyms and Abbreviations

Acronym Description FCD

GIS GPS GSM Hq IOC ISKY OGC SIM SMS VIP

Floating Car Data

Geographic Information System Global Positioning System

Global System for Mobile communications Headquarter

International Olympic Committee.

Eye In the Sky

Olympic Game Committee Subscriber Identity Module Short Message Service Very Important Person

(4)

1. Introduction

1.1. System Goals and Scope

ISKY is a system based on the synergy of surveillance, communications and digital mapping technologies. It aims at providing support for two types of services that facilitate (1) fleet management and customized mobility information and (2) support for crisis situations (communications and surveillance) during large-scale events [ANN]. ISKY system aims to provide the aforementioned services by using a combination of terrestrial and sky-borne technologies including air-to-ground communications (both low and high-bandwidth), real time surveillance and advanced traffic data collection and validation techniques (Floating Car Data-FCD).

The ISKY system will consist of software and hardware that will allow users to visualise up-to-date traffic information by integrating diverse data sources (imagery, maps, FCD) into a Geographic In- formation System (GIS). In addition, ISKY aims to provide back-up communications (with a guaran- teed quality of service) and surveillance services within a specific urban area in the case where the existing communication infrastructure is congested or out of order (say, after an earthquake or other natural disaster).

1.2. Document Objectives and Overview

This document reports the functional requirements of the ISKY system. The functional requirements are grouped into Use-Cases and each use-case is described by way of a scenario of use. The use-case methodology is utilised for documenting the user/system interactions. This document describes what the system does for the user. All of the use cases describe the system from the user’s perspective. A brief introduction of the Use-Case methodology is given in Appendix A.

Section 2 presents the users and the external components (actors), which ISKY will interact with. Sec- tion 3 describes the cases of use of the ISKY system.

1.3. Document status

This is a draft document, which is not based on any structural interviews with the users. It combines a preliminary analysis, which is mainly derived from similar projects, with new considerations and as- sumptions that capture the ISKY goals and objectives. Its aim is to specify some preliminary func-

(5)

tional requirements of ISKY and show the user involvement in obtaining certain services. Future changes are anticipated when user interviews are completed.

2. Actors

There are five types of actors in the ISKY system¹. These are shown in Table 1.

Table 1 Actors in ISKY system

Actor’s Name Actor’s Role in the ISKY system

Public authority user Ministry, traffic authority, civil protection service

Mobile Telecom operator User of traffic information for re-distribution to subscribers

Media TV, radio, Internet portal

Closed user group* (driver) Individuals, VIPs, drivers in general

Closed user group* (headquarters) Tour operator, OGC-2004 Hq, taxi company central office

(*) Closed User Group is a group of individuals who purchase the provided service and use it for their own purposes. It is not open for public use. It consists of a central office / Hq and moving targets / vehicles. A closed user group may be a taxi company, the IOC or OGC2004 group of VIPs, a tour operator, etc.

3. USE case description

In this preliminary phase, the following use cases have been identified for the ISKY system Service 1: Fleet Management and Customised Mobility Information

• Traffic Monitoring & Traffic Information (service 1)

• Dynamic Fleet Management & Guidance (service 1)

• Pre-trip Information Services (service 1)

Service 2: Emergency Support for Crises during large-scale events, based on the use of low- altitude platforms and floating car data

• Voice and Data Transfer (service 2)

• Sky-borne Surveillance (service 1 and 2)

1A more detailed description of users has been neglected at this stage. However, it is desirable to include in the user description, information related to their roles and responsibilities as well as the tasks they perform.

(6)

Figure 1 shows the ISKY system boundary and the use cases that form the basic functionality of the system as well as the actors and their interactions with certain use cases. The use cases have been grouped into two packages, each of which corresponds to one of the aforementioned services. The fleet managementpackage is concerned about fleet management and customised mobility information (service 1) while theemergency supportpackage is concerned about emergency support for crises during large-scale events and it is based on the use of low-altitude platforms and floating car data (service 2).

closed_user_

group_driver public_

authority_

user

closed_user_

group_

headquarter Mobile_

telecom_

operator

Media EIS-System Boundary Box

emergency_support

sky_borne_

surveillance voice_data_

transfer

fleet_management

traffic_info_and_

monitoring

Dynamic_fleet_

management_

guidance

Pre_trip_Info_

Services 1

1

1 1 1

1 1

1

1 1 1

1

1 1

1

<<Uses>>

1

<<Uses>>

1

1 1

1

Media public_

authority_

user Mobile_

telecom_

operator

closed_user_

group_

headquarter closed_user_

group_driver

emergency_support

fleet_management

traffic_info_and_

monitoring

Dynamic_fleet_

management_

guidance

Pre_trip_Info_

Services sky_borne_

surveillance voice_data_

transfer

Figure 1 Use case diagram of the ISKY system

The description of the above use cases is following.

(7)

3.1. Use Case: Traffic monitoring & Traffic Information

Title Traffic monitoring & Traffic Information

Goal To provide permanent road-network-monitoring and congestion detection to the traffic monitoring centre and to the drivers by combining floating car algorithms and real-time imagery.

Actors • Public authority user

• Closed user group (driver)

• Closed user group (headquarter)

Description This is the most promising (and thus commercially important) use case. The description will evolve as on-going work in wp 3 identifies the optimal synergy between the sky-borne surveil- lance data and the floating car data; also the road sensor data and floating car data.

The actor initially makes a traffic condition request concerning the area of interest.

The request may have two options; (1) request for Floating Car Data (FCD) and (2) request for real time imagery. The system responds to this request by retrieving the most up to date traffic flow data and/or imagery data. The actor may make such a request once and the system sends a response at the end of a user-defined interval of time. The actor may visualize the FCD on a GIS (Geographic Information Sys- tem), send it to interested parties, archive it for future use (historical traffic flow data may be used afterwards for planning and decision support)

The actor is also able to visualize, send and archive real time images of the area of interest. These images are taken from the airship (Zeppelin), which gives an addi- tional visual view (‘Eye in the Sky’) of the traffic conditions in case either the FCD is not available for the given area or it is too poor for making any decision.

FCD contains traffic float data recorded with the assistance of a sample fleet (2-5%

of all vehicles) moving along with traffic. Each participating car transmits traffic flow data to headquarter through a wireless communication channel (GSM -SMS).

The traffic flow data is then stored in a database, processed, compared with other available information (road sensor data, real time imagery from Zeppelin etc.) and then the traffic conditions are estimated and made available to interested parties for visualization.

Preconditions None Postconditions None

Dependencies It depends on thesky-borne surveillanceuse case. This is done whenever

(8)

real-time imagery data needs to be compared to FCD in order to increase the reliability and accuracy of the traffic conditions

Constrains Availability of GPS signal and GSM coverage Non-Functional

requirements

Update rate

Exceptions None

Notes Each sample vehicle must be within GSM coverage and equipped with a GPS (Global Positioning System) receiving unit and a GSM (Global System of Mobile communications) telecommunication unit. In case, the driver of a participating car wishes to have a visual traffic condition representation of his own, a portable com- puter (laptop-palmtop-handheld etc.) is needed for processing incoming and outgo- ing data and providing a visual reproduction of traffic information for the driver.

3.2. Use Case: Dynamic Fleet Management & Guidance

Title Dynamic Fleet management & Guidance

Goal To assist fleet management by providing vehicle tracking and co-ordination, dynamic route guidance and fleet information exchange.

Actors Closed user group (headquarter) Closed user group (driver)

Description The Headquarter will be able to visualize in near real time the whole fleet on a GIS and check the status of each vehicle. The Headquarter will also be able to exchange information with the fleet members regarding good ordering and delivery instruc- tions. Vehicle tracking is facilitated by storing and visualizing the vehicle’s track log.

Dynamic route guidance suggests or orders the drivers about the routes. In such a service, the destination point is initially identified and the shortest path from a given position is determined. Other information concerning road conditions etc.

could be sent along to the driver.

Preconditions None Postconditions None

(9)

Dependencies It depends on thetraffic monitoringuse case Constrains Availability of GPS signal and GSM coverage

Non-

Functional requirements

Positioning accuracy

Communication channel capacity

Exceptions None

Notes None

3.3. Use Case: Pre-trip Information Services

Title Pre-trip Information Services

Goal To provide information on a given trip Actors • Public authority user

Description Pre-trip information includes any possible information that one needs to have before departing. This may include sites of interest, traffic conditions, time it takes to get to the destination etc.

The actor specifies (1) the starting and the ending point of the trip (2) his profile that indicates what information he/she is interested in getting. The system responds by providing the shortest path as well as the requested information. A user can register his/her preferences by filling in a special form.

Preconditions User profiles must be registered Postconditions None

Dependencies None Constrains None Non-Functional

requirements

None

(10)

Exceptions None Notes

3.4. Use Case: Voice and Data Transfer

Title Voice and Data Transfer

Goal To provide a communication means for transferring voice and data from one actor to the other

Actors • Public authority user

Description This refers to a single closed GSM cell, whose hub is located on the Zeppe- lin. This onboard GSM hub covers a limited geographic region and it is a dedicated closed communication GSM system that is solely used by a limited number of users (i.e. fleet members). This communication system al- lows information to be exchanged between fleet members and it guarantees a good quality of service with a high degree of reliability and availability.

The actor uses this ISKY system case with a straightforward way. Each actor is supplied with a GSM terminal and a special SIM card. An actor can call any other actor or the Headquarter for voice communication. Data transfer is also possible through the same communication channel.

Preconditions None Postconditions None Dependencies None

Constrains GSM coverage of the closed cellular communication system.

Non-Functional requirements

None

Exceptions None

Notes None

(11)

3.5. Use Case: Real Time Surveillance

Title Real Time Surveillance

Goal To Provide imagery of the area covered by the Zeppelin

Actors • Media

• Public authorities

Description The Zeppelin is equipped with special cameras, which regularly takes snap- shots of the urban area. These images are stored in a database and they can be visualised on a GIS as is or made available to media and public authorities. In addition, these images may be used in combination with FCD to improve the accuracy of the traffic flow estimation in the given area.

The user can easily (by way of a GIS interface or special software) view the most up to date image of a requested area by retrieving the image from the database.

Preconditions None Postconditions None Dependencies None Constrains None Non-Functional

requirements

Image resolution

Exceptions None

Notes None

4. References

[ANN] Annex 1- Description of Work, Project: Eye in the Sky. Information Society Technologies (IST) program, March 2001.

(12)

5. Appendix A: A brief introduction to use case methodology

Use case methodology is used to capture user requirements by collecting possible sequences of interactions between the system and its users. The collection of the use cases (cases of use of the system) defines the behaviour of the system relevant to the user’s goals.

A Use Case defines a goal-oriented set of interactions between external actors and the system under consideration. The functional requirements of the system are captured along these interactions. A collection of Use Cases defines all system behaviour relevant to the actors and ensures that the users’

goals will be carried out properly. A Use Case Diagram (UCD) shows typical interactions between the system under consideration and external actors who may want to interact with it.

Use Case Diagrams can have the following parts:

actor

Actors can be either users of the system or external components, such as sensors or actuators that either provide information to the system or use information provided by the system. An actor may be primary or secondary. A primary actor is one having a goal re- quiring the assistance of the system. A secondary actor is one from which the system needs assistance to satisfy the goal.

usecase

Use Cases Capture some user-visible function. A use case

can be big or small, but it must capture an important goal of a user for the system.

usecase

actor

usecase

actor

Association Lines show relationships between actors and use cases.

(13)

usecase

usecase usecase

usecase

System Boundary set the boundary between the system un-

der consideration and the external actors. Use cases go inside the system boundary.

package

Packages group systems or parts of a system into logical components.

The following template is used to describe a use case

Field Description

Title A descriptive unique name of the use case Goal The main business goal of the use case Actors List of actors involved in the use case

Description The description should list the functional requirement to achieve the goal. A sequence of interactions between system and actors may be presented through which the goal is achieved. The sequence of interactions leads to the description of a set of scenarios that traverse an actor from a trigger event (start of the use case) to the goal (successful scenario) or to a failure (unsuccessful scenario). What is considered a success or failure must be clearly described. External events that trigger the start of the use case should be also described.

Preconditions Any prerequisites before the use case can be started. The precondition ex- presses an assumption that must be satisfied when running the use case and it describes the input that the use case requires at the moment it is invoked.

This input usually comes from external sources (not within the boundary of the use case).

(14)

Postconditions Any predicates that should be true at the end of the use case (immediately after the occurrence of the use case). The postcondition may state the prom- ises of what the use case guarantees to establish. It presents constraints that must be satisfied just after a use case is run. The use case must ensure the postconditions.

Dependencies Other Use cases, which the current use case depends on (i.e. hierarchical dependencies through Extends and uses relationships)

Constrains Any restrictions that must be addressed concerning the use case Non-

Functional requirements

Performance, reliability, accuracy, fault tolerance, frequency of use, priority

Exceptions Nature of the exception and the recovery step in the scenario to return to

Notes Any notes

5.1. Use Case Bibliography

Ivar Jacobson. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison- Wesley, 1992

Booch, G., I. Jacobson and J. Rumbaugh, The Unified Modeling Language User Guide. Addison- Wesley, 1999, pp. 219-241.

Geri Schneider, Jason P. Winters. Applying Use Cases. Addison-Wesley, 2nd edition, 2001 Doug Rosenberg, Scott Kendall. Use Case Driven Object Modelling With UML: A Practical Ap- proach. Addison-Wesley, 1999

Functional Requirements Document -Use Cases-

EUROPEAN COMMISSION

November 2001

“EYE IN THE SKY” (ISKY)

Functional Requirements Document

-Use Cases-

Table of Contents

List of Figures

List of Tables

Acronyms and Abbreviations

1. Introduction

1.1. System Goals and Scope

1.2. Document Objectives and Overview

1.3. Document status

2. Actors

3. USE case description

3.1. Use Case: Traffic monitoring & Traffic Information

3.2. Use Case: Dynamic Fleet Management & Guidance

3.3. Use Case: Pre-trip Information Services

3.4. Use Case: Voice and Data Transfer

3.5. Use Case: Real Time Surveillance

4. References

5. Appendix A: A brief introduction to use case methodology

5.1. Use Case Bibliography