Nov 13, 2001 - Cyber-security & New Technologies for Combating Fraud (CSCF). Institute for the ... ISKY-functional requirements document. DRAFT 2-Only for ...
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)
“EYE IN THE SKY” (ISKY)
Functional Requirements Document -Use Cases-
Evangelos Kotsakis, Michalis Ketselidis
Joint Research Centre (JRC)
November 2001
Table of Contents 1.
Introduction................................................................................................................................ 4 1.1.
System Goals and Scope.................................................................................................... 4
1.2.
Document Objectives and Overview .................................................................................. 4
1.3.
Document status ................................................................................................................ 4
2.
Actors......................................................................................................................................... 5
3.
USE case description .................................................................................................................. 5 3.1.
Use Case: Traffic monitoring & Traffic Information .......................................................... 7
3.2.
Use Case: Dynamic Fleet Management & Guidance .......................................................... 8
3.3.
Use Case: Pre-trip Information Services............................................................................. 9
3.4.
Use Case: Voice and Data Transfer .................................................................................. 10
3.5.
Use Case: Real Time Surveillance ................................................................................... 11
4.
References................................................................................................................................ 11
5.
Appendix A: A brief introduction to use case methodology....................................................... 12 5.1.
Use Case Bibliography .................................................................................................... 14
List of Figures Figure 1 Use case diagram of the ISKY system................................................................................... 6
List of Tables Table 1 Actors in ISKY system .......................................................................................................... 5
ISKY-functional requirements document DRAFT 2-Only for internal use
2
Last modified on 13 Nov. 2001
Acronyms and Abbreviations Acronym
Description
FCD
Floating Car Data
GIS
Geographic Information System
GPS
Global Positioning System
GSM
Global System for Mobile communications
Hq
Headquarter
IOC
International Olympic Committee.
ISKY
Eye In the Sky
OGC
Olympic Game Committee
SIM
Subscriber Identity Module
SMS
Short Message Service
VIP
Very Important Person
ISKY-functional requirements document DRAFT 2-Only for internal use
3
Last modified on 13 Nov. 2001
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 Information System (GIS). In addition, ISKY aims to provide back-up communications (with a guaranteed 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. Section 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 assumptions that capture the ISKY goals and objectives. Its aim is to specify some preliminary func-
ISKY-functional requirements document DRAFT 2-Only for internal use
4
Last modified on 13 Nov. 2001
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 system1. 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 lowaltitude platforms and floating car data
1
•
Voice and Data Transfer (service 2)
•
Sky-borne Surveillance (service 1 and 2)
A 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.
ISKY-functional requirements document DRAFT 2-Only for internal use
5
Last modified on 13 Nov. 2001
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 management package is concerned about fleet management and customised mobility information (service 1) while the emergency support package 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). EIS-System Boundary Box emergency_support 1 voice_data_ 1 transfer
1
1
1 1
1
1
1
sky_borne_ surveillance
public_ authority_ user
Mobile_ telecom_ operator
fleet_management
1
traffic_info_and_ monitoring 1 1
1 1
1
Media Dynamic_fleet_ management_ guidance
1
1 1
11
1 1
Pre_trip_Info_ Services
1 1
1 1
closed_user_ group_ headquarter
closed_user_ group_driver
Figure 1 Use case diagram of the ISKY system
The description of the above use cases is following.
ISKY-functional requirements document DRAFT 2-Only for internal use
6
Last modified on 13 Nov. 2001
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
Description
•
Public authority user
•
Closed user group (driver)
•
Closed user group (headquarter)
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 surveillance 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 System), 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 additional 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 the sky-borne surveillance use case. This is done whenever
ISKY-functional requirements document DRAFT 2-Only for internal use
7
Last modified on 13 Nov. 2001
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
Update rate
requirements 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 computer (laptop-palmtop-handheld etc.) is needed for processing incoming and outgoing 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 instructions. 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
ISKY-functional requirements document DRAFT 2-Only for internal use
8
Last modified on 13 Nov. 2001
Dependencies
It depends on the traffic monitoring use case
Constrains
Availability of GPS signal and GSM coverage
Non-
Positioning accuracy
Functional re-
Communication channel capacity
quirements 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
Description
•
Public authority user
•
Closed user group (driver)
•
Closed user group (headquarter)
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
None
requirements ISKY-functional requirements document DRAFT 2-Only for internal use
9
Last modified on 13 Nov. 2001
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
Description
•
Public authority user
•
Closed user group (driver)
•
Closed user group (headquarter)
This refers to a single closed GSM cell, whose hub is located on the Zeppelin. 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 allows 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
None
requirements Exceptions
None
Notes
None
ISKY-functional requirements document DRAFT 2-Only for internal use
10
Last modified on 13 Nov. 2001
3.5.
Use Case: Real Time Surveillance
Title
Real Time Surveillance
Goal
To Provide imagery of the area covered by the Zeppelin
Actors
Description
•
Media
•
Public authorities
The Zeppelin is equipped with special cameras, which regularly takes snapshots 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
Image resolution
requirements Exceptions
None
Notes
None
4. [ANN]
References Annex 1- Description of Work, Project: Eye in the Sky. Information Society Technologies (IST) program, March 2001.
ISKY-functional requirements document DRAFT 2-Only for internal use
11
Last modified on 13 Nov. 2001
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:
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 reactor
quiring the assistance of the system. A secondary actor is one from which the system needs assistance to satisfy the goal.
Use Cases Capture some user-visible function. A use case can be big or small, but it must capture an important goal of a
usecase
user for the system.
usecase
Association Lines show relationships between actors and use cases. actor
ISKY-functional requirements document DRAFT 2-Only for internal use
12
Last modified on 13 Nov. 2001
usecase
System Boundary set the boundary between the system under consideration and the external actors. Use cases go inside
usecase
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 expresses 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).
ISKY-functional requirements document DRAFT 2-Only for internal use
13
Last modified on 13 Nov. 2001
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 promises 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-
Performance, reliability, accuracy, fault tolerance, frequency of use, priority
Functional requirements 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. AddisonWesley, 1992 Booch, G., I. Jacobson and J. Rumbaugh, The Unified Modeling Language User Guide. AddisonWesley, 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 Approach. Addison-Wesley, 1999
ISKY-functional requirements document DRAFT 2-Only for internal use
14
Last modified on 13 Nov. 2001
