Commit 1de246aa authored by Richard Olav Rud's avatar Richard Olav Rud
Browse files

Update text to be non-technical

parent d92e3321
...@@ -4,10 +4,6 @@ IEEE System Requirements Specification Template ...@@ -4,10 +4,6 @@ IEEE System Requirements Specification Template
# Software Requirements Specification # Software Requirements Specification
## For Task 5.1 Development of online tools for data curation of homeless data ## For Task 5.1 Development of online tools for data curation of homeless data
Version 0.1 approved
Prepared by Richard Rud
NILU - Norwegian Institute for Air Research
2021-09-14
Table of Contents Table of Contents
================= =================
...@@ -43,7 +39,7 @@ Table of Contents ...@@ -43,7 +39,7 @@ Table of Contents
### 1.1 Purpose ### 1.1 Purpose
The purpose of this document is to present a detailed description of the homeless data portal and the underlying RI specific tools for data curation, QC and archiving of data. Furthermore, the document will present the features and interface of the application, what the application will do, as well as constraints related to RI specific tools and workflows. The document is intended for stakeholders in the projects, developers and users of the application. The purpose of this document is to present a detailed description of the homeless data portal and the underlying RI specific tools for data curation, QC and archiving of data. Furthermore, the document will present the features and interface of the application, what the application will do, as well as constraints related to RI specific tools and workflows. The document is intended for stakeholders in the projects, developers and users of the application.
This is not a QA tool, but and archiving and access tool to data that is now not curated anywhere. The crucial point is to document the homeless data through rich meta data to document quality, and provide access. This is not a QA tool, but and archiving and access tool to data that is currently not curated anywhere today. The crucial point is to document the homeless data through rich meta data to document quality, and provide access.
This tool is for data that is not regularly produced within the RIs, but as an offer to research projects and TNA activities, making sure that also this data is available for future use. This tool is for data that is not regularly produced within the RIs, but as an offer to research projects and TNA activities, making sure that also this data is available for future use.
### 1.2 Document Conventions ### 1.2 Document Conventions
...@@ -58,17 +54,22 @@ This Document was created based on the [IEEE template for System Requirement Spe ...@@ -58,17 +54,22 @@ This Document was created based on the [IEEE template for System Requirement Spe
### 1.4 Product Scope ### 1.4 Product Scope
The homeless data portal is a tool to help those who collect data from TNA activities and campaigns with long-term storage of data at relevant research infrastructure. The goal of the tool is to make more data available to the end-user, as well as benefits for data collectors in terms of usage tracking and access to RI specific tools for curation as well as data access. The homeless data portal is a tool to help those who collect data from TNA activities and campaigns with long-term storage of data at relevant research infrastructure. The goal of the tool is to make more data available to the end-user, as well as benefits for data collectors in terms of usage tracking and access to RI specific tools for curation as well as data access.
(*Refer here also to the project description.) More information on the atmo-access project could be found [here](https://www.atmo-access.eu/project/work-packages/).
### 1.5 References ### 1.5 References
* [ATMO-ACCESS project website](https://www.atmo-access.eu/) * [ATMO-ACCESS project website](https://www.atmo-access.eu/)
## Overall Description ## Overall Description
### 2.1 Product Perspective ### 2.1 Product Perspective
The homeless data portal will be developed for everyone collecting atmospheric composition data during TNA and campaign activities. The homeless data portal will be a form based application that will route requests for data curation and storage to specific RIs based on the provided metadata in the forms. The goal is then to directly curate and store TNA and campain datasets or if a dataset is not directly supported by the relevant RI, establish bi-lateral contact with the data curation team at a given RI. The homeless data portal will be developed for everyone collecting atmospheric composition data during TNA and campaign activities.
The goal is to directly curate and store TNA and campain datasets in long-term repositories.
The homeless data portal will be simple form based one-page application. The form will prompt multiple questions that the data provider will need to answer in order to described their data. Based on the description and metadata selected in the form, the application will automatically route the request to the relevant RI. If it is not clear from the answers in the form which RI the data belongs to, a combined effort will be made.
All requests will end up in a issue tracking system, where tasks are delegated to data curators at the specific RIs.
![Rought sketch of the components in the system](img/figure1.png) In addition, it should be possible for the different RIs, to connect their specific data curation workflows to the API of the issue tracking systems, in cases where it is possible to aumotate parts of the data curation process. A more detailed explanation of RI specific workflows are available [here](#42-workflows)
![Rought sketch of the components in the system](img/atmo-access-description.png)
Figure 1: Rough sketch Figure 1: Rough sketch
### 2.2 Product Functions ### 2.2 Product Functions
...@@ -80,24 +81,22 @@ Figure 1: Rough sketch ...@@ -80,24 +81,22 @@ Figure 1: Rough sketch
* Feedback: * Feedback:
* User will recieve email confirmation and a link to the issue tracking system * User will recieve email confirmation and a link to the issue tracking system
* Issue tracking system: * Issue tracking system:
* Open issue tracking system, see "tickets" associated to a users request for providing data * Open issue tracking system, see "tickets" associated to a specific user, as well as the status
#### System View #### System View
* Form: * Form:
* Form information is stored and metadata from form selction is provided to the API of the issue tracking system * Form information is stored and metadata from form selction is provided to the API of the issue tracking system
* Workflows: Depending on the selected paramters and other relevant metadata from the "Homeless data portal" form, different workflows will be triggered in the issue tracking system. * Workflows: Depending on the selected parameters and other relevant metadata from the "Homeless data portal" form, different workflows will be triggered in the issue tracking system.
* Form will trigger storage of data in those cases where the data provider wants to provide examples or send the whole dataset together with the metadata. * Form will trigger storage of data in those cases where the data provider wants to provide examples or send the whole dataset together with thes metadata.
* If file is provide, save file to archive. Metadata will be stored and triggers a given workflow, should include feedback and email functionality. * If file is provide, the file will be saved to a secondary archive, to ensure backup and tracebility
* Storage: Possibility to store submitted metadata and files via forms to a archive for backup and tracebility.
* Feedback * Feedback
* Issuetracking system will be "in-charge" of sending feedback upon creation and update of a specific issue. * Issue tracking system will be "in-charge" of sending feedback upon creation and update of a specific issue.
* Issue tracking system
* Functionality of issue tracking system should be treated like a black-box
#### Research Infrastructure (RI) View #### Research Infrastructure (RI) View
* RI will look through the request for providing data and accept/decline in the issue tracking system * RI will look through the request for providing data and accept/decline in the issue tracking system
* RI will provide all feedback through the issue tracking system * RI will provide all feedback through the issue tracking system
* It should be possible for RI to utilize issue tracking API for integrating the data curation process with their internal workflow and data curation tools.
### 2.3 User Classes and Characteristics ### 2.3 User Classes and Characteristics
...@@ -107,14 +106,10 @@ It will be all type of users, not only users internal to the RIs. Can be users ...@@ -107,14 +106,10 @@ It will be all type of users, not only users internal to the RIs. Can be users
* Developers who is working on the project and further developing the functionality * Developers who is working on the project and further developing the functionality
### 2.4 Operating Environment ### 2.4 Operating Environment
Browser based application, should work on all operating systems and accross the most commonly used web-browsers. As a minimum requirement, the application should be tested in the following web-browsers: Browser based application, should work on all operating systems and accross the most commonly used web-browsers.
* Chrome
* Safari
* Firefox
* Edge
### 2.5 Design and Implementation Constraints ### 2.5 Design and Implementation Constraints
E.g. The "Homeless data portal" application will be develop using vue.js on an nginx server where build and deploy is handled by gitlab and jenkins. The first version of the requirements specification will not include any specific information on design and implementation. This will be handled in MS5.2 (Mockups of services presented to user panels) and MS5.3 (Prototype services presented to user panels​).
### 2.6 User Documentation ### 2.6 User Documentation
User documentation will be created when the prototype of the portal is operational (estimated 1th of October 2022). User documentation will be created when the prototype of the portal is operational (estimated 1th of October 2022).
...@@ -128,21 +123,14 @@ The application will run in the browser, and therefore it will not require any s ...@@ -128,21 +123,14 @@ The application will run in the browser, and therefore it will not require any s
Details of the user interface design will be documented in a separate user interface specification (MS 5.2). Details of the user interface design will be documented in a separate user interface specification (MS 5.2).
### 3.3 Software Interfaces ### 3.3 Software Interfaces
The "Homeless data portal" will only connect to the Mantis issue tracking system through the Mantis API and a file storage system, preferably cloud based like one drive or nextcloud. The "Homeless data portal" will connect to the issue tracking system through an API
The "Homeless data portal" will connect to a secondary storage system through an API
Mantis Bug Tracker REST API: https://documenter.getpostman.com/view/29959/mantis-bug-tracker-rest-api/7Lt6zkP
**To be considered:**
OneDrive API for python: https://github.com/OneDrive/onedrive-sdk-python
Python wrapper for NextCloud API: https://github.com/matejak/nextcloud-API
**Will need to describe connection the connection through the Mantis API and workflow tools at the RI level, if this should be a part of the scope?** **Will need to describe connection the connection through the Mantis API and workflow tools at the RI level, if this should be a part of the scope?**
![Rought sketch of the components in the system](img/figure4.png) ![Rought sketch of the components in the system](img/atmo-access-description.png)
Figure x: Components and software interfaces Figure x: Components and software interfaces
## System Features ## System Features
### 4.1 Interactive form ### 4.1 Interactive form
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment