future internet enabled optimisation of transport …...the research leading to these results has...

The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement no. 285598

FInest – Future Internet enabled optimisation

of transport and logistics networks

D2.1

Use Case Specification Methodology

Project Acronym Finest

Project Title Future Internet enabled optimisation of transport and logistics

networks

Project Number 285598

Workpackage WP2 Use Case Specification

Lead Beneficiary MARINTEK

Editor Åsmund Tjora MARINTEK

Contributors(s) Cyril Alias Uni. Duisburg-Essen

Kay E. Fjørtoft MARINTEK

Fabiana Fournier IBM

Marianne Hagaseth MARINTEK

Lone S. Ramstad MARINTEK

Agathe Rialland MARINTEK

Reviewer Michael Zahlmann Kuehne+Nagel

Reviewer Clarissa Marquezan Uni. Duisburg-Essen

Dissemination Level Public

Contractual Delivery Date 30-06-2011

Actual Delivery Date 30-06-2011

Version 1.1

The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement no. 285598

Disclaimer

The content of the publication herein is the sole responsibility of the publishers and it does not

necessarily represent the views expressed by the European Commission or its services.

While the information contained in the documents is believed to be accurate, the author(s) or

any other participant in the FInest consortium make no warranty of any kind with regard to this

material including, but not limited to the implied warranties of merchantability and fitness for a

particular purpose.

Neither the FInest Consortium nor any of its members, their officers, employees or agents shall

be responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or

omission herein.

Without derogating from the generality of the foregoing neither the FInest Consortium nor any

of its members, their officers, employees or agents shall be liable for any direct or indirect or

consequential loss or damage caused by or arising from any information advice or inaccuracy or

omission herein.

FP7-2011-ICT-FI — Finest

© D2.1 Use Case Specification Methodology V1.1 of 66

Abstract

International transport and logistics operations are concerned with the planning and execution

of the world-wide shipment of goods and people. The FInest project addresses this domain as a

useful example for the Future Internet. Within this scope, the FInest project envisioned three

different use case studies around transport and logistics. Having a methodology for the

descriptions and structuring of these use cases and their corresponding scenarios is essential to

achieve consistency, and to create procedures that can be followed and repeated by all

members of the project.

This report describes the main procedures to be carried out when describing and detailing

FInest use cases. The report also defines a template for presenting the scenarios that will be

described in the FInest project, and presents criteria for categorization of the scenarios.

Appendix A intends to serve as a "user manual" on how to carry out the actual work in FInest to

assure maximum synchronization and consistency among the partners working on different

aspects of the use cases.

The document is being submitted as specified in the FInest Description of Work (DoW) as part

of deliverable D2.1 – Use case specification methodology. FInest methodology will be revised

and updated throughout the lifespan of the project as the work in the project progresses and

insights and feedback regarding the use cases is obtained.



Document History

Version Date Comments

V0.1 27-04-2011 First document structure

V0.2 13-05-2011 Added content

V0.3 11-06-2011 Main contents in deliverable

V0.4 16-06-2011 Deliverable ready for internal review

V0.5 22-06-2011 Edits from internal reviews

V0.6 27-06-2011 Inserted appendices

V0.7 27-06-2011 Final edits

V1 30-06-2011 Final version

V1.1 30-06-2011 Minor error correction in ref. no. and addition of

footnote



Table of Contents

1 Introduction .......................................................................................................................... 9

1.1 Objectives and content of this deliverable ................................................................. 10

1.2 Summary of contents for this deliverable ................................................................... 11

2 Relations between T2.1 to other tasks and work packages in the FInest project .............. 11

2.1 Relationship with the other tasks in work package 2 ................................................. 12

2.2 Relationship with tasks of work package 1 ................................................................. 12

2.3 Relationship with other work packages ...................................................................... 13

3 Background methodologies and models ............................................................................. 13

3.1 Case studies in S-Cube ................................................................................................. 13

3.2 SiSaS ............................................................................................................................ 14

3.3 ARKTRANS ................................................................................................................... 16

3.4 e-Freight ...................................................................................................................... 18

3.5 MIS .............................................................................................................................. 20

3.6 Shipping KPI ................................................................................................................. 21

3.7 SHAPE .......................................................................................................................... 22

4 Development of a methodology for the FInest project ...................................................... 23

4.1 High-level description of the use cases ....................................................................... 24

4.1.1 Describing work processes .................................................................................. 24

4.1.2 Operational phases ............................................................................................. 25

4.2 Detailed use case scenarios ........................................................................................ 26

4.2.1 As-is and to-be scenarios .................................................................................... 27

4.2.2 Increasing the detail level ................................................................................... 27

4.3 Experimentation specification .................................................................................... 27



4.4 Designing evaluation criteria ....................................................................................... 28

4.4.1 Identification of goals .......................................................................................... 28

4.4.2 Finding and defining key performance indicators............................................... 29

4.5 Methods for gathering data ........................................................................................ 29

4.5.1 Document studies and existing process descriptions ......................................... 29

4.5.2 User stories .......................................................................................................... 29

4.5.3 Interviews ............................................................................................................ 29

4.5.4 Surveys ................................................................................................................ 30

4.5.5 Existing research material ................................................................................... 30

4.6 Structuring the data .................................................................................................... 30

4.6.1 Use case scenario templates ............................................................................... 30

4.6.2 Categorizing use case scenarios .......................................................................... 33

4.6.3 Use of process diagrams ..................................................................................... 33

5 Discussions and conclusion ................................................................................................. 34

References ................................................................................................................................... 34

A. Methodology handbook ...................................................................................................... 36

Activity 1 Identification of Use Cases .................................................................................. 37

Activity 2 High level specification of use case scenarios ..................................................... 41

Activity 3 Detailed Specification of Use Case Scenarios ...................................................... 47

Activity 4 Experimentation specification ............................................................................ 49

Activity 5 Evaluation ............................................................................................................ 50

B. Templates ............................................................................................................................ 51

Template 1: Interview guide for as-is description............................................................... 52

Template 2: Interview report template (as-is description) ................................................. 58

Template 3: FInest Use Case Template ............................................................................... 65



List of Tables

Table 1 – S-Cube Business Goal and Domain Assumption description template ....................... 13

Table 2 – S-Cube Scenario description template ........................................................................ 14

Table 3 – SiSaS Use Case template .............................................................................................. 15

Table 4 – FInest use case template ............................................................................................. 31

List of Figures

Figure 1 – WP2 case studies main components ............................................................................ 9

Figure 2 – Relationships between the methodology task and other FInest tasks ...................... 12

Figure 3 – Structure of SiSaS methodology ................................................................................. 15

Figure 4 – The ARKTRANS reference architecture ...................................................................... 18

Figure 5 – e-Freight main roles and parties ................................................................................ 19

Figure 6 – e-Freight overall use case ........................................................................................... 19

Figure 7 – Categorization of operations from MIS project ......................................................... 21

Figure 8 – Shipping KPI hierarchy ................................................................................................ 22

Figure 9 – Performance Measures development and application in the project SHAPE ............ 23

Figure 10 – Main components of the high level case study descriptions ................................... 25

Figure 11 – Four phases of operation used for identifying processes in the MIS project .......... 26

Figure 12 – Example of UML use case diagram ........................................................................... 31



Acronyms

Acronym Explanation

Dx.y Deliverable y from work package x in the FInest project

FI Future Internet

ITS Intelligent transport system

KPI Key performance indicator

Mx Month x of the FInest project

PI Performance indicator

SaaS Software as a service

SPI Shipping performance index

Tx.y Task y in work package x in the FInest project

WPx Work package x of the FInest project



1 Introduction

International transport and logistics operations are concerned with the planning and execution of

the world-wide shipment of goods and people. The FInest project addresses this domain as a

rich example for Future Internet services. The second work package (WP) of the FInest project

"Use Case Specification", is concerned with the definition of use case scenarios for testing,

demonstration, and evaluation of the FInest solutions, as well as a preparation of a plan for

conducting large-scale trials of the use cases for phase 2 of the FI-PPP program.

The studies in WP2 will consist of high level descriptions of the use cases, with descriptions of

the main processes that the use cases involve, and detailed scenarios describing both the current

“as-is” situations as well as possible “to-be”-situations where it is shown how Future Internet

technologies can be used to improve the processes. Selected scenarios will be refined further,

generating specifications for experimentation in the use cases as well as methods for evaluating

the results from the experimentation. These will again be used for generating large-scale trial

plans for the second phase of the FI-PPP programme. Figure 1 describes the main components

of the studies to be carried out in WP2 and their relations to the Future Internet component and

platform work and the Experimentation Environment.

Figure 1 – WP2 use case specification main components

High level description of use cases

As-Is scenarios

To-Be scenarios

Detailed specifications

Experimentation specifications

Evaluation criteria

Large scale trial plans

Domain analysis

Future Internet components and

platform

Experimentation environment

Domain model and dictionary

Requirements

Possibilities

Requirements

Possibilities



1.1 Objectives and content of this deliverable

The first task of WP2 is to define the methodology that shall be used for the other main tasks of

the work in the work package. The objective of this deliverable is to describe the methodology

and the use case scenario structure to be applied in the remaining tasks in WP2 as well as input

to other WP tasks in the project.

Clearly, outlined directions and procedures will increase consistency among all WPs of the

project when dealing with the use cases. The deliverable will mainly focus on the work for high-

level use cases and detailed use case scenario descriptions. Methodologies for experimentation

specifications and evaluation criteria will only be briefly outlined; as these are part of a later

deliverable (i.e., D2.4 – Initial experimentation specification and evaluation methodologies for

selected use case scenarios).

The methodology will give guidelines to:

what data should be collected

suggestions on how data can be collected

a structure for presenting and organizing the use cases which is an important base for

the work on the use cases across all tasks in the Finest project.

A standardized template for describing the use case scenarios in the FInest project, as well as a

structured way of categorizing the scenarios are important in order to properly handle the data

that is collected in the use case work. The work on defining a standardized way of describing

scenarios will mostly be extensions and tailoring of earlier scenario description works to FInest,

like methods described by Cockburn [1] or SiSaS [2] and S-Cube [3] projects. The work will

also present results from projects that have done important domain mapping in the transport and

logistics sector. It is expected that results from “FInest domain understanding”, which is a part

of the deliverables of WP1 (D1.1 – Initial report on the transport and logistics domain analysis

and D1.2 – Transport and logistics domain dictionary, both due to M6 of the project), will

enhance the work of previous projects. However, the models of other projects may serve as

temporary categorization criteria for the FInest project, and they may also function as a way of

structuring the data gathering work.

In addition to a structured way of presenting the use case scenarios, this deliverable will also

look into gathering data for the use cases, giving guidelines both for how to gather data and

what kind of data is expected from the use cases.

