Background material on use cases
Mentoring material
Date:
Authors:
Number of pages:
Number of Annexes:
Version
Dissemination
Contract
Friday, 14 July 2017
Lina Huertas, Junuz Jakupovic
8
0
1.0
Public
678860
Main message:
Use cases are a key element in the processes to be performed by DIH. This document
provides guidance on the structure of a use case description and how to complete it,
including an example. A template is included at the end of the document for use by the
DIHs.
No part of this publication may be reproduced and/or published by print, photo print, microfilm or any other means without the previous
written consent of the XS2I4MS consortium. Submitting the report for inspection to parties who have a direct interest is permitted.
© 2016, XS2I4MS
Background material on use cases
I4MS Mentoring material
Version 0.1
1
Introduction to use cases
1.1
Introduction to the Mentoring
programme
This background paper is developed within the framework of
the XS2I4MS project. The XS2I4MS project is part of the
European I4MS strategy to enhance the use of ICT within
European manufacturing SMEs in order to enhance their
competiveness and create new business.
 The objective of this document is to provide guidance
for Digital Innovation Hubs on the generation of use
cases and definition of work for prospect customers.
 The audience of this document are personnel within
Digital Innovation Hubs who are involved in scoping
new project opportunities for digitisation of SMEs.
During phase 2 of the I4MS a major new
activity was launched: The Mentoring and
sponsorship programme. This activity aims
at extending and enhancing the I4MS
ecosystem to mainly cover European
regions which are not currently involved in
I4MS. The objective is to assess the
feasibility and prepare 29 Digital
Innovation Hubs involving new and
existing competence centres, manufacturing SMEs and mid-caps and other stakeholders such as regional
bodies.
This Mentoring programme is set within the framework of the I4MS. The first phase of the I4MS 2013-2015 has
resulted in seven integrated projects, more than 60 competence centres and about 150 experiments
implemented in the I4MS community. However, when looking at the distribution of the activities it is clear that
participation to the I4MS is mostly limited to the Member States that are strong in the technologies supported
by I4MS. The I4MS Phase 2 aims to significantly expand the coverage of I4MS to include regions not presently
participating in the I4MS initiative in order to achieve a more balanced coverage of EU regions. To create
participation of new regions in I4MS, some will need support and mentorship. This is also of importance, as to
the further developed the I4MS ecosystem, other sources of funding (regional, national, other) have to be
linked up.
The I4MS Mentoring programme call addressed activities that extend the I4MS ecosystem to European regions
where I4MS is not yet systematically addressed. Projects were selected that assess feasibility of new Digital
Innovation Hubs to be established in an EU Member State. The projects selected proposed to assess and
prepare an innovation ecosystem in their region which can benefit from the use of the technologies and
competences available in I4MS network.
The main objective of these projects was to conduct a feasibility study to assess if establishing a DIH would be
possible in their region. The overall work includes:
• Participate in a kick-off meeting that will inform the new hubs on the opportunities of digital industry for
their regions and approaches to (further) develop an I4MS innovation network in their region. The multiple
day meeting will be organised by the I4MS partners and inform the core project consortia partners on the
I4MS context, but also educate them on specific topics to create their DIH (e.g. finding and financing hubs,
creating networks, the I4MS technologies, etc.).
• Organise regional workshop(s) with potential interested partners and stakeholders such as SMEs, midcaps,
investors, technology providers, education and R&D institutions to explore the possible development of a
DIH. The workshop(s) are instrumental to creating commitment in the region to establish the DIH.
• Up to 3 use cases, experiments, including the innovation hub and SMEs (and possibly mid-caps) located in
the region. This feasibility study must show the added value of the DIH towards the region in concrete
case (added value of the RDMI-hub, costs, organisation of the experiment, possible regional funding
sources, objectives, core technology, etc.)
• Prepare a business plan on how to develop innovation activities with local & regional administrations and
industry and what are the possible funding mechanisms that can be used. This plan must at least include an
analysis of the potential added value of the DIH (regionally, nationally and internationally), as well as a
description of the business models (and services), estimation of costs, possible funding, and a description
of the how the consortium will continue after the Mentoring and sponsoring project.
• The consortium must be represented during a one day meeting within the framework of the Mentoring and
sponsoring programme, presenting their project to the European Commission (in Brussels).
This background document will provide background information on the development of the use cases.
14/07/17
Page 2 of 8
Background material on use cases
I4MS Mentoring material
Version 0.1
1.2
Use cases are an important element to the DIH feasibility studies
The main remit of Digital Innovation Hubs is to provide innovation services to SMEs to accelerate and drive the
digitisation of European industry from the bottom up. A key part of this is to have a formalised process to
capture industry requirements and to provide a statement of the services that may be provided by the DIH to
address those requirements. Use cases, are a way to support this process, by providing a template to formalise
industrial challenges and objectives, proposed services (including deliverables, timescales and cost), expected
benefits and impact. In this way, use cases are a communication tool to: 1) facilitate the dialogue between the
DIH and an organisation during initial engagement, 2) support the definition of realistic and relevant projects
and 3) negotiate scope, timescales and project price.
1.3
What to deliver: Overview of the use case deliverable elements
As the use cases are seen as mechanisms to ensure concrete experience with the services of the DIH, the
following elements are to be addressed:






