Commit 94547b81 authored by Richard Olav Rud's avatar Richard Olav Rud
Browse files

Update

parent bce8df0d
# task5.1-SRS
# ATMO-ACCESS Task5.1-SRS
IEEE System Requirements Specification Template
......@@ -23,14 +23,10 @@ Table of Contents
* 2.7 [Assumptions and Dependencies](#27-assumptions-and-dependencies)
* [External Interface Requirements](#external-interface-requirements)
* 3.1 [User Interfaces](#31-user-interfaces)
* 3.2 [Hardware Interfaces](#32-hardware-interfaces)
* 3.3 [Software Interfaces](#33-software-interfaces)
* 3.4 [Communications Interfaces](#34-communications-interfaces)
* 3.2 [Software Interfaces](#33-software-interfaces)
* [System Features](#system-features)
* 4.1 [Interactive form](#41-interactive-form-1)
* 4.2 [4.2 Workflows](#42-workflows)
* [Other Nonfunctional Requirements](#other-nonfunctional-requirements)
* 5.1 [5.1 Safety and Security Requirements](#51-safety-and-security-requirements)
* 4.1 [Interactive form](#41-interactive-form)
* 4.2 [Workflows](#42-workflows)
* [Other Requirements](#other-requirements)
* [Appendix A: Glossary](#appendix-a-glossary)
......@@ -39,7 +35,7 @@ Table of Contents
### 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.
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 is not a QA tool, but and archiving and access tool to data that is currently not curated anywhere today. The goal 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.
### 1.2 Document Conventions
......@@ -48,14 +44,14 @@ This Document was created based on the [IEEE template for System Requirement Spe
### 1.3 Intended Audience and Reading Suggestions
* Programmers who will work on developing the software.
* Stakeholder who will need to validate the requirements, making sure they fullfill what is in the project description.
* Stakeholder who will need to validate the requirements, making sure they fulfill what is in the project description.
* Researchers who have or will perform TNA activities or campaign measurements.
### 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 infrastructures. 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 and data access.
In addition, data produced by the "Interactive time series analysis tool" (Task 5.3) would promote the use of the homeless data portal for data curation on user demand.
More information on the atmo-access project could be found [here](https://www.atmo-access.eu/project/work-packages/).
More information on the ATMO-ACCESS project could be found [here](https://www.atmo-access.eu/project/work-packages/).
### 1.5 References
* [ATMO-ACCESS project website](https://www.atmo-access.eu/)
......@@ -63,14 +59,14 @@ More information on the atmo-access project could be found [here](https://www.at
## Overall Description
### 2.1 Product Perspective
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 goal is to directly curate and store TNA and campaign 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 describe 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.
The homeless data portal will be a simple form based one-page application. The form will prompt multiple questions that the data provider will need to answer in order to describe 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.
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)
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 automate 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)
![Rough sketch of the components in the system](img/atmo-access-description.png)
Figure 1: Homeless data portal overview
### 2.2 Product Functions
......@@ -80,17 +76,18 @@ Figure 1: Homeless data portal overview
* Form:
* Open the website, fill in form with PI information and information describing the dataset or collection of dataset from TNA and/or campaign activities
* Feedback:
* User will recieve email confirmation and a link to the issue tracking system
* User will receive an email confirmation and a link to the issue tracking system
* Issue tracking system:
* Open issue tracking system, see "tickets" associated to a specific user, as well as the status
#### System View
* Form:
* Form information is stored and metadata from form selction is provided to the API of 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 thes metadata.
* If file is provide, the file will be saved to a secondary archive, to ensure backup and tracebility
* Form information is stored and metadata from form selection is provided to the API of 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 form metadata.
* If a file is provide, the file will be saved to a secondary archive, to ensure backup and traceability
* Feedback
* Issue tracking system will be "in-charge" of sending feedback upon creation and update of a specific issue.
......@@ -101,13 +98,14 @@ Figure 1: Homeless data portal overview
### 2.3 User Classes and Characteristics
It will be all type of users, not only users internal to the RIs. Can be users from both free external research projects, in addition to ATMO-ACCESS TNA.
Multiple type of users, not only users internal to the RIs. Can be users from both free external research projects, in addition to ATMO-ACCESS TNA.
For example:
* Researchers, data providers and technical staff that are part of campaigns and TNA activities.
* Data curators at each RI
* Developers who is working on the project and further developing the functionality
### 2.4 Operating Environment
Browser based application, should work on all operating systems and accross the most commonly used web-browsers.
Browser based application, should work on all operating systems and across the most commonly used web-browsers.
### 2.5 Design and Implementation Constraints
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​).
......@@ -116,14 +114,14 @@ The first version of the requirements specification will not include any specifi
User documentation will be created when the prototype of the portal is operational (estimated 1th of October 2022).
### 2.7 Assumptions and Dependencies
The application will run in the browser, and therefore it will not require any spcific dependencies to run.
The application will run in the browser, and therefore it will not require any specific dependencies to run.
## External Interface Requirements
### 3.1 User Interfaces
Details of the user interface design will be documented in a separate user interface specification (MS 5.2).
### 3.3 Software Interfaces
### 3.2 Software Interfaces
The "Homeless data portal" will need to connect to the issue tracking system through an API.
The "Homeless data portal" will need to connect to a secondary storage system through an API.
......@@ -175,38 +173,37 @@ The "Homeless data portal" will need to connect to a secondary storage system th
* Annual data
* Other, please specify
6. Is your data currently formatted and undergoing certain quality assurance criterias, or unformatted/not quality assured?
* Includes metadata and quality controlled data for defined critereas (processed data)
* Only partly include metadata or quality controlled data for defined critereas
6. Is your data currently formatted and undergoing certain quality assurance criteria, or unformatted/not quality assured?
* Includes metadata and quality controlled data for defined criteria (processed data)
* Only partly include metadata or quality controlled data for defined criteria
* Not formatted nor quality assured
7. Contact information
* first_name
* last_name
* organisation_name
* country_code
* delivery_point
* address_city
* administrative_area
* postal_code
* email
* position_name
8. Other relevant information?
9. Attach an file or example of your data
10. Speific constraints
* First name
* Last name
* Organization name
* Country code
* Delivery point
* Address city
* Administrative area
* Postal code
* Email
* Position name
8. Attach an file or example of your data (optional)
9. Specific constraints
* Embargo
* Licencing etc.
11. Is this a collection of datasets.
10. Is this a collection of datasets.
* Yes
* No
12. Expected volume of the data
11. Expected volume of the data
* Provide file or size of collection collection in mb
12. Other relevant information?
### 4.2 Workflows
......@@ -218,7 +215,7 @@ Within ACTRIS, the data submission & curation process is tracked in an issue tra
Below the workflow description and figure describing the ACTRIS In Situ workflow is included.
![ACTRIS InSitu workflow description](img/in-situ-workflow-description.png)
Table x: ACTRIS InSitu workflow description
Table 1: ACTRIS InSitu workflow description
![Workflow ACTRIS InSitu](img/actris-insitu-workflow.png)
Figure 2: ACTRIS InSitu workflow
......@@ -233,12 +230,8 @@ Figure 3: ACTRIS GRES workflow
![Workflow IAGOS](img/iagos.atmo-access.workflow.png)
Figure 4: IAGOS workflow
#### ICOS
## Other Requirements
### 5.1 Safety and Security Requirements
Storage of data and metadata must follow GDPR requirements.
### Appendix A: Glossary
* **Homeless Data:** Data resulting from research campaigns and TNA activities are normally not included into any data management and data curation system and activity. These data sets are “homeless data”, not associated with any long-term projects nor sustainable data centres. The objective of this task is to develop tools facilitating access to TNA data and campaign data for future use through long term, sustainable data centres”
* **Homeless Data:** Data resulting from research campaigns and TNA activities are normally not included into any data management and data curation system and activity. These data sets are “homeless data”, not associated with any long-term projects nor sustainable data centres. The objective of this task is to develop tools facilitating access to TNA data and campaign data for future use through long term, sustainable data centres”
\ No newline at end of file
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