Based on the methodology, a “user manual” is developed and presented in a “Methodology

handbook” (Appendix A of this report) that can be used as a separate, stand-alone, document

during the actual work of collecting data and describing the use cases. The intention with the

handbook is to describe the methods in steps that are easy to follow for the involved partners in

the actual use case work.

Note on the use of the terms “use case” and “use case scenario” in this deliverable

In this deliverable, “use case” (or “use case study”) refer to the overall studied scenarios, i.e. for

the FInest project, the three main use cases are Fish transport from Ålesund to Europe, Air

transport of equipment, and Global consumer goods production and distribution.

Each use case comprises one or more scenarios that describe how actors in the use case perform

a set of operations in order to achieve a specific result. In FInest, both “as-is” and “to-be”

scenario descriptions will be created. The “as-is” descriptions describe the current operations

that will serve both as a base for understanding the operations and for pointing out current

challenges and opportunities for Future Internet technologies. “To-be” scenario descriptions



will include the use of Future Internet technology, and may thus serve as an input to the

requirements for the technology.

1.2 Summary of contents for this deliverable

The rest of this report is organized as follows:

Chapter 2 discusses the methodology development task’s connection to other tasks in the FInest

project, both in the Use Case Specification work package and other work packages.

Chapter 3 contains a study of background methodologies, models, and frameworks that are used

as a base for the methodology developed in this report.

Chapter 4 describes the FInest methodology.

Chapter 5 discusses the results and conclusions.

Appendix A is the first version of the “Methodology Handbook”, giving a description of how to

apply the methodology in FInest. The intention of this appendix is to function as a “stand-

alone” handbook for the FInest use case specification methodology. The handbook is intended

to be a “live” document during the project, and will be updated and modified as the work in

WP2 and other WPs of the project progresses, and more insights and developments are

obtained.

2 Relations between T2.1 to other tasks and work packages in the FInest project

There exists a strong synergy among this deliverable and other tasks in WP2. Furthermore,

inputs from other tasks that run in parallel are required in order to develop a valid and solid

methodology. However, because this deliverable is the first to be submitted, in practice only

some of the work that is carried out in other tasks can actually be used. To ensure

synchronization and cooperation among the different and related tasks a single team has been

assigned to these activities.

The output from this task is intended for use with the use case scenario descriptions in WP2, but

it is also important to create a structure and methodology that ties the use case studies to the rest

of the work in the project.

Figure 2 below shows the relationships between the methodology task (T2.1) and the other tasks

in the project. Sections 2.1 and 2.2 further detail these relationships.



Figure 2 – Relationships between the methodology task and other FInest tasks

2.1 Relationship with the other tasks in work package 2

The other tasks in WP2 - Use Case Specification (i.e., T2.2–T2.5) are the main consumers of

D2.1 output. The main focus of this deliverable is towards task T2.2, the definition of use case

scenarios and the structure for presenting these scenarios. As can be seen from Figure 2,

decisions and experiences made during the early work of T2.2 - Definition of Use Case

Scenarios affect and influence the methodology developed in T2.1. Methodologies for the

experimentation specification and evaluation methodologies are briefly mentioned in this report,

since they will be detailed in D2.4 – Initial experimentation specification and evaluation

methodologies for selected use case scenarios.

2.2 Relationship with tasks of work package 1

A strong domain model and a common domain understanding for the transport and logistics

domain are useful for creating relevant use cases and creating a good structure for categorizing

the scenarios. The work on domain analysis, including the generation of a domain dictionary, is

part of FInest WP1.

While the methodology development is not directly dependent on the results from the first work

package, it is assumed that results from the domain understanding task (T1.1) will be used in the

use case work, and may be central to the categorization of the scenarios.

T2.1 Methodology

T2.2

Definition of Use Case Scenarios

T2.3

Experimentation specification

T2.4

Evaluation methodologies

T2.5

Phase 2 plan for large-scale trials

Meth

od

olo

gy

Early experiences in the use case studies

T1.1

Common domain understanding

Domain understanding

Models and dictionary



2.3 Relationship with other work packages

While the methodology development does not require input from other work packages, the

methodology should be developed in a way that makes the results from the use cases useful to

the work carried out in these work packages. The methodology serves as a baseline for the

remaining WPs in the project and as guidelines for defining any use case component.

Available results from the other FInest work packages, especially the component development

work (WP5–8) as well as results from the core platform work (alignment with the core platform

is handled in WP9) are helpful when describing the “to-be” situation. It is also expected that the

“to-be” descriptions of the components will be used to identify new requirements to the

component and platform work.

The work on experimentation specification for the use cases must be in cooperation with the

experimentation platform work (WP4).

3 Background methodologies and models

The Finest project will leverage the work of previous studies in the transport and logistics

domain and adapt it to the purposes of the project. The methodology developed for the FInest

use cases will be extended and tailored from earlier work on use case studies and models from

the transport and logistics domain. This chapter describes the background material that the

FInest use case specification methodology is based upon.

3.1 Case studies in S-Cube

S-Cube [3] is a European Network of Excellence in Software Services and Systems, aiming at

establishing an integrated, multidisciplinary, vibrant research community, enabling Europe to

lead the software-services revolution, thereby helping shape the software-service based Internet

which is the backbone of a future interactive society.

S-Cube has published a methodology for describing pilot cases [4] and also describes the

classification of case studies according to application domain and relevant research topics. The

methodology is also available as an online Wiki [5].

In the S-Cube methodology, a case study is described by:

A list of Business Goals and Domain Assumptions (see Table 1)

A Domain description

A list of Scenario descriptions (see Table 2)

Table 1 – S-Cube Business Goal and Domain Assumption description template

Field Description

Unique ID Give a unique ID for this goal/assumption

Short name Give a short name for this goal/assumption

Type One of the following

Business goal

Domain assumption

Description Specify the intention of the goal/assumption



Rationale Give a justification of the goal/assumption

Involved Stakeholder Stakeholders involved in the business goal/assumption

Supporting materials Give a pointer to documents that illustrate and explain this

goal/assumption (in particular those of domain analysis)

Priority of accomplishment One of the following

Must have: The system must implement this

goal/assumption to be accepted

Should have: The system should implement this

goal/assumption: some deviation from the

goal/assumption as stated may be acceptable

Could have: The system should implement this

goal/assumption, but may be accepted without it

Tentative scheduling Tentative scheduling of accomplishment. To be used only

if the case study has to be implemented

Table 2 – S-Cube Scenario description template

Field Description

Unique ID Give a unique ID for this scenario

Short name Give a short name for this scenario

Related to Specify the goal/assumption IDs to which the scenario is

related

Involved actors Specify the actors involved in the current scenario

Detailed operational description Give a textual description of the scenario

Problems and challenges Describe the specific problems that each scenario addresses

or that consumers and providers face

Additional material e.g. UML diagrams supporting the understanding of the

scenario

The first part of the S-Cube methodology, business goals and domain assumptions, and the

domain description, will be among the topics that are studied in the first work package in the

FInest project. As mentioned previously, results from the work on WP1 will be used in the use

case specification work.

The methods for domain- and research-oriented classification of use case studies from S-Cube

will be used in the FInest use case specification methodology.

3.2 SiSaS

SiSaS (Scientific Software as a Service) is an internal project in the SINTEF group focusing on

methodology and tools, primarily for Software-as-a-Service (SaaS) development, but also for

other purposes. MARINTEK is a participant in the project.

Among the other participants in SiSaS are SINTEF ICT and SINTEF Materials and Chemistry,

research institutes that are involved in the EnviroFI project [6] that is also one of the FI-PPP

projects. For this reason the SiSaS project has also been an arena for discussion on

methodologies for use cases and structures for scenario descriptions.

The structure of the SiSaS methodology can briefly be explained as shown in the following

picture (see Figure 3).



Figure 3 – Structure of SiSaS methodology

In the Inception & Elaboration phase, the focus should be on understanding the business domain

and the requirements of the system. There are different possible ways of describing such studies

where one of them is by using a use case methodology. This is the one we bring in to the FInest

project, including a template to fill in when the use cases are developed (see Table 3).

The SiSaS project has created a use case template based on work done in the EnviroFI project,

with some inputs from the FInest project. The template has been published on the SiSaS

methodology website [2]:

Table 3 – SiSaS Use Case template

Use case template Description

Use case name < The name is the goal as a short active verb phrase. >

Use case ID < A unique identification of for the use case, e.g. UC01. >

Revision < Revision number for the use case. >

Reference (optional)

< URL pointing to the use case element in a UML model. >

Use case diagram < UML use case diagram for the actual use case. The diagram should include extend and include relationships if there is any. >

Status < Status of the use case. One of the following:

Active

Deprecated

In the case of a deprecated use case please provide a reason,

Work products

24

Requirements ModelBusiness Model

Service Model

Platform Realization Model

Business Process

Model

Services Architecture Service Contract

Service Detailed designService design

Business

Information

Modell

System

Boundary

Cloud, Web Services, JEE, MAS, P2P/Grid, SWS

uc MODUS Studio

MODUS Language Engineering Workbench

Language

Engineering

LanguageEngineerCheck

Language

Quality

IDE DeveloperDevelop IDE

Roadside

Existing Systems

Vehicle

Existing Systems

driver

Traffic manager

Service providerSW supplier

CVIS Host

HMI

Traffic

Management

Existing Systems

Roadside

Gateway

IPv6Vehicle

Gateway

Service

Centre

Host

Management

Centre CVIS

existing

Rich Picture

Use case

scenario. Modeling artefacts at different

levels of abstracion

and from different viewpoints

Inception

Elaboration

& Construction phase focus

NFR and

other

requirements

Construction

& Transition phase focus

& Elaboration phase focus



e.g. in the ‘notes’ field. >

Priority of accomplishment (optional)

< One of the following:

Must have: The system must implement this goal/assumption to be accepted.

Should have: The system should implement this goal/assumption: some deviation from the goal/assumption as stated may be acceptable.

Could have: The system should implement this goal/assumption, but may be accepted without it. >

Goal < Description of the goal(s) for the use case. >

Summary < A short textual description of the use case. >

Category < Categorisation of use cases according to an overall reference architecture defining scope, levels and main architectural elements. >

Actors < All users that interact with the system, including other systems relied upon to accomplish use case. >

Primary actor < A role name or description for the primary actor. The primary actor initiates the use case. >

Stakeholder (optional)

< A list of stakeholder, i.e. individuals or organisations, that has an interest in the solution of the problem. >

Facade (optional)

< A (simplified) interface for the use case. >

Preconditions < Description of the pre conditions for the use case, i.e. what we expect is already the state of the world. >

Triggers < The action upon the system that starts the use case. >

Main success scenario < Description of the use case scenarios. This includes the primary scenario and related secondary scenarios. The scenarios are described as a scenario of steps from trigger to goal delivery, and any cleanup after. >

