When You Don’t Know With Whom to Collaborate: Towards an Interactive System Connecting Contributors in a Research Project Jil Klünder1,2[0000−0001−7674−2930] , Wasja Brunotte1,2 , and Kurt Schneider1,2 1 Software Engineering Group, Leibniz University Hannover, Hannover, Germany 2 Cluster of Excellence PhoenixD, Leibniz University Hannover, Hannover, Germany {jil.kluender | wasja.brunotte | kurt.schneider}@inf.uni-hannover.de Abstract. Stakeholders are important for software projects as they help to define the requirements. However, in case of multiple stakeholders with different viewpoints, it is often difficult to find a suitable solution for almost everybody. We faced this situation in a large interdisciplinary research project with contributors from different 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 disci- plines. 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 difficult to identify stakeholders who can contribute to the requirements elicitation at the moment. In this paper, we present the first idea of our approach, as well as faced and expected challenges and open questions. Keywords: interdisciplinary collaboration · stakeholder identification · interactive system 1 Introduction Software projects often require a close collaboration of different people in order to be successful [1, 3]. In most software projects, at least two parties are involved: the development team that is responsible for the development of the software and the customer, whose needs lead to the requirements of the system. Having clearly defined requirements is a prerequisite for a successful project [4]. However, when helping to define the requirements, the customer often has to take different viewpoints into account [7]. These viewpoints are given by different stakeholders that have different requirements to be fulfilled by the software [2]. The task of clarifying the requirements and uniting different stakeholder viewpoints is even more difficult when the stakeholders do not know their needs or if the requirements engineer does not know the stakeholders [9]. We faced this situation in the large interdisciplinary research project PhoenixD with contributors from different 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 Com- mons License Attribution 4.0 International (CC BY 4.0). 2 J. Klünder et al. 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 different unit systems that are only partially compatible. Thus, the collaboration is difficult 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 different 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 Context and Background 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 Uni- versity 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 sup- ports the involved parties in exchanging data considering their different research areas, e.g., data respectively unit formats. In particular, we strive towards a software system enabling interactions between different 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 different research groups from, e.g., mechanical engineering. However, at this early project stage, several research groups do not know with whom to collabo- rate (gray arrows in Figure 1). The project requires data exchange between the different research groups which is difficult due to, e.g., missing knowledge about the other domains and different unit systems used for data analysis. Even though a research group has a problem, e.g., the reduction of a partial differential 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 different 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/. Connecting Contributors in a Research Project 3 Mechanical Engineering Chemistry ? Physics Other Disciplines Discipline A Discipline B Discipline C Discipline D ? Legend A needs to Research A needs to A and B need to A B collaborate with B A B collaborate A B collaborate with B Group where B is unknown Fig. 1. Abstracted structure of PhoenixD and the required collaborations between research groups 3 Vision In order to solve the above-mentioned problem, i.e., to enable and facilitate the collaboration between different research groups, we propose to develop an interactive system. The development of such a system is difficult 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 inter- disciplinary research groups working on, e.g., the simulation part of the research group (Area Sn ) or on the suitability of different materials (Area Mn ). The in- teractive system can be defined as an intelligent data bus that processes data by different 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 different 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 prob- lem. The intelligent data bus identifies research group 2 (RG2) to be able to help RG1. Therefore, the system notifies 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 4 J. Klünder et al. Area Area Area Fn Mn Sn direct access Intelligent Data Bus Specific Middleware on Comprehensive Reference Data Model access via adapters X1 X2 X3 Xm Fig. 2. Visionary solution with adapters for data exchange 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 different needs and viewpoints of the users, i.e., the con- tributors. 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 different ex- changeable 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. Fur- thermore, 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 different needs of the users. This way, we want to ensure the best possible usability and acceptance. 4 Current State 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 identified two stakeholders. One is from academia (inorganic chem- istry) and the other one from industry (physicists from Laser Zentrum Han- nover). The chemists need support and more fine-grained results when calcu- Connecting Contributors in a Research Project 5 Rich Client with modular structure Further Bus Access Interfaces (BAI) Rest API Intelligent Data Bus Transform Public Key … & Data Infrastruc- Transport ture (PKI) … Fig. 3. Vision of preliminary architecture 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 fine-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 dif- ferent levels of knowledge had to be resolved. Both the chemists and the physi- cists do research in the field of crystallography but from a different 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 respec- tive 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. Oth- erwise, 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 confidential and cannot be shared via, e.g., e- mail. Therefore, both the data itself and all traffic needs to be encrypted. In addition to the security part, we also face issues typical for research data man- agement: 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. 6 J. Klünder et al. Crystallographic Data (1) Inorganic (2) Chemistry Academia SERVER Calculations (5) Results (4) (3) Laser Zentrum Intelligent Data Hannover Bus Industry Fig. 4. The current state of the interactive system including two stakeholder groups Figure 4 visualizes the current state. At the moment, the intelligent data bus supports the data exchange between the research group from inorganic chemistry and the Laser Zentrum Hannover: The research group from inorganic chemistry can upload their crystallographic data (1). The Laser Zentrum Hannover down- loads the respective files (2) and runs the requested calculations (3). Afterwards, the research group from the Laser Zentrum Hannover uploads the results (4). In the last step, the research group from inorganic chemistry downloads the data (5). Fortunately, the data does not need to be converted as the chemists can export their data in a format which can be imported by the software used by the physicists. 5 Future Research 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 identified who can contribute to the requirements elicitation? In order to integrate other stake- holders’ viewpoints, we first need to identify those who can currently contribute to the requirements elicitation. With this question, we want to investigate pos- sibilities to identify important stakeholders to get to know their viewpoints. RQ2: How do multiple stakeholders’ viewpoints affect the phases of the tradi- tional requirements engineering process? Multiple stakeholders who are unknown at the beginning of a project seem to affect the applicability of the traditional requirements engineering phases, including the requirements elicitation and the Connecting Contributors in a Research Project 7 negotiation. Probably, techniques from Crowd-RE can help to overcome this problem. To answer this research question, we want to analyze different require- ments engineering approaches with respect to their applicability in our context, including Crowd-RE, Agile RE and the like. RQ3: How can different 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 con- sider 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 Related Work Research on multiple viewpoints in requirements engineering and how to iden- tify these viewpoints – mainly given by different stakeholders – is not new. Sommerville et al. [8] present PREview, an approach for multi-perspective re- quirements engineering allowing for an incremental elicitation of requirements – for example due to different stakeholders. Pacheco and Garcia [5] summarize approaches to identify these different stakeholders. They present the results from a literature review of methods to identify stakeholders in the requirements elic- itation phase. Although they found several approaches to identify stakeholders, they also state that all these approaches still have limitations that need to be taken seriously although stakeholder identification is very important for success- ful software development. Sharp et al. [6] discuss current work on stakeholder identification and outline an approach helping to identify relevant stakeholders. 7 Conclusion Although including various viewpoints of different stakeholders is required in order to finish a software project successfully, identifying these stakeholders is not always easy. In the research project PhoenixD with contributors from differ- ent natural sciences and industry we faced this problem. In this specific 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 different contribu- tors. As next steps towards this bus, we need to identify the stakeholders and integrate their requirements step by step in the software. Further research direc- tions will be the influence of having multiple stakeholders including their distinct 8 J. Klünder et al. viewpoints on the different phases of requirements engineering and its impact for an incremental development process. Acknowledgments. This research is funded by the Deutsche Forschungsgemein- schaft (German Research Foundation) under Germany’s Excellence Strategy within the Cluster of Excellence PhoenixD (EXC 2122, Project ID 390833453). References 1. DeMarco, T., Lister, T.: Peopleware: Productive projects and teams. Addison- Wesley (2013) 2. Fricker, S.: Requirements value chains: Stakeholder management and requirements engineering in software ecosystems. In: International Working Conference on Re- quirements Engineering: Foundation for Software Quality. pp. 60–66. Springer (2010) 3. Kraut, R.E., Streeter, L.A.: Coordination in software development. Communications of the ACM 38(3), 69–82 (1995) 4. Mishra, D., Mishra, A., Yazici, A.: Successful requirement elicitation by combining requirement engineering techniques. In: 2008 First International Conference on the Applications of Digital Information and Web Technologies (ICADIWT). pp. 258– 263. IEEE (2008) 5. Pacheco, C., Garcia, I.: A systematic literature review of stakeholder identification methods in requirements elicitation. Journal of Systems and Software 85(9), 2171– 2181 (2012) 6. Sharp, H., Finkelstein, A., Galal, G.: Stakeholder identification in the requirements engineering process. In: Proceedings. Tenth International Workshop on Database and Expert Systems Applications. DEXA 99. pp. 387–391. IEEE (1999) 7. Sommerville, I., Sawyer, P.: Requirements engineering: a good practice guide. John Wiley & Sons, Inc. (1997) 8. Sommerville, I., Sawyer, P., Viller, S.: Viewpoints for requirements elicitation: a practical approach. In: Proceedings of IEEE International Symposium on Require- ments Engineering: RE’98. pp. 74–81. IEEE (1998) 9. Sutcliffe, A., Sawyer, P.: Requirements elicitation: Towards the unknown unknowns. In: 2013 21st IEEE International Requirements Engineering Conference (RE). pp. 92–104. IEEE (2013)