<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta>
      <journal-title-group>
        <journal-title>De Roure, D., C. Goble, and R. Stevens, The design and realisation of
the Virtual Research Environment for social sharing of workflows.
Future Generation Computer Systems</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Multidisciplinary Collaboration Through Online Virtual Research Environments (VREs): what do VRE users need?</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Xander de Ronde</string-name>
          <email>X.E.J.deRonde@student.tudelft.nl</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
          <xref ref-type="aff" rid="aff3">3</xref>
          <xref ref-type="aff" rid="aff4">4</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Keith Jeffery ERCIM</string-name>
          <email>keith.jeffery@keithgjefferyconsultants.c</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
          <xref ref-type="aff" rid="aff3">3</xref>
          <xref ref-type="aff" rid="aff4">4</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Anneke Zuiderwijk Delft University of Technology Delft</institution>
          ,
          <country country="NL">The Netherlands</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Delft University of Technology Delft</institution>
          ,
          <country country="NL">The Netherlands</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Faringdon</institution>
          ,
          <country>United Kingdom o.uk</country>
        </aff>
        <aff id="aff3">
          <label>3</label>
          <institution>Marijn Janssen Delft University of Technology Delft</institution>
          ,
          <country country="NL">Netherlands</country>
        </aff>
        <aff id="aff4">
          <label>4</label>
          <institution>Yi Yin Delft University of Technology Delft</institution>
          ,
          <country country="NL">The Netherlands</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2016</year>
      </pub-date>
      <volume>25</volume>
      <issue>5</issue>
      <fpage>561</fpage>
      <lpage>567</lpage>
      <abstract>
        <p>-Making new data combinations and collaborating with researchers from different disciplines are becoming essential ingredients of scientific research. These activities are increasingly contributing to solutions for multidisciplinary global problems, such as climate change and energy transition. Virtual Research Environments (VREs) can potentially support making data combinations and researcher collaborations by providing a multiplicity of data and services. Many VREs have been developed already and are used in specific research domains. However, there is a lack of insight into what is needed to develop a multidisciplinary VRE in comparison with monodisciplinary VREs. This is currently blocking the development of innovative multidisciplinary VREs. This study aims to investigate the requirements for building a multidisciplinary VRE and to study the key differences between monodisciplinary VREs and multidisciplinary VREs. Our study shows that comprehensive requirements in nine categories need to be fulfilled when designing a multidisciplinary VRE. Lack of considering many requirements and limit focus in monodisciplinary VREs hinder the wide use of current VREs in multidisciplinary research.</p>
      </abstract>
      <kwd-group>
        <kwd>VRE</kwd>
        <kwd>research data sharing</kwd>
        <kwd>requirements</kwd>
        <kwd>multidisciplinary Virtual Research Environment</kwd>
        <kwd>science gateway</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>I. INTRODUCTION</title>
      <p>
        Virtual Research Environments (VREs) have become
critical to modern research processes [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. VREs or Science
Gateways, aim to support researchers from multiple disciplines
to collaborate [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. They do so by managing the increasingly
complex range of tasks involved in carrying out research on
both small and large scale, such as tracking the change of data
using information from seafloor scans for undersea
archaeology, using data on greenhouse gas concentrations for
climate change research, or research on the Internet-of-Things.
In a study conducted by Zuiderwijk, Jeffery [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], they state that
VREs consist of three major components or layers, namely:1)
e-Infrastructures(e-Is) providing Information and
Communication Technology (ICT) facilities; 2) e-Research
Infrastructures (e-RIs) providing access to data, software and
computing resources; 3) the VRE with its users, who can
cooperatively work through the VRE to conduct various
research activities [
        <xref ref-type="bibr" rid="ref3 ref4 ref5">3-5</xref>
        ].
      </p>
      <p>
        Many VREs have been developed and used for specific