A description of the service that is to be provided by the DIH and its direct link to the business case of
the customer.
General description of the use case and/or description of your use case in a non-technical, userfocused way.
Short description of the technical objectives for the use case.
The expected benefits the customer hopes to gain from the service.
A list the solutions and capabilities provided by the DIH.
A more detailed description of the possible project scope and price.
These use cases must be developed in close cooperation with a concrete customer to ensure practical handson experience. As many use cases as possible should be conducted to increase practical experience.
For the reporting of the use cases, a template is available.
14/07/17
Page 3 of 8
Background material on use cases
I4MS Mentoring material
Version 0.1
2
How to conduct a use case assessment
2.1
Suggestions to the overall process to create a use case
Use cases should be captured with significant input from the customer and should be developed on the basis
of an understanding of the customer requirements and the value proposition offered by the DIH. It is
recommended that interactive sessions with the customer are held (e.g. calls, face to face meetings,
workshops or site visits, depending on the scale of the project) to build an understanding of the context of the
service request and what the customer is trying to achieve. This understanding should be portrayed in the first
part of the use case template (sections 1 and 2).
The second part of the use case template (section 3, 4 and 5) should capture the solution to be provided by the
DIH. This should be defined together with the technical experts in the topic within the DIH or in partner
organisations. This entail the definition of a service that addresses the objectives outlined in the first part of
the use case. This should include a definition of the service (including costs and preferably timescales), the
expected benefits and the areas of risk in the project. These sections should provide the customer enough
information for them to make a decision to contract the services and submit a Purchase Order.
This guide will walk you through the process of filling in a use case. What you need to take into consideration
with example of what to write. The template is included in the following section.
2.2
Discussion on the reporting elements
2.2.1 Description of the organisation
When describing the organisation, particular emphasis should be put on the jobs they are trying to do and the
outcomes they are trying to achieve in relation to the use case. It is also important to understand the specific
business drivers of the organisation (e.g. quality, on-time delivery, safety), as this will be key to direct the use
case later on.
Name of the organisation who the use case is for. E.g. if you are writing a use case about a problem MTC is
having, then MTC is what you write.
What do the organisation do e.g. if they are an end user and manufacture goods, what is it that they
manufacture?
1.
Name of the organisation
Organisation Information
Anonymous
Description of organisation.
14/07/17
Page 4 of 8
Background material on use cases
I4MS Mentoring material
Version 0.1
2.2.2 Description of the use case
Description / User Story:
Leading on from the organisation description, this section should provide detail about what the end user or
the organisation is trying to achieve in the use case, in terms of jobs or outcomes.
This section should provide details on the barriers and obstacles to achieving the outcomes or jobs described
in the use case name. This is the main description of the problem.
Technical Objectives:
This section should define the key success factors of the use case and answer what does success looks like. A
qualitative description of the objectives is necessary, but quantifiable targets are even better and would
significantly strengthen the use case (e.g. 20% improvement in resource utilisation). Any additional
information on specific requirements would strengthen the use case.
Example:
2. Use Case
The name of the use case should express what happens when the use case is performed.
Quality traceability
Description/User story
General description of your
use case and/or description
of your use case in a nontechnical, user-focused way.
Technical Objectives
Short description of the
technical objectives for this
Use Case.
Current processes for quality traceability are usually manual and paperbased i.e. when there is a problem with a product, paper documents have
to be sourced to find out what the issues were. This is a time consuming,
unreliable and error prone process. This in turn leads to losses in
productivity and slow response times with customers.
The main issues are related to:
 Formalisation of information in paper based format as this is prone
to human error resulting in the wrong information being captured
and lack of longevity of the information as the data gets obsolete
and the paper and ink age.
 Storage of information as there is not a rigorous process and
protocol for information storage and therefore sometimes
documents are lost.
 Document check in and check out as there are not formalised
processes to remove or return documents to storage or any
traceability on who has the documents at all times and a history of
who have the documents when.