Extensions < Extensions are actions that will be executed additionally to the main scenario, optional actions, which refine the main actions, e.g. condition causing branching. >

Alternative paths (optional)

< Alternative paths are actions which replace another action in the main scenario or from the extension actions. >

Post conditions < Description of the post conditions for the use case. The post condition will often correspond to the goals. >

Non-functional requirements < Description of non-functional requirements for this use case. These could be linked to a database containing the non-functional requirements for the system. >

Notes < All important information that don’t match another item in the template. >

Author and date < When and by whom the use case (version) was created. >

3.3 ARKTRANS

ARKTRANS [7, 8] is a Norwegian multimodal ITS framework architecture. It has been used as

a base for modelling in the transport domain for several transport and logistics projects both in

Norway and the EU. The work in ARKTRANS has defined a large set of roles and objects for



the transport sector, as well as high-level generic use cases showing relations between actors of

the sector and functions that are performed.

Because of the complexity of the transport sector, the ARKTRANS reference model divides the

sector into five domains:

The Transport Demand domain supports transport preparation and planning, transport

booking, and follow-up for freight as well as passenger transport. The aim is to support

the Transport User, which may be both the party who wants to travel or to send goods

and a third party who is organising the transport on behalf of any Transport User (travel

agency, forwarding agent, logistics provider).

The Transport Service Management domain addresses the management and provision

of transport services to the Transport Demand domain. Such services may for example

be provided by transport companies or terminals. A service may, for example, be

transport along predefined and scheduled routes; ad hoc routes based on actual

demands; document handling services; and terminal services like loading, unloading

and transhipment.

The On-board Support and Control domain addresses navigation, the integration of

Transport Modes and Transportation Network Users in traffic operations, and safety

issues related to the operation of the Transport Means. Adaptation to traffic situation,

traffic regulations, Transportation Network conditions, security and efficiency are

emphasized. On-board equipment provides information and supports safety during

operation of the Transport Means.

The Transport Sector Support domain provides information and supportive services

to the other parts of the Reference Model shown in Figure 3. However, the services do

not represent core transport or traffic activities, as these are covered elsewhere in the

Reference Model (e.g. transport service management). Several types of services may be

offered to the other domains.

The Transportation Network Management domain addresses the infrastructure

provided by roads, fairways, railways, air corridors and Transfer Nodes. A Transfer

Node is in this context a location or area where goods and passengers enter, leave or

transfer between Transport Means. The Transportation Network arrange for mobility in

general. The Transportation Network Management domain is further divided into four

sub-domains, Transportation Network Infrastructure Management, Transportation

Network Utilisation, Regulation Enforcement, and Emergency Management

The ARKTRANS reference model is shown in Figure 4.



Figure 4 – The ARKTRANS reference architecture

The framework architecture, as well as the extensive work on identification and classification of

the roles in the transport sector, can be used as a way of categorizing the use case scenarios and

classification of the actors involved in the use cases. While the results in FInest should

ultimately use the results from the domain understanding task in WP1 for categorization, the

ARKTRANS models can be used before results from WP1 are available and should

complement these results when available.

The high-level generic use cases presented in ARKTRANS may also function as a base for

understanding the processes that must be mapped in the use cases in FInest.

3.4 e-Freight

The e-Freight project [9] aims at supporting, from a transport perspective, the three pillars of

European Policy, namely: Strengthening of the internal market and competitiveness, Improving

regulation to create a more dynamic business environment, and Promoting sustainable

development. This includes enabling transport users to identify and use direct or combined

transport services through the development of open freight transport e-marketplaces, providing

transport chain management solutions assisting stakeholders to establish common end-to-end

transportation processes, and the simplification and harmonization of regulatory requirements

across modes and states through the Single Transport Document and the development of next

generation Single Window solutions.

The e-Freight project develops a reference model for the transport and logistics domain that may

be useful for the work in the FInest project. The project has defined a set of relevant roles and

parties that interact in this domain. Figure 5 shows some of the major roles and parties

involved.



Figure 5 – e-Freight main roles and parties

The e-Freight project has also defined some overall use cases describing some of the main

functions that should be performed in a supply chain setting, as shown in Figure 6.

Figure 6 – e-Freight overall use case



As with the ARKTRANS framework, a reference model from the e-Freight project can be

useful for classifying the use cases that are developed in the FInest project. The work on

identifying roles and the overall use cases can be used for classifying roles and scenarios in the

FInest project, and may also function as useful background information when generating the

FInest use cases.

3.5 MIS

The MIS project [10] is concerned with identifying requirements for a future Norwegian

“Maritime Information Centre”, with a focus on extending the Single Window concept for

simplifying reporting routines and information handling in the maritime sector, and increasing

the availability and visibility of information in the sector.

As a part of the project, a high level mapping of processes for maritime freight operations was

performed, with a categorization of when the processes where performed (in the marketing and

sale of the services, or during planning, execution or completion of the operations), and whether

the processes were mainly related to port and terminal operations, ship operations, or cargo

operations. Figure 7 shows the main groups of operations and their classification in the MIS

project.

The overview may function as an aid to categorizing information gathered in the use case study

work, and the division into marketing and sales, planning, execution, and completion has been

used in early work with the high-level description of the use cases.



Figure 7 – Categorization of operations from MIS project

3.6 Shipping KPI

Shipping KPI [11] is a project that proposes a global shipping industry standard for defining,

measuring, and reporting information on operational performance in order to boost performance

improvements internally in companies engaged in the ship operation activities and provide an

efficient communication platform of ship operation performance to internal and external

stakeholders.

The Shipping KPI Standard is built up hierarchically with 7 Shipping Performance Indexes

(SPIs), 34 Key Performance Indicators and 66 Performance Indicators (PIs). This hierarchy is

shown in Figure 8.



Figure 8 – Shipping KPI hierarchy

There is a mathematical relation between the high level SPIs which are calculated from Key

Performance Indicators, and KPIs which are calculated from Performance Indicators. The PIs

are based on data capture (measurements or counters) directly from a vessel or from the

shipping management. The KPIs are scaled into a range from 0-100, where zero indicates

unacceptable and 100 is outstanding performance. This makes it possible to compare vessels

with different characteristics or amounts of data captured. The KPIs are then combined into

Shipping Performance Indexes in order to express performance within specific areas.

While the Shipping KPI project has a focus on performance indicators for ship operation, it is

expected that experiences with, and methods for, designing KPIs from the Shipping KPI project

will be useful for generating evaluation criteria for the experimentation in the use cases in the

FInest project.

3.7 SHAPE

SHAPE [12] (Semantically-enabled Heterogeneous Service Architecture and Platforms

Engineering) is a European Research Project under the 7th Framework Programme that

developed an infrastructure for model-driven engineering for service-oriented landscapes. The

technologies were tested, demonstrated, and evaluated by two industrial use case partners.

For conducting the Technology Feasibility Study, the project developed a set of Performance

Measures for assessing whether the technological innovations designed in the project fulfil the

business challenges identified in the use case scenarios [13].

The performance measures and evaluation approaches are illustrated in Figure 9. The

performance measures (in the middle) are designed for achieving a set of goals. These goals are

defined based on the business challenges (left hand side), and used to assess the technological

innovations (right hand side).



Figure 9 – Performance Measures development and application in the project SHAPE

Each performance measure is composed of a number and a unit of measure (“Measure Scale”).

The number provides a magnitude (how much) and the unit gives the number a meaning (what).

Performance measures are tied to a Goal, and to Performance Requirements for achieving this

goal, by enabling the measurement of the effect of a capability necessary to fulfil any

performance requirement. The project has adopted the techniques described by Gilb [14] in

order to define performance measures for assessing technologies in later development stages.

Methods on performance measures and evaluation from the SHAPE project may be used in the

work on generating evaluation criteria for the FInest project.

4 Development of a methodology for the FInest project

As mentioned before, the methodology applied in Finest will extend and leverage the previously

referenced projects. This chapter describes the methodology to be used for the use case work in

FInest, and how the methodology is developed.

The methodology for the FInest use case work shall cover the following main items:

A high-level description of the use case scenarios. The work here will be to develop

the proposed use cases (i.e., sea transport of fish, air transport of equipment, and

distribution of consumer goods) into realistic scenarios, showing the main operations of

the involved actors and the main challenges that the actors face. This also includes

some initial expectations on the potential improvements that can be made with Future

Internet technologies.

Detailed use case scenarios, bringing more details to the processes and expected

impact of Future Internet components in the use cases. These will include both “as-is”

descriptions of the processes that are studied, showing how they are performed today,

and “to-be” descriptions showing how the processes can be performed with the use of

Future Internet components. It is expected that this work will bring new requirements

to both the proposed components and to the Future Internet core platform, as well as

ideas for functionality and components not covered by the current FI-PPP projects.

SHAPE use case

scenarios SHAPE

technology results

Business

challenges

Technological innovations

G(oal)

P(erformance) requirement

E(ffect) of capability

M(easure) scale

Pe

rfo

rma

nce

mea

su

res



Experimentation specification, refining the use case scenarios further into

specifications for large scale experiments to be performed in phase 2 of the FI-PPP

projects.

Evaluation criteria, showing how to evaluate improvements made by introducing

Future Internet technologies to the transport and logistic processes.

This deliverable will mainly cover the work on high-level use case description in section 4.1 and

detailed use case scenario descriptions in section 4.2. Methodologies for experimentation

specification and designing evaluation criteria will be briefly discussed in sections 4.3 and 4.4;

these will be described in detail in deliverable D2.4.

This chapter will also describe the methods for gathering data for the use case studies, including

interviews, user stories, surveys, and studies of existing material. This will be further explained

in section 4.5.

The tailoring of the templates to be used in the use case studies in the FInest project, the

structuring of use cases, and the use of diagrams for illustration will be discussed in section 4.6.

4.1 High-level description of the use cases

The aim of the high level description of the use cases is to get an overview of the three main use

case scenarios, making necessary modifications to the proposed scenarios in order to make them

more realistic, and to extend them by describing the work processes that the use case scenarios

involve. to The objective of this effort will be to generate rich descriptions of the processes of

the proposed scenarios, as well as the main deviations and challenges that are encountered.

The high-level description should include details of the main work processes for the involved

stakeholders in the use case study. The focus will naturally be on the stakeholders involved as

participants in the project, but also processes for other stakeholders should be mapped when

these are closely related to the use cases.

4.1.1 Describing work processes

A natural starting point for the high-level description would be to map the work processes

involved in the normal operations of the use cases, and describe the work processes of the

involved stakeholders with “success stories”, i.e., explanations of the processes when there are

no deviations. The story shall include the main steps of the process as well as the important

actors (persons, companies, systems) involved in the steps of the process.

The data gathering at this step will typically be interviews, user stories, or existing process