research domains. For example, the EVER-EST [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] and the
EPOS [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] VRE in earth sciences, the VI-SEEM [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] VRE in life
sciences, climatology and digital cultural heritage, and the
GenePattern [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] VRE in biological sciences. Requirements for
VREs in monodisciplinary research have already been
investigated. They include easy-to-use interfaces, adequate
data storage, available analysis tools, high performance
computing resources [
        <xref ref-type="bibr" rid="ref10 ref11">10, 11</xref>
        ], secure access mechanisms via
the same credentials [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], metadata management [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ], help and
training support for VRE users [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ].
      </p>
      <p>Multidisciplinary research, intending to solve many
problems, such as climate change, environmental pollution,
and earthquakes monitoring and prediction, needs to combine
data from several disciplines and requires collaboration.
However, there is a lack of insight into what is needed to
develop a multidisciplinary VRE in comparison with
monodisciplinary VREs. This is currently blocking the
development of innovative multidisciplinary VREs. The
objective of this study is twofold: 1) to investigate the
requirements for building a multidisciplinary VRE and 2) to
study the key differences of current practices of
monodisciplinary VREs in comparison with multidisciplinary
VREs. To attain this objective, we have investigated VRE
requirements using multiple methods, including a literature
review, interviews with potential VRE users and developers,
and the characterisation of existing research infrastructures.</p>
      <p>This paper is organized as follows. Section 2 describes the
requirements engineering approach applied in this study.
Section 3 and 4 describe the requirements for monodisciplinary
VREs and multi-disciplinary VREs accordingly. In Section 5,
we compare the requirements between monodisciplinary VREs
and multidisciplinary VREs. Section 6 concludes this paper.</p>
    </sec>
    <sec id="sec-2">
      <title>II. REQUIREMENT ENGINEERING APPROACH</title>
      <p>
        VREs support research by interconverting between the
multiple underlying e-RIs supported by e-Is, while the VRE
users neither know nor care about the underlying e-Is [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
Depending on e-RIs, VREs are on a higher level of hierarchy
than e-RIs and underlying e-Is, and provide more advanced
functionalities for their end-users which are mainly researchers.
The perspective of the user, i.e. the researcher, is essential for
developing the VREs. Understanding user requirements is
generally recognized as the most crucial and the most difficult
stage for the successful development, deployment and
evolution of information systems [
        <xref ref-type="bibr" rid="ref13 ref14 ref15">13-15</xref>
        ]. This is also the case
for the VREs. Aybuke and Claes [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ] state that requirements
should include both user needs and needs arising from other
stakeholders like organizations, governmental bodies and
industry standards. What is common among requirement
definitions is that they refer to describing what the proposed
information system is supposed to do and how it should do this
[
        <xref ref-type="bibr" rid="ref13 ref16 ref17">13, 16, 17</xref>
        ]. However, the understanding regarding “what” and
“how” differs per stakeholder, and it is not easy to identify the
differences between various requirement classifications in
practise [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]. In this study, we adopted the definition of
requirement from Aybuke and Claes [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ], namely descriptions
of how a software products should perform.
      </p>
      <p>
        The requirements engineering process concerns the
investigation and learning about the problem domain in terms
of understanding the actual goals, needs and expectations of
the users regarding a system [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. Browne et. al (2001) stated
that this process consists of three steps, namely: 1)
information gathering, 2) representation and 3) verification
[
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. Maguire et. al (2002) mentioned that the requirement
analysis process encompasses 4 steps, namely 1) information
gathering, 2) user needs identification, 3) envisioning &amp;
evaluation and 4) requirement specifications. Parviaien et. al
(2003) stated three phases in the requirement engineering
processes, including 1) requirements elicitation, 2)
requirements analysis &amp; negotiation and 3) requirements
validation [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ]. We state that in reality the requirements
collection is a continuous and iterative process which needs to
accommodate changes from the involved organizations,
environment and stakeholders. From these engineering
processes we derived four common elements as shown in
Figure 1, namely 1) elicitation, 2) analysis and negotiation, 3)
evaluation and 4) evolution management. Below we explain
how we identified and elicited requirements in this research
through each of the steps shown in Figure 1.
      </p>
      <sec id="sec-2-1">
        <title>Step 1: Elicitation</title>
        <p>
          Requirements elicitation helps to discover and