Full digitisation of quality data management;
Increasing accuracy and longevity of quality data;
Ensuring complete traceability of quality data at all times;
Reduction data retrieval time by at least 50%;
Complete elimination of quality data loss.
2.2.3 Description of the services provided by the DIH
This section should provide a statement of work (i.e. a description of the work proposed to solve the use case).
Ideally, the description of services should include the general description of the solution or service to be
provided (e.g. technology benchmarking or FEA simulation for process calibration), deliverables, costs
estimates and timescales. Providing a menu of different alternative project sizes might help a customer making
a decision.
14/07/17
Page 5 of 8
Background material on use cases
I4MS Mentoring material
Version 0.1
3.
Description of Service, Cost estimate and Funding Source
List the services provided and the price estimate (the numbers provided are fictitious and only provided as
examples)
There is a requirement to fully digitise and automate processes around quality data, including capture,
storage and retrieval. The project will be delivered in three phases:
Phase 1: Implementation of tools for digitisation of legacy data (4 weeks)
Phase 2: Development of a data model, data repository and population with existing data (7 weeks)
Phase 3: Definition and implementation of digital quality data processes including capture, storage,
queries and traceability (12 weeks)
Milestone 1: Paper based data assessment
Deliverable 1: Delivery of tested digitisation solution (£15,000)
Deliverable 2: Delivery of quality data repository populated with existing data and with an accompanying
document describing the data model. (£30,000)
Deliverable 3: Delivery of tested and documented quality data management solutions (£40,000)
Funding mechanisms (e.g. European H2020, national, regional or direct funding)
Direct funding
For all deliverables 50% payment on receipt of order and 50% payment on delivery.
2.2.4 Expected benefits of the DIH service
Ideally, this section would address directly the statements in the user story description and the technical
challenges. This section should describe how the project / solution / service is enabling the jobs and outcomes
described in the user story and how is it achieving the technical objectives and to what extent). It is also very
important to describe to your customer the implications of the results achieved in wider business drivers.
After indicating your objectives, now you have to write what you expect to achieve or how you expect to
benefit. An example can be found below:
4. Expected benefits / Impact
What are the expected benefits you hope to gain from this?
The project is expected to streamline quality data management processes, including:
 Full digitisation of quality data management;
 Increasing accuracy and longevity of quality data;
 Ensuring complete traceability of quality data at all times;
 Reduction data retrieval time by at least 50%;
 Completely elimination of quality data loss.
As a result, the customer is expected to generate 15% savings on the cost of quality management.
Additionally, employee time will be released to perform higher value added tasks such as problem solving
and quality improvement. Finally, the organisation with increase value to customer by ensuring full
traceability of all quality data and by reducing response times for quality issues, ultimately leading to
significant improvements on customer service and customer relationship.
14/07/17
Page 6 of 8
Background material on use cases
I4MS Mentoring material
Version 0.1
2.2.5 Issues and Challenges with the DIH service
This section acts as a technical risk register. It is important to highlight the areas that may be particularly
challenging (for example, because the technology is not mature or because it is a critical application). The role
of this section is to set the use case in a realistic context and to provide the user with an understanding of the
potential challenges that may affect the scope of the project (with potential time and cost implications) or
your ability to meet the objectives.
Finally, after indicating the use case, the current state and objectives. You need to enter what challenges you
may face through the implementation. An example can be found below:
5. Issues/Challenges
List of issues that remain to be resolved;
Current status of paper based data: The scope and complexity of phase 1 may vary depending on the current
status of the data formalised on paper. The phase has been scoped on the basis of the assumption that the
data is legible and in a structured format. The solution will be tested on this assumption. Additional
requirements would require requoting.
Adoption issues and training: Even though the solutions delivered will be successfully, adoption cannot be
ensured. There may be issues related to change management that will have to be addressed outside the
scope of the project. Additionally, the lack of relevant skills in the organisation may delay the adoption
process. Appropriate training and support should be provided.
14/07/17
Page 7 of 8
Background material on use cases
I4MS Mentoring material
Version 0.1
3
Use Case Template
1.
Organisation Information
Name of the organisation
Description of organisation.
2.
Use Case
The name of the use case should express what happens when the use case is performed.
Description/User story
General description of your
use case and/or description
of your use case in a nontechnical, user-focused
way.
Technical Objectives
Short description of the
technical objectives for this
Use Case.
3.
Description of Service, Cost estimate and Funding Source
List the services provided and the price estimate
Funding mechanisms (e.g. European H2020, national, regional or direct funding)
4.
Expected benefits / Impact
What are the expected benefits you hope to gain from this?
5.
Issues and Challenges
Issues and challenges that may occur during the project or that will remain to be resolved
14/07/17
Page 8 of 8