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
66
Embed
Future Internet enabled optimisation of transport …...The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013]
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
otherwise noted) In the case of a deprecated use case please provide a reason, 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 (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 >
Notes < All important information that don’t match another item in the template. >
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
•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.
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)
Expected Outcomes from Step 1.2:
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.
- 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.
Expected Outcomes from Step 2.1:
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.
Expected Outcomes from Step 2.2:
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.
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.
Expected Outcomes from Step 2.3:
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.
Expected Outcomes from Step 2.4:
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
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
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.
Expected Outcomes from Step 2.5:
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.
Expected Outcomes from Step 2.6:
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.
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).
Expected Outcomes from Step 3.1:
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.
Expected Outcomes from Step 3.2:
Design of to-be scenarios using the FInest use case template to be found on page 65.
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
This step will be better understood and described further in the project (within Task 2.3, starting month 7)
This step will be better understood and described further in the project (within Task 2.3, starting month 7)
Expected Outcomes from Step 4.3:
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
This step will be better understood and described further in the project (within Task 2.4, starting month 12)
Step 5.2 Definition of key performance indicators
This step will be better understood and described further in the project (within Task 2.4, starting month 12)
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.
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):
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
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:
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 …)
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)
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.
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
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 (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. >
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 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 (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 >
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. >