Stakeholders are important for software projects as they help to de ne the requirements. However, in case of multiple stakeholders with di erent viewpoints, it is often di cult to nd a suitable solution for almost everybody. We faced this situation in a large interdisciplinary research project with contributors from di erent natural sciences. The contributors have to collaborate with each other, i.e., they need to share and exchange knowledge, data, and research strategies from their disciplines. In order to support them, we develop an approach that facilitates the collaboration by enabling data exchange between research groups. However, the contributors { i.e., stakeholders { do not know with whom and how to collaborate. Therefore, it is di cult to identify stakeholders who can contribute to the requirements elicitation at the moment. In this paper, we present the rst idea of our approach, as well as faced and expected challenges and open questions.
Software projects often require a close collaboration of di erent people in order
to be successful [
We faced this situation in the large interdisciplinary research project PhoenixD with contributors from di erent natural sciences. These contributors need to collaborate, i.e., exchange data and knowledge or share research strategies from Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). their disciplines. However, at this point in time, they do not know with whom to collaborate in order to keep the project on track. In addition, in particular the data exchange is not that easy due to di erent unit systems that are only partially compatible. Thus, the collaboration is di cult to realize.
In this paper, we present our approach to support the collaboration of the contributors by developing an interactive system taking into consideration their di erent viewpoints. We further outline our plan of action to develop the system and present challenges we faced so far as well as open questions and future research directions. 2
PhoenixD: Photonics, Optics, Engineering - Innovation Across Disciplines is a cluster of excellence merging optical systems, design and simulation tools with production technologies. The goal of PhoenixD is the creation of individualized and highly-functional optical devices.3 Researchers i.a. from the Leibniz University Hannover, the Technical University Braunschweig, the Laser Zentrum Hannover, and the Max Planck Institute for Gravitational Physics are involved in the project.
The Software Engineering part of PhoenixD is to develop a system that supports the involved parties in exchanging data considering their di erent research areas, e.g., data respectively unit formats. In particular, we strive towards a software system enabling interactions between di erent groups of contributors without the necessity to be totally aware of the other's domain. As visualized in Figure 1, the collaboration can take place interdisciplinary, e.g., between the physicists from the Laser Zentrum Hannover and the chemists from the inorganic chemistry at Leibniz University Hannover, as well as intradisciplinary between the di erent research groups from, e.g., mechanical engineering. However, at this early project stage, several research groups do not know with whom to collaborate (gray arrows in Figure 1).
The project requires data exchange between the di erent research groups which is di cult due to, e.g., missing knowledge about the other domains and di erent unit systems used for data analysis. Even though a research group has a problem, e.g., the reduction of a partial di erential equation, another group can solve, both groups have to know about each other.
We want to solve this problem using an interactive system that allows for collaboration without the need of knowing each other and each other's domain. Summarizing, the system has to solve the following problem: Enable di erent research groups to interact by providing the possibility to fast, easily and securely exchange data without the need to know exactly with whom to collaborate and without having sound knowledge in other research domains. 3 For further information visit https://www.phoenixd.uni-hannover.de/en/.
?
Discipline A Discipline B ? Discipline C Discipline D Legend Research A Group
A needs to B collaborate with B where B is unknown In order to solve the above-mentioned problem, i.e., to enable and facilitate the collaboration between di erent research groups, we propose to develop an interactive system. The development of such a system is di cult as it has to solve domain problems and to gain a huge acceptance of the research groups. Otherwise, the research groups may neglect to use the system.
Our overall vision is visualized in Figure 2. The yellow areas represent interdisciplinary research groups working on, e.g., the simulation part of the research group (Area Sn) or on the suitability of di erent materials (Area Mn). The interactive system can be de ned as an intelligent data bus that processes data by di erent research groups, e.g., computations, transformations, and simulations. The process starts with research group 1 (RG1), that is part of at least one of the area groups, requesting a computation by another research group. This request can be motivated, for instance, by a higher precision given by computing capacities or to ensure that di erent research groups obtain comparable results. RG1 uploads the input data needed for the calculations. In addition, RG1 states which parameters should be used for the calculations, and their concrete request. RG1 does not necessarily know which research group can help to solve the problem. The intelligent data bus identi es research group 2 (RG2) to be able to help RG1. Therefore, the system noti es RG2 and converts the input data as requested by RG2. RG2 receives the data in the required format and runs the computations as requested by RG1. Afterwards, RG2 uploads the results which triggers the system to notify RG1 and to convert the uploaded results to the
Area Fn
Area Mn
Area
Sn
Intelligent Data Bus Specific Middleware on Comprehensive Reference Data Model direct access access via adapters
X1
X2
X3
Xm format requested by RG1. RG1 can download the data and contact RG2 in case of callbacks.
Our preliminary architecture is sketched in Figure 3. It is important for our solution to consider the di erent needs and viewpoints of the users, i.e., the contributors. Hence, the architecture of such a system has to be adaptive and should grow with the changes caused by user needs during the project's evolution. In addition, we always have the best possible UX level in mind during the planning phase. As illustrated in Figure 3 the intelligent data bus consists of di erent exchangeable components. One component is responsible for storing data. Another component dispatches incoming and outgoing data (Transform & Transport ). To ensure certain security aspects like data integrity or encryption, the intelligent data bus is connected to a public key infrastructure (PKI). The components on the right-hand side with the three dots inside indicate the extensibility. Furthermore, the intelligent data bus is equipped with various interfaces for data exchange, so-called bus access interfaces (BAI). A possible access adapter which connects the intelligent data bus to a bus access interfaces could be a Rest API interface. The users of the interactive system communicate with the intelligent data bus using a rich client. The client consists of distinct components to respond to the di erent needs of the users. This way, we want to ensure the best possible usability and acceptance. 4
We already started implementing our vision. Developing the interactive system is not straight forward, as we do not know the stakeholders and the stakeholders do not know themselves. Consequently, it is not clear which contributors are stakeholders who can help us to identify the requirements for the software.
So far, we identi ed two stakeholders. One is from academia (inorganic chemistry) and the other one from industry (physicists from Laser Zentrum Hannover). The chemists need support and more ne-grained results when calcuRich Client with modular structure Rest API
Further Bus Access
Interfaces (BAI)
Intelligent Data Bus Transform
& Transport
Data
Public Key Infrastructure (PKI) …
… lating with crystallographic data representing the structure of molecules. The physicists from Laser Zentrum Hannover have a higher computing capacity which is why their calculations are more ne-grained. Since both research groups need to collaborate, it is highly important that the data they use is comparable and coincides (modulo granularity).
We already faced some challenges with these two stakeholders. First, the different levels of knowledge had to be resolved. Both the chemists and the physicists do research in the eld of crystallography but from a di erent point of view. Consequently, we had to identify the needs of each stakeholder, understanding their needs by ourselves and reconcile the elicited requirements with the respective project partner. It is highly important to create a usable solution so that the prototype gets accepted and is perceived as support in the research work. Otherwise, the stakeholders would neglect using the system. However, this is only limited possible as there are research groups who do not know which contributor can help to overcome their problems. To ensure the stakeholders' acceptance of the system, we follow a prototypical approach to ultimately reach a preferably high degree of usability and to meet the needs of the stakeholders. Moreover, one of the project partners requests to have additional parameter data for the calculations. This information is con dential and cannot be shared via, e.g., email. Therefore, both the data itself and all tra c needs to be encrypted. In addition to the security part, we also face issues typical for research data management: E.g., licensing has to be discussed, for example when using licensed work of other contributors to achieve some results. In addition, the integrity of the data is important to both parties as well as the platform independence of the software solution.
Crystallographic
Data (1) Inorganic Chemistry Academia
(2) SERVER (5) Intelligent Data
Bus
Calculations Results (4)
(3) Laser Zentrum
Hannover Industry In the next step, we need to extend our system to allow other research groups to use it. Therefore, we need to answer the following research questions: RQ1: Given a large set of possible stakeholders, how can those be identi ed who can contribute to the requirements elicitation? In order to integrate other stakeholders' viewpoints, we rst need to identify those who can currently contribute to the requirements elicitation. With this question, we want to investigate possibilities to identify important stakeholders to get to know their viewpoints. RQ2: How do multiple stakeholders' viewpoints a ect the phases of the traditional requirements engineering process? Multiple stakeholders who are unknown at the beginning of a project seem to a ect the applicability of the traditional requirements engineering phases, including the requirements elicitation and the negotiation. Probably, techniques from Crowd-RE can help to overcome this problem. To answer this research question, we want to analyze di erent requirements engineering approaches with respect to their applicability in our context, including Crowd-RE, Agile RE and the like.
RQ3: How can di erent stakeholders' viewpoints be integrated step-by-step in the development process even if they are unknown at the beginning of the project? Given the fact that we do not know the stakeholders at the beginning of the project, we probably need to include more stakeholders' viewpoints during the development process. With RQ3, we want to analyze how we can overcome this problem.
In order to answer these questions, we will start with a literature study to consider previous work from other researchers, and continue with the requirements elicitation in the group of contributors. Meanwhile, we will iteratively develop the interactive system and collect feedback right from the beginning to ensure the acceptance of the system. 6
Research on multiple viewpoints in requirements engineering and how to
identify these viewpoints { mainly given by di erent stakeholders { is not new.
Sommerville et al. [
Although including various viewpoints of di erent stakeholders is required in order to nish a software project successfully, identifying these stakeholders is not always easy. In the research project PhoenixD with contributors from di erent natural sciences and industry we faced this problem. In this speci c case, a contributor to the research project is a stakeholder as soon as he has a problem another contributor may be able to solve { without the necessity to know the other contributor. In order to facilitate this collaboration, we want to provide an intelligent data bus allowing for data exchange between di erent contributors. As next steps towards this bus, we need to identify the stakeholders and integrate their requirements step by step in the software. Further research directions will be the in uence of having multiple stakeholders including their distinct viewpoints on the di erent phases of requirements engineering and its impact for an incremental development process.
Acknowledgments. This research is funded by the Deutsche Forschungsgemeinschaft (German Research Foundation) under Germany's Excellence Strategy within the Cluster of Excellence PhoenixD (EXC 2122, Project ID 390833453).