conceptualize system requirements through information
gathering and user needs identification. We collected
background information from interviews and publicly
available documentations of existing VRE research projects.
After the user information is collected, analysis can start to
identify the real user needs and expectations. In this research
we use existing VRE projects and the characterisation of e-RI
projects to identify user needs. Interview protocols were
created to collect information from the end-users and VRE
developers [
          <xref ref-type="bibr" rid="ref21">21</xref>
          ]. Ten interviews have been conducted (see
Table 1).
        </p>
        <p>A VRE allows for connecting existing VREs and e-RIs,
we have analyzed the functionalities in the existing VRE
projects as a starting point to understand the VRE
requirements. Eight ESFRI landmark projects have been
selected for analysis. These projects are relatively mature
VREs or e-RIs which have been developed or are already in
operation now. These VREs focus on a single discipline such
as earth science, social science, or life science. A protocol
guiding and structuring the characterisation of e-RIs was also
created on the basis of six key types of functional elements in
an e-RI defined by the ENVRIPlus project [22]. The
questions of these three protocols were created using the
Reference Model of Open Distributed Processing (ODP) [23].
The questions covered each of the five ODP viewpoints:
enterprise (science), information, computation, engineering
and technology. The VRE should account for the needs of
heterogeneous user groups. In addition, the questions
concerning activities of VRE users addressed user activities in
line with those mentioned in the literature [24, 25].</p>
      </sec>
      <sec id="sec-2-2">
        <title>Step 2: Analysis and negotiation</title>
        <p>Once an initial set of user requirements has been
formulated, requirements can be detailed, discussed and
agreed by stakeholders in the analysis and negotiation phase,
including two main steps:</p>
        <p>1) Analyse and envision. When analysing and describing
the requirements, it is essential to fully document “the design
element or its interfaces in terms of requirements (functional,
performance, constraints and design characteristics)” [26].
After describing the requirements, it is also necessary to
develop a conceptual prototype to illustrate the requirements
and get feedback from the stakeholders. On the basis of the
feedback, the requirements are evaluated and may be
modified.</p>
        <p>
          2) Specification and negotiation. In the analysis step of
user requirements, the following should be discussed with all
stakeholders and documented within the specification:
identification of the range of relevant users, clear design goals,
the requirements with prioritized levels and evaluation criteria
to test the requirements whether they will be fulfilled and
evidence of acceptance of the requirements by stakeholders.
The following methods are used for specification and
negotiation: function mapping, requirements categorisation
[
          <xref ref-type="bibr" rid="ref14">14</xref>
          ].
        </p>
      </sec>
      <sec id="sec-2-3">
        <title>Step 3: Evaluation</title>
        <p>
          The evaluation of requirements is to check the consistency
and completeness of the requirements [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ]. This phase is
concerned with the examination of the requirement description
to ensure that it defines the system in an accurate and
comprehensive way. In this research, we have used use case
analysis, online questionnaire and several workshops with
VRE experts to evaluate the collected requirements. After these
activities, we have also designed a VRE system architecture to
accommodate all collected requirements.
        </p>
      </sec>
      <sec id="sec-2-4">
        <title>Step 4: Evolution management</title>
        <p>
          Requirements are the starting point for the system design
phase [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ]. However, we cannot wait for complete
requirements as the content and the priority of the initial
requirements may evolve and change during the development
process. Therefore, we also keep track of changes in or new
requirements. These initial requirements have been used to
define the system functionalities when designing the VRE
architecture. During the development of the VRE architecture
and analysis of use cases, some additional requirements have
been identified. These requirements are not new but support
requirements identified in step 2.
        </p>
        <p>In this study, we focused on the research results from the