descriptions provided by the stakeholder.

Using the success story as a frame, the following items may be pointed out:

Common alternative success stories: For some processes, success may be obtained by

other operations than those described in the first success story. If there are several

“success stories” for the same process, all that commonly occur should be described.

Challenges to the operations: Operations may have parts that are considered

problematic or difficult, or where errors commonly occur. These should be described.

The described challenges may give an indication of where the application of new

technologies may give an important impact.



Common deviations to the processes: Most processes will have commonly occurring

deviations that have to be handled, or that may lead to the failure of the process. These

should be pointed out.

Opportunities for Future Internet technologies: These are initial thoughts given by

the stakeholders on how they envision that Future Internet technologies can be used in

the process. Focus could be on the four prototype components developed in the FInest

project (namely Collaboration Manager, Event Driven Monitoring, Transport Planning

and Replanning, and Logistics Contract Establishment and Management) as well as the

identified challenges in the process, but the described opportunities should not be

limited to those.

Figure 10 depicts these main components and their inter-relationships.

Figure 10 – Main components of the high level case study descriptions

It is important to note that processes are not required to have all of these items described; for

some processes, there may be only one way of doing the tasks, deviations may be rare, or there

may be few challenges or opportunities for improvement.

The process descriptions, along with the descriptions of challenges, opportunities, alternatives,

and deviations should be fitted into the template described in section 4.6.1.

The descriptions of common deviations are handled in the same way as the main operations,

e.g., describing them as cases with processes of their own, starting with a “successful” deviation

handling, and then pointing out challenges, deviations and opportunities for the deviation

handling. The same is done when describing important alternative steps for the process. Cross-

references should be used both in the main case and the deviation case. In cases, where

deviation handling is usually not performed, a separate case for the deviation handling is not

necessary, but the effects (e.g. failure of the main process) of the deviation should be described

in the main process. For the deviations in deviation handling (or alternative execution steps),

the description process can be applied “recursively”, but one should note that for the high-level

description, it is not necessary to describe processes that are not fairly common.

4.1.2 Operational phases

As a help for finding relevant processes, it can be useful to use the four phases of transport

operations used in the MIS project [10]: Marketing and sale of the services, planning of the

Success story

Possible deviations

Deviation handling

Challenges

Future Internet opportunities



operations, the actual execution of the services, and the completion of the services (see Figure

11). It is expected that processes relevant to the FInest work will be found in all four phases.

Figure 11 – Four phases of operation used for identifying processes in the MIS project

The Marketing and Sale processes are concerned with creating contact between the actors that

have a need for transport or services and those who can offer transport and services that fulfil

the demand; and the sale of the transport or service. This phase consists of the publishing of

needs or offered services, establishing contact between the parties, agreeing on the terms of the

service, and the sale of the service.

The provision of transport and services is planned and managed based on actual and foreseen

demands and information about the Transportation Network infrastructure and traffic

conditions. The Planning phase includes decisions about routes, schedules, service types, and

the use of resources.

The Execution phase begins when work processes are initiated in accordance with the execution

plans and ends when the execution is completed or cancelled. The execution of the operations

includes movement of goods, cargo handling, document handling, monitoring and control of

operations and goods, supporting effective coordination and accomplishment of the whole

transport chain. This may include transport and terminal operations managed by several

Transport Service Providers (transport companies, terminals, etc.). This phase also deals with

detection and management of deviations.

The Completion phase includes the agreed completion of the services (e.g. delivery of the

transported goods at the destination), handling of payment and claims when the actual service

has deviated from the agreed terms. Also, while the handling of payment for services may come

at any time in the process (e.g. prepayment), it fits in the completion phase from a logical

viewpoint.

4.2 Detailed use case scenarios

The high-level descriptions of the use cases will be refined further to generate detailed use case

scenarios. Here, the main operational steps described in the high-level use cases will be

detailed, including smaller steps, not-so-common challenges and deviations, as well as more

details and requirements for the Future Internet platform and components. Much of the

refinement work will use the same method as the high level description of processes, i.e., start

with the “success story” of the process and then extend this with descriptions of alternative

paths, deviations, challenges, and opportunities for Future Internet technologies.

All scenarios shall be presented in the FInest use case template described in section 4.6.1.

For many of the processes that are to be described, there will be two scenario descriptions; an

“as-is” description that shows the process as it is performed today, and a “to be” description

showing how the process can be performed with envisioned Future Internet technology.

A first step of generating the detailed scenarios will be to identify the processes and operations

from the high-level descriptions where Future Internet technology is expected to make an

impact. In the FInest project, these will be the focus of the detailed use case work.

Marketing and sale

Planning Execution Completion



The processes should then be described in detail. A start here could be to use one or a few of

the main steps of the high-level description, and generate a scenario with a more detailed

process description of the step. Cross-references must be used to indicate that a step is

described in detail in a sub scenario, and that a scenario is a detailed description of a step in

another scenario.

4.2.1 As-is and to-be scenarios

When generating the scenarios, it is useful to first make a description on how the operations are

performed today (i.e., the “as-is” description). This description should be used as a base for a

description of the operation with the envisioned Future Internet technology available (i.e., the

“to-be” description).

A starting point for reasoning about the possible “to-be” scenarios would be to use the proposed

FInest prototype components (i.e., business network collaboration, proactive event driven

monitoring, transport planning and re-planning, and logistics contract establishment and

management), but the “to-be” descriptions do not need to be limited to these. The “to-be”

descriptions should be used to capture requirements to the Future Internet components and

platform.

Note that for some scenarios, there may be several possible “to-be” descriptions for an “as-is”

description, indicating several visions on how new technology may be applied. When

generating a “to-be”-description based on an “as-is”-description, the two use cases should

reference each other.

Having both “as-is” and “to-be” descriptions of the same operations may also be useful when

designing evaluation criteria, i.e. by using comparison with the current situation when

evaluating the results of Future Internet technology.

As with the high-level descriptions, it can be useful to use the “success stories” as a starting

point, i.e. starting with a successful, no-deviation version of the process, and identify alternative

execution paths, deviations, and challenges to the process. For Future Internet opportunities,

these should be identified, and the expected use of the FI technology should be described in the

“to-be” scenario.

4.2.2 Increasing the detail level

It may be possible to generate increasingly more detailed scenarios by identifying steps in the

descriptions that can be expanded as separate “sub scenarios”, just as the initial detailed

scenarios can be derived from steps in the high-level descriptions. In the presentation of the

scenarios, steps that are further detailed in a sub scenario should be linked to the sub scenario

(e.g. by a hyperlink in an electronic presentation or a reference text in a paper document).

The sub scenarios may also be further detailed by generating new scenarios, but one should

keep in mind that the purpose is that the scenarios should be useful to the FInest project, and

that large amounts of data with extreme detail levels can be quite cumbersome to understand

and apply.

4.3 Experimentation specification

The experimentation specification work will consist of refining selected use case scenarios and

generating specification for large-scale trials. This will include detailed definition of the



scenario setting, necessary real-world test data from involved partners, required functionalities

and planned usage of the technical solutions designed in the project, and requirements to the

experimentation environment.

It is assumed that the main use cases that will be part of this work will be “to-be” scenarios that

clearly show the usage of the developed technologies. “As-is” scenarios that correspond to the

“to-be” scenarios may also be used for comparison.

The description of the experimentation specification must be in cooperation with the work

packages that describes the platform and components to be used. Functional and non-functional

requirements from the use cases will be an input to the other work packages, and the

possibilities and limitations of the technology should be communicated to the experimentation

specification work. It is also expected that the experimentation specification work must

cooperate closely with the experimentation environment work in WP4.

The main work on generating a methodology for this topic will be presented in a later

deliverable, D2.4 – Initial experimentation specification and evaluation methodologies for

selected use case scenarios.

4.4 Designing evaluation criteria

To determine the usefulness of the technology that is developed in the FInest project, evaluation

criteria is needed. The criteria must be designed in a way that show if the technology work

towards goals that the different stakeholders have, including goals both for the individual

companies of the industry as well as the overall logistic process.

When important goals are identified, Key Performance Indicators (KPIs) may be identified that

can be used to measure any change towards the goals.

This section gives a short description of the work on designing evaluation criteria. The main

work on this topic will be presented in a later deliverable, D2.4 – Initial experimentation

specification and evaluation methodologies for selected use case scenarios.

4.4.1 Identification of goals

In order to generate evaluation criteria, the goals that the Future Internet technology should

work towards should be identified. A practical starting point for identifying goals is the

industry challenges that are observed in current situation.

It should be noted that the goals are not always universal; different stakeholder have different

goals, and the goals may some times be conflicting. Also, the goals identified for the overall

system (in FInest, improvements to the overall logistic chains) may also be in conflict with

some of the goals identified for the individual stakeholders.

While the project aims at creating technology that makes improvements toward the overall

system, the technology will not be easily adopted by industry unless the industry feels that the

technology also makes improvements toward their own goals, so goals should be identified both

for the overall transport and logistics process as well as for the individual stakeholders in the

process.



4.4.2 Finding and defining key performance indicators

When goals are identified, key performance indicators that may be used to measure the

improvements towards the goals should be found.

The KPIs should be defined in a way that measures the effects of the FI technology without to

much “noise” from other factors. They should also be robust against manipulation (e.g.

knowledge that a certain operation is measured may create an “unwanted” shift of focus towards

that operation, thus generating skewed results). The key performance indicators may be a

function of other performance indicators that may be easier to measure.

4.5 Methods for gathering data

In order to carry out the use case studies, data must be gathered from the participants in the

processes that the use cases include. There are several methods for gathering data, with

different strengths and weaknesses. This section summarizes methods that are likely to be used

in the work in WP2.

4.5.1 Document studies and existing process descriptions

Document studies may include general information about the company, services and strategies

which contribute to understand the case context.

It is not rare that sometimes involved stakeholders already have some documentation describing

processes in the study. In this case the project will use this input as a starting point for gathering

information on the "as-is" situation.

4.5.2 User stories

A user story1 is a free text description of a scenario from an involved participant’s viewpoint.

The description is usually written by the participant. As the story is free text, there is no

training needed, and the writer is not bound by the structure that the results shall have. User

stories do, however, require more work from the modeller, as it becomes the modeller’s job to

structure the story and fit it into the framework used for modelling.

As the stories can easily be written without much help from an interviewer, they may be

effective for getting a high-level description of the processes in the studies, and may thus be an

important way of gathering data in the high-level description work.

4.5.3 Interviews

Collecting data based on interviews may be done as key informant interviews or by focus

groups interviews which involves a moderator facilitating a small group discussion between

selected individuals on a particular topic. For structured qualitative interviews, it is usually

necessary to develop an interview schedule which lists the wording and sequencing of questions

[15]. In this project several templates are developed which constitutes a structure for the

