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 200
Table of Contents. Introduction... 4.. System Goals and Scope... 4.2. Document Objectives and Overview... 4.3. Document status... 4 2. Actors... 5 3. USE case description... 5 3.. 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... 0 3.5. Use Case: Real Time Surveillance... 4. References... 5. Appendix A: A brief introduction to use case methodology... 2 5.. Use Case Bibliography... 4 List of Figures Figure Use case diagram of the ISKY system... 6 List of Tables Table Actors in ISKY system... 5 2 3 Nov. 200
Acronyms and Abbreviations Acronym FCD GIS GPS GSM Hq IOC ISKY OGC SIM SMS VIP Description 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 3 3 Nov. 200
. Introduction.. 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 () 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)..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..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- 4 3 Nov. 200
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. Table Actors in ISKY system Actor s Name Public authority user Mobile Telecom operator Media Closed user group* (driver) Closed user group* (headquarters) Actor s Role in the ISKY system Ministry, traffic authority, civil protection service User of traffic information for re-distribution to subscribers TV, radio, Internet portal Individuals, VIPs, drivers in general 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 : Fleet Management and Customised Mobility Information Traffic Monitoring & Traffic Information (service ) Dynamic Fleet Management & Guidance (service ) Pre-trip Information Services (service ) Service 2: Emergency Support for Crises during large-scale events, based on the use of lowaltitude platforms and floating car data Voice and Data Transfer (service 2) Sky-borne Surveillance (service 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. 5 3 Nov. 200
Figure 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 ) 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 public_ authority_ user emergency_support voice_data_ transfer sky_borne_ surveillance <<Uses>> fleet_management Mobile_ telecom_ operator traffic_info_and_ monitoring <<Uses>> Dynamic_fleet_ management_ guidance Pre_trip_Info_ Services Media closed_user_ group_driver closed_user_ group_ headquarter Figure Use case diagram of the ISKY system The description of the above use cases is following. 6 3 Nov. 200
Title Goal 3.. Use Case: Traffic monitoring & Traffic Information Traffic monitoring & Traffic Information 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 Description 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; () 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. Preconditions Postconditions Dependencies 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. It depends on the sky-borne surveillance use case. This is done whenever 7 3 Nov. 200
Constrains Non-Functional requirements Exceptions Notes real-time imagery data needs to be compared to FCD in order to increase the reliability and accuracy of the traffic conditions Availability of GPS signal and GSM coverage Update rate 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 Goal Actors Description Dynamic Fleet management & Guidance To assist fleet management by providing vehicle tracking and co-ordination, dynamic route guidance and fleet information exchange. Closed user group (headquarter) Closed user group (driver) 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. Preconditions Postconditions 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. 8 3 Nov. 200
Dependencies Constrains Non- Functional requirements Exceptions Notes It depends on the traffic monitoring use case Availability of GPS signal and GSM coverage Positioning accuracy Communication channel capacity 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 Closed user group (driver) Closed user group (headquarter) 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 () 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 Postconditions Dependencies Constrains Non-Functional requirements User profiles must be registered 9 3 Nov. 200
Exceptions 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 Closed user group (driver) Closed user group (headquarter) Description 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. Preconditions Postconditions Dependencies Constrains Non-Functional requirements Exceptions Notes 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. GSM coverage of the closed cellular communication system. 0 3 Nov. 200
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 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. Preconditions Postconditions Dependencies Constrains Non-Functional requirements Exceptions Notes 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. Image resolution 4. References [ANN] Annex - Description of Work, Project: Eye in the Sky. Information Society Technologies (IST) program, March 200. 3 Nov. 200
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 requiring 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 Association Lines show relationships between actors and use cases. actor 2 3 Nov. 200
usecase usecase System Boundary set the boundary between the system under 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 Title Goal Actors Description Preconditions Description A descriptive unique name of the use case The main business goal of the use case List of actors involved in the use case 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. 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). 3 3 Nov. 200
Postconditions Dependencies Constrains Non- Functional requirements Exceptions Notes 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. Other Use cases, which the current use case depends on (i.e. hierarchical dependencies through Extends and uses relationships) Any restrictions that must be addressed concerning the use case Performance, reliability, accuracy, fault tolerance, frequency of use, priority Nature of the exception and the recovery step in the scenario to return to Any notes 5.. Use Case Bibliography Ivar Jacobson. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison- Wesley, 992 Booch, G., I. Jacobson and J. Rumbaugh, The Unified Modeling Language User Guide. Addison- Wesley, 999, pp. 29-24. Geri Schneider, Jason P. Winters. Applying Use Cases. Addison-Wesley, 2nd edition, 200 Doug Rosenberg, Scott Kendall. Use Case Driven Object Modelling With UML: A Practical Approach. Addison-Wesley, 999 4 3 Nov. 200