Skip to main content

Introduction

Goals

The following documentation of the architecture for the sciebo Research Data Services was created by Peter Heiss (peter.heiss@uni-muenster.de). First of all, the core task of the system should be mentioned and then a detailed task description should be explained.

Core task

The system offers bridging functionalities to already existing research data services and supports the researcher working in Sciebo in his research data management from project development to publication and archiving. The most important aspects are the low-threshold services, reuse of existing services, integration of the system in Sciebo and user experience.

Task definition

The application documents for this project for the DFG describe many of the tasks in great detail. They can be found in the sciebo RDS-specific folder in Sciebo under 'sciebo RDS/Documents-DFG/DFG-Antrag_sciebo_RDS_final.pdf'. These are summarized in the following.

IDRequestExplanation
M-1Integration in ScieboResearchers are already familiar with Sciebo.
M-2Low-threshold servicesEasy handling guarantees long-term use.
M-3offers bridge functionalitiesAlready existing services are connected by bridge functionalities
M-4Integration of external servicesIt is avoided to initiate new developments by reusing already existing services and infrastructures.
M-5adapts external expert toolsThe researchers' tools are to be integrated into the bridge functionalities.
M-6offers basic FDMFor this purpose, functionalities for the indexing of research data are developed.
M-7continuous working methodsThe FDM receives continuous support from project development through operational work to publication and archiving.

Legend: M = Must, O = Optional

The following figure is a symbolic classification of the software architecture to be generated into the existing internal and external services.

![requirement cluster](/images/request cluster.svg)

A detailed list of all services and repositories to be connected can be found in the application on p. 15.

Quality objectives

The following table lists goals and requirements that are intended to help stakeholders in the operation and user experience of the services.

IDPrioQuality TargetExplanation
Q-12PerformanceThe system processes user requests as instantaneously or asynchronously as possible, so that the users have no delay in their workflow.
Q-21FlexibilityNew functions can be added without much effort. New services can be integrated.
Q-31SecurityUser data is not changed during processing, data protection is taken into account. User data remain the property of the user.
Q-42CorrectnessThe user guidance and understanding of the functionalities is comprehensible for non-technical departments and meets the expectations.
Q-53ContinuousThe user guidance has a continuous sensible workflow or the users can use their own workflow.
Q-63TransparencyThe processing of data is designed transparently and the software is provided as open source.
Q-71MonitoringAll services and orders and their status can be viewed at any time.

Legend: Priority scale 1 (particularly valuable) to 4 (to be aimed at)

(TODO) add scenarios (see