interviews and tools for conducting the interviews. Still it is recommended to make the

interviews conversational and informal, and not to produce a numbered script of questions in a

1 Note that in this deliverable, the term “user story” is not used in the same way as it will be used in the

alignment work between the FI-PPP projects.



tightly structured sequence. This is especially important when it comes to creative interviews

which are tailored, customised and thematic [16]. The Methodology Handbook (appendix A)

includes information about:

How to prepare for and conducting interviews

How to analyse and interpret the data from the interview

How to write, present, and disseminate the results

4.5.4 Surveys

Surveys can contribute in the data gathering process by focusing certain issues and to get data

from several respondents. Based on the first phases of data collections and analysis, the project

should consider developing and conducting surveys which makes it possible to collect large

amounts of data quickly. It is important to know much of the processes that are asked for to

design a good survey and to get the right data. A web based survey may be efficient to collect

data and make initial statistical analysis.

4.5.5 Existing research material

There have been several research projects where processes and operations in the transport and

logistics sector have been described, like ARKTRANS and e-Freight mentioned earlier in this

deliverable. Studies from other projects may be useful both for background material for the

case studies in FInest, as well as for “filling in gaps” in the collected material.

4.6 Structuring the data

The data and information gathered in the use case studies have to be structured in a way that

makes it easy to use further in the FInest project. For the use case scenario descriptions,

standardized templates should be used.

As the use case work is likely to come up with a large number of scenarios, there should also be

ways of categorizing the scenarios, so that the relevant scenarios for a given task in the FInest

project are easily found. Categorization will also make it easier to reuse the results of the use

case studies in other projects, thus increasing the value of the use case material.

4.6.1 Use case scenario templates

The main descriptions of the scenarios in the use cases should be text, structured by using

templates. Diagrams should serve as illustrations, and the information present in the diagrams

should also be described in the text. This will assure that the main contents of the use cases are

readable by all, and that no information becomes hidden in the diagrams.

Textual descriptions require little additional training to understand, making it easier for the

participants in the use cases to discuss the use cases for verification and further refinement.

The S-Cube and SiSaS projects both present use case scenario templates that could be used for

the description of FInest use cases, as described in chapter 3. The fields for the main parts of a

scenario description are the same for both templates, but the SiSaS template is more detailed.

Much of the extra information in the SiSaS template may be useful for keeping track of a large

set of scenarios (e.g., fields that can be used for referencing to other use cases). It is assumed



that the use case studies in the FInest project will produce a large set of varied scenarios, which

makes the extra fields in the SiSaS templates useful.

The SiSaS template is used as the base for the descriptions, but with some modifications. As

many of the described use cases are “as-is” descriptions of current processes, they will not

directly show how Future Internet technology is used; for these scenarios it may be more useful

to sum up expectations to the technology as well as challenges experienced with today’s

processes in separate fields. In the “to-be” descriptions, the use of new technology will usually

be shown in the normal scenario descriptions.

The diagrams used together with the scenario descriptions will in most situations be normal

UML use case diagrams, describing the actors and use cases, as shown in Figure 12. These can

be useful as a visual aid, especially when the use case scenario is linked to other scenarios, e.g.,

through extension, inclusion, or specialization. Note that the use case shall be fully explained

through the text in the template; the diagrams support the understanding of the text, but shall not

replace a textual description in any way.

Figure 12 – Example of UML use case diagram

The template used for the use case scenarios is presented below. The parts changed from the

SiSaS template have been marked in blue:

Table 4 – FInest use case template








Status (Optional – use cases are considered active unless

< Status of the use case. One of the following:

Active

Deprecated



otherwise noted) In the case of a deprecated use case please provide a reason, e.g. in the ‘notes’ field. >













Facade (optional)









Non-functional requirements (optional)

< Description of non-functional requirements for this use case. These could be linked to a database containing the non-functional requirements for the system. >

Challenges (optional)

< Known challenges that are met in the scenario, e.g. parts of the operation considered difficult, common errors etc. >

Future Internet opportunities (optional)

< Opportunities and expectations for Future Internet technology that may improve the case. To be used in “As-Is” description of processes, in “To-Be” descriptions, the expected use of new technologies should be in the scenario descriptions >





A standard template will be generated both for manual use in a document (i.e., the table above)

and for an electronic model version. It is expected that for the generation of reports for use

cases existing in an electronic model, tables generated automatically from the tool will be used.

4.6.2 Categorizing use case scenarios

An important task in the use case descriptions will be to categorize the scenarios. The S-Cube

case study methodology recommends using domain-oriented classification and research-

oriented classification as the main categorization criteria for the scenarios. Categorization of the

scenarios will make it easier to find relevant scenarios for the given research challenges or

components in the FInest project, and will also make it easier to reuse the use case material in

other projects.

The categorization should be used when designing a structure for the presentation of the

scenarios. In an electronic version of the use case, this should be made into a searchable

structure with navigable cross references. In a paper report, this will have to be mapped to a

“flat” structure; if a paper report is generated from the electronic, it should be possible to use the

categories to sort the cases or to just generate a report for scenarios relevant for a given topic.

For a domain-oriented classification, references to placement in a domain or reference model

are used. This model may be provided as a result of the work in WP1, or the models from

ARKTRANS or e-Freight may be used. If the work of WP1 defines a domain or reference

model for use in the FInest project, it will be natural to use this domain model for classification

of the scenarios.

For research-oriented classification, it will be natural to use the research topics of the prototype

component development (i.e., business network collaboration, proactive event driven

monitoring, transport planning and re-planning, and logistics contract establishment and

management), as well as input to the core platform work as classes. There may also be a class

for topics not covered by the FInest work. There should also be an “empty” research class, as

there may be some “as-is” descriptions of processes where we cannot currently find any

opportunities for Future Internet technologies.

Note that the scenarios will also be linked to each other in other ways than the main

categorization. Each scenario will belong to one of the three main use case studies, and will

thus have connection to other scenarios of the same study. Often, the scenarios will be in “as-

is” and “to-be” pairs, describing the same process without and with the proposed Future Internet

technology. Also, many scenarios will be parts, extensions, or specializations of other

scenarios, and thus have a natural link to another scenario. In an electronic presentation of the

cases, this information will be used for generating clickable cross-references, making it possible

to navigate through the use case material in the best possible way for a given task. For a paper

presentation, clear cross-references should be given.

4.6.3 Use of process diagrams

Some times, the use cases describe complex processes or complex interactions between

different actors of the scenario, or there may be a close interaction between several scenarios

that could be useful to point out. Process diagrams can be useful to illustrate these scenarios,

showing the work flow in the process and the information flow between actors.



When creating diagrams, focus should be on the usefulness of the diagrams, and one should

avoid generating complex diagrams if these are not necessary.

5 Discussions and conclusion

FInest’s ultimate goal is to develop a Future Internet enabled ICT platform to support

optimizing the collaboration and integration within international transport and logistics business

networks. To successfully achieve this goal, it is essential that the use cases envisioned in this

project will be studied, developed, and deployed in a consistent and systematic manner. To this

end, this report describes the main procedures to be carried out when describing and detailing

FInest use cases. Appendix A intends to serve as a "user manual" on how to carry out the actual

work in FInest to assure maximum synchronization and consistency among the partners working

on different aspects of the use cases.

A methodology will never be “perfect”, and when using the described methodology, weaknesses

may be discovered. There will be parts of the use case studies that the methodology does not

cover, and there may be parts where the described methodology seems weak. Ideas from other

sources or common sense may be used to “overrule” the guidelines if necessary, but major

modifications to the methodology should be discussed with the WP2 participants.

Furthermore, we believe that as the project progresses, new insights will be obtained and

refinements will be required. While we believe that the use case template described in this

deliverable will cover the main points of the use case scenarios in the FInest project, it may also

evolve during the work. If elements in the template are not used, or if the same kind of

information is listed in the “notes” section in many of the scenario descriptions, the template

should be updated accordingly.

References

1. Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.

2. SiSaS Method Website. [Internet] http://sisas.modelbased.net/

3. Software Services and Systems Network. [Internet] http://www.s-cube-network.eu/

4. Plebani, Pierluigi (editor). S-Cube: Final version of the methodology for describing pilot

cases. 2010.

5. Case studies repository. [Internet] http://scube-casestudies.ws.dei.polimi.it/

6. EnviroFI project web site. [Internet] http://www.envirofi.eu/

7. ARKTRANS. [Internet] http://arktrans.no/

8. Natvig, Marit, et al. ARKTRANS: The multimodal ITS framework architecture. SINTEF ICT.

SINTEF ICT, 2009.

9. e-Freight project website. [Internet] http://www.efreightproject.eu/



10. MIS - Maritime Information Centre. [Internet] http://www.sintef.no/Projectweb/MIS/

11. Shipping KPI. [Internet] http://www.shipping-kpi.com/

12. Shape Project Website. [Internet] http://www.shape-project.eu/

13. Elvesæter, Brian, et al. Shape D1.4: Case Study Execution and Validation. 2010.

14. Gilb, Tom. How to Quantify Quality: Finding Scales of Measure. Proceedings of the INCOSE.

Washington DC , 2003.

15. Patton, Michael Quinn. Qualitative Research & Evaluation Methods, 3rd Edition. Thousand

Oaks : Sage, 1991.

16. Mason, Jennifer. Presentation: What is creative interviewing? Realities, University of

Manchester, 2010.



A. Methodology handbook

Appendix A of D2.1 is the Methodology Handbook. This chapter describes the different steps for conducting a use case study in the FInest project, from the use case identification to its evaluation based on prototype testing on real data. These steps are grouped according to the five Activities that encompass the work on use case studies (see Figure 1). The purpose of this chapter is to be a stand-alone handbook, i.e. guidelines for FInest partners on how to conduct the work. This methodology is to be applied for each use case in FInest, but we believe it is generic enough to be applied to any use case in the domain of Transport and Logistics.

Note: As this Handbook is also based on input from the actual work conducted in the use case studies, it will be updated as the work in T2.2 will be progressing.

ACTIVITY 1:

Identification ofUse Case

•Step 1.1: Refine the use case

•Step 1.2: Identify main processes

..... Page 37

ACTIVITY 2:

High LevelSpecification

As-Is DescriptionStep 2.1: Data Collection / as-isStep 2.2: Process description / as-is Step 2.3: Validation of resultsStep 2.4: The big picture (combining results)

Opportunities for FI technologiesStep2.5: Identification of Future opportunities / potential improvement Step2.6: Dissemination of results

Templates

..... Page 41 ..... Page 52

ACTIVITY 3:

DetailedSpecification

•Step 3.1 Data Collection

•Step 3.2 Design of to-be scenarios

•Step 3.3 Validation and dissemination of results

Templates

..... Page 47 ..... Page 65

ACTIVITY 4:

Experimentation

•Step 4.1: Input from other work packages

•Step 4.2: Refined use-case for experimentation•Step 4.3: Experimentation trial plan

Templates

..... Page 49 .....

2



ACTIVITY 5:

Evaluation

•Step 5.1: Identification of goals

•Step 5.2: Definition of KPIs •Step 5.3: Evaluation of the to-be solutions

Templates

..... Page 50 .....

2

Figure 13: Activities and steps for conducting a case study in FInest2

Activity 1 Identification of Use Cases

Use Case (or use case study) refers to the overall studied scenarios, i.e. for the FInest project, the three main use cases are Fish transport from Ålesund to Europe, Air transport of equipment, and Global consumer goods production and distribution.

Objective:

To identify the use cases, including case partners and processes suitable for testing the four FInest platform components, which are the Business Network Collaboration, Proactive Event Driven Monitoring, Transport Planning and Re-planning, and Logistics Contract Establishment and Management.

ACTIVITY 1:

Identification ofUse Cases

•Step 1.1: Refine the use case

•Step 1.2: Identify main processes

Step 1.1 Refine the use case

This introduction phase shall concentrate on refining each use case study that has been proposed in the project’s Description of Work. The purpose is to define scenarios that are realistic and built on real-life facts and information.

Expected Outcomes from Step 1.1:

Each use case shall be described with the following elements:

2 The methodology for experimentation specification and evaluation criteria will be described in a later

deliverable. Therefore, the templates for the corresponding activities are currently not available.



Element Description

Case title A short name for the use case and more specifically the scenario being studied.

Operational description

Give a textual description of what the use case is about; the business goal (the logistics service identified) and the solution chosen for achieving this goal ( delivering this service)

Cargo Type Describe the type of cargo

Transport Mode Identify the transport modes involved

FInest Components Specify Finest Components which are a priori most relevant for the use case

Companies involved and roles

For each use case, describe the companies selected for representing the transport operations (the role they fulfil) covered by the use case.

Challenges Describe business-, operational, technical challenges that the use case addresses, i.e. the problems that the case companies face.

Related Finest R&D areas

Specify Finest R&D areas which a priori contributed the most to the use case Study.

Step 1.2 Identification of main processes

For each company involved in the use case on focus, the main business processes shall be identified around the following chronological operational phases (taken from MIS project, [10]):

1. Marketing, Sale, and Alignment

The Marketing, Sale, and Alignment processes are concerned with creating contact between the actors that have a need for transport or services and those who can offer transport and services that fulfil the demand; and the sale of the transport or service. The phase consists of:

- the publishing of needs or offered services, - establishing contact between the parties, - agreeing on the terms of the service and - selling of the service.

2. Planning

The provision of transport and services is planned and managed based on actual and foreseen demands and information about the Transportation Network infrastructure and traffic conditions. The planning includes decisions about:

- routes, - schedules, - service types and - use of resources.

3. Execution

The Execution phase begins when work processes are initiated in accordance with the execution plans and ends when the execution is completed or cancelled. The execution of the operations includes movement of goods, cargo handling, document handling,



monitoring and control of operations and goods, supporting effective coordination and accomplishment of the whole transport chain. This may include transport and terminal operations managed by several Transport Service Providers (transport companies, terminals, etc.). This phase also deals with detection and management of deviations.

4. Completion

The completion phase includes the agreed completion of the services (e.g. delivery of the transported goods at the destination), handling of payment, and claims when the actual service has deviated from the agreed terms. Also, while the handling of payment for services may come at any time in the process (e.g. prepayment), it fits in the completion phase from a logical viewpoint.

To summarise, Figure 2 below shows each of the four main transport phases and some of the transport operations engaged in these phases.



Figure 14: Four Main Processes involved in Transport Service (Source: MIS, 2010)


The main purpose of this step is preparation. The Identification of Main Processes should result in an understanding of the scope of the use case, giving the interviewers (people who will be responsible for gathering the data) an initial idea of the processes to focus on in the use



case study, regardless of their previous experience and level of knowledge about the Transport and Logistics domain.

Activity 2 High level specification of use case scenarios

Objective:

To describe realistic real-world scenarios and understand the overall processes and main challenges faced by the actors involved.

ACTIVITY 2:

High LevelSpecification

As-Is DescriptionStep 2.1: Data Collection / as-isStep 2.2: Process description / as-is Step 2.3: Validation of resultsStep 2.4: The big picture (combining results)

Opportunities for FI technologiesStep2.5: Identification of Future opportunities / potential improvement Step2.6: Dissemination of results

The following diagram summarizes the execution plan and process of interaction with the companies involved in the use case studies during the Activity 2, followed by a detailed description of all steps of Activity 2.

Data Collection / as-is

As-is process description

Validation

Future Opportunities and Specification of potential improvement

Dissemination

Mile

sto

nes

sSt

eps

AS-IS DESCRIPTION OPPORTUNITIES FOR FI TECHNOLOGIES

Combining results

Figure 15: Execution plan for Activity 2.

Step 2.1 Data Collection / as-is

This step is concerned with the collection of all primary and secondary data necessary for describing and mapping the as-is business processes of each use case scenario, as well as information on users requirements for the FInest components.



The data gathering shall consist of:

- Review of company’s documentation (as secondary data), such as procedures, guidelines, systems in use.

- Interviews of company’s representatives and user stories (description of a process done by the person or people usually performing the process) to capture information on as-is processes, main challenges countered, most common deviations from plans, and actions taken to deal with these. This will result in a high level specification of the use case studies, thus a starting point for the high level specification of the to-be situation. In addition, as input to other work packages in the FInest project, the interview will seek to collect the company’s requirements to FInest components and discuss Key Performance Indicators to be used for evaluating the to-be reconfiguration.


The data to be collected shall cover the followings:

- Description of the processes engaged in the use case study, specifying the title of the process as well as describing its realisation (a summary). The level of detail in the process/sub-process description should depend on the relevance for the use case. As a baseline, the “success story” shall be used, e.g. the description of “normal” processes when no deviations occur. The story shall include the main steps of the process as well as the important companies (persons, companies, systems) involved in the steps of the process, the type of activity and information exchanged as well as the communication channel(s) used.

- Thereafter, the data collection process shall focus on challenges, such as common errors, obstacle to operations, problems often encountered.

- This will be further expanded by introducing deviations (extensions) from a “normal process” and the processes of handling the deviations (alternative paths, if described).

- Finally, the data collection process shall aim at identifying opportunities for Future Internet technologies. These are initial thoughts from the stakeholders on how they envision that Future Internet technologies can be used in the process. Focus could be on the four prototype components developed in the FInest project, as well as the identified challenges in the process, but the described opportunities should not be limited to those. The identification of these opportunities should also be related to the user requirements or expectations expressed by the case companies during the first gathering of data, as well as some first ideas on success criteria or performance measures discussed during the interview.

An interview guide presenting advice for interview preparation and execution is to be found in the template chapter on page 52.

Step 2.2 As-is process description

The high level descriptions should aim at creating a rich description of the scenarios, using information from involved companies, with the purpose to identify Future Internet Opportunities. This shall include description of the normal operations (“success story”) as well as common deviations and the operations for handling the deviations. The descriptions shall



also include descriptions of the main challenges that must be met and may also include descriptions of expectations from and opportunities for Future Internet technologies in the operations; this includes both the proposed FInest components as well as other technology. This process of high level description of use case studies is schematised in Figure 4 below.

Figure 16 – Main parts of the high level use case descriptions

The descriptions of the handling of deviations shall be done in the same way as the main operations, e.g. describing them as scenarios with processes of their own, starting with a “successful” deviation handling, and then pointing out challenges, deviations and opportunities for the deviation handling. The same is done when describing important alternative steps for the process. Cross-references should be used both in the main scenario and the deviation scenario.

When deviation handling is usually not performed, a separate scenario for the deviation handling is not necessary, but the effects (e.g. failure of the main process) of the deviation should be described in the main process.

For the deviations in deviation handling (or alternative execution steps), the description process can be applied “recursively”, but one should note that for the high-level description, it is not necessary to describe processes that are not fairly common.


Once the interview is completed, an interview report shall serve for documenting the information collected. A template for producing that report is available in the template chapter on page 59. This template is just for indication purpose, and its layout can be modified according to the data collected.

Step 2.3 Validation of results

Once the report on as-is processes has been described in textual format, it should be distributed to the company involved in the use case for verification and validation. It is important to communicate with the companies involved in the use cases, ensuring that the description reflects their work correctly.

Success story

Possible deviations

Deviation handling

Challenges

Future Internet opportunities



In addition, this step will also serve to complete the data collection. Based on the interview report produced in Step 2.2 and a list of missing points, further information needed or clarification of existing information, should be prepared and communicated to the case companies (preferably the same respondents as previously). This process can be done by email or even telephone.

It is important to note that the case study companies are participated in other parts of the project and therefore solicited by other work package for delivering information. The Step 2.3 shall be used to coordinate with these other data collection initiatives, making sure all data required is covered, but also for avoiding too much repetition of work from the part of the respondents.


Revised and final versions of the as-is process description reports from each interview with use case partner.

Step 2.4 The “Big Picture”: combining results into an overall use case process description

What?

A description of the process and transport operation for the use case should be made based on data and results from all companies involved in the use case study. The “Big Picture” constitutes the construction of an overall picture and descriptions of the use case including all roles/actors, where the focus is on the value creation process and interfaces between involved companies. This can be done in form of a process diagram displaying the main processes of the transport service on one axis and the transport operations (roles) on the other axis.

How?

Conceptually, the merging of all results from as-is descriptions is illustrated in the example below (example from the Fish transport case). Another example is the one from the project MIS, displayed in Figure 14.

For each of the companies represented in the use case, a broad description of the business processes, divided into four main processes (marketing, planning, execution and completion) has to be drawn. These process descriptions will be juxtaposed with the purpose to identify the interfaces between two or more companies , how they interact with each other and during which process.



Figure 17: example of high level process description

Who?

Each use case study leader (more preferably their modeling experts) have to combine the as-is process description from each company involved in the use case (i.e. the outcome of Step 2.2, validated in Step 2.3) in order to constructing the “big picture”. This picture should be validated by the companies involved. Preferably, this may be done through discussions in a meeting, where all involved partners participates to create a shared understanding of the picture and a common frame of reference, which is valuable regarding the next phases in the project.


A “picture”, diagrams showing the main processes in which the case companies are engaged and through which they interact and descriptions of main operations/processes, interfaces and information exchange between actors.

Step2.5: Identification of Future opportunities and Potential Improvement

Marketing,

Sales, Alignment

Planning Execution Completion

Freight Forwarder (e.g Kuehne&Nagel)

Transport & Logistics Service Provider (e.g NCL)

Port (e.g Port of Ålesund)