step 1 and step 2 while the results from step 3 and step 4 are
beyond the scope of this paper.</p>
        <p>III. ELICITATION OF MONO-DISCIPLINARY VRE</p>
        <p>REQUIREMENTS</p>
        <p>In order to tackle the global challenges and solve complex
scientific problems, scientists need to use VREs as shorthand
for the tools and technologies. They can conveniently make
use of resources and technical infrastructures available both
locally and remotely to conduct their research and to interact
with other researchers who might be from different countries.</p>
        <p>Therefore, VREs need to provide tools and computing
resources related to data acquisition, data storage, data
processing, and data analysis. According to the e-infrastructure
research project ENVRIplus, VREs should meet requirements
and provide six types of functionalities, including data
identification and citation, i.e. assigning global unique
identifiers to data; data curation, i.e. data quality check; data
cataloguing, i.e. adding metadata to datasets; data processing,
i.e. converting data format and data visualization; data
optimization, i.e. data compartmentalization; and data
provenance, i.e. tracking the changes of data. We also add
collaboration, training and support as an additional category in
this table, since researchers are in need of support related to
finding collaboration for research projects, i.e. finding the
collaborators with specific expertise, writing grant proposal
and research project management tools, according to
interviewees #1, #8, and #9.</p>
        <p>According to the interviewees #1, #3, #4, #5, and #9 (als
researchers that are potential VRE end-users), a
quicklyaccessible, reliable, easy-to-use, low-cost VRE is expected.
Therefore, when designing the VRE, it is very important to
also consider the non-functional performance-related
requirements defined by commonly used software engineering
standards in FURPS+ and ISO 25010:2011 such as efficiency,
usability, reliability, maintainability, sustainability,
compatibility and portability.</p>
        <p>In addition, interviewee #6 indicated that all VREs have to
carefully deal with data containing privacy sensitive
information. Therefore, privacy, security, trust and legal
requirements are necessary to be considered in term of
regulatory compliance. Privacy and security requirements
specify how the use of the VRE should be robust against
cyberattacks in term of enhanced privacy and security. Trust
requirements specify the acceptable behaviours of the
stakeholders in the VRE, such as users, system developers and
service providers. Legal requirements specify that the whole
development of VRE should comply with all legislation,
especially the new General Data Protection Regulation issued
by the European Parliament, the Council and the Commission
in 2015.</p>
        <p>
          Research into mono-disciplinary VREs already shows that
many challenges exist for the use of VREs [27], including: data
context issues (understanding the creation context of research
data), data heterogeneity issues (large amount of data
generating from various sources), data quality issues (it is not
easy to control data quality), privacy issues (datasets
containing privacy information need to shared and reused),
user experience issues (the expectation of users on the system
varies), availability of technology issues. Previous research
also shows that for multidisciplinary VREs, even more
challenges should be added to this list, since multidisciplinary
VREs need to interoperate between a large variety of
standards, ontologies and terminologies used by different
research disciplines in different countries. According to the
information from interviews and the e-RI characterisations,
additional challenges concern the availability of data from
different sources, data use licensing for different organizations,
scalability in terms of connecting High Performance
Computing (HPC) facilities, system management responsibility
and financial support. Another challenge concerns the access
policy. VRE system administrators prefer one certificate per
research community in order to lower the effect on user
credential management[
          <xref ref-type="bibr" rid="ref11">11</xref>
          ], while many organizations cannot
easily make agreements on sharing certificates to grant access
to VREs.
        </p>
        <p>From the requirements collection work, we have analyzed
eight monodisciplinary VREs or e-RIs based on seven
functional requirement categories. These VREs provide
integrated services and datasets and cross-country access to
various resources for research. Researchers from the same
research domain can use these resources. Some VREs only
provide these services to authorized researchers. Researchers
from other disciplines or general public cannot easily access
some of these VREs. Some VREs are still in the development
phase, although some functionalities in the seven categories are
being designed or already implemented. The usability of these
functionalities significantly varies. These VREs mainly provide
dataset download and limited data analysis tools. The
collaboration, training and support functionalities are largely
missing in these VREs and e-RIs.</p>
        <p>IV. ANALYSIS OF REQUIREMENTS FOR MULTIDISCIPLINARY</p>
        <p>VRES</p>
        <p>In this section we describe the requirements for
