OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
1 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
OPEN_NEXT
Deliverable 3.1
User stories of collaborative engineering needs
This project is funded by the European Union’s Horizon 2020 Research and Innovation
Programme under the Grand Agreement no. 869984.
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
2 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
OPEN_NEXT – Transforming collaborative product creation
Consortium:
#
Participant Legal Name
Short Name
Country
1
TECHNISCHE UNIVERSITAT BERLIN
TUB
DE
2
INSTITUT POLYTECHNIQUE DE GRENOBLE
GINP
FR
3
ALEXANDER VON HUMBOLDT-INSTITUT FURINTERNET
UND GESELLSCHAFT GGMBH
HIIG
DE
4
UNIVERSITY OF BATH
UBA
UK
5
ZENTRUM FUR SOZIALE INNOVATION GMBH
ZSI
AT
6
FRAUNHOFER GESELLSCHAFT ZUR FOERDERUNG DER
ANGEWANDTEN FORSCHUNG E.V.
FHG
DE
7
DANSK DESIGN CENTER APS
DDC
DK
8
WIKIMEDIA DEUTSCHLAND - GESELLSCHAFT ZUR
FÖRDERUNG FREIEN WISSENS EV
WMDE
DE
9
WIKIFACTORY EUROPE SL
WIF
ES
10
STICHTING WAAG SOCIETY
WAAG
NL
11
MAKER
MAK
DK
12
AGILE HEAP EV
FLB
DE
13
SONO MOTORS GMBH
SOM
DE
14
OPNTEC GMBH
OPT
DE
15
STYKKA APS
STY
DK
16
TILL WOLFER
XYZC
DE
17
FICTION FACTORY
FIF
NL
18
M2M4ALL
SOD
NL
19
INNOC OSTERREICHISCHE GESELLSCHAFT FUR
INNOVATIVE COMPUTERWISSENSCHAFTEN
HAL
AT
Duration: 09/2019-08/2022
Grant: H2020-869984
Contact (coordinator): Prof Dr-Ing Roland JOCHEM
Address: Technische Universität Berlin, Sekretariat PTZ 3, Pascalstr. 8-9, 10587 Berlin
E-mail: roland.jochem@tu-berlin.de
Disclaimer: The contents of this document are not intended to replace consultation of any
applicable legal sources or the necessary advice of a legal expert, where appropriate. All
information in this document is provided "as is" and no guarantee or warranty is given that the
information is fit for any particular purpose. The user, therefore, uses the information at his/her
sole risk and liability. For the avoidance of all doubts, the European Commission has no liability
in respect of this document, which is merely representing the view of the author(s).
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
3 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
D3.1 - User stories of collaborative engineering needs
Review and approval status:
Name and Surname
Role in the Project
Partner
Author(s)
Sonika Gogineni
Research associate
FHG
Reviewed by
Robert Mies
Project manager
TUB
Dr-Ing Kai Lindow
Project manager
FHG
Approved by
Prof Dr-Ing Roland
Jochem
Project coordinator
TUB
History of changes
Version
Date
Description of changes
By
0.1
17.02.2020
Initial draft
Sonika Gogineni
0.2
24.02.2020
Manuscript for review
Sonika Gogineni
0.3
28.02.2020
Publish-ready deliverable
Sonika Gogineni
Details
Dissemination level
Open Access
Due date
01.03.2020
Issue date
01.03.2020
Contract No.
869984
Responsible Partner
FHG
File name
D3.1_User stories of collaborative engineering needs_GoS
Abstract:
This document is a deliverable (3.1) of project OPEN_NEXT. This deliverable report describes
and summarizes the activities carried out and their results in Task 3.1: Assessing the needs,
which belongs to work package (WP) 3. The work package aims at developing information and
communication technology (ICT) infrastructure to support open source hardware (OSH) and
collaborative engineering in company-community collaboration (C3).
Hence, the activities
mentioned in this deliverable report is the first step to find and understand the needs for
developing the required ICT infrastructure. This deliverable document delivers the following
results, which are further detailed in later sections:
• Collecting and accessing needs: An outline of twenty in-depth interviews conducted to
assess community needs.
•
Development of user stories: A summary of the user stories generated from the
interviews. The user stories act as the first step to translate the needs into solutions for
filling the current ICT infrastructure gaps.
•
Data flow architecture development: Analysis and development of data flow
architecture to understand the activities and processes of OSH development in C3.
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
4 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Table of Contents
1 Introduction ................................................................................................................................................................ 6
2 Definitions ................................................................................................................................................................... 7
3 Collecting and accessing needs ............................................................................................................................ 7
3.1 Development of interview questionnaire ............................................................................................. 8
3.2 Conducting interviews .................................................................................................................................. 8
3.3 Interview assessment ................................................................................................................................... 8
3.3.1 Demography ............................................................................................................................................ 9
3.3.2 Basics of OSH ........................................................................................................................................... 9
3.3.3 Community collaboration ............................................................................................................... 10
3.3.4 Basic operations ................................................................................................................................. 12
3.3.5 Future plans ......................................................................................................................................... 14
4 Development of user stories .............................................................................................................................. 14
5 Data flow architecture development .............................................................................................................. 16
6 Conclusion and outlook ....................................................................................................................................... 18
References .......................................................................................................................................................................... 18
List of abbreviations and terms
C3 Company-community collaboration
EU European Union
ICT Information and communication Technology
MFP Minimum functional prototype
CFP Complete functional prototype
DFM Design for manufacturing
ODM Open distributed manufacturing
OSH Open source hardware
SME Small and medium enterprises
WP Work package
List of figures
Figure 1: Systematic approach followed in Task 3.1 and in this report ...................................................... 6
Figure 2: Structure of interview ................................................................................................................................... 8
Figure 3: The categories of business classifications of interview participants ........................................ 9
Figure 4: Distribution of participants’ experience of working with OSH ................................................... 9
Figure 5: General advantages and disadvantages of OSH .............................................................................. 10
Figure 6: Distribution of participants’ experience in C3 in OSH .................................................................. 10
Figure 7: Communication channels used for community collaboration in OSH ................................... 11
Figure 8: General advantages and disadvantages of C3 in OSH ................................................................... 11
Figure 9: General processes for product development and launch in an organisation ..................... 12
Figure 10: Phases of prototyping ............................................................................................................................. 13
Figure 11: General advantages and disadvantages in ODM .......................................................................... 14
Figure 12: Excerpt of the ideation process in the data flow .......................................................................... 17
Figure 13: Excerpt of documentation, guidelines and business considerations for the ideation
process in the data flow ................................................................................................................................................ 17
Figure 14: Excerpt of user journey on Wikifactory platform and the mapped user stories ............ 18
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
5 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
List of tables
Table 1: Excerpt of derived user stories for community management group ....................................... 15
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
6 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
1 Introduction
The work package 3 aims at delivering ICT infrastructure solutions to the OSH community in order
to support OSH development and collaboration by carrying out the following enhancements:
1) Extension of Wikifactory1 platform with features for
a) Product and service data management
b) Tools for open production engineering
2) Development of a dedicated Wikibase2 instance to focus on
a) Data discoverability and structuration
In order to gain insights into the different opportunities available for development of solutions
mentioned above there was a need to collect requirements in the field of OSH and company
collaboration. Partial insights on requirements for development platforms have been conveyed
by Abhari et al. (2016, 2017) with a conceptual model of social product development. In addition,
the project OPEN (Mies et al., 2020) also delivered requirements for such platforms based on
inter-organisational collaborative development framework by Lünnenmann et al. (2016). These
works provided a start to look into relevant technical features to enable co-development, however
they are not an exhaustive set of requirements for OSH and C3. Hence, this report aims to deliver
an exhaustive set of requirements from the activities of task 3.1 in WP3.
The methodological approach of the activities in Task 3.1 is shown in Figure 1. The method used
to collect the requirements was semi-structured interviews. This method was chosen because the
OSH community has different stakeholders who have diverse characteristics in terms of goals, size
of operation, way of operations, business models and the customers they focus on. Hence, it was
first important to understand their goals and steer the interview to obtain the relevant needs for
the project. In total, twenty interviews were conducted among various stakeholders in the
community.
Figure 1: Systematic approach followed in Task 3.1 and in this report
1 https://wikifactory.com/
2 https://www.wikimedia.de/projects/wikibase/
•Development of interview
questionnaire
•Conducting interviews
•Interview assesment
Collecting
and assesing
needs
•Derivation of user stories
•Clustering the similar user stories in
according groups
Development
of user
stories
•Development of data flow
architecture
•Mapping user stories in the data
flow architecture
Data flow
architecture
development
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
7 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
This deliverable reports the summary of the interviews followed by the derived user stories.
Development of use stories were chosen as the suitable method here because they are effective in
initially defining the ICT features required by translating the user’s requirements (Gilson & Irwin,
2018). In addition, it was important to understand the various activities in OSH development and
C3, therefore a data flow architecture analysis was considered to be a suitable method to map the
activities and their connections (Riedelsheimer et al., 2017). This helps in understanding and
improving the efficiency of activities and corresponding processes. Mapping the user stories onto
the data flow architecture further points out the activities which are connected to them. This is
important as the activities influence the ICT features which have to be developed and
incorporated into the demonstrators. The demonstrators are the prototypical implementations of
ICT solutions, which will be developed in WP3 in the following tasks (Task 3.2 and Task 3.3).
2 Definitions
In this report, the terms company and organisation are used interchangeably. They refer to a
company which designs/manufactures/produces products or manages projects or a research
institute or foundation or non-governmental organisation.
Small and medium enterprises (SME) are defined as organisations who have a particular
headcount and amount of turnover (European Commission). In addition, in this report SMEs are
considered as organisations who are developing or have already developed products for OSH, or
those who have already been involved or are planning to be involved in C3.
Fab labs and makerspaces or any organisation, which provides space for people to come together
and work in groups or to work on technical equipment, are handled synonymously in this report.
This is because it is difficult to distinguish them from each other owing to of their many facets. Fab
labs have signed up to a Charter defining a core set of capabilities and tools allowing sharing of
projects between different labs. In contrast to makerspaces, the ideas of knowledge sharing and
public access are specifically anchored in the Charter, officially giving fab labs an educational
character rather than “just” working at the same place and using common tools like in
makerspaces (García Sáez, 2016; Klemichen et al., 2018). Since makerspace communities often
share the same mindset on sharing as fab labs communities, differentiation is – in real life settings
– often only of descriptive nature (Colegrove, 2013; van Holm, 2015).
3 Collecting and accessing needs
The needs or requirements from the OSH community is an important starting point for the
development of infrastructure to support OSH development. Hence, it was important to obtain
various perspectives from different stakeholders in the OSH community. The targeted community
consisted of SMEs who have worked/are working on OSH projects, fab labs or makerspaces who
have worked/are working on OSH projects, institutes which support OSH projects, or any of the
above organisations who are planning to work on OSH projects.
The request to participate in the interview was sent out to twenty eight organisations who are not
part of the OPEN_NEXT consortium, they were recommended from internal project partners.
These organisations are active participants in OSH fields or were interested in being actively
involved with OSH. Ten of them participated in the interviews. In addition, ten interviews were
also conducted with the internal project partners (SMEs and fab labs of the project). Hence, in
total twenty in-depth interviews were conducted. The following sub-sections provides a detailed
report on the procedure used to conduct the interviews and a brief summary of the interviews.
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
8 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
3.1 Development of interview questionnaire
The aim of the interviews was to collect needs for ICT infrastructure from the community. Hence,
the structure shown in Figure 2 was adopted. The structure was developed by discussing with
internal WP partners Wikifactory and Wikimedia in an independent workshop and web
conference respectively. In addition, the inspiration was also taken from literature research
sources (Johnsen & Ford, 2000; Lock, 2013). As the focus of the project lies in OSH, C3, product
development and design to production, the questionnaire was structured to address these topics.
The questions of the interview was divided into five sections. The first section, called demography,
aimed at capturing a brief overview of the interview participants experience and about the
organisation they are a part of. In the next section, basics of open source hardware, the interview
participants were asked about their perspective of OSH and about their experience with OSH
projects (if they had any). In community collaboration section, the questions focused on how the
company/organisation collaborated with the community and their positive and negative
experiences. In the fourth section, the working of the company was discussed to question and
analyse the pain points or challenges faced. We also recommended the use of a familiar example
to the participant to explain their processes. In the last section, future plans of organisations with
respect to OSH was questioned.
The complete list of questions can be found in the Annex A and B. Annex A has the interview
questions for the SMEs and the Annex B is similar to Annex A with a few additional or modified
questions for fab labs and makerspaces. The interview questionnaire was assisted with a set of
slides, which was presented to the user during the interview. The purpose of the slides was to
guide the user during the interview. The slides used during the interviews for the SMEs and the
fab labs are attached separately and are called: Interview_Concept_Slides_SMEs.pdf and
Interview_Concept_Slides_Fablabs.pdf respectively.
3.2 Conducting interviews
The interviews were conducted in consent with the interview participants, this was done by
agreement and signing of the consent forms. The consent form was prepared following the format
mentioned in the Deliverable 7.1 (H- Requirement No. 1). The duration of the interview was one
hour and thirty minutes. The medium of interview was web conference.
3.3 Interview assessment
During the interviews, the responses were manually recorded. In addition, the interviews were
recorded and saved. This was done to make sure that the written responses were correct and
Figure 2: Structure of interview
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
9 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
complete. The interview responses were then digitally transcribed using Microsoft Excel after
evaluating the recordings and the handwritten transcripts. A brief summary of all the interviews
is detailed in the following sub-sections ordered by the sections in the interview as shown in
Figure 2.
3.3.1 Demography
This section contained questions to obtain a clear picture about the interview participant and the
organisation they are a part of. The Figure 3 shows the diversity of the business classifications of
interview participants. The majority of the participants with a count of nine were SMEs, followed
by five fab lab/makerspace organisations. Foundations, institutes and associations were divided
equally with two participants each.
Figure 3: The categories of business classifications of interview participants
3.3.2 Basics of OSH
In this section, the definition of OSH was discussed to establish a common understanding.
Followed by discussions about the experiences of the participants in OSH related activities. The
definition of OSH by OSHWA was used (Open Source Hardware Association), which states: “
open
source hardware as a term for tangible artifacts — machines, devices, or other physical things —
whose design has been released to the public in such a way that anyone can make, modify,
distribute, and use those things
”. Most of the participants agreed to the definition and stated that
it was a board definition hence accommodating various scenarios. Some additional considerations
were inclusion of credits to the original idea and allowing the contributing community to
determine the path of further licensing of their ideas.
Seventeen interview participants already have experience of working with OSH projects, three
participants have no experience of working on OSH projects yet, but are planning to work on OSH.
This is visualised in Figure 4.
Figure 4: Distribution of participants’ experience of working with OSH
17 3
0 2 4 6 8 10 12 14 16 18 20
Worked on OSH Not, but planning to
9
5
2
2
2SME
Fablab/Makerspace
Foundation
Institute
Association
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
10 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
The participants were also questioned about the general advantages and disadvantages of OSH
from their experience and knowledge. The advantages are synonymous to potentials of OSH and
the disadvantages highlight the challenges of OSH. The most stated general points are summarized
in Figure 5.
Figure 5: General advantages and disadvantages of OSH
3.3.3 Community collaboration
Following the aims of the OPEN_NEXT project, community collaboration here was focused on
highlighting the collaboration between an organization and the community. Hence, it was defined
as: Company-community collaboration (C3) refers to collaboration between companies and an
undefined crowd undefined crowd as per open innovation practices (Heitmann, 2012). On the
definition, most of them disagreed with the words “undefined crowd”. The clarification was that
they do know who the crowd is when they are collaborating. A participant suggested to define the
undefined crowd as “experts, specified group or interested people” instead, which is similar to
what the other participants expressed. Figure 6 shows that seventeen of interview participants
were involved in C3 related activities and three participants had no experience in C3.
-Contribute and receive innovative ideas to
and from the community
-Feedback on various aspects of projects
-Social impact
-Support reuse and the advantages
associated with that
-Support open distributed manufacturing
(local manufacturing)
-Promotion of company/organisation
through public relations
-Supportive community to develop
products/ projects
-Opportunity for global collaboration
-Lack of quality of contributions
-Lack of OSH tools
-Uncertainty of business models
-Lack of education of community about OSH
-Lack of knowledge about certifications and
regulations
-Incomplete and inconsistent
documentation
-Difficulty in motivating community to
participate and contribute in OSH
Advantages Disadvantages
17 3
0 2 4 6 8 10 12 14 16 18 20
Experience in C3 No experience in C3
Figure 6: Distribution of participants’ experience in C3 in OSH
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
11 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
The interaction channels used to interact with the community depended on the organisation. The
statistics of the channels used is shown in Figure 7. The collaborating organisations use one or
more channels to communicate. Direct communication with community and communication
through physical events or workshops had a tie of being used by seven participants organisations’
each. Usage of external platforms and through own platform/website are mentioned five times
each. Communication through social media is followed by two interview participants’
organisations.
The interview participants were also asked about what the advantages of disadvantages of
company-community collaboration in OSH from their perspective and the most stated points are
summarized in Figure 8.
Figure 8: General advantages and disadvantages of C3 in OSH
-New perspectives, ideas and
interpretations from community
-Oppurtunities to improve projects
-Interactive community who support &
learn from each other
-Knowledge sharing
-Education of community
-Promotion of company
-Investment on ressources and effort
to build and maintain a community
-Investment of time to curate and
nurture community contributions
-Finding and motivating the right
collaborators
-Lack of feedback
-Lack of quality contributions
-Lack of interoperable tools to
collaborate
-Inconsistent documentation
7
2
5
7
5Direct
Social media
An external platform
Workshops/Events
Own platform
Figure 7: Communication channels used for community collaboration in OSH
Advantages Disadvantages
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
12 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
3.3.4 Basic operations
The processes and activities in the organizations related to OSH or in general was questioned
examined in this section. This was spread across five generic phases namely: concept
development, concept validation, design & development, prototyping and production. These
phases were derived from literature analysis (Boujut et al., 2019, p. 2309; Stark & Müller, 2009;
The Department of Justice, 2003). To guide the questions a high-level representation of processes
as shown in Figure 9 was used. The procedure starts with the development of the concept, where
the idea generation followed by concept development takes place to solve a problem. This is
succeeded by concept validation where questions about validation through community were
asked. The next phase called design and development consisted of questions related to the further
design and development of the validated concept. After the designing phase, the prototyping
phase was discussed. The last phase is the production with considerations such as certifications,
regulations testing, etc. It was also explained that the processes are not linear as show in Figure
9, but iterative in nature. This was agreed upon by all the participants.
Figure 9: General processes for product development and launch in an organisation
All of them accepted the phases and activities mentioned were familiar to them and their
organisations working. However, there were just a few who carry out concept validation and that
was mostly done through talking to experts they knew. Just one participant mentioned the use of
community to validate the concept. In addition, most of them expressed that there is often a quick
and direct jump from the concept development or ideation phase to the prototyping phase. This
is often followed by rethinking, redesigning and iterative prototyping. There were a few requests
to include additional phases such as problem identification and description, and service,
maintenance and repair. The summary of responses to the questions in the individual phases is
described below.
Concept development. In concept development, how the SMEs go about the generation of a concept
to solve a problem was investigated. In the case of fab labs/makerspaces how they support
concept development was investigated. The problem they try to solve is often an internal company
problem and seldom a problem directly received from a community. The process of concept
development is mostly offline in the early phase; hence, there is less to no feedback received from
the online community in concept development. A challenge to develop concepts with a community
was that there is no standardized structure/documentation, which acts as a guide. This results in
unorganized community collaboration, which is hard to manage and maintain. Some IT-Tools the
participants use in this phase are office tools, LibreOffice, GitHub, their own platform/website,
WebEx, Zoom and Slack.
Concept validation. The main questions in this phase are targeted at understanding how concept
validation was carried out and if the opportunity of validating with the community was being
used. In general, the concept validation in the organisations is usually carried out through direct
communication with experts known to the organisation or the customers they are developing for.
The online community is rarely involved in the validation phase, only one SME interacts with a
community to obtain validation on aesthetic factors. However, some of the organisations are
planning to involve the community in the future. They also see a potential in using the community
for market research of the concept developed.
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
13 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Design and development. In this phase, the processes, tools and community collaboration methods
used to design and develop the concepts were questioned and assessed. The design and
development focus among the interview partners was spread across various domains such as
electronic, mechanical and software, which in turn was across sectors such as automobile,
electronics, furniture, health and humanitarian aid. The most used information technology (IT)
tools in design & development phase can be divided into design tools and collaboration tools. The
design tools used are a mix of open source tools (such as KiCad and FreeCAD) and closed source
tools (such as SolidWorks and Fusion 360). For collaboration tools used are also a mix of open
source (such as Github and Wikifactory) and closed source tools (such as Trello, Slack and MS
project).
As IT tools were mostly used in this section, it was further investigated if there was a need for
additional features in existing tools or if there was a need for new tools. The following points were
often mentioned in the interviews:
• Improvements in built-in visualizations of models on development platforms
• Version management to collaborate and track changes
• Connected project elements on a metadata level to enable traceability
• Design quality management measures
Prototype. Prototyping phase was spread across four phases as shown in Figure 10 supported by
testing across the phases. Most of the participants agreed with the shown figure, but there were
differences in the actual implementation. Experience with designing of processes and products
for manufacturing which belong to the process of Design for Manufacturing (DFM), was sparse.
Similarly, the experience with collaborative prototyping was also sparse. The reason being that
the community has to have access to the education, resources and support to actively participate
in collaborative prototyping. Some suggested possibilities were integration of fab
labs/makerspaces and use of new ICT tools to enable this in OSH. The challenges that have to be
addressed here are to handle complex products, to produce and test small quantities of prototypes
without high investment, to improve quality and to enable less-qualified community to
collaborate.
Figure 10: Phases of prototyping
Production. In production phase, general questions were asked about production, certifications,
regulations and testing. In this section open distributed manufacturing (ODM) was also defined
and the participants were asked if they see any potential for ODM.
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
14 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
ODM defines a small, scalable and flexible manufacturing with a decentralized production (Matt
et al., 2015, p. 185). This enables lower logistic costs, shorter delivery time and higher flexibility.
It reflects local customer needs with better accuracy and quickly responds to the increasing
competition and market globalization of companies (Fjeldsted et al., 2012). Most of them saw a
potential in ODM, but had little to no experience in the field. Those who did have the experience
face some challenges which are summarized as disadvantages in Figure 11. Additionally the
potentials in terms of advantages are also summarized in Figure 11.
Figure 11: General advantages and disadvantages in ODM
3.3.5 Future plans
All the participants see potentials of OSH in the future. Hence, they are already working on it or
planning to integrate it in their plan. However, there is lack of clarity on how OSH would develop
and mature in the future.
4 Development of user stories
The interviews resulted in the derivation of two hundred and sixty user stories. The user stories
consist of elements such as its name and description, the role of the user it refers to as well as the
goal of the user and what purpose it should fulfil (Zeaaraoui et al., 2013 - 2013, p. 3).
The roles/perspectives of the user stories were categorized into the following roles:
• Project owner: Anyone who contributes and shares their own design files, making and
testing process and documents this is called a project owner (Li & Seering, 2019)
• Company: An organisation or entity
• Community: According to Fjeldsted et al. (2012) community consists of “users who wish
to participate in the development of the product and administration which usually is
provided by the initiating company” or by an individual as well.
The user stories were then clustered based on their similarities and connections. When grouping
user stories there were some user stories that were very similar but did not consider certain
aspects, this was then noted in the column additional considerations. Some user stories do belong
to one or more groups and this information is mentioned in the column additional groups. From
-Producing on larger scale
-Products can be made anywhere in
the world
-Different versions of the product
according to specific market
-Large investment
-Finding local manufacturers
-Professionalism and responsibility
of partners
-Need for education & training of
partners
-Setting & maintaining quality
-Different regulations/certifications
for each country
Advantages Disadvantages
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
15 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
the complete set of interviews the frequency of user stories are also indicated to highlight how
many of the participants mentioned the requirement. The complete list of clustered user stories
are attached separately as a file called Userstories.pdf. In addition, Table 1 shows an excerpt of
the clustered user stories under community collaboration. As an example, the user story U1/2
belongs to the cluster community management and is from the perspective of the project owner.
Here the project owner, that has uploaded a project and its files, wants to find and attract the right
collaborators for the project. The purpose here is to grow and sustain the project with a
community with the aim of receiving effective contributions from the community. Some additional
considerations here are to bring together various stakeholders such as other companies and
building heterogeneous teams to support various aspects of the project. This user story was
mentioned by fifteen of the interview participants.
Table 1: Excerpt of derived user stories for community management group
Number
Group
name
Perspective
User story
Aim
Purpose
Additional
considerations
Addition-
al
Group/s
Freq-
uency
U1/1
Community management
Community
collaboration
platform
manager
Managing
community
service needs
Provide
relevant
services
Engage
community
3
U1/2
Project owner
Finding and
attracting the
right collaborators
Growth and
effective
contribution
Growth &
sustenance of
community
collaboration
- Including companies
- Build heterogeneous
teams (to encourage
development of all
aspects of a project)
- Skill based
categorization
15
U1/3
Project owner
Motivating
community to
contribute
Healthy &
innovative
collaborative
environment
Growth &
sustenance of
community
collaboration
- Promote out of the
box thinking
- Avoid feeding
influential
ideas/concepts to the
community
- Keep community on
board for a longer
term
- Provide triggers to
encourage community
to collaborate
15
U1/4
Project
owner:
Company/org
anization
Determine
business viability
of community
collaboration
through online
channels
to successfully
collaborate/not
collaborate
with a
community on
the long run
Avoid risks
-Select processes
which are of interest
to the community
5
U1/5
Project owner
Curation of
community
content
Effective
community
collaboration
To ensure the
users are not
overwhelmed
with
irrelevant
data
3
U1/6
Project owner
Community
collaboration tool
Use IT tools to
collaborate
with
community
reduce
efforts and
improve
effectivity of
working with
a community
- Stand-alone tool for
community
collaboration
- Connect with
internal platform with
community
collaboration tool
- Scheduling
9
U1/7
Project owner
Improve quality of
contributions
To receive
contributions
which are of
good quality
To ensure
good quality
open source
hardware
development
- Educate community
about how to
contribute
Quality,
Guidelin-
es
8
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
16 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
In conclusion, these extensive set of user stories form the basic requirements list to start the
development of the demonstrators. To further analyse the connection of the user stories with the
activities and processes carried out in OSH and C3 a data flow architecture was developed. This is
discussed in the next section.
5 Data flow architecture development
Data flow architecture analysis, is an original method developed by Fraunhofer (FHG) to trace
data paths in product development processes (Riedelsheimer et al., 2017). Data flow architecture
analysis aims at tracing elements of activities such as data source, data destination, tools used,
stakeholder roles and data artefacts generated or modified.
The data flow architecture for OSH development and collaboration derived in Task 3.1 is based on
literature research and from the data collected in the interviews. The literature research is further
explained in the next paragraph. The interview participants were asked about the basic
operations of their organizations as mentioned in sub section 3.3.4. Most of them found the phases
shown in Figure 9 to be similar to what they go through. However, the most important difference
is that much thought or time is not spent on activities such as concept development and concept
validation. There was often a direct and quick jump from concept to prototype, with few working
on designing the prototype before building it.
The data flow architecture is spread over ideation, concept development and validation, design
and development, prototyping, testing (for certifications, for personal use) and production. It is
important here to highlight that the derived data flow architecture is based on hypothetical
activities. These assumptions grow from general procedures which – consciously or
subconsciously – take place in the individual phases. The ideation process is based on the
procedures in VDI2220 - product planning, but this is enhanced with several feedback loops
considering the OSH and C3 practices to map the community influence (VDI, 1980). The phases
concept development and design and development take VDI2221 into account, but - as described
above –it is not very detailed, since the interviews showed a more general approach in the OSH
community (VDI, 1993). The validation part of the concept development and validation phase and
the prototyping share the same ideas as VDI2206 in having a validation loop for every
development step, similar to the V-model for software development (VDI, 2004). The certification
process is shown on an abstract and general level (Berndt & Scholz, 2012) and depends of course
on the specific certification bodies and processes. For personal use of OSH products in the testing
phase priority is provided to the basic requirements for safety. For the production process, the
data flow has been followed until ordering of production with the manufacturer is concluded.
The hypothetical activities are also enhanced with roles, tools, data artefacts, data sources and
destinations, which are also general and hypothetical. This was done to determine the various
activities involved in OSH and C3 processes and to associate them with the interviews partners.
An excerpt of the data flow architecture can be seen in Figure 12. The phase here is Ideation and
the activities across the ideation phases are mapped. In addition, the user stories derived in
section 4 are mapped onto respective actives in the data flow architecture. The round bubbles
below the activity boxes represent the user stories. In Figure
13 two additional columns namely
documentation & guidelines and business considerations are shown. This highlights the fact that
these aspects have to be taken into consideration in parallel with the activities across phases.
Similar to in Figure 12, the round bubbles with the user stories are also included in the two
columns and categorized based on the phases. The complete data flow architecture document
called Dataflow_with_Userstories.pdf is separately attached to this report.
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
17 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Figure 12: Excerpt of the ideation process in the data flow
User stories in association with their mapping in the data flow architecure provide the location
and aim of the need to be addressed. With this information ICT infrastructure solutions can be
generated to be implemented in both the demonstrators. This ensures the consideration of the
relevant activities, roles, data artefacts, tools and the origin and destination of the data artefacts
associated with the user story.
In addition to the general data flow analysis, there was a workshop conducted with our partner
Wikifactory. The aim of the workshop was to understand the Wikifactory platform and to generate
user journeys. This was important to understand as the future demonstrators have to be
developed based on the Wikifactory platform. The user journeys enabled identifying the different
interactions a user of the platform can have. We then mapped the user stories onto the user
journey to identify the areas for future improvement. An excerpt of this can be seen in Figure 14.
The excerpt for example highlights the journey of starting a project which is for public use and
then a list of possible activities which can be carried out on the right side of the image. These
activities include inviting collaborators, commenting, uploading files or creating issues. The
complete user journey mapping is attached separately in a document called
User_journey_Wikifactory.pdf.
Figure 13: Excerpt of documentation, guidelines and business considerations for the ideation process in the data flow
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
18 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Figure 14: Excerpt of user journey on Wikifactory platform and the mapped user stories
The data flow analysis was not conducted with our other partner Wikimedia, which is involved in
the project to provide and integrate an open software for knowledge databases called Wikibase
with other platforms. Therefore, Wikibase is not an OSH product development platform unlike the
Wikifactory platform. However, the data flow analysis developed and shown as an excerpt in
Figure 12 takes into consideration of the aspects that would be integrated into the Wikibase
instance demonstrator as well.
6 Conclusion and outlook
In this report the results of the task 3.1 in WP3 are detailed and discussed. The results were
divided into three main sections namely: collecting and accessing needs, data flow architecture
development and development of user stories. The results of each of these sections were aimed at
deriving requirements and then generating user stories to be used for developing demonstrators
in the next tasks of the project. This in turn is aimed at aiding the OSH community at large with
ICT infrastructure in cooperation with Wikifactory and Wikimedia. The derivation of two hundred
and sixty user stories from the interviews provides an extensive list of requirements for future
development. The frequency of the user stories helps in prioritizing the implementation of next
steps. In addition, it also highlights the fact that multiple participants pointed out similar pain
points. However, there is still plenty of room for additional requirements and user stories from
those experiences of other organisations taking part in OSH and C3 activities. In a similar way
there is also an opportunity to expand and continuously enhance the data flow architecture along
the project period to reflect the changing conditions and best practices for OSH and C3. At the end
of the project, the demonstrators are also validated, which also helps in validating the data flow
architecture.
References
Abhari, K., Davidson, E. J., & Xiao, B. S. (2016). Taking Open Innovation to the Next Level: A
Conceptual Model of Social Product Development (SPD). In
AMCIS 2016.
https://www.semanticscholar.org/paper/Taking-Open-Innovation-to-the-Next-Level%3A-A-
Model-Abhari-Davidson/5e9d99ef41385c79dfd4432b09171d7531ac1778
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
19 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Abhari, K., Davidson, E. J., & Xiao, B. (2017). Co-innovation platform affordances.
Industrial
Management & Data Systems
,
117
(5), 873–895. https://doi.org/10.1108/IMDS-05-2016-
0156
Boujut, J.-F., Pourroy, F., Marin, P., Dai, J., & Richardot, G. (2019). Open Source Hardware
Communities: Investigating Participation in Design Activities.
Proceedings of the Design
Society: International Conference on Engineering Design
,
1
(1), 2307–2316.
https://doi.org/10.1017/dsi.2019.237
Colegrove, T. (2013). Editorial Board Thoughts: Libraries as Makerspace?
The Department of Justice. (2003).
Systems Development Life Cycle Guidance: Chapter 1
.
https://www.justice.gov/archive/jmd/irm/lifecycle/ch1.htm
European Commission.
What is an SME?
https://ec.europa.eu/growth/smes/business-friendly-
environment/sme-definition_en
Fjeldsted, A. S., Adalsteinsdottir, G., Howard, T. J., & McAloone, T. (2012). Open Source
Development of Tangible Products.
NordDesign 2012
.
García Sáez, C. (2016). We need to make (almost) everything. A social and educational look at
Fab Labs and the maker movement. http://www.fundacionorange.es/wp-
content/uploads/2016/08/Estudio_Fablabs_Casi_Todo_por_hacer_en.pdf
Gilson, F., & Irwin, C. (2018). From User Stories to Use Case Scenarios towards a Generative
Approach. In
2018 25th Australasian Software Engineering Conference (ASWEC)
(pp. 61–65).
IEEE. https://doi.org/10.1109/ASWEC.2018.00016
Heitmann, M. (2012).
Open source development and company-community collaboration: Impact
factors on the process of entering the open source market
. Zugl.: Berlin, Techn. Univ., Diss.,
2012.
Schriftenreihe innovative betriebswirtschaftliche Forschung und Praxis: Vol. 348
.
Kovač.
Johnsen, T., & Ford, D. (2000). Managing Collaborative Innovation in Complex Networks:
Findings from Exploratory Interviews.
Klemichen, A., Roeder, I., Ringhof, J., & Stark, R. (2018). Needs and Requirements for
Environmental-friendly Product Development in Makerspaces - A Survey of German
Makerspaces.
Li, Z., & Seering, W. (2019). Does Open Source Hardware Have a Sustainable Business Model? An
Analysis of Value Creation and Capture Mechanisms in Open Source Hardware Companies.
Proceedings of the Design Society: International Conference on Engineering Design
,
1
(1),
2239–2248. https://doi.org/10.1017/dsi.2019.230
Lock, J. (2013).
Open Source Hardware: Can embedded electronics companies thrive through the
use and/or development of open source hardware?
Lünnemann, P., Müller, P., Neumeyer, S., Wang, W. M., Hayka, H., & Kirsch, L. (2016).
Zukunft der
unternehmensübergreifenden Kollaboration: Expertenmeinungen zu aktuellen
Herausforderungen und zukunftsweisenden Trends in der kollaborativen
Produktentwicklung
(1st ed.). Fraunhofer IPK. 978-3-945406-07-6
Matt, D. T., Rauch, E., & Dallasega, P. (2015). Trends towards Distributed Manufacturing Systems
and Modern Forms for their Design.
Procedia CIRP
,
33
, 185–190.
https://doi.org/10.1016/j.procir.2015.06.034
Mies, R., Bonvoisin, J., & Stark, R. (2020). Development of open source hardware in online
Communities: investigating requirements for groupware. In
Design 2020.
Open Source Hardware Association.
Definition
. https://www.oshwa.org/definition/
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
20 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Riedelsheimer, T., Lünnemann, P., Lindow, K., & Stark, R. (2017). Betrachtung des
Entwicklungsumfeldes durch die methodische Datenflussanalyse.
ProduktDaten Journal
(2),
52–56.
Stark, R., & Müller, P. (2009). Product-service system methodologies in research and industry. In
H. Meier (Ed.),
Industrial product service systems // Seminar proceedings / 2nd International
Seminar on IPS2, 23 - 24 March 2009, Berlin, Germany ; paper and presentations volume:
Dynamic interdependency of products and services in the production area ; seminar
proceedings, paper and presentations volume
(pp. 5–11). Shaker.
Van Holm, E. J. (2015). What are Makerspaces, Hackerspaces, and Fab Labs?
Zeaaraoui, A., Bougroun, Z., Belkasmi, M. G., & Bouchentouf, T. (2013, August - 2013, August).
User stories template for object-oriented applications. In
Third International Conference on
Innovative Computing Technology (INTECH 2013)
(pp. 407–410). IEEE.
https://doi.org/10.1109/INTECH.2013.6653681
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
21 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Appendix A: Questionnaire for SMEs
Subject area
Question
Identification of the respondent / respondents
Date of interview
Company name
Name of the interview protocoler
Introduction
Thank the participant
-Reference to privacy information and consent form (must be signed):
Emphasize confidentiality of data, data will be treated anonymously and used only to prepare the maturity level and in the study.
The data will then be deleted.
-First about FHG and what we do
-Then about OpenNext goals in general
Demography What does your company/organization do? What are your core business competencies?
Demography Which business classification can your company be categorized into?
Demography How many employees does your company employ?
Demography In which specialist area are you active in?
Basics of open source hardware
We want to know how you perceive and define Open source hardware:
We define Open source hardware as: Open Source Hardware (OSHW) is a term for tangible artifacts — machines, devices, or
other physical things — whose design has been released to the public in such a way that anyone can make, modify, distribute, and
use those things. This definition is intended to help provide guidelines for the development and evaluation of licenses for Open
Source Hardware.
Basics of open source hardware How would you define Open source hardware?
Basics of open source hardware Have you worked on Open source hardware projects or applications?
Basics of open source hardware If you worked with Open source hardware projects, can you explain them.
Basics of open source hardware What were the advantages and disadvantages you observed?
Community collaboration
We want to know about your involvement in community collaboration
What we mean by Company-community collaboration is: Company-community collaboration (C3) refers to collaboration between
companies and an undefined crowd undefined crowd as per open innovation practices.
Community collaboration Do you participate in community collaboration?
Community collaboration Have you ever worked on a community collaboration project or application?
Community collaboration How do you collaborate with the community? What were the advantages & disadvantages of Community collaboration?
Community collaboration What are the challenges you observed?
Community collaboration Do you reuse information or knowledge from the community/ If yes, how?
Community collaboration
Have you worked with supporting partners (e.g. Fablabs / SMEs)? If yes, how did you collaborate and what were advantages &
disadvantages?
Basic operation of company
We want to know in brief how your company is organized
We have a few general categories here which can help you define the processes in the organization
Basic operation of company So lets take an example and go through the operations in your organization over the following phases
Concept Development This phase concentrates on generating a concept from an idea/problem
Concept Development How do you go about concept development?
Concept Development Are you facing any challenges here or would you like to change or improve anything here?
Concept Development Do you see a need for ICT tools to be integrated in this process to address the challenges?
Concept Validation Validation of concept, community engagement & market research
Concept Validation How did/do you validate your concept?
Concept Validation Do you involve/plan to involve a community in validating your concept and/ market research?
Concept Validation How do you get feedback from the community on concepts?
Design & Development Generating the design
Design & Development How do you design and develop your product/ project?
Design & Development Is a community involved in this process or are you participating in a community?
Design & Development Do you use any supporting IT tools?
Design & Development Do you currently face any challenges or would you like to change or improve anything here?
Design & Development Do you see a need for new IT tools to be integrated in this process?
Prototyping MFP -> CFP -> DFM -> Supplier Integration
Prototyping Is this how your prototyping process looks like?
Prototyping What are the challenges you face here or would you like to improve anything here?
Prototyping Is a community involved in this process or are you participating in a community?
Produce Turning DFM into many identical products
Produce Do/Did you currently produce products for sale on the market?
Produce Do you see potential to integrate a community for open distributed manufacturing?
Produce How did you go about testing?
Produce How did you go about certifications and regulations?
Produce How about supplier arrangements/integration?
Future plans or thoughts Finally, we would like to talk about the future of OSH?
Future plans or thoughts What is your future plans about your company? What do you want to accomplish ?
Future plans or thoughts if you can make a wish: What does the future of the OSH look like for you in 20 years?
Future plans or thoughts How do you assess the potential in your company to use OSH in the future to assess innovation and community collaboration?
Future plans or thoughts How large w+A1:B53ould you rate this potential on the following scale: 0 = no potential; 1 = little potential; 2 = large potential?
OPEN_NEXT (869984)
Deliverable 3.1 “User stories of collaborative engineering needs”
22 of 22
This document is licensed under a
Creative Commons Attribution 4.0
International License.
Appendix B: Questionnaire for Fab labs/Makerspaces
Subject area
Question
Identification of the respondent / respondents
Date of interview
Makerspace (Company) name
Name of the interview participant
Name of the interview protocoler
Introduction
Thank the participant
-Reference to privacy information and consent form (must be signed):
Emphasize confidentiality of data, data will be treated anonymously and used only to prepare the maturity level and in the study.
The data will then be deleted.
-First about FHG and what we do
-Then about Open!Next goals in general
Demography So let's start by getting to know you and your company/organization.
Demography What does your company/organization do? What are your core business competencies?
Demography Which business classification can your company be categorized into?
Demography What USP do you have in comparison to other FabLabs? (or how do you differentiate your Fablab from the others?)
Demography How many employees does your company employ?
Demography In which specialist area are you active in?
Basics of open source hardware
We want to know how you perceive and define Open source hardware
We define Open source hardware as: Open Source Hardware (OSHW) is a term for tangible artifacts — machines, devices, or other physical things — whose design
has been released to the public in such a way that anyone can make, modify, distribute, and use those things. This definition is intended to help provide guidelines
for the development and evaluation of licenses for Open Source Hardware.
Basics of open source hardware How would you define Open source hardware?
Basics of open source hardware Have you worked on Open source hardware projects or applications?
Basics of open source hardware If you worked with Open source hardware projects, can you explain them.
Basics of open source hardware What were the advantages and disadvantages you observed?
Community collaboration
We want to know about your involvement in community collaboration
what we mean by Company-community collaboration is: Company-community collaboration (C3) refers to collaboration between companies and an undefined
crowd undefined crowd as per open innovation practices.
Community collaboration Do you participate in community collaboration?
Community collaboration Have you ever worked on a community collaboration project or application?
Community collaboration How do you collaborate with the community? What were the advantages & disadvantages of Community collaboration?
Community collaboration What are the challenges you observed?
Community collaboration Do you reuse information or knowledge from the community/ If yes,why and how do you reuse it?
Community collaboration Have you worked with other companies/Fablabs/Makerspaces? If yes, how did you collaborate and what were advantages & disadvantages?
Basic operation of company
We want to know in brief how your company is organized
We have a few general categories here which can help you define the processes in the organization
Basic operation of company So lets take an example and go through the operations in your organisation over the following phases
Basic operation of company Are these processes similar to what you do? or services in?
Basic operation How does your business model work?
Basic operation What is the starting point of interaction with makers (in person, platform)?
Concept Development This phase conceptrates on generating a concept from an idea/problem
Concept Development How do you go about concept development?
Concept Development Are you facing any challanges here or would you like to change or improve anything here?
Concept Development Do you see a need for ICT tools to be integrated in this process to address the challenges?
Concept Development Do you support makers with a broad concept to further develop?
Concept Validation
Concept Validation How did/do you validate your concept?
Concept Validation Do you involve/plan to involve a community in validating your concept and/ market research?
Concept Validation How do you get feedback from the community on concepts?
Concept Validation Fablabs Can you already at this stage suggest if or how you can "produce" according to customer requirements?
Concept Validation Fablabs Can provide suggestions from similar project experiences based on the congruency of requirements? Is that in your eyes useful/practicable?
Design & Development
Design & Development How do you design and develop your product/ project?
Design & Development
Do you reuse existing designs?
If yes, do you face any challanges?
If no, what are the main barriers?
Design & Development Is a community involved in this process or are you praticipating in a community?
Design & Development Do you use any supporting IT tools?
Design & Development Do you currently face any challenges or would you like to change or improve anything here?
Design & Development Do you see a need for new IT tools to be integrated in this process?
Prototyping
Prototyping Is this how your prototyping process looks like? (Show presentation)
Prototyping What are the challenges you face here or would you like to improve anything here?
Prototyping Is a community involved in this process or are you praticipating in a community?
Prototyping According to your experience, what are here significant differences of Fablabs compared with private makers and SMEs?
Prototyping What evaluations/testing do you provide for prototypes (When is my protoype ready for production?)
Produce
Produce Do/Did you currently produce products for sale on the market?
Produce Do you see potential to participate with companies and community for open distributed manufacturing?
Produce How did you go about testing?
Produce How did you go about certifications and regulations?
Produce How about supplier arragements/integration?
Produce
Do you have collaborations to manufacture? How is the communication and contact with customer here managed? (separat contact, collaborator can access
directly data...)
Future plans or thoughts Finally, we would like to talk about the future of OSH?
Future plans or thoughts What is your future plans about your company? What do you want to accomplish ?
Future plans or thoughts if you can make a wish: What does the future of the OSH look like for you in 20 years?
Future plans or thoughts How do you assess the potential in your company to use OSH in the future to assess innovation and community collaboration?
Future plans or thoughts How large would you rate this potential on the following scale: 0 = no potential; 1 = little potential; 2 = large potential?
Future plans or thoughts What advantages/disadvantages would you see for your business?