Terminal operator (e.g Tyrholm & Farstad)

Cargo Owner (e.g Fish producer)

M,S,

P E C

M,S,

P E C

M,S,AP E C

M,S,AP E C

M,S,A P E C



This step involves discussion with case partners and identification of opportunities for Future Internet technologies suitable for bringing improvements to the as-is processes.

A natural starting point for this identification process will include (1) the overall use case process description (step 2.4) highlighting the bottleneck areas, and (2) an cross-reference matrix showing the FInest components under construction (WP5-8) and their intended support to transport and logistics operations. A draft of this matrix is presented in the figure below.

Figure 18: Relevance of the FInest components for each phase of transport.

The purpose of this step is to collect reflections from the use case companies on expected improvements.

MARKETING, SALE, ALIGNMENT

PLANNING

EXECUTION

COMPLETION

AS-

IS:

Ho

w t

ran

spo

rt p

roce

sse

s ar

e c

arri

ed

ou

t to

day

BUSINESS NETWORK COLLABORATION

EVENT DRIVEN MONITORING

PLANNING / REPLANNING

CONTRACT MANAGEMENT

User requirements: How can Finest facilitate the transport processes

• Invoice

• Payment • Claim

• Follow-up of logistics process

• Flexible respond to change

• Coordinate planning and execution of inter-organiational processes

• Combine functionality of roles

Agile planning / replanning

• Resource

overview

• Collaborative solutio

n search

• Implementation of transp

ort plan

• Deviation

Enable detection of

deviation

Enable real-time planning

Contract negociation,

establishment, and enactment

Determine



For each challenge identified (in step 2.1), a solution should be suggested (yet under the scope of the FInest components to be developed), and the parts of the as-is process expected to be changed/facilitated by selected Future Internet technologies should be described more in detail (specifying how the expected solution would improve and/or change the current process).

This identification of Future Internet opportunities shall be done in close dialog with the case partners. This can be done through workshop, telephone meeting, email exchange, etc. but the more important is to ensure that the challenges currently faced are understood and that the identified potential solutions effectively address these challenges.


A short report summarizing the identified opportunities for Future Internet Technologies, potential improvements expected and recommendations for the to-be design phase (in the Detailed Specification of use cases). If possible, use cases representing a particular challenge in current operations, and thus an opportunity for the FInest collaboration and integration platform should be modeled.

Step2.6: Dissemination of results

This step focuses on consolidating and delivery on the report on High Level Specifications (D2.2), compiling all documented working processes, proceedings from interviews and mapping and descriptions of processes.


The Deliverable D2.2: High Level Use Case Specification

Activity 3 Detailed Specification of Use Case Scenarios

Note: This activity will be refined at the beginning of Task 2.3.

Use case scenarios: Each use case comprises one or more scenarios that describe how actors in the use case perform a set of operations in order to achieve a specific result. In FInest, both “as-is” and “to-be” scenario descriptions will be created. The “as-is” descriptions describe the current operations that will serve both as a base for understanding the operations and for pointing out current challenges and opportunities for Future Internet technologies. “To-be” scenario descriptions will include the use of Future Internet technology, and may thus serve as an input to the requirements for the technology.

Objective:

To re-design the scenario(s) based on new solutions for tackling the challenges identified and making use of the technologies envisioned.



ACTIVITY 3:

DetailedSpecification

•Step 3.1 Data Collection

•Step 3.2 Design of to-be scenarios

•Step 3.3 Validation and dissemination of results

There are two main types of detailed use cases; cases describing the “as-is” situation, i.e. the processes as they are performed today, and cases describing “to-be” situations, i.e. the processes as they are envisioned with availability of FI technology.

The “to-be”-scenarios shall capture the envisioned use of new technology, the requirements to the technology, and thus generate a better understanding of how the technology is expected to work.

Step 3.1: Data collection

User stories and interviews are the main ways of collecting data. When a more detailed understanding of the processes involved is in place, surveys may be used for data gathering. Some data may be collected by using existing material (e.g. process descriptions provided by companies or use case studies from other projects).


Each detailed use cases shall be presented following the FInest use case template to be found on page 65.

Step 3.2: Design of to-be scenarios

Typically, “to-be”-scenarios will be created based on the “as-is” scenarios, e.g. describing the same scenarios with new technology available. An input to the “to-be” scenarios will be the (envisioned) possibilities of the FInest components and the Future Internet platform. The same components and platform will also be consumers of results from the “to-be” scenarios, as it is expected that new requirements to the components, as well as wishes for functionality from the industry will come out of the scenario descriptions.


Design of to-be scenarios using the FInest use case template to be found on page 65.

Step 3.3: Validation and Dissemination of results




The Deliverable D2.3: Detailed Use Case Specification

Activity 4 Experimentation specification

Note: This activity will be completely defined during Task 2.3.

Objective:

To refine the use cases further into specifications for large scale experiments to be performed in phase 2 of the FI-PPP projects.

ACTIVITY 4:

Experimentation

•Step 4.1: Input from other work packages

•Step 4.2: Refined use-case for experimentation

•Step 4.3: Experimentation trial plan

The description of the experimentation specification must be in cooperation with the work packages that describes the platform and components to be used. Functional and non-functional requirements from the use cases will be an input to the other work packages, and the possibilities and limitations of the technology should be communicated to the experimentation specification work. It is also expected that the experimentation specification work must cooperate closely with the experimentation environment work in WP4.

The main work on generating a methodology for this topic will be presented in a later delivery, D2.4 – Initial experimentation specification and evaluation methodologies for selected use case scenarios.

Step 4.1: Input from other work packages (possibilities and limitations of the technology)

This step will be better understood and described further in the project (within Task 2.3, starting month 7)

Step 4.2: Refined use-case for experimentation


Step 4.3 Experimentation trial plan





The Deliverable D2.4: Initial experimentation specification and evaluation methodologies for

selected use case scenarios.

Activity 5 Evaluation

Note: This activity will be completely defined during Task 2.4.(starting month 12)

Objective:

To design the evaluation criteria, showing how to evaluate improvements made by introducing Future Internet technologies to the transport and logistic processes.

ACTIVITY 5:

Evaluation

•Step 5.1: Identification of goals

•Step 5.2: Definition of KPIs

•Step 5.3: Evaluation of the to-be solutions

To determine the usefulness of the technology that is developed in the FInest project, evaluation criteria is needed. The criteria must be designed in a way that show if the technology work towards goals that the different stakeholders have, including goals both for the individual companies of the industry as well as the overall logistic process.

When important goals are identified, Key Performance Indicators (KPIs) may be found that can be used to measure any change towards the goals.

This section gives a short description of the work on designing evaluation criteria. The main work on this topic will be presented in a later delivery, D2.4 – Initial experimentation specification and evaluation methodologies for selected use case scenarios.

Step 5.1 Identification of goals


Step 5.2 Definition of key performance indicators




Step 5.3 Evaluation of the to-be solutions



The Deliverable D2.4: Initial experimentation specification and evaluation methodologies for selected use case scenarios.

B. Templates

Template 1: Interview guide for as-is description page: 52

Template 2: Interview report template (as-is description) page: 58

Template 3: FInest Use case template page: 65



Template 1: Interview guide for as-is description

INTERVIEW GUIDE FOR AS-IS DESCRIPTION

1 Preparation for the Interview

The following check list should be followed by each use case study during preparation for the interview:

1. Take contact with the companies for introduction and making an appointment for a meeting, and to set a date for the interviews.

2. Study available information from the companies to learn about their transport processes (either company presentations, procedures, and other documents available, or theoretical publications).

3. Identify the respondents that need to be involved in the use case study. This includes persons with knowledge on all phases in the transportation processes (e.g. at least sales, operations, planning, finance departments).

4. Review the questionnaire template and adapt it to the particular interview if necessary/possible (start to fill in with available information, write some specifications around the questions, make preparation-note for the interviewees), based on the company’s documentation reviewed.

5. Send the information to contact persons. This e-mail should confirm the appointment, the proposed agenda and information on what the companies need to prepare (ref. preparation note) in front of the studies (if judged necessary).

6. Ask if voice recording of the interview can be done. This will help greatly for the production of the interview report.

7. Confidentiality: verify the level of confidentiality required by the use case company. The aim is to publish all deliverables from FInest, which means that the interviewer must extract as much non-confidential information as possible, while making sure all processes and requirements are covered.

2 Advices for the Interview

Meeting Design:

A one-day meeting should be planned. Please note that besides face-to-face meetings, teleconference with presentation possibility is available. You can use conferencing software such as netmeeting, go to meeting or Adobe Connect to conduct the interview, in case that your interview partner or yourself is not available for travelling.

Alternatively, data can be collected through user stories, by which the respondents are asked to described in written format the way processes are being executed. Such a technique leave more time for the respondent to structure his/her answers, but obviously enable less interactions and possibilities for asking direct questions.

Interview participants:



Interviewer: One should aim at being at least two persons at each interview; one makes notes while the other asks questions (the roles can switch between the persons).

Interviewees: one by one or grouped, depending on the availability of the employees. The representatives should cover all the processes to be studied.

The following agenda may be proposed for the interview:

1) Welcome and introduction a. Thanks for the willingness to participate b. Presentation of agenda

2) Overview of FInest project objectives (PPT available on eRoom) 3) WP2 objectives 4) Objectives for the interviews (Why? How?) 5) How can the results from Finest be useful for the interviewee / company respondent? 6) Start the data collection:

a. Give an introduction to the template, e.g. showing the various phases in the transportation that are to be covered in the interview, the type of information expected.

b. Questions / discussions

It should be noted that this agenda is of course open for changes. It is just meant as a support, but should be adapted to the specific use case study and the type of respondent.

3 Information to be Captured during the Interviews

The information captured during the interviews will be used in several work packages: WP1 (business requirements, ICT solutions in use), WP2 (as-is processes), WP5-8 (user requirements for the Finest components).

The interview shall cover the following topics:

As-is description of current practices:

Get a description of what happens during all phases of transportation, including a description of the process, what data/information is produced and exchanged, what formats are used, and which actors are involved and how they interact. The information shall be collected by going through each transport process (see chap 5.1 for detailed description):

- Marketing, sale, and alignment

- Planning

- Execution

- Completion



Information on normal process (“success story”) shall be collected, as well as main deviations and actions normally taken for handling these deviations (alternative paths)

This will be used as a starting point for Activity 3, to identify improvement areas or opportunities for Future Internet Technologies (and design the to-de processes).

Identify users’ requirements for the components to be developed in Finest:

User’ requirements must be understood in a broad sense. While the high level specification shall focus on description of as-is processes, the first interview with companies should also be taken as an opportunity to collect more input for the use cases and for the rest of the project. The user’ requirements data collection part shall therefore consist of:

1. Challenges:

Any challenge faced by the company, in any the processes described or overall challenges that are of relevance for Finest, i.e. which Future Internet Technologies may help overcoming.

Special focus on information relevant for Finest shall include::

o Planning and Replanning: what information is gathered and how in order to get overview of resources available, find a solution, negotiate and implement a transport plan, and re-act in case of deviation from plan.

o Monitoring (Event handling and Event-driven monitoring): get a description of event handling: what events occur, how frequent, what is the consequences, how is normal operation restored

o Business network collaboration: how inter-organisational processes are coordinated, how the functionalities of each role are combined, i.e. how information is kept and by whom, how supply chain processes are synchronised and by whom, how information is exchange and by whom.

o Contracting and Contract management: how contract is defined, negotiated, established, and enacted, including invoicing, payment, and claim handling.

2. Expectations from Finest / Opportunities for Future Internet Technologies:

Based on the challenges identified or in addition to those, information should be collected about the company’s expectations from Finest and more specifically from the four defined components (WP5-8). The purpose is to start specifying areas of opportunities for Future Internet Technologies. This will be investigated more in depth during the second phase of the High Level Specification (i.e. second phase of Activity 2).

3. Success Criteria / Performance Measures:

The company’s goals (business goals, technical objectives etc) form the basis for their requirements regarding new technologies or solutions. During the description of the as-is processes, deviations, challenges etc. It is important to collect information about success criteria and performance indicators which the company either applies today to its own processes for measuring performance and achievement towards goals, or



which the company identifies as the most relevant success criteria for the to-be solutions and Future Internet Technologies.

4 Templates for Questionnaires

This section contains templates that can serve as a check-list when performing the interviews. The templates cover all information described above to be identified through the interviews and use of available documentation. It is important to note that a detailed table is not to be filled up by the respondent, but by the interviewer, based on the information obtained during the interviews. Besides, these templates / tables do not need to be filled up during the interview, but after, for information structuring purpose and to ensure that all necessary information has been collected.

Two types of templates are used:

1) AS-IS template: Template to describe the AS-IS situation. This includes describing the normal situations (success stories), but also to identify deviations (events and exceptions) that happen and handling of these deviations (alternative solutions).

2) Requirements Template: Template to focus on organizational challenges, functional and non-functional requirements to Finest (opportunities identified), and success criteria for Finest components (which will contribute to building the evaluation of the to-be solutions developed during the detailed specification phase.

4.1 AS-IS Template

Figure 19 shows the template to describe the AS-IS situation regarding the use cases.

Process Name (1) Process Description (2) Actors/Roles

involved

(3) Exchange of information

(3a) Information description

(3b) Sender (3c) Receiver (3d)

Communication channel

1) Success Story / Normal Process

Deviations

Alternative paths...

2)

3)

4)

5)

6)

Figure 19: As-is template

Each line in the table contains a process/business task that is part of the transportation and logistics chain.

The columns represent information that has to be captured for each process:

1) Process description: Description of the actual process including



a. General description; goals; normal process.

b. Critical dependencies to other processes, actors, or information.

c. What is the situation before this step is conducted, after the step has been conducted?

d. What triggers the activity?

e. Events or exceptions (Deviations) that can occur during this process, and alternative paths (how deviation is handled). This is listed in a separate line in this table, below the process it belongs to

2) Actors involved in this process, and which role they have in the process. It is important to distinguish between actors and roles, since each actor can fulfil several roles, and a role can be handled by several actors. For instance, in the fish transport use case, the actor Tyrholm-Farstad is an actor with at least two roles: ship agent, and cargo agent.

3) Exchange of information:

3.a. Description of the information: contents, data format, standard of the information that is exchanged.

3.b. Sender: who or what is sending the information; this can be an actor or an ICT system.

3.c. Receiver: who or what is receiving the information; this can be an actor or an ICT system.

3.d. Communication channel: how is the information transferred? E-mail? Phone call? Fax? Electronic system, software?

4.2 Requirements Template

Figure 20 shows the template to describe requirements, exceptions, and success criteria related to the use cases. This template focuses more on the TO-BE situation for the use cases.

(4) Organizational

Challenges

(5) Expectations from Finest (opportunities) (6) Success Criteria

(5a) Business Network

Collaboration

(5b) Event-driven

Monitoring

(5c) Transport Planning

and replanning

(5d) Contract Estabishment

and Management

Figure 20: Requirements Template

Each line in the table contains a process/business task that is part of the transportation and logistics chain.

The columns represent information that has to be captured for each process:

4) Organizational Challenges:



a. Cooperation b. offer services that includes several transport service providers

5) Expectations from FInest: These expectations are to be seen as a first input which will be studied in depth in the second part of the Activity 2. These expectations and identified opportunities will form the basis for the high-level description of the TO-BE situation of the use cases, and also be used as input to the Finest component development.

5.a. Business Network Collaboration: i. Collaboration

ii. Exchange of information iii. Status tracking iv. Security v. Privacy

5.b. Event-driven monitoring: i. What reaction should be given on what event

ii. Get event from sources, route events iii. Filtering of events iv. Aggregate events v. Transfer events to humans or via systems

5.c. Transport Planning and replanning: i. Pickup times

ii. Hazmat restrictions iii. Environmental goals iv. Replanning: information about resource status, availability, new

transport possibilities, cargo configuration 5.d. Contract Establishment and Management:

i. Responsibilities ii. Legal terms

iii. Pricing information iv. Negotiation v. Management of contracts

6) Success Criteria / Performance indicators

(Not mandatory to cover this absolutely, but good to have some input)

Rather than focusing on identification of bottlenecks or process failures, it is important to focus on defining success criteria. This for two reasons:

Focusing of success criteria on a high level (overall goal) rather than operational level (type of resource, information flow etc) gives rooms for identifying innovative solutions, i.e. solutions that are focus on performance and outcomes and are not limited by as-is processes.

Success criteria and performance measurement will enable the evaluation of the to-be processes, enable comparison and discussion.

Identification of success criteria and performance indicators:

Examples of success criteria/performance requirement:

Reduced costs of activity (less time consumed, less human resources, ,,

Enable ”normal” working hours (avoid week end over night work…)

Reduce vulnerability (reduce dependency on other roles for obtaining data …)



Template 2: Interview report template (as-is description)

FInest – Future Internet enabled optimisation

of transport and logistics networks

As-Is Description

< name of the use case company>

Interviewers:

<name of FInest partner>

<Names of interviewers>

Interviewees:

<name of the use case company>

< Names of interviewees>

Interview Date: <date>

Report Date: <date>



5 Contents

1. Meeting Agenda .................................................................................................................. 60

2. Introduction to <Company name> ...................................................................................... 60

2.1. Company presentation ................................................................................................ 60

2.2. [Type of transport / cargo on focus in the use case] .................................................. 60

2.3. Matters related to the Finest project .......................................................................... 60

3. As-Is Description .................................................................................................................. 61

3.1. Processes and Information flow diagram ................................................................... 61

3.2. As-Is text description / success story .......................................................................... 61

3.3. Summary table ............................................................................................................ 61

4. Requirements Description................................................................................................... 63

4.1. Main challenges to be tackled: ................................................................................... 63

4.2. Expectations from Finest ............................................................................................. 63

4.3. Main KPIs: .................................................................................................................... 63

4.4. Summary table ............................................................................................................ 64

Annex 1: Company Presentation ................................................................................................. 64



1. Meeting Agenda

Reproduce the meeting agenda that was communicated to the participating company.

2. Introduction to <Company name>

If available, insert the presentation made by the company in annex.

2.1. Company presentation

History

...

Strategy:

...

Markets:

...

Resources and transport network:

...

Datasystem

...

2.2. [Type of transport / cargo on focus in the use case]

[E.g “fish transport”]

Give a more in-depth introduction to the type of transport services relevant for the use case (i.e. the scenario described) and list the main challenges reported by the company.

2.3. Matters related to the Finest project

List any expectations from FInest mentioned by the respondent.

This can include:

Matters related to project administration and management

Suggestions regarding the content of the use case (additional companies to be involved in the process)



3. As-Is Description

3.1. Processes and Information flow diagram

This section should give a broad picture of the processes identified and described. A work flow diagram can be used for facilitating the understanding.

3.2. As-Is text description / success story

Each process and sub-process shall be described in text, will all the information communicated by the respondents. The as-is “success story” shall be described, as well as the associated challenges encountered, and the actions normally taken for overcoming these challenges.

3.3. Summary table

The as-is process description shall be summarised in the template table below (same table as in the interview guide). This table will help structuring the information when combining the data from each Company interviewed.



Process name (1) Process Description (2) Actors/Roles

involved

(3) Exchange of information

(3a) Information description (3b) Sender (3c)Receiver (3d)Communication channel

MARKETING, SALE, ALIGNMENT

Examples of sub-processes:

Publish schedule

PLANNING

Prepare Operation Plan

Discharge/load list

Build WayBill

EXECUTION

Stowage plan

COMPLETION

Issue invoice

Invoice Control

Table 1: AS-IS table description of information exchange in each business process.



4. Requirements Description

4.1. Main challenges to be tackled:

A summary description of the main challenges to be tackled in the phase of to-be design shall be

written.

4.2. Expectations from Finest

Some first input regarding FInest components and which part of the company’s processes

FInest should help improving and how, as well as identified opportunities for Future Internet

Technologies.

4.3. Main KPIs:

A list of main evaluation criteria and KPI collected during the interview shall be given here.

These may be summarised in the following table:

KPI name Description Measurement Target Comment



4.4. Summary table

The challenges, success criteria and FInest requirements shall be summarised in the template table below (same table as in the interview guide). This table will help structuring the information when combining the data from each Company interviewed.

This table will serve as starting point for the to-be design in the next step.

(4) Organizational

Challenges

(5) Expectations from Finest (opportunities) (6) Success Criteria

(5a) Business Network

Collaboration

(5b) Event-driven

Monitoring

(5c) Transport Planning

and replanning

(5d) Contract Estabishment

and Management

Table 5: Requirements Template

Annex 1: Company Presentation

.....



Template 3: FInest Use Case Template








Status (Optional – use cases are considered active unless otherwise noted)

< Status of the use case. One of the following:

Active

Deprecated

In the case of a deprecated use case please provide a reason, e.g. in the ‘notes’ field. >













Facade (optional)











Non-functional requirements (optional)

< Description of non-functional requirements for this use case. These could be linked to a database containing the non-functional requirements for the system. >

Challenges (optional)

< Known challenges that are met in the scenario, e.g. parts of the operation considered difficult, common errors etc. >

Future Internet opportunities (optional)

< Opportunities and expectations for Future Internet technology that may improve the case. To be used in “As-Is” description of processes, in “To-Be” descriptions, the expected use of new technologies should be in the scenario descriptions >



future internet enabled optimisation of transport …...the research leading to these results has...

Documents