multidisciplinary VRE collaboration, compared to
monodisciplinary VRE use. Table 2 presents a list of requirements
for the development of a multidisciplinary VRE, containing
nine categories of requirements, namely:
1)
2)
3)
4)
5)</p>
        <p>Data identification and citation requirements which
define the approaches to provide everlasting and
unique references to each research data object;
Data curation requirements which define the needs of
processes to assure the availability and quality of data
object over the long term;
Data cataloguing requirements which define the
needs of easy and quick access to data objects by
queries over catalogues;
Data processing requirements which define the needs
of providing computational transformation software on
data objects;
Data optimization requirements which define the
needs of providing computational transformation and
6)
7)
8)
9)
processing towards desired effects from the viewpoint
of data object creator or users;
Data provenance requirements which define the needs
of making logs on the transformation and
computational process on data objects;
Collaboration, training and support requirements
which define the needs of providing research
collaboration tools and manuals for using VREs
systems;
None-functional requirements which define the
software performance related objectives such usability,
stability;
Security, privacy trust and legal requirements which
define the needs of system design in compliance with
all regulation and improvement measures in terms of
improving users’ overall trust on the VREs.</p>
        <p>
          This list contains 148 requirements in 9 categories which
have been reported in a project deliverable of the VRE4EIC
project [
          <xref ref-type="bibr" rid="ref21">21</xref>
          ]. Our requirements provide a comprehensive
overview of many perspectives that need to be considered
during the development of VREs. The requirement categories
mentioned in Table 2 are also important to monodisciplinary
VREs, however, the examples of the requirements themselves
are specific to multidisciplinary VREs.
        </p>
        <p>We have analyzed eight e-RIs and VREs to understand the
current practices in the development of VREs. Table 3 showed
the implementation of functional requirements in these
projects. From the table we can see that many projects have
considered data-related requirements while collaboration
requirements are largely ignored. Although the categories of
the requirements have been covered by many existing VRE
projects, but the range and details of specific requirements in
each categories are not comprehensive enough for developing
a multi-disciplinary VRE. Privacy and trust related
requirements have not been identified in these projects.
TABLE 3 Characterisation of the e-Research Infrastructures and Virtual
Research Environments.
eResearch
Infrastruc
ture /
Virtual
Research
Environm
ent
EUROARGO
ICOS
EPOS
ELIXIR
Lifewatch
CESSDA
ENVRIPL
US
CLARIN</p>
        <p>Identifi
cation
and
citation
●
●
●
●
●
●
●
●</p>
        <p>Cu
rati
on
●
●
●
●
●
●
●
●</p>
        <p>Cat
alo
gui
ng
●
●
●
●
●
●
●
●
*
●
●
●
●
●
●
●
Requirements
Data
Proce
ssing</p>
        <p>Data
Optimi
zation</p>
        <p>Data
Proven
ance
*
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
● Requirements covered
○ Requirements not covered
* Requirements suggested by the project vision or limitedly covered</p>
        <p>A multidisciplinary VRE is ideally open to any researcher.
In our study, we found that many researchers are already using
some domain-specific resources like research data, software
tools or e-infrastructures to support their research activities.
However, these resources are only known or open to a small
research community. Some of the mono-disciplinary VREs we
studied claim to be openly accessible, but they are de facto
only open to some researchers due to bureaucratic user
registration and approval processes. It is very difficult for
researchers from other domains to find these existing VREs
since they are not aware of the VRE development in the
research domain other than their own science community.
Collabor
ation,
training
&amp;
support
○
○
*
○
○
*
*
*</p>
        <p>When a new VRE becomes available, researchers do not
