README.md 9.65 KB
Newer Older
Richard Olav Rud's avatar
Richard Olav Rud committed
1
2
# task5.1-SRS

3
4
5
IEEE System Requirements Specification Template

# Software Requirements Specification
Richard Olav Rud's avatar
Richard Olav Rud committed
6
7
8
9
10
## 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
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

Table of Contents
=================
  * [Revision History](#revision-history)
  * [Introduction](#1-introduction)
    * 1.1 [Purpose](#11-purpose)
    * 1.2 [Document Conventions](#12-document-conventions)
    * 1.3 [Intended Audience and Reading Suggestions](#13-intended-audience-and-reading-suggestions)
    * 1.4 [Product Scope](#14-product-scope)
    * 1.5 [References](#15-references)
  * [Overall Description](#overall-description)
    * 2.1 [Product Perspective](#21-product-perspective)
    * 2.2 [Product Functions](#22-product-functions)
    * 2.3 [User Classes and Characteristics](#23-user-classes-and-characteristics)
    * 2.4 [Operating Environment](#24-operating-environment)
    * 2.5 [Design and Implementation Constraints](#25-design-and-implementation-constraints)
    * 2.6 [User Documentation](#26-user-documentation)
    * 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)
  * [System Features](#system-features)
Richard Olav Rud's avatar
Richard Olav Rud committed
35
36
    * 4.1 [Interactive form](#41-interactive-form-1)
    * 4.2 [4.2 Workflows](#42-workflows)
37
  * [Other Nonfunctional Requirements](#other-nonfunctional-requirements)
Richard Olav Rud's avatar
Richard Olav Rud committed
38
    * 5.1 [5.1 Safety and Security Requirements](#51-safety-and-security-requirements)
39
40
41
42
43
44
  * [Other Requirements](#other-requirements)
* [Appendix A: Glossary](#appendix-a-glossary)

## Revision History
| Name | Date    | Reason For Changes  | Version   |
| ---- | ------- | ------------------- | --------- |
Richard Olav Rud's avatar
Richard Olav Rud committed
45
| ROR     | 2021-09-14        | Intial revision                    |     0.1      |
Richard Olav Rud's avatar
Richard Olav Rud committed
46
|  ROR    | 2021-09-29         |   Second revision                  |    0.2       |
47
48
49
|      |         |                     |           |

## 1. Introduction
Richard Olav Rud's avatar
Richard Olav Rud committed
50
51
52

### 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.
53
54

### 1.2 Document Conventions
Richard Olav Rud's avatar
Richard Olav Rud committed
55
56
This Document was created based on the [IEEE template for System Requirement Specification Documents](https://doi.org/10.1109/IEEESTD.1996.81000).

57
### 1.3 Intended Audience and Reading Suggestions
Richard Olav Rud's avatar
Richard Olav Rud committed
58
59
60
61
62

* 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.
* Researchers who have or will perform TNA activities or campaign measurements.

63
### 1.4 Product Scope
Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
64
65
66
67
68

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.)


69
### 1.5 References
Richard Olav Rud's avatar
Richard Olav Rud committed
70
* [ATMO-ACCESS project website](https://www.atmo-access.eu/)
71
72
73

## Overall Description
### 2.1 Product Perspective
Richard Olav Rud's avatar
Richard Olav Rud committed
74
75
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.

Richard Olav Rud's avatar
Richard Olav Rud committed
76
![Rought sketch of the components in the system](img/figure1.png)
Richard Olav Rud's avatar
Richard Olav Rud committed
77
78
Figure 1: Rough sketch

79
### 2.2 Product Functions
Richard Olav Rud's avatar
Richard Olav Rud committed
80

Richard Olav Rud's avatar
Richard Olav Rud committed
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
* Form: If file is provide, save file to archive. Metadata will be stored and triggers a given workflow, should include feedback and email functionality.
* Workflows: Depending on the selected paramters and other relevant metadata from the "Homeless data portal" form, different workflows will be triggered.
* Storage: Possibility to store submitted metadata and files via forms to a archive for backup and tracebility.

### 2.3 User Classes and Characteristics

* 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. As a minimum requirement, the application should be tested in the following web-browsers:
* Chrome
* Safari
* Firefox

### 2.5 Design and Implementation Constraints
The "Homeless data portal" application will be develop in python on an nginx server where build and deploy is handled by gitlab and jenkins.

### 2.6 User Documentation

### 2.7 Assumptions and Dependencies

## 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
Describe the connections between the "Homeless data portal" and the other specific software components that are related to RI specific tools. This includes everything we believe should be a integrated part of the "Homless data portal2 e.g. databases, operating systems, tools, libraries, and integrated commercial components.

Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way, specify this as an implementation constraint.

## System Features

### 4.1 Interactive form
Richard Olav Rud's avatar
Richard Olav Rud committed
117

Richard Olav Rud's avatar
Richard Olav Rud committed
118
#### Form elements
Richard Olav Rud's avatar
Richard Olav Rud committed
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188

1. Atmospheric component(s) you are working with Immersive Reader
  * Aerosol
  * Greenhouse gases
  * Reactive trace gases
  * Clouds
  * Other

2. What specific kind of measurement data do you want to submit and archive for long term access? Immersive Reader
  * Gas concentrations/mixing ratio: Greenhouse gases (CO2, CH4, N2O)
  * Gas concentrations/mixing ratio: Greenhouse gases (halocarbons and other fluorinated gases)
  * Gas concentrations/mixing ratio: Reactive trace gases (VOC, NOxy, ozone, CO)
  * Aerosol properties: Ground based In-Situ aerosol optical, physical and chemical properties
  * Aerosol properties: Remote observations from ground – profiles
  * Aerosol properties: Remote observations from ground – total column
  * Cloud properties: Ground based In-Situ measurements
  * Cloud properties : Ground based remote sensing observations – profiles
  * Ballon?
  * Model?
  * Metrology

3. Observation type
  * Ground based In-Situ observations
  * Ground based Remote sensing observations
  * Aircraft measurements
  * Other mobile/moving platforms
  * Other, please specify

4. Location of measurements site(s)?
  * One country in Europe
  * Europe
  * Northern Hemisphere
  * Southern Hemisphere
  * Arctic regions
  * Antarctic region
  * Globally distributed
  * Asia
  * America

5. What is the nature of the data you would like to store? Immersive Reader
  * Campaign data
  * Annual data
  * Other, please specify

6. Is your data currently formatted and undergoing certain quality assurance criterias, or unformatted/not quality assured?  Immersive Reader
  * Includes metadata and quality controlled data for defined critereas (processed data)
  * Only partly include metadata or quality controlled data for defined critereas
  * 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
  * Embargo
  * Licencing etc.


Richard Olav Rud's avatar
Richard Olav Rud committed
189
### 4.2 Workflows
Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
190

Richard Olav Rud's avatar
Richard Olav Rud committed
191
#### ACTRIS
Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
192

Richard Olav Rud's avatar
Richard Olav Rud committed
193
##### ACTRIS InSitu
Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
194
195
New task: Data and metadata will be stored and email containing link to data curation tools will be sent to the data provider. A task will be created in the InSitu issue tracker system.

Richard Olav Rud's avatar
Richard Olav Rud committed
196
197
Figure ![Workflow ACTRIS InSitu](img/figure2.png)
Figure 2: ACTRIS InSitu workflow
Richard Olav Rud's avatar
Richard Olav Rud committed
198

Richard Olav Rud's avatar
Richard Olav Rud committed
199
##### ACTRIS CLU
Richard Olav Rud's avatar
Richard Olav Rud committed
200

Richard Olav Rud's avatar
Richard Olav Rud committed
201
##### ACTRIS ARES
Richard Olav Rud's avatar
Richard Olav Rud committed
202

Richard Olav Rud's avatar
Richard Olav Rud committed
203
#### IAGOS
Richard Olav Rud's avatar
Richard Olav Rud committed
204

Richard Olav Rud's avatar
Richard Olav Rud committed
205
#### ICOS
Richard Olav Rud's avatar
Richard Olav Rud committed
206

Richard Olav Rud's avatar
Richard Olav Rud committed
207
#### Other
208
209

## Other Nonfunctional Requirements
Richard Olav Rud's avatar
Richard Olav Rud committed
210
211
### 5.1 Safety and Security Requirements
Storage of data and metadata must follow GDPR requirements.
212
213
214

## Other Requirements
Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.
Richard Olav Rud's avatar
Richard Olav Rud committed
215

216
### Appendix A: Glossary
Richard Olav Rud's avatar
Richard Olav Rud committed
217
Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS.