George Veranis

James Lockerbie

Thanassis Parathyras

Antonis Papadakis-Pesaresi

Guglielmo De Angelis

Valerie Issarny

Rokas Bartkevicius

Keywords: Case, DynaRoute, assessment, requirements, scenario definition, demonstration, Mobile Internet Device CHOReOS

The purpose of this deliverable is to clarify the individual actions that take place among different actors of the "DynaRoute" scenario, as initially described in the DoW. People, services and Smart Things interact with each other synthesizing choreographies throughout the entire sequence of steps that compose the scenario which supports this specific use case of the CHOReOS project. This document also provides the involved in the "DynaRoute" use case domain experts" requirements through a detailed requirement analysis. Moreover this deliverable presents an abstract overview of choreographies that take place in use case of "DynaRoute". In the end of this document addressed the methods of the assessment specifications that will be applied in demo and pilot application.

Introduction

This document is the work product of Task 8.1 of the DoW, under the title "Scenario Definition & Requirements Analysis". It constitutes the first report of work package 8 aiming to record specifications, requirements as well as the design for the demonstration activities of the "DynaRoute" use case of CHOReOS project. Moreover, it specifies assessment methods to be used progressively during the work schedule, until a pilot, real-world demo application shall be released. The aforementioned pilot application will cover only a subset of the demonstrator that will be developed in the laboratory environment.

The purpose of this deliverable is to clarify the individual actions that take place among different actors of the "DynaRoute" scenario, as initially described in the DoW. People, services and Smart Things interact with each other synthesizing choreographies throughout the entire sequence of steps that compose the scenario which supports this specific use case of the CHOReOS project. The choreographies in the subject use case demonstrate a dynamic and adaptive behaviour, in order to respond to the challenges of the Future Internet.

In addition, this document mainly provides the involved in the "DynaRoute" use case domain experts" requirements, along with a comprehensive list of requirements for the demonstrator applications. Despite the fact that the same requirements stand for the pilot application, this real-world demo is bound to be defined during the implementation phases that follow.

The rest of this document is organized as follows:

 Chapter 2 deals with the detailed description of the use case and identifies the roles of each participant. More specifically, we record the involved services that participate in the synthesis of "DynaRoute" choreographies, while providing eligible description for each one as well. The definition and specification of the choreographies is also presented in this chapter.  Chapter 3 provides the requirements based on a story board. In this story board we extracted the specifications as those were defined by the stakeholders using the appropriate methodology.  Chapter 4 presents the seven choreographies as these are formed from definitions, requirements and specifications in chapters 2 and 3. In this chapter the choreographies are presented providing a specific description, yet showing an abstract view, using the BPMN 1 standard.  Finally, Chapter 5 describes the strategy through which it is possible to get valuable results from the laboratory and the real world demonstration, as soon as the DynaRoute demonstrator will be implemented.

It is crucial to note at this point, the section 2.3.5, that provides a response to the FI challenges tackled in the "DynaRoute" use case. Enumeration and scalability dimensions of the demonstrated applications are also presented, in order to investigate the possible impact of the use of these choreography-based applications in citizens" life.

CHOReOS 3 FP7-257178

Scenario Definition of Use Case "DynaRoute"

Overview description of scenario

The goal of the "DynaRoute" scenario is to illustrate a use case of tools and software developed under the CHOReOS project. The scenario description that defines "DynaRoute" sequence of events is provided in table 2.1.

Step Scenario Description

Start Collista is flying today back to Brazil after a 2-week vacation in Thessaloniki, Greece! 1 An itinerary is fixed for her by her Mobile Internet Device, a.k.a. MID (which can be PDA, smart phone, netbook), in order to spend her last day in Greece most efficiently (and not miss her flight, too!).

The schedule contains: a 2-hour shopping spree, 1-hour site-seeing and finally a taxi drive to the airport.

After getting up late and talking a bit more on the phone with her boyfriend, she is ready to leave her hotel, however, being 2.5 hrs behind schedule! 3 As a result, her MID modifies on-the-fly her itinerary and she is now instructed to skip the shopping and site-seeing and ask right away for a taxi; she confirms her device"s suggestion and leaves the hotel immediately.

4

Collista waits for a taxi by the street, outside the hotel. MID sets on a "waiting for taxi" beacon transmitting locally its position and the desired destination coordinates.

5

A nearby passing taxi receives the mobile device's beacon message. The taxi GPS device notifies the driver for the request. He accepts, and an acknowledgement is sent to Collista"s device.

6

The taxi driver reaches the place where Collista is waiting. Her MID receives the taxi's acknowledgement and notifies her to enter the taxi. The MID gives the airport destination to the taxi"s navigator and an optimal route is computed.

7 While heading to the airport, the airport authorities announce a 3-hour delay for Collista's flight and the airline sends a 3G (cellular) notification to Collista"s device.

Collista's device receives the notification and re-evaluates its itinerary. Collista can still do her shopping and site-seeing! (She confirms ecstatic, responding to her device"s suggestion!)

9

A new destination (e.g., Tsimiski Str., the main shopping street of Thessaloniki) is set by the device and provided to the taxi's navigator. The navigator computes the new route and re-routes the taxi to Tsimiski Str., (confirming to the device a 20 min drive delay). Step Scenario Description device in range, as they are both in each other's access lists and user directories.

13

Valeria sends a "request for a short meeting" to Collista, including coordinates of the café, where Valeria is sitting at; Collista accepts and her mobile device sets a route to the café. At some point Collista's MID reminds her that the site-seeing is due, so Collista tells her boss that she has to leave.

16

Collista waits for a taxi by the street (again, same sub-scenario as above, at the hotel). 17 Collista's MID provides the taxi's navigator with the desired sequence of destinations for site-seeing.

18 While passing by the White Tower, the monument's beacon broadcasts a message, inviting tourists for some tourist info or tour. The MID relays this message to Collista and she accepts the info stream.

19 After evaluating their velocity, the Tower decides to transmit to them the short version of the tour and not call for a tour guide.

20

While site-seeing, a traffic-info message is relayed to the taxi driver (from another taxi, passing nearby), indicating a traffic jam at the Ring-Road, due to a car accident. (The Ring-Road is on Collista's way to the airport).

21

The taxi's navigator 'thinks' it's wise to inform Collista's mobile device about this ~45 min estimated delay.

22

Collista"s MID realizes that the site-seeing must be interrupted and the taxi should head to the airport. So, it sends a "new destination" (= the airport's) coordinates to the taxi's navigator, the navigator computes the shortest route and reaches the airport in time! 23 Collista gets off the taxi and waits for a porter to carry her 3 pieces of luggage; Her device sets a "request luggage porter" beacon.

24

A nearby available porter receives the beacon request and moves to the given coordinates.

25

The porter picks up Collista's luggage and his MID checks with the Departures service, in order to make sure he has enough time to pick up some more luggage. Meanwhile, Collista has some free time to spend shopping and browsing around.

26

Upon the airline"s notification, the porter takes Collista's luggage to the check-in counter and notifies Collista"s device (and others") to meet him at the airline"s check-in counter.

End

Collista is happy for spending her time efficiently and her mobile device is happier for serving its boss wisely! The above described scenario is depicted in Figure 2.1. External events triggering changes during the play of the scenario are noted along the different steps. Some of the internal steps described in table 2.1 have been merged, in order to achieve the expected visual understanding for this use case.

Method of scenario development

In the following sections we define the main services of the "DynaRoute" scenario and we show how each individual service interacts with other services to produce the next logical step for the choreography. We follow a "bottom up" approach where we identify the communication requirements that are actually met through services and then introduce the actors of the scenario. Afterwards, we describe the inputs and outputs of each service and how they interact with each other so in the end they all form respective choreographies (specification of the choreographies is refined in 2.3.4). All involved parties in this use case include People, Services and Things, which have been initially defined in deliverable D1.2 "Choreos perspective on the Future Internet and Initial Conceptual Model" [START_REF] Bartkevicius | D1.2 "Choreos perspective on the Future Internet and Initial Conceptual Model[END_REF].

In the beginning of the scenario Collista sets the basic requirements for her schedule of the day. A personal itinerary is created by her intelligent assistant MID, in order to spend efficiently her last day in Greece and finally catch up with her flight. The schedule created for Collista contains a 2-hour shopping spree, 1-hour site-seeing and finally a taxi drive to the airport. The exact details of the schedule (which retail store, which tour guide) are either predefined by Collista herself or are approximated by MID, based on some pre-existing FP7-257178 preferences by Collista. In any case MID must contact a number of services in order to obtain the current information on the details of the schedule. The interaction between the services initiates the first and main choreography of our scenario, namely the C1 -contextaware adaptive itinerary choreography.

Unfortunately, Collista gets up late and is now ready to leave the hotel 2.5 hours behind schedule. MID discovers this delay by using core functionalities and sensors of the device such as the clock (or the GPS sensor as described later) and triggers a notification that the schedule has changed so as to modify on-the-fly the itinerary and meet the new change in time. So, MID instructs Collista through notifications to skip shopping and sightseeing and ask immediately for a taxi. Collista proceeds to confirm this notification and leaves the hotel immediately.

Collista has checked out of the hotel and is waiting on the road for a taxi. Through MID, she sets up a beacon service asking for available taxis in the area. An available taxi receives the beacon message and after the necessary criteria have been met, picks up Collista at the predefined GPS position and sets route for the airport. In a more general fashion, this interaction between m people and n taxis, where the various services attempt to assign a subset of people to each taxi in a dynamic way, represents the C2 -co-taxi-ing choreography.

Following the scenario, Collista"s MID is informed about a 3-hour delay of the flight so it notifies Collista about this change in schedule. After Collista acknowledges this notification, MID proceeds to dynamically re-evaluate her itinerary and re-organize the shopping and sightseeing tasks in her schedule. After this change of plan, Collista has time for shopping and sightseeing so she selects a new (shopping) destination. The taxi's infrastructure receives the new destination coordinates from Collista's MID which passes them along to the navigator to compute the optimal route. In this case, we have one airline and m passengers where upon notification from the airline, the passengers" schedule is modified and adapted accordingly. This is the C3 -distributed alert system choreography, where services communicate with each other in order to broadcast critical information notifications.

After Collista arrives at the new destination and exits the taxi, her MID receives a new beacon message that says "70% sales on shoes" that is coming from a nearby shoe-store. Collista accepts this notification and the shop"s coordinates are confirmed in MID which navigates Collista to the shop.

However, while Collista was shopping, her boss Valeria happened to be nearby. Valeria's MID used the social proximity service to identify that Collista's MID is in range, as they are both in each other's access lists and user directories. Note that in order for this scenario step to work, both MIDs should run these services so they can exchange instant messages and set up a relationship. In this context, when Valeria's and Collista's MIDs have been authenticated and validated for further communication, Valeria sends a "request for a short meeting" notification to Collista including coordinates of the cafe where Valeria is sitting etc. Collista accepts by sending a notification to Valeria and her MID sets a route to the cafe. Finally, Collista and Valeria meet and talk over frappe (greek coffee). This "social interaction" of services represents the C4 -context aware, distributed ad hoc social networking choreography, where the main focus point is to establish social relationships through people with the use of instant messaging.

Sometime after, Collista's MID notifies her that the sightseeing is due, so Collista tells her boss that she has to leave. At that point, Collista repeats the same step of the scenario when she was outside the hotel. A beacon service is activated and soon a nearby taxi responds to the request and picks up Collista and her itinerary is resumed. FP7-257178

While passing by the White Tower, its beacon service broadcasts a message inviting tourists on a guided tour. MID notifies Collista about this event and she continues to respond "I am mobile user, need only text description" and accept the info stream on her MID. Since she is on a tight schedule (and a moving taxi) she does not have enough time for a guided tour, so she can only accept text/video messages on MID. Monument infrastructure service acknowledges this and transmits the short tour and does not call for a tour guide. This is the C5 -context-aware, touristic guide choreography, where we have a main monument infrastructure that transmits (and accepts) information from n tourists.

Collista continues sightseeing however at some point a traffic-info message is delivered to the taxi infrastructure indicating a traffic jam on the Ring-road (which is Collista's way to the airport) due to an accident. This happens because other taxis that have already passed from the Ring-road have notified the traffic detection service about the traffic conditions in the area and the service has concluded that there is a significant traffic jam. During Collista"s trip to the airport, the taxi"s infrastructure polls the traffic query service for possible traffic jams along the route. When a traffic jam is detected, a notification is sent to Collista to modify her itinerary. In this event, the sightseeing stops prematurely and Collista begins heading to the airport. During these steps of the scenario there are a number of services that run on taxis that report traffic, a main traffic detection service and a traffic query service; this is the C6distributed ad-hoc traffic management choreography.

As soon as Collista arrives at the airport and exits the taxi, she setups a beacon message requesting a luggage porter. After some time a porter comes which qualifies the criteria that Collista has given. If the porter has enough time he arranges to pick up more luggage. Meanwhile, Collista continues shopping and waits for the check-in opening. Porter"s MID checks the departure table of the airport. When specific flight"s time is due, porter"s MID issues a notification to all flight passengers MID"s that he is carrying their luggage to meet at the check-in counter. This way Collista"s MID notifies her to meet the porter at the airline's check-in counter. This procedure synthesizes C7 -personalized, airport ground service choreography, which is quite interesting for our use case since it involves services of many different types and different actors.

All aforementioned communication between actors (services & people) represent the basic sources of information that Collista"s MID has to interact with in order to establish a welldesigned and flexible schedule.

The "DynaRoute" scenario

In the following sections we elaborate the scenario description, in order to clarify the main characteristics of the involved actors. People, Things and Services that participate in this scenario, are defined as the actors of the scenario. The last section of this chapter gives the choreographies description, as the synthesis of their components.

People

During the play of "DynaRoute" scenario, people are the end users of applications provisioned by choreographed services. Choreographies that are demonstrated by this scenario provide applications in the transportation and traveling living of citizens.

People that participate in the "DynaRoute" scenario are:  Citizen Collista is a citizen that acts as an airplane traveler, taxi passenger in city routes, shops/mall visitor, tourist sightseeing, social life actor, airport guest.

Valeria is a citizen that acts as a friend of Collista, also her boss and social event participant. FP7-257178

 Taxi driver These actors provide taxi service by making use of electronic call system and traffic information.

 Porter

Acts as the professional to provide luggage transfer service for the airport guests.

Services

The main philosophy behind these services is that they accept as inputs some predefined parameters such as date & time etc. and return as output the availability of the service with any additional limitations and general information that is needed. As mentioned before, MID is the main presentation media to Collista for the synthesized result that these services provide. Also, MID itself provides services that participate as well in the synthesis process.

The services that play role in the scenario "DynaRoute" are the following:  Device pairing service Description: Each mobile device is able to pair with another device for exchanging information such as schedule changes and beacon messages.


Provided by: Citizen"s MID, taxi"s navigator Inputs: the ids of the devices to be paired Outputs: a pairing connection  3G Access service Description: Each mobile device is able to access the internet using this service and exchange information with other devices. Provided by: Citizen"s MID, taxi"s navigator, Porter"s PDA Inputs: N/A Outputs: an internet connection  POI maps Description: POI query service Provided by: Web service Inputs: POI/area, category Outputs: a list of POI coordinates  User preferences Description: This service compiles all the user preferences in categories while simultaneously being accessible to new information about schedule changes and general information that may affect the user"s preferences on the schedule. Provided by: Citizen"s MID Inputs: various user preferences Outputs: a chronological schedule of the to-do tasks of the user  Airline announcement service Description: A service that is responsible for the information announcement for specific flight(s) and/or corresponding passengers. Provided by: Airline server infrastructure through Future Internet Inputs : airline's flights of the day, passenger list for each flight, general announcements Outputs : notifications for flight's status (cancellation, delay etc.), notification on special offers [optional], personalized notification for clients (e.g. updated on miles status)

[optional]  Navigation Description: A service provided by specialized software such as a navigator, that offers navigation instructions to the user. Provided by: Citizen"s MID, taxi"s navigator Inputs: satellite signal (GPS) Outputs: navigation instructions  Retail store info service (shoe-store)

Description: Announcements and information about the store is provided in a specific range of local area (approx. 100m).

Provided by: Store"s wireless infrastructure Inputs: date & time & duration of visit, abundance of specific products [optional] Outputs: feasibility of visit, abundance of specific products [optional], special offers notification messages by the shoe-store.

 User directory

Description: A sorted catalogue of the people that the MID"s owner is associated with. Provided by: Citizen"s MID Inputs: N/A Outputs: sorted catalogue of contacts FP7-257178

 Social proximity service Description: A service that enables social interactions (meetings setups, instant messaging) based on proximity criteria. Provided by: Citizen"s MID Inputs: user directory Outputs: validation of the user"s proximity

 Instant messaging

Description: A service that offers instant send-and-receive messages between people that belong in each other"s user directory.

Provided by: Citizen"s MID Inputs: N/A Outputs: instant messages  Traffic detection service Description: A service that detects area traffic based on incoming messages received by taxis.

Provided by: Taxi company infrastructure services Inputs: incoming traffic messages by taxis Outputs: traffic conditions of areas  Traffic query service Description: A service that receives requests for traffic information about the ongoing traffic on the taxi"s area.

Provided by: Taxi company infrastructure services Inputs: traffic information request messages Outputs: traffic information messages  Airport departures announcement service Description: A personalized information services offered by the airport on flight status and general information.

Provided by: Airport infrastructure services Inputs : traveller information Outputs : departures times of flights, general information

Smart Things

Things involved in the "DynaRoute" scenario are smart phones, PDAs, laptops and taxis" GPS navigators of involved people. The devices in this scenario provide the way to interact between choreographies and people, while utilizing its built-in features to participate the choreographies itself.

In the context of "DynaRoute" scenario actors are equipped with Mobile Internet Devices, that except the interconnection capabilities they provide also carry sensors and are featured with traditional service applications:  Citizen's MID This device could be an Android Smart Phone equipped with 3G, GPS, clock, calendar, device pairing (bluetooth), beacon RX/TX, user directory and audio/visual notifications.

In the "DynaRoute" scenario, this type of device is owned by Collista and Valeria.

 Taxi's GPS navigator device

This device could be an Android Smart Phone with special GIS software like MLS Destinator or a dedicated GPS device from MLS series with Internet connection feature. Characteristics for this device include GPS, navigation service, device pairing (BT) and beacon RX/TX. FP7-257178  Porter's MID This device could be an Android Smart Phone or Android tablet equipped with GPS, clock, beacon RX/TX and audio/visual notifications.

Choreographies

The components of choreographies are services, as they have been described in the previous section 2.3.2. In this section we describe, for each choreography in "DynaRoute" use case: (i) features provision, (ii) goal to achieve and (iii) components (services) to synthesize. In the following list (i) and (ii) are presented:  C1 -Adaptive itinerary The Adaptive itinerary choreography C1 represents the main choreography of the "DynaRoute" scenario. It is synthesized and initiated by the MID"s services and starts executing with a predefined schedule of activities. External events from services or other choreographies trigger adaptive behavior in the itinerary. Also self awareness contributes in the interaction with other services and choreographies.

 C2 -Co-taxi-ing

The Co-taxi-ing choreography C2 is dynamically synthesized among m people and n taxis, attempting to assign a subset of people to each taxi.

 C3 -Distributed alert system

The Distributed alert choreography C3 is synthesized between one airline company and m passengers, It provides notifications about the passenger"s flight such as possible delays, change of departure gate, personalized offers etc.

 C4 -Distributed ad-hoc social networking

The Distributed ad-hoc social choreography C4 is dynamically synthesized between two persons. Its instantiation is based upon the existence of the persons" identities in each other"s access lists and/or user directories and is triggered from proximity criteria. After the initial recognition both MIDs exchange credentials so as to verify the relationship and further options are revealed to [ACTOR-owner/s of MID] such as greeting notification, appointment request etc.

 C5 -Tourist guide

The Touristic guide choreography C5 is dynamically synthesized among 1 monument and n nearby tourists. It is instantiated upon proximity criteria and it is highly adaptable so as to match the tourist"s interest and traveling status for a short and fast (text-only) description, a longer video or a regular guided tour.

 C6 -Distributed ad-hoc traffic management

The Distributed ad-hoc traffic choreography C6 is synthesized among m taxis. This choreography is based on the notion that each taxi is able to identify traffic jams independently and pass this information along from taxi to taxi, hop by hop, in a fully distributed fashion.

 C7 -Personalized airport ground service

Personalized airport ground choreography C7 is synthesized between m travelers and n porters whereas each porter selects which traveler to serve. FP7-257178

These seven choreographies interact each other during the "DynaRoute" scenario is being played. The main choreography is C1, which adapts events created or triggered by the other choreographies. Following we provide a picture (figure 2.2) presenting the choreographies synthesized and the relation among them. The interaction can be bidirectional or single-directional, denoting a "dialogue" of messages between choreographies in the first case and an external trigger event in the former case.

"DynaRoute" choreographies are presented in further detail and also specified using the BPMN standard in Chapter 4.

Each choreography is a synthesis of various services, as described in section 2.2. We provide a mapping of the composed services for the choreographies of DynaRoute in the below table 2.2.

Choreography

Use Case "DynaRoute" and FI Dimensions

The main goal of this use case is to demonstrate the service and innovation levels that users could gain while in the same time considering that the requirements in Future Internet are extremely challenging. "DynaRoute" actors as described in this report involve People, Services and Things introducing this way all of the requirements and challenges in the Future Internet as already described in deliverable D1.2 "Choreos perspective on the Future Internet and Initial Conceptual Model" [START_REF] Bartkevicius | D1.2 "Choreos perspective on the Future Internet and Initial Conceptual Model[END_REF].

The central storyline in the "DynaRoute" scenario anticipates for an "Adaptive Itinerary" software management application. In this use case, this is synthesized as a choreography of services among Smart Things and Business Services interacting with People. The requirement for adaptability is demonstrated from the fact that external events can be managed on the fly, as well as interaction with third party provided applications, to modify or perform actions listed in the itinerary of a user. User preferences, situation (location, time) FP7-257178 and external constraints (traffic jam) are also computed in the "Adaptive Itinerary" application covering other adaptability and awareness requirements of this application. The concept of awareness is then again demonstrated in the applications of "ad-hoc Social Networking" and "ad-hoc Traffic Management". In the first application a choreography is synthesized between Smart Things of the users, to utilize MID location sensors and user preferences friend list, in order to provide social networking using proximity criteria. The second application provides traffic management services for taxis in a city, by synthesizing location and speed sensors along with map services.

One critical challenge that we need to respond is the very large number of the networked entities and users in the Future Internet. In the table 2.3, we provide estimated numbers of the actors that are involved during "DynaRoute" use case. The estimate is based on empirical approach for a city with 500 thousands population. Although the scenario story describes the point of view of the citizen (Collista), the same scenario could be played in parallel for other citizens in the same regional area. For our estimation we assume a medium populated city of 1 million citizens (like Thessaloniki), as the regional area that the choreography-based software applications are deployed. One significant characteristic of this scenario is the use of Location Based Services. The same software application can be provided across several cities in EU or global, which could multiply the above numbers of involved actors (people, services, things). The choreography provided applications could be concurrently available to citizens of several cities concurrently. Thus, the distributed nature of choreographies deployment demonstrated in "DynaRoute" use case can allow a really large number of citizens to take advantage of services, that for the time being are provided by centralized web services, like navigation and map service or social networking. According to the statistics provided by Eurostat for "Population and living conditions in Urban Audit cities, larger urban zone" [START_REF]Population and living conditions in Urban Audit cities, larger urban zone (LUZ), Total population in Urban Audit cities[END_REF], across the EU there are 140 cities with over 500 thousand people population, which citizens" could take advantage of choreography-based software application like these demonstrated in the "DynaRoute" scenario. FP7-257178

Type of Actors DynaRoute Actors Number Estimate

People

Requirement Analysis

A detailed requirements analysis was used to identify the specifications and functionality of services and choreographies for the "DynaRoute" use case. The requirements specification specifies both functional and non-functional characteristics for the assessment of the solution developed within the CHOReOS dynamic development process.

Methods for eliciting and managing requirements

The requirements process for CHOReOS builds upon a method developed for the EU Framework VII MIRROR integrated project 2 . High level requirements are elicited using a structured scenario-based approach. Using the scenario as a means of requirements elicitation enables the requirements analyst to ground questions in context through the sequence of events in the scenario.

To present the scenario to stakeholders, a storyboard was developed featuring one frame per event, or scenario step, and a section for requirements related to that action. Figure 3.1 shows a detailed example from the storyboard containing:  Notes section including the event description, choreography (NB there are 7 choreographies labeled A to G) and questions related to the event and areas for further exploration.  Storyboard frame including a pictorial representation of the event and a section containing the involved actors, devices, services and the choreography.  Requirements table for documenting the requirement, rationale (in case the purpose of the requirement is not clear), type and owner.  Assumptions table for documenting statements of fact that are assumed true for the actions in the scenario step to happen. By walking through the scenario, the aim of the process was to capture user and system requirements from the stakeholders according to a set of requirements types. Taxonomies of requirements are used to improve understanding, analysis and testing of the solution. The following types were specified for the DynaRoute use case to be used for the elicitation exercisesee Table 3  Mr. Dimitris Paraschos (MLS) for mall requirements, given his previous experience working in this domain.  MLS team members for airport requirements. The selected stakeholders had experience of similar projects in the airport domain.

City University London facilitated a requirements scenario walkthrough workshop on 3 rd June 2011 with Mr. Mantelos Dimitris along with partners from MLS and VTRIP. The result was a set of 58 requirements, which were specified at one of two levels:  System-wide requirements which relate to the system as a whole  Action-level requirements which relate to an individual step in the scenario Following the workshop, stakeholders from MLS added a further 17 requirements for the scenario steps related to the mall and the airport. The requirements are detailed in the following two sections.

System-wide requirements

System-wide requirements are the high-level requirements that express desirable properties of the system as a whole. The following requirements were captured during the scenario walkthrough:  FR005: The service consumer shall be able to request higher prioritization regarding calls or arrangements made using MID  SR001: MID data shall be encrypted to not reveal service consumer details [Security -Privacy]  IR001: MID shall be able to transmit data to different devices/services/servers Additionally, a set of high-level future internet requirements specific to the "DynaRoute" scenario and systems is presented in CHOReOS deliverable D1.2. These cover the requirements types: scalability; interoperability; mobility; awareness and adaptability. FP7-257178

Requirements presented by scenario step

Action-level requirements are the more detailed requirements that relate to the individual steps in the scenario. The following requirements were captured during the scenario walkthrough with stakeholders and subsequent follow ups. The graphical representations of each scenario step are simplified version of the rich pictures used in the actual scenario storyboard (presented in Annex A).

Notes

The requirements were given a type and number identifier according to the order in which they were elicited.

 Requirement specific to scenario step (event) o Requirement shared by more than one scenario step  Requirement from scenario step specified as a system-wide requirement [Supporting information] For requirement type codes see the glossary.

"MID" refers to the traveller"s intelligent mobile device. Other devices are specified by actor e.g. Porter"s MID.

Start

Choreography C1

 FR003: Traveller shall be able to arrange beforehand when the taxi shall arrive  FR004: Taxi company shall be able to receive a confirmation a couple hours before the reservation time from MID  FR006: Traveller shall be able to subscribe to VIP taxi subscriptions to enhance prioritization  FR007: MID shall be able to receive weather forecasts  FR005  IR001  SR001

Assumptions:

The taxi company do not accept reservations of less than 1 hour from the time of the request FP7-257178 4. Collista waits for a taxi by the street, outside the hotel. The intelligent device sets on a "waiting for taxi" beacon transmitting locally its position and the desired destination coordinates.

Directory of taxis

Taxi company

Taxi details (e.g. taxi number, arrival time)

Choreography C2

 FR012: MID shall be able to transmit traveller (customer) details to the taxi company  FR013: MID shall be able to display the taxi number that will pick up the traveller (customer)  FR014: Traveller shall be able to know how long it will take for the taxi to arrive  FR015: Traveller shall receive an alert with regards to how long it will take for the taxi to arrive  AcR001: Traveller shall be able to receive the position of the taxi with an accuracy of 30m radius  FR016: MID shall allow the traveller (customer) to change the pickup location and position and inform the taxi company of the changed location  FR017: MID shall be able to inform the traveller (customer) just before the taxi arrives  FR018: Taxi company shall be able to send another taxi in case of problems with original taxi [MID receives new details]

Assumptions:

Only one set of customer(s) for every taxi -cannot take other customers apart from the one who called (currently in Greece) FP7-257178

6. The taxi driver reaches the place where Collista is waiting. Her MID receives the taxi's acknowledgement and notifies her to enter the taxi. The MID gives the airport destination to the taxi's navigator and an optimal route is computed.

Route info

Choreography C2

 FR019: Navigator shall be able to show the coordinates graphically  FR020: Taxi driver shall be able to recognize customer, not only "optical" recognition  IR002: MID shall be able to transmit destination details to taxi navigation device (wireless, bluetooth)  IR003: Navigator shall be able to accept navigation details sent by MID

Assumptions:

Greece: taxi company cannot send navigation information to taxi driver on his navigation device

While heading to the airport, the airport authorities announce a 3-hour delay for

Collista's flight and the airline sends a 3G (cellular) notification to Collista's device.

Airport Auth.

Airline

Choreography C1

 FR023: MID shall be able to send a reminder regarding the itinerary  FR024: MID shall be able to detect the phase of the itinerary o AvR001: MID"s location service shall be able to access the servers at all times ( hot-spot wi-fi ) ] FP7-257178

Choreography C5

 FR033: MID shall be able to retrieve locations of souvenir shops (or shops, restrooms, etc.) nearby  FR034: MID shall be able to retrieve opening times, events that happen at particular days/times  FR035: MID shall be able to filter attractions depending on a user profile

Taxi driver

Traffic notification

Other taxi driver

Traffic notification

Choreography C6

 FR036: Taxi driver shall be able to inform of their location and the problem they may encounter on that route  FR037: MID shall be able to retrieve current status of route (red, yellow, green indicators)  MoR001: MID shall receive information from the MLS Map Services Provider to detect traffic situations  RR001: Ad hoc mobile sensor network service shall provide reliable traffic jam information that relates to everyday situations [>certain %]  AvR002: Ad hoc mobile sensor network service shall provide traffic jam information that relates to sudden and unusual situations that is available within

Choreography C7

 FR047: Porter"s MID shall receive the beacon message from the porter beacon service  FR048: Porter shall be able to express their availability through their MID in response to a beacon request  FR049: Porter"s MID shall receive further customer details and position data after porter availability has been sent FP7-257178

25. The porter picks up Collista's luggage and his intelligent device checks with the Departures service, in order to make sure he has enough time to pick up some more luggage too. Meanwhile, Collista has some free time to spend shopping and browsing around.

Choreography C7

 FR050: Traveller shall be able to confirm porter"s beacon message for pickup and send flight details using MID  FR051: Porter"s MID shall receive transmitted data for flight details  FR052: MID shall be able to receive data for a shop"s offer in the airport based on the traveller"s (customer"s) profile  FR053: MID shall able to schedule a walk to the airport"s shops based on a flight time

Upon the airline's notification, the porter takes Collista's luggage to the check-in counter and notifies Collista's device (and others') to meet him at the airline's check-in counter.

Porter <<Device>> Porter MID

Flight departures Service

Receive notification from airline/notify travellers

Traveller

<<Device>> MID

Luggage service

Luggage to check-in notification

Choreography C7

 FR054: Porter"s MID shall be able to receive notification from airline company based on traveller"s flight schedule  FR055: MID shall be able to receive notification to go to check-in from porter/luggage service  AcR005: MID shall recognize porter"s MID within a 5 meter range End: Collista is happy for spending her time efficiently and her mobile device is happier for serving its boss wisely! FP7-257178

Summary and analysis of requirements

In total, 75 requirements were specified during the elicitation process. The requirements specified were mainly functional, 56 of them, and these added detail and definition to the steps in the scenario. There was a good coverage across the non-functional requirements types, with 19 specified in total across 9 types. However, there were no requirements specified for the scalability, adaptability and maintainability types. In the case of scalability and adaptability, requirements in these areas are defined in deliverable D1.2. A breakdown of the requirements by type is presented in Table 3

Analysis with respect to the FI challenges and requirements

In this section, the five main FI challenges and requirements from deliverable D1.2 are analysed with respect to the requirements elicited from the scenario.

Awareness and Adaptability

Both context and self-awareness are needed in the DynaRoute scenario. For example, in step 12 the detecting of other devices is required:

AwR001: MID shall be able to detect nearby "friends"

Self-awareness is important as mobility increases, as is self healing, optimization, configuration and maintenance. It is worth noting here the lack of maintainability requirements elicited during the scenario as there will be no IT support for the actors. Self manageability will be required to support the mobility requirements in the scenario.

Monitoring and measurement is a key feature of the DynaRoute environment, in particular for traffic monitoring and awareness of tourist attractions. For example, the traveller is made aware of nearby attractions and the route is adjusted dynamically: FP7-257178

AwR002: MID shall be able to dynamically change route depending on nearby attractions Fast recovery, reliability, incident detection and analysis are major requirements for DynaRoute to support the overall service provided to, and consumed by, the end users. Levels of seconds should be considered as the minimum acceptable recovery times. Many of the elicited requirements need to be supported by reliability and recovery. An obvious example in this scenario is the notification of flight status from the airline, which is a key requirement for the passenger to reach their main goal to fly home:

FR041: Airline service shall send flight status notifications to passengers

For adaptability, we can use the example of the context-aware adaptive itinerary. This choreography adapts to different circumstances and interacts with all of the other choreographies. For example, in step 8 the itinerary is re-evaluated based on the notification of the flight delay. The ability to adapt to new circumstances is needed and reflected in requirements such as:

FR042: MID shall have the ability to evaluate the importance of information and notify the traveller accordingly FR021: MID shall be able to inform navigator about changed coordinates

Interoperability

A number of different devices will need to be supported, as reflected in the system-wide requirement:

IR001: MID shall be able to transmit data to different devices/services/servers This requirement applies across the whole scenario and supports interactions between travellers, friends, porters etc. via their devices. An example implementation of this requirement is:

IR002: MID shall be able to transmit destination details to taxi navigation device (wireless, bluetooth)

Dynamic content integration is an important consideration, particularly concerning multiple data views in the information exchange between taxis and through information transmitted by the airline, for example:

IR003: Navigator shall be able to accept navigation details sent by MID IR004: MID shall be able to receive and decode the information transmitted from the airline service DynaRoute relies upon dynamic service composition in all of the choreographies. For example, the following requirement captured in step 26 associated with the context-aware personalized airport ground service (NB recorded as a functional requirement):

FR055: MID shall be able to receive notification to go to check-in from porter/luggage service Overall, many of the user requirements across all 7 choreographies depend on the systemwide interoperability requirements.

Mobility

The nature of the DynaRoute scenario is one of mobility and features strongly in the choreographies. For example, native support/integration of mobility is required for the ad hoc mobile sensor network service in step 20:

MoR001: MID shall receive information from the MLS Map Services Provider to detect traffic situations This requirement also depends on routing efficiency, stability and robustnesscaptured in the reliability requirement:

RR001: Ad hoc mobile sensor network service shall provide reliable traffic jam information that relates to everyday situations [>certain percentage] FP7-257178

Finally, it is important to consider the resource demands of mobile devices, in particular battery power. For the traveller, the scenario presented may cause issues regarding battery life which supports the vast majority of the user requirements.

Scalability

Scalability can be viewed from a number of dimensionsthe number, size and quality of networked entities; storage (scale and size of content and sensors" data); discovery (search and retrieval); streaming data, addressing and naming. However, no specific scalability requirements were elicited from the scenario walkthrough. This may be because users have the tendency to express requirements from their own perspective and do not consider the scale involved with other users, devices, services etc.

For the number and size of networked entities, an example where this requirement is appropriate is in step 7 where the airline notifies all of the passengers of the delay. The following requirement depends on the message scaling to all passengers concerned: FR041: Airline service shall send flight status notifications to passengers Storage is not expected to be an issue and is not a focus of CHOReOS. The elicited requirements seem to assume that devices will be able to store the size of data required, for example the user profile:

FR035: MID shall be able to filter attractions depending on a user profile Discovery is a challenge, as demonstrated in the example of matching friends with different itineraries and geographical areas in the context-aware social network. For example, the following requirement needs to be scalable across many users:

FR025: MID shall be able to upload the location and its user identifier

The biggest streaming challenge for DynaRoute is in step 19 where the monument transmits tours to different tourists with different needs, e.g. quality of service for device:

FR032: MID shall be able to receive information for specific attraction

Addressing and naming of devices assumes IPv6 and is expected to suffice for the case study. No particular requirements from the scenario walkthrough relate to this aspect of scalability. FP7-257178

Choreographies description

In this section we describe the choreographies designed for the DynaRoute scenario. These choreographies are the natural outcome of the interaction of services that happen during the various steps of the scenario. We proceed to formalize the communication between business participants and coordinate their interactions based on the exchange of information between them by introducing novel BPMN diagrams for each choreography.

To better understand the diagrams presented below we give a brief overview of the BPMN elements that we use in our choreographies:  Flow objects: objects that interrupt the sequence flow and may lead to divergence/convergence.  Connecting objects: objects that represent different types of associations between flow objects/data etc.

In order to implement the choreographies in the DynaRoute scenario we used MagicDraw Enterprise edition 17.0 modeling suite. Many tools and plugins are featured in this edition that aid the business modeler to leverage on the benefits of the UML and BPMN standards so as to design, create and test BPMN diagrams. FP7-257178 The Adaptive itinerary choreography (C1) is the central choreography in our scenario and is responsible for guiding Collista through her day schedule. As seen in Figure 4.1, Collista starts with an initial itinerary and then instructs MID to follow it. Based on incoming events we may need to pause or modify the itinerary. In the first case, Collista is the one who instructs her MID to pause the itinerary whereas in the latter, the MID decides to change the itinerary based on the incoming events it receives. If none of these happens, then the itinerary completes with success. However, when the itinerary is in pause mode, a reminder is sent in appropriate time from the MID to Collista in order to remind her to resume her itinerary. In this point it is up to Collista to resume and follow the itinerary or to cancel it altogether. The Co-Taxi-ing choreography (C2) in Figure 4.2 begins when Citizen exits the hotel and waits for a taxi. The MID sends a notification to Citizen to confirm the taxi request and after successful validation, it proceeds to send a request for a taxi to the taxi company. In this point we have two possible outcomes coming from the taxi company (expressed with a gateway exclusive object) : the taxi company either denies or accepts this request. In case of denial, the Citizen re-tries to issue the request after a specific period of time. In our case, Citizen's request is accepted and MID proceeds to display to Citizen all the information regarding the taxi booking (should be reservation not booking). Thus, when the taxi arrives Citizen boards it and her MID pairs with taxi's GPS device. The Destination Service which runs on the GPS device of the Taxi calculate the route based on data which it received from Citizen's MID and sets the route. FP7-257178 The Distributed ad-hoc social networking choreography (C4) in Figure 4.4 aims to create social interactions between people that know each other. In the beginning, MID reads Valeria"s phone directory (who is Collista"s boss) and then continues to match the GPS position of all contacts by using the social proximity service. If the contacts" GPS location cannot be matched effectively with Valeria"s GPS position, then no event is created. However, in case contacts are found nearby, then the MID displays this list of contacts to Valeria. She proceeds to send a request availability notification to Collista that happens to be nearby and Collista acknowledges it and responds positively with a message to set up a meeting. FP7-257178 The Context-aware touristic guide choreography (C5) represents the interaction between a tourist place and nearby tourists. As seen in Figure 4.5, the tourist place that is a monument sends a tourist information notification to the MID of available nearby tourists. The MID proceeds to notify our tourist, Collista, about the tour guide programs that this monument provides. In any case the tourist can reject this notification, but Collista accepts it by responding that is a mobile user and needs only mobile description so the tourist place starts to transmit the respective data to her MID.

Choreography C1 -Adaptive itinerary

Choreography C2 -Co-Taxi-ing

Choreography C3 -

Choreography C6 -Context aware distributed ad-hoc traffic management

Assessment specifications

Introduction

In this use case we will develop an application in two levels for scalability reasons. The first one consists of the lab version, where all services, actors and choreographies will take part. The other level is a pilot version where we determine specific actors, services and choreographies that will interact with each other. It is considered necessary to clarify a testing and evaluation methodology for both versions of the DynaRoute application that will be under a common format. According to the analysis of the requirements, we are able to identify that the evaluation methodology will cover qualitative and quantitative evaluation for both functional and non-functional characteristics Generally, the services of the end application will be based on the following fields: According to DoW and based on the use case of DynaRoute, the end application will be collaborative software, among components, middleware, actors, services and choreographies. In order to manage the complexity of the use case, we should put forward these rules and principles of evaluation to ensure the quality of the final services.


Due to the volume of information that we are able to manage among different users, services and devices that are involved in the flow of the use case should be invoked in the Ishikawa Diagram as seen in Figure 5.1, better known as a cause -effect diagram. It is a useful tool to be used for the evaluation methodology of the application on MID. The above chart is based on the 6-M method (Man, Machine, Material, Method, Measure, Mother, Nature (Environment)). For each category we should define the relevant parameters and sub-parameters.

The main sections to which we will apply the methods of evaluation as they arise from requirement analysis are the following:  Communication efficiency  Filtering and validation transmitted information based in user profile  Routing models for GPS device  Stability and reliability of application  Assessment of methods that used for the communication level between actors and MID  Interoperability between devices and software components  User Feedback

Quality Control of use case

Software reliability evaluations can be conducted at many stages during the design and development process. The ultimate goal should be to meet the targets set. But what is generally accepted is that the monitoring and evaluation of applications must be fulfilled before the end of development and certainly before making them available to end users.

Checking the proper functioning of the subsystems and ultimately of the entire application is not an independent, single stage, but follows each stage of the application development. So, this is a retrospective production evaluation method (recursive formative) through which various aspects of development, such as specifications, documentation, general issues of source code infrastructure (Technical Inspection) and, most importantly, an initial assessment of the usability and efficiency of the application, are examined.

Upon the completion of the application"s subsystems, a general, large scale summative evaluation will take place in order to ensure that possible errors and defects that were detected during the production evaluation and testing have been corrected.

The aforementioned approach for monitoring and evaluating has three important advantages:

 relieves designers from future problems and generally from undesirable situations which arise when tests take place only after the implementation phase,  contributes significantly in improving the design and development procedures,  all results of the evaluation can be used easily for possible future upgrades, targeting to the optimization of the final release.

As a result, the final evaluation of the application and its subsystems will operate mainly corroboratively (i.e. that all deficiencies will have been corrected), ensuring this way that no significant changes able to affect the cost and schedule of the project will take place.

Usability evaluation

Usability is a measure of interface quality that refers to the effectiveness, efficiency and satisfaction of users while performing tasks with a tool. Evaluating usability is now considered an essential part of the system development process and a variety of methods have been developed to support the human factors as professionally as possible in this field. FP7-257178

There is a variety of approaches to usability evaluation that one may choose to make use of.

The methodologies can be divided into two broad categories: those that gather data from actual users and those that can be applied without the presence of actual users.

The selection of the appropriate method depends on:  Evaluation Cost  Appropriateness to project  Time constraints  Implementation cost  Cost of training new users Usability evaluations can be conducted at many stages during and after the design and development process. When selecting a method, it is important to calculate the cost not only in terms of time and materials involved, but also in terms of the impact on the end-users, especially considering the cost of losing return visitors to a website due to unusable design.

Historically, the concept of usability has been defined in multiple ways, most often on one of the following bases:  Semantics: in this case usability is equated to terms such as 'ease of use' or 'userfriendliness', without formal definition of the properties of the construct.  Features: here, usability is equated to the presence or absence of certain features in the user interface such as Windows, Icons, Menus or Pointing devices.  Operations: where the term is defined in terms of performance and affective levels manifest by users for certain task and environmental scenarios.

The following diagram ( Figure 5.2 ) shows the four types of tests required to evaluate the usability of the application and its subsystems. The tests are conducted at many stages of development contributing, this way, in a productive evaluation. In accordance with the Directive 90/270/EEC of the EU, among others, are referred the specific requirements related to human-computer machine interaction. The software must allow easy handling operations, must be versatile and adaptable and focused to the user (user oriented).

These requirements are compatible with ISO 9241 (1994).

Exploratory Test

Exploratory test will take place at an early stage of the development of the environment of the platform, provided that it has been completed during the analysis of requirements. The exploratory test still requires the existence of a prototype which will perform the essential functions of the final system. The objective of this test is to answer the following questions:  What do users think about the application environment in general and also, every time they use it?  Have the users ever used in the past a similar application environment?  What further information should be given to the users in order to use the environment?  Are all application"s services/functions well understood without the need of further assistance? If not record the ones that are not.  How easily can the application be used both by novice and experienced users? Provided that the application environment will be completed at an advanced stage during the test the user will be asked to accomplish a first use (walk through) or a general overview (review). It should be noted, however, that the exploratory test is rather intuitive and has the main purpose of assessing the propriety (sounding) of the application rather than checking its individual characteristics.

These tests are characterized by the close cooperation between users and auditors. Since the most essential results are intuitive, an exploration of the mindset of users is essential. For this reason, the user is encouraged to "think aloud" during the audit or discuss with another user who also performs the same process. He is also encouraged to submit ideas and suggestions.

Assessment Test

The objective of the assessment test is to apply tests for a number of criteria and characteristics in the design level. For example checking the time management for each step of the use case in conjunction with the number of errors or mismatching of the application. Under this level of testing we will set the criteria for the next levels of testing as demonstrated in Figure 5.2. The table 5.1 below contains a summary of the evaluation criteria of the units developed under this project with all the critical parameters / metrics. It should be noted that although these indicators are mostly qualitative rather than quantitative, they relatively easy to be estimated. FP7

Validation Test

The validation testing scope is to validate and ensure the confidentiality of the end software application, which will interact with other applications and devices using the Choreos platform. In this level of testing, which will be applied in the end of development of pilot or lab version of application, we expect to measure the software quality in terms of the number of defects found in the software, the number of tests that we have run as well as the number of tests covered by the system itself. Validation tests will be run for both functional and nonfunctional attributes of the use case. Testers will check all parts of the application in the use case for connectivity in order to collect qualitative characteristics. As a matter of fact, we propose a distinct approach to perform this test in the following points: 1) Component Testing At this level we will control the parts of the application as classes, objects, modules that compose it. The aim of the tests that will be carried out in this testing type is to search for defects in the application. Moreover, the goal of the unit testing is also to isolate each part of the program and prove that the individual parts are correct. Additionally, this method, it is considered to be the appropriate control method of testing for Java language which is used for the development of application.

2) Integration Testing

The scope of the integration testing is to verify functional performance and reliability of requirements also through this testing verified the development process. It is an important part of the validation model, where the interaction between the different interfaces of the components is tested. Under this testing we aim to collect quantitative characteristics as far as time effect in communication between the parts of system is concerned. FP7-257178

During integration testing it is crucial to create tests plans and produce test cases and test data based on those plans. The integration test cases specifically focus on the data flow, as well as the information and control from one component to the other. Integration test cases should typically focus on scenarios where one component is being called from another, please note that at this point the modelling of choreographies plays its role. Also the overall application functionality should be tested to make sure that the application works when different components are brought together. The integration testing is a continuous process due to the fact that when errors and bug are fixed it is obligatory to run the integration testing again.

3) System Testing

Upon completion of integration testing, system testing is started. System testing, also known as functional and system testing is carried out when the entire software system is ready. The scope of this testing is to validate an application's accuracy and completeness in performing the functions as they were initially designed. Another objective of this testing is to check the behaviour of the whole system as defined by the scope of the project. Moreover, the main concern of system testing is to test the system along with the specified requirements. While carrying it out, the tester is not concerned with the internals of the system, but only checks if the system behaves as expected. This method of testing will be applied in the pilot version of the application because it is more appropriate for real life scenarios. Also during system testing, various other testing such as checking the software and hardware specification of the use case application can be applied. For example:  Usability testing, the scope of this testing is to measure the efficiency, accuracy, recall and emotional response from end users of application. The results from these tests will be the baseline and a control type of measurement for the next versions of pilot application.  Compatibility testing between devices -hardware and software level -from different manufactures. This test can measure the loyalty to communication protocols and also the interoperability of system in general.  Performance testing can measure the qualitative characteristics as they derive from the requirements section and user questionnaires or other technical metrics.  Security testing in order to measure the ability of protection of data that are transmitted among devices in the use case. Furthermore, through this testing we are able to apply metrics for functional and non-functional characteristics such as authorization, availability, authentication, integrity, confidentiality and non-repudiation of application.  Scalability testing is essential in this application because of the increased number of users and services that take part in the use case.  Reliability testing in order to discover potential problems that are caused due to the design of the application. it is undeniable that the application on MID will be a very complex system, so as a result reliability tests should be applied at several levels.

CHOReOS 47 FP7-257178

Comparison Test

Comparison Test can be applied at every stage of development. In early stages different development methodologies can be contrasted, while in the middle of development phase we have the ability to measure the effectiveness of different components of the application. With this methodology we also have the possibility to measure the strengths and weaknesses of an application along with other similar characteristics from different applications, probably from other use cases. Another approach of the comparison test methodology is checking similar services between different choreographies and measure the effectiveness and reliability based on the end users opinion. Last but not least, this test will be useful for the exploitation plan of Choreos platform and will also help to decide on the development of next generation of applications based on Choreos. FP7-257178

Glossary

Elicitation "The discovery, gathering, or "capture" of requirements, often by developing scenarios." Functional requirement

Functional requirements define what the system must do in terms of the interaction between the machine and the problem domain, behaviours, functions and services to be provided. Functional requirements are either met or not met by the future system: they cannot be partially met.

Non-functional requirement

Non-functional requirements restrict the types of machine solution (i.e. system) which should be developed. Examples of non-functional requirements are those which relate to maintainability, reliability and usability. A more complete list of non-functional requirement types is given below. Unlike functional requirements, non-functional requirements focus on a whole system rather than its parts, and may not be formalisable.

Requirement

Requirements have variously been defined and described, for example: A requirement is "something that a product must do or a quality that the product must have". [START_REF] Robertson | Mastering the Requirements Process[END_REF]; Requirements are expressions of required phenomena that are shared between a machine (product) and the domain or environment [START_REF] Jackson | Software requirements and specifications[END_REF]; "Requirements invariably contain a mixture of problem information, statements of system behaviour and properties, and design and implementation constraints" [START_REF] Sommerville | Requirements Engineering: A Good Practice Guide[END_REF]

10

  Collista exits the taxi and her device receives a "70% Sales on shoes!" beacon message from a nearby shoe-store. Her mobile device informs Collista and she gladly accepts the suggestion! 11The device sets a route to the given coordinates and instructs Collista how to get there fast! 12 While Collista is window-browsing and shopping, her boss, Valeria, happened to be nearby. Valeria's Mobile Internet Device identified Collista's

Figure 2 . 1 .

 21 Figure 2.1. An overview of DynaRoute use case scenario.

Figure 2 . 2 .

 22 Figure 2.2. Interaction among choreographies in "DynaRoute".

Figure 3 . 1 .

 31 Figure 3.1. An example frame taken from the "DynaRoute" storyboard showing the storyboard frame and requirements, assumptions and notes sections.

1 . 3 .

 13 : The citizen is flying back to Brazil after a 2-week vacation in Thessaloniki, Greece! An itinerary is fixed for her by her intelligent mobile device (which can be PDA, smart phone, netbook), in order to spend her last day in Greece most efficiently (and not miss her flight, too!). The schedule contains: a 2-hour shopping spree, 1-hour site-seeing and finally a taxi drive to the airport. FR001: MID shall be able to arrange web-check-in as well as anything that is related to the check-in process  SR001 FP7-257178 2. After getting up late and talking a bit more on the phone with her boyfriend, she is ready to leave her hotel, however, being 2.5 hrs behind schedule! FR002: MID alerts shall be voice and vibration As a result, MID modifies on-the-fly her itinerary and she is now instructed to skip the shopping and sightseeing and ask right away for a taxi; she confirms her device's suggestion and leaves the hotel immediately.



  FR040: Airport authorities shall transmit information about flight delays to airline companies  FR041: Airline service shall send flight status notifications to passengers Assumptions: Airline company has data for passenger lists and destinations Airport authorities and airline companies will be able to transmit/receive data between each other FP7-257178 8. Collista's device receives the notification and re-evaluates its itinerary. Collista can still do her shopping and site-seeing! (She confirms ecstatic, responding to her device's suggestion!) IR004: MID shall be able to receive and decode the information transmitted from the airline service  FR042: MID shall have the ability to evaluate the importance of information and notify the traveller accordingly [e.g. sound alert, visual effect , vibrate]  FR043: MID shall repeat the notification periodically until confirmation is received from the traveller Assumptions: MID has enough battery power to receive and display notifications MID has a strong enough signal to receive notifications 9. A new destination (Tsimiski Str., the main shopping street of Thessaloniki) is set by the device and provided to the taxi's navigator. The navigator computes the new route and re-routes the taxi to Tsimiski Str., (confirming to the device a FR021: MID shall be able to inform navigator about changed coordinates  FR022: MID shall be able to send the location of where the taxi shall pick up the customer Assumptions: Taxi driver does not to have to inform taxi company about the change of destination CHOReOS 24 FP7-257178 10. Collista exits the taxi and her device receives a "70% Sales on shoes!" beacon message from a nearby shoe-store. Her mobile device informs Collista and she gladly accepts the suggestion! FR044: Mall shall transmit data on offers and marketing to the CHOReOS platform periodically  AcR003: MID shall receive a notification based on user profile from nearby shops (10m range )  FR045: Choreos platform shall provide to MID specific instructions for the exact location of mall"s shop [Due to lack of the GPS in internal areas of the mall] Assumptions: MID has enough battery power to receive and display notifications MID has a strong enough signal to receive notifications 11. The device sets a route to the given coordinates and instructs Collista how to get there

20.

  While sightseeing, a traffic-info message is relayed to the taxi driver (from another taxi, passing nearby), indicating a traffic jam at the Ring-Road, due to a car accident. (The Ring-Road is on Collista's way to the airport).Ad hoc mobile sensor network service (Input/output: traffic notification msgs)

Figure 4 . 1 .

 41 Figure 4.1. BPMN diagram of the Adaptive itinerary choreography

Figure 4 . 2 .

 42 Figure 4.2. BPMN diagram of the Co-Taxi-ing choreography

Figure 4 . 3 . 4 . 4 .

 4344 Figure 4.3. BPMN diagram of the Distributed Alert system choreographyThe Distributed Alert system choreography (C3) represents the interaction between the flight company and its respective clients. As shows in Figure4.3, this choreography starts by using the Airline Announcement Service to notify about a delay in Citizen's flight. MID receives this announcement and proceeds to display it to Citizen which reads and acknowledges this notification. Obviously, this announcement is sent to the respective services of all the interested parties in the flight (passengers, pilots etc.)

Figure 4 . 4 .

 44 Figure 4.4. BPMN diagram of the Distributed ad-hoc social networking choreography

4. 5 .Figure 4 . 5 .

 545 Figure 4.5. BPMN diagram of the Context-aware touristic guide choreography

Figure 4 . 6 .Figure 4 . 7 .

 4647 Figure 4.6. BPMN diagram of the Context-aware touristic guide choreographyThe Context-aware distributed ad-hoc traffic management choreography (C6) collects traffic info and decides/announces information about traffic jams (Figure4.6). In this choreography, each taxi sends traffic messages to the traffic detection service. This service uses both the incoming messages and the Map services to decide about an impeding traffic jam in the area. When such a traffic jam is detected, respective messages are announced to all taxis that are close to this area. As soon as the taxi receives such a notification, it forwards it to MID which then decides to send a rerouting message back to the GPS device.

Figure 5 . 1 .

 51 Figure 5.1. Ishikawa Diagram (6-M)

Figure 5 . 2 .

 52 Figure 5.2. Detail plan of testing for development circle of life.

Table 2 .1: DynaRoute Scenario Description FP7

 2

-257178

Time/clock service

  NotificationsDescription: Each mobile device is able to produce audio, visual and vibration signals to the user of the device. Used by: Citizen"s MID, taxi"s navigator, Porter"s PDA Inputs: textual message, some event Outputs: Audio signal, Visual on-screen message, Vibration signal  Location service Description: A fine (GPS) or rough (GSM) estimation of the location coordinates of the mobile device is provided.

	Description: The current time/date provided by either a clock or by using the NTP
	protocol through internet
	Provided by: Citizen"s MID, taxi"s navigator, Porter"s PDA
	Inputs: internet (3G), mobile carrier cell signals (GSM)
	Outputs: time/

Complementary: Usage of location-based social networking websites (such as Foursquare, Facebook Places) that enable users to check-in at particular venues. Provided by: Citizen"s MID, taxi"s navigator, Porter"s PDA Inputs: satellite signals (GPS), mobile carrier cell signals (GSM), internet (3G) Outputs: location coordinates estimate (longitude, latitude) 

date  Task list / calendar service Description: A list which stores to-do tasks and is organized in a calendar basis.

	Provided by: Citizen"s MID
	Inputs: predefined tasks from Collista, pre-existing preferences
	Outputs: an organized to-do list of tasks
	 Beacon service
	Description: This service is able to receive, transmit or relay short messages between
	actors and things based on proximity criteria.
	Provided by: Citizen"s MID, monument/shoe shop infrastructure
	Inputs: message
	Outputs: broadcasted message
	

Tour guide service Description

: Upon successful confirmation of a tour request by a tourist, this service sends either text/video messages or issues a request for a tour guide. Provided by: monument infrastructure Inputs: N/A Outputs: text/video messages, requests for tour guides FP7-257178

Choreographed Services C1 -Context-aware adaptive itinerary

		TAXI location service (GPS)
		TAXI beacon service (transmit, receive)
		TAXI navigation
	C3 -Distributed alert	Airline announcement service (web service)
	system	MID 3G access service
		MID user preferences
		MID notifications
	C4 -Context-aware,	MID location service (GPS, GSM)
	distributed ad hoc social networking	MID user preferences MID notifications MID setup meeting
		MID user directory
		MID Instant Messaging
	C5 -Context-aware,	Monument beacon service
	touristic guide	MID beacon service (transmit ,receive)
		MID notifications
		MID location service (GPS, GSM)
		Monument data transmit service (short text guided tour)
	C6 -Context-aware	TAXI beacon service (transmit, receive)
	distributed, ad hoc traffic management	TAXI location service (GPS) TAXI notifications
		MLS Maps Service
	C7 -Context-aware,	MID beacon service (transmit, receive)
	personalized airport ground service	Porter device beacon service (transmit, receive) MID notifications
		Porter"s device notifications
		MID user preferences
		MID location service (GPS, GSM)
		Airport departures announcement service

MID notifications MID location service (GPS, GSM, web service) MID time/clock service MID task list / calendar service MID beacon service (transmit, receive) MID device pairing service MID 3G access service MID user preferences (shopping, flight details) POI maps (web service) Retail store info service C2 -Co-taxi-ing MID location service (GPS, GSM) MID notifications MID beacon service (transmit, receive) TAXI notifications FP7-257178

Table 2 .2: Choreographies and Services mapping

 2

Table 2 .3: Estimated numbers of actors FP7

 2

-257178

  .1. These types included those specified for the DynaRoute Future Internet requirements in deliverable D1.2[START_REF] Bartkevicius | D1.2 "Choreos perspective on the Future Internet and Initial Conceptual Model[END_REF].

		new specifications or operating	the itinerary
		environments
	*Mobility [MoR]:	The platforms, devices and operating	e.g. mobile sensor / ad
		systems that MID should be required to	hoc network
		run on
	Maintainability	The minimum acceptable levels of time	e.g. this could be
	[MR]:	and resources needed to upgrade of	concerned with
		MID	Service consumer requirements	supportability of a service
	Functional [FR]: Reliability [RR]:	Something (service, behaviour, The minimum levels of failure that MID	e.g. The boss shall e.g. the product shall
		function) that a product must do and related systems should	send a request for achieve 99% up time
		demonstrate	meeting
	Performance [PR]: The desired times and/or throughput *denotes requirement types where requirements already exist for D8.1	e.g. The traveller shall
		rates that an actor should be able to	receive a revised route
		undertake	within 10 seconds
	Availability [AvR]: The minimum required levels of access	e.g. The traveller shall
		that stakeholders have to MID and	be able to access flight
		related work activities	departure information
				at all times
	Usability [UR]:	The desired levels of tolerable user	e.g. The passenger
		errors and frequencies of error	shall set a beacon
				message with less than
				one error per 1000
	Accuracy [AcR]:	The error rate produced by the service	e.g. The traveller shall
		calculated on the basis of the expected	receive their current
		results.	position accurate to
				10m 2
	*Security (&	The minimum levels of security that a	e.g. The passenger
	privacy and trust)	person using MID and related work	shall provide
	[SR]:	activities should be exposed to	authentication in order
				to access their user
				profile details
		Service developer (system) requirements
	*Scalability [ScR]: The capability and system's ability to	e.g. a few hundred to
		process more users' requests,	thousands of services
		operations or transactions in a given	in choreography C1
		time interval.
	*Interoperability	The ability of a software component to	e.g. Different devices
	[IR]:	interact with other components or	(navigators, smart
		systems.	phones)
				circumstances like
				choreography C1 for
	FP7-257178

*Awareness [AwR] & Adaptability [AdR]:

The level of awareness and predictability of upcoming changes & the ability of the system to change to e.g. adapt to

Table 3 .1. Requirements types for the DynaRoute Use Case A

 3 set of stakeholders was identified to take part in the analysis of the scenario and the elicitation of requirements. The stakeholders covered the key areas of the scenariotourism, taxi company, shopping mall and airport: IT department head from Municipality of Thessaloniki  Mr. Mantelos Dimitris (CEO) from IT company who support the taxi company "MERCEDES club"

A nearby passing taxi receives the mobile device's beacon message. The taxi GPS device notifies the driver for the request. He accepts, and an acknowledgement is sent to Collista's device.

  MID shall be able to transmit location coordinates to taxi company  FR009: Traveller shall be able to choose type of car, big boot, air-conditioning, etc.  FR010: Traveller shall be able to request a taxi driver who speaks English  FR011: Traveller shall be able to request a taxi with green card 5.

		User preferences
	Input parameters e.g. Taxi	<<Device>>
	size, air-conditioning	MID
	Traveller
		Beacon Service (Output: GPS
		position, destination coordinates)
			Choreography C1
	 FR008: Traveller	<<Device>> MID User preferences	Taxi passenger service (Output: feasibility of request)
	Beacon Service (Output: GPS
	position, destination coordinates)

12. While Collista is window-browsing and shopping, her boss, Valeria, happened to be nearby. Valeria's intelligent device identified Collista's device in range, as they are both in each other's access lists and user directories.

		Access list, user	Access list, user
		directory	directory
	MID notification	<<Device>> MID	<<Device>> Boss MID
	Traveller
		MID identifier	MID identifier
		Proximity
		detection service
		(criteria e.g. 3km)
			Choreography C4
	 FR025: MID shall be able to upload the location and its user identifier
	 AwR001: MID shall be able to detect nearby "friends"
	13. Valeria

sends a "request for a short meeting" to Collista, including coordinates of the café, where Valeria is sitting at; Collista accepts and her mobile device sets a route to the café.

	14.
			MID Propose / User
			Confirm
	Request for meeting
	<<Device>>	<<Device>>
	(coordinates, location
	Boss MID	MID
	Boss	details)	MID route	Traveller
	Proximity
		Navigation service
	detection service
			Choreography C4
	 UR001: Service consumer shall be able to send requests by selecting contacts from
	the contacts menu easily
	FP7-257178

Valeria and Collista meet and talk over frappe (coffee).

	Choreography C1 suspended
	 FR026: MID shall be able to detect the movement of the traveller and the time that
	they spend at a location
	o AvR001: MID"s location service shall be able to access the servers at all times
	( hot-spot wi-fi )
	15. At

some point Collista's device reminds her that the sightseeing is due, so Collista tells her boss that she has to leave.

		Schedule
	Time alert	<<Device>> MID
	Traveller
		Choreography C1

 FR027: Traveller shall be able to access a list of top attractions nearby  FR056: MID shall be able to access a network that detects customer location and directs to top attractions 16.

Collista waits for a taxi by the street (again, same sub-scenario as above, step 5 at the hotel).

	17. Collista'
		User preferences
	Input parameters e.g. Taxi	<<Device>>
	size, air-conditioning	MID
	Traveller
		Beacon Service (Output: GPS
		position, destination coordinates)
		Choreography C1
	 FR028: MID shall be able to show locations of taxi stands nearby
	 FR029: MID shall be able to transmit destination information to nearby taxis
	 FR030: MID shall be able to contact taxi company of where customer is
	FP7-257178

s device provides the taxi's navigator with the desired sequence of destinations for sightseeing.

		Schedule
			Taxi company Taxi driver
	Sightseeing preferences	<<Device>> MID	<<Device>> Taxi MID	<<Device>> Navigator
	Traveller
			Location service & Taxi	Route info
			passenger service
			(Destination coordinates)
				Choreography C1
	 AwR002: MID shall be able to dynamically change route depending on nearby
	attractions
	 FR031: MID shall be able to inform navigator/taxi driver of route to be taken to
	destination
	18.

While passing by the White Tower, the monument's beacon broadcasts a message, inviting tourists for some tourist info or tour. The mobile device relays this message to Collista and she accepts the info stream.

	19.
		User status
	MID Propose / User Confirm tour	<<Device>> MID	Tour guide service (Output: notification message, info stream)
	Traveller		Monument
		Beacon Service (Output: GPS
		position, destination coordinates)
			Choreography C5
	 FR032: MID shall be able to receive information for specific attraction
	[currently leaflet or brochures]
	Assumptions:
	Support from tourist office for getting this
	FP7-257178

After evaluating their velocity, the Tower decides to transmit to them the short version of the tour and not call for a tour guide.

		User status
		(in taxi)
	MID Propose / User accept text -only tour	<<Device>> MID	Tour guide service (Output: notification message, info stream)
	Traveller		Monument
		User
		preferences/profile

The taxi's navigator 'thinks' it's wise to inform Collista's mobile device about this ~45 min estimated delay.

	21. <<Device>> Navigator Traffic notification (plus <<Device>> MID estimate of delay)
	Traveller
	Taxi passenger service	Traffic notification
		Choreography C6
	 UR002: Traveller shall be able to view alerts without problems
	 AcR002: MID shall be able to accurately determine any delay
	 PR001: MID shall be able to retrieve new information about delays every 30 seconds
	22. Collista'
		3 minutes
	[ Sudden and unusual situations e.g. accidents or change of weather]
	FP7-257178

s device realizes that the sightseeing must be interrupted and the taxi should head to the airport. So, it sends a "new destination" (= the airport's) coordinates to the taxi's navigator, the navigator computes the shortest route and reaches the airport in time!

		Schedule
	Inform of airport	<<Device>>	<<Device>>
	destination	MID	Navigator
	Traveller
			Route info
		Taxi passenger service
		(Destination coordinates)
			Choreography C1

 FR038: MID shall be able to find quickest route  FR039: Traveller shall be able to accept new route even if it is longer but quicker FP7-257178 23.

Collista gets off the taxi and waits for a porter to carry her 3 pieces of luggage; Her device sets a "request luggage porter" beacon.

	Input parameters e.g. Number	<<Device>>
	of bags, approx. weight	MID
	Traveller
		Porter beacon Service
		Luggage service
		Choreography C1
	 FR046: MID shall recognize traveller"s location and distance-time from airport based
	on a GPS signal
	 AcR004: MID shall send a bacon message to porter"s service within a range of 1km
	of the airport
	24. A

nearby available porter receives the beacon request and moves to the given coordinates.

	Beacon request (coordinates	<<Device>>
	of traveller, number of bags)	Porter MID
	Porter
		Porter beacon Service
		Luggage service

Table 3 .2. Number of requirements by type for the DynaRoute Use Case

 3 .2.

	Requirement type	Number of requirements
	Accuracy [AcR]	5
	Adaptability [AdR]	0
	Availability [AvR]	2
	Awareness [AwR]	2
	Functional [FR]	56
	Interoperability [IR]	4
	Maintainability [MR]	0
	Mobility [MoR]	1
	Performance [PR]	1
	Reliability [RR]	1
	Scalability [ScR]	0
	Security [SR]	1
	Usability [UR]	2
	Total	75

Table 5 .1. Evaluation criteria

 5

Valeria and Collista meet and talk over frappe (coffee).

Requirements process developed by the Norwegian University of Science and Technology and City University London as part of the MIRROR EU Framework VII Integrated Project

FP7-257178