just move from one e-RI or VRE which they are already
familiar with to another. The process of transferring from one
VRE to another creates challenges for researchers. Since the
usability of existing mono-disciplinary VREs developed based
on the requirements in Table 3 significantly varies, the
interoperability of those VREs cannot meet the researchers’
demands in multi-disciplinary research. In addition,
researchers do not want to spend much time on learning how
to use new software or work in a new online environment.
Therefore, easy access to data from multiple disciplines and to
computing resources are crucial. A portal or gateway
connected with those resources might be suitable to fulfill this
task.</p>
        <p>In multidisciplinary research, researchers desire to use a
single tool with an easily understandable Graphical User
Interfase (GUI) and plug-and-play features provided by
different VREs or e-RIs to submit their experiment tasks, data
analysis assignments and to monitor the status. They do not
want to know the complexity behind simultaneously running
these tasks. A powerful workflow engine with an intuitively
usable GUI needs to be designed in a multidisciplinary VRE
to integrate several mono-disciplinary VREs.</p>
        <p>Different research communities use different standards and
data models to process research data. Researchers from the
same research domain can use their own standards and
practices for data processing. In multidisciplinary research,
researchers need to combine data from different research
domains with interoperable data processing tools. Our
research showed that they do not want to encounter errors
when they put the data in the VRE system. In the interviews,
researchers also expressed their concerns related to the control
of their data if shared with other researchers. They want their
work and data to be acknowledged and properly referred to
when used by others. In a multidisciplinary VRE stored data
and data use are more complex compared to a
monodisciplinary VRE, thus better security mechanisms are
required without hindering the ease-to-use of the system.</p>
        <p>In general, we found that there remains a big gap in the
completeness of requirements fulfilled by the existing
monodisciplinary VREs towards multidisciplinary VREs. This is
shown in Table 3. A comprehensive multidisciplinary VRE
should fulfill the requirements described by in the
aforementioned nine requirement categories (see section IV).
Multidisciplinary VREs need to be developed in terms of
interoperability, a single gateway with an intuitive GUI to
easily access data and computing resources, and complying
with data protection regulation.</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>VI. CONCLUSIONS</title>
      <p>This research aims to 1) study the requirements for developing
a multidisciplinary VRE, and 2) investigate the requirement
differences between the current practices of monodisciplinary
VRE and the requirements of developing a multidisciplinary
VRE. A comprehensive set of requirements needs to be
considered when developing a multidisciplinary VRE.
Building on the ENVRIplus categorization for e-Research
Infrastructure requirements, we categorized functional
requirements in the following categories: data identification
and citation, data curation, data cataloguing, data processing,
data optimization, data provenance, collaboration, training and
support. Non-functional requirements were added to this
categorization and collected in the categories of
performancerelated requirements, security, privacy, trust and legal
requirements.</p>
      <p>Researchers’ concerns on losing control of their own research
data, lack of interoperability between different VREs and
eRIs and e-Is, as well as lack of comprehensive consideration
of various requirements in monodisciplinary VREs limit their
adoption for multidisciplinary research. When developing
multidisciplinary VREs, we have to take all these
requirements into consideration and choose suitable
technologies to meet them. However, we have to admit that
developing VREs is a rather complex engineering process.
Requirements identified in this study may not be implemented
at once, but fulfilled stage by stage during the development of
mature multidisciplinary VREs.</p>
    </sec>
    <sec id="sec-4">
      <title>ACKNOWLEDGMENT</title>
      <p>This work was carried out within the VRE4EIC project
and received funding from the European Union’s Horizon
2020 research and innovation programme under grant
agreement No. 676247. The authors should like to thank their
colleagues in this project for their input for this paper
(particularly Daniele Bailo, Zhiming Zhao, Valerie Brasse,
Theodore Patkos, and Jacco van Ossenbruggen for
coordinating the interviews). The views expressed in this
paper are the views of the author and not necessarily of the
VRE4EIC project.</p>
      <p>[cited
2018;</p>
      <p>Available
[22] ENVRIplus. 2018</p>
      <p>http://www.envriplus.eu/.
[24] Buddenbohm, S., et al., Success Criteria for the Development and
Sustainable Operation of Virtual Research Environments. D‐Lib
Magazine, 2015. 21(9/10).
[26] IEEE-STD, ISO/IEC Standard for Systems Engineering - Application
and Management of the Systems Engineering Process. ISO/IEC 26702
IEEE Std 1220-2005 First edition 2007-07-15, 2007: p. c1-88.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <surname>Buddenbohm</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          , et al.,
          <article-title>Success criteria for the development and sustainable operation of virtual research environments</article-title>
          .
          <string-name>
            <surname>D-Lib</surname>
            <given-names>Magazine</given-names>
          </string-name>
          ,
          <year>2015</year>
          .
          <volume>21</volume>
          (
          <issue>9</issue>
          /10).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <surname>Susha</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Janssen</surname>
          </string-name>
          , and
          <string-name>
            <given-names>S.</given-names>
            <surname>Verhulst</surname>
          </string-name>
          .
          <article-title>Data collaboratives as a new frontier of cross-sector partnerships in the age of open data: Taxonomy development</article-title>
          .
          <source>in Proceedings of the 50th Hawaii International Conference on System Sciences</source>
          .
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Zuiderwijk</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , et al.,
          <article-title>Using Open Research Data for Public Policy Making: Opportunities of Virtual Research Environments</article-title>
          , in Conference for E-Democracy and
          <string-name>
            <given-names>Open</given-names>
            <surname>Government</surname>
          </string-name>
          .
          <year>2016</year>
          :
          <article-title>Krems an der Donau</article-title>
          , Austria.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Crosas</surname>
            ,
            <given-names>M.,</given-names>
          </string-name>
          <article-title>The dataverse network®: an open-source application for sharing, discovering and preserving data. D-lib</article-title>
          <string-name>
            <surname>Magazine</surname>
          </string-name>
          ,
          <year>2011</year>
          .
          <volume>17</volume>
          (
          <issue>1</issue>
          ): p.
          <fpage>2</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Edwards</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          , et al.,
          <article-title>Lessons learnt from the deployment of a semantic virtual research environment</article-title>
          .
          <source>Web Semantics: Science, Services and Agents on the World Wide Web</source>
          ,
          <year>2014</year>
          .
          <fpage>27</fpage>
          -
          <lpage>28</lpage>
          : p.
          <fpage>70</fpage>
          -
          <lpage>77</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>EVER-EST.</surname>
          </string-name>
          EVER-EST.
          <year>2018</year>
          ;
          <article-title>Available from: www.ever-est</article-title>
          .eu.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>EPOS. European</given-names>
            <surname>Plate Observing System</surname>
          </string-name>
          .
          <year>2018</year>
          ; Available from: https://www.epos-ip.org/.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <surname>Vi-SEEM</surname>
          </string-name>
          ,
          <article-title>Virtual Research Environment (VRE) in Southeast Europe and the Eastern Mediterranean (SEEM</article-title>
          ).
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <surname>GenePattern. GenePattern: A Patform for Reproducible Bioinformatics</surname>
          </string-name>
          . 2018; Available from: http://software.broadinstitute.org/cancer/software/genepattern#.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <surname>McGrath</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , et al.,
          <article-title>The Essential Components of a Successful Galaxy Service</article-title>
          .
          <source>Journal of Grid Computing</source>
          ,
          <year>2016</year>
          .
          <volume>14</volume>
          (
          <issue>4</issue>
          ): p.
          <fpage>533</fpage>
          -
          <lpage>543</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Gesing</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          , et al.,
          <article-title>Using Science Gateways for Bridging the Differences between Research Infrastructures</article-title>
          .
          <source>Journal of Grid Computing</source>
          ,
          <year>2016</year>
          .
          <volume>14</volume>
          (
          <issue>4</issue>
          ): p.
          <fpage>545</fpage>
          -
          <lpage>557</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <surname>Grunzke</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          , et al.,
          <article-title>Metadata management in the MoSGrid science gateway-evaluation and the expansion of quantum chemistry support</article-title>
          .
          <source>Journal of Grid Computing</source>
          ,
          <year>2017</year>
          .
          <volume>15</volume>
          (
          <issue>1</issue>
          ): p.
          <fpage>41</fpage>
          -
          <lpage>53</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <surname>Yu</surname>
            ,
            <given-names>E.S.K.</given-names>
          </string-name>
          <article-title>Towards modelling and reasoning support for early-phase requirements engineering</article-title>
          .
          <source>in Proceedings of the 1997 3rd International Symposium on Requirements Engineering</source>
          .
          <year>1997</year>
          . Los Alamitos, CA,
          <string-name>
            <surname>United</surname>
            <given-names>States</given-names>
          </string-name>
          , Annapolis,
          <string-name>
            <surname>MD</surname>
          </string-name>
          , USA: IEEE.
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <surname>Maguire</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          and
          <string-name>
            <given-names>N.</given-names>
            <surname>Bevan</surname>
          </string-name>
          ,
          <article-title>User requirements analysis</article-title>
          ,
          <source>in Usability. 2002</source>
          , Springer. p.
          <fpage>133</fpage>
          -
          <lpage>148</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <surname>Browne</surname>
            ,
            <given-names>G.J.</given-names>
          </string-name>
          and
          <string-name>
            <surname>M.B. Rogich</surname>
          </string-name>
          ,
          <article-title>An empirical investigation of user requirements elicitation: Comparing the effectiveness of prompting techniques</article-title>
          .
          <source>Journal of Management Information Systems</source>
          ,
          <year>2001</year>
          .
          <volume>17</volume>
          (
          <issue>4</issue>
          ): p.
          <fpage>223</fpage>
          -
          <lpage>249</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <surname>Aybuke</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          and
          <string-name>
            <given-names>W.</given-names>
            <surname>Claes</surname>
          </string-name>
          , Engineering and Managing Software Requirements.
          <year>2005</year>
          , Springer-Verlag Berlin.
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <surname>Robinson</surname>
            ,
            <given-names>W.N.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>S.D.</given-names>
            <surname>Pawlowski</surname>
          </string-name>
          , and
          <string-name>
            <given-names>V.</given-names>
            <surname>Volkov</surname>
          </string-name>
          ,
          <source>Requirements Interaction Management. ACM Computing Surveys</source>
          ,
          <year>2003</year>
          .
          <volume>35</volume>
          (
          <issue>2</issue>
          ): p.
          <fpage>132</fpage>
          -
          <lpage>190</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <surname>Curtis</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Krasner</surname>
          </string-name>
          , and
          <string-name>
            <given-names>N.</given-names>
            <surname>Iscoe</surname>
          </string-name>
          ,
          <article-title>A field study of the software design process for large systems</article-title>
          .
          <source>Communications of the ACM</source>
          ,
          <year>1988</year>
          .
          <volume>31</volume>
          (
          <issue>11</issue>
          ): p.
          <fpage>1268</fpage>
          -
          <lpage>1287</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <surname>Koukias</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , et al.
          <article-title>Approach on analysis of heterogeneous requirements in software engineering</article-title>
          .
          <source>in 11th IFAC Workshop on Intelligent Manufacturing Systems</source>
          ,
          <string-name>
            <surname>IMS</surname>
          </string-name>
          <year>2013</year>
          .
          <year>2013</year>
          . Sao Paulo.
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <surname>Parviainen</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          , et al.,
          <article-title>Requirements engineering inventory of technologies</article-title>
          .
          <source>VTT PUBLICATIONS</source>
          ,
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [21]
          <string-name>
            <surname>Yin</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Zuiderwijk</surname>
          </string-name>
          ,
          <article-title>State-of-the-art and user requirement analysis</article-title>
          .
          <year>2016</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>