README.md 16.8 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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

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)
    * 4.1 [System Feature 1](#41-system-feature-1)
    * 4.2 [System Feature 2 (and so on)](#42-system-feature-2-and-so-on)
  * [Other Nonfunctional Requirements](#other-nonfunctional-requirements)
    * 5.1 [Performance Requirements](#51-performance-requirements)
    * 5.2 [Safety Requirements](#52-safety-requirements)
    * 5.3 [Security Requirements](#53-security-requirements)
    * 5.4 [Software Quality Attributes](#54-software-quality-attributes)
    * 5.5 [Business Rules](#55-business-rules)
  * [Other Requirements](#other-requirements)
* [Appendix A: Glossary](#appendix-a-glossary)
* [Appendix B: Analysis Models](#appendix-b-analysis-models)
* [Appendix C: To Be Determined List](#appendix-c-to-be-determined-list)




## Revision History
| Name | Date    | Reason For Changes  | Version   |
| ---- | ------- | ------------------- | --------- |
Richard Olav Rud's avatar
Richard Olav Rud committed
54
| ROR     | 2021-09-14        | Intial revision                    |     0.1      |
55
56
57
58
|      |         |                     |           |
|      |         |                     |           |

## 1. Introduction
Richard Olav Rud's avatar
Richard Olav Rud committed
59
60
61

### 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.
62
63

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

66
### 1.3 Intended Audience and Reading Suggestions
Richard Olav Rud's avatar
Richard Olav Rud committed
67
68
69
70
71

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

72
### 1.4 Product Scope
Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
73
74
75
76
77

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


78
### 1.5 References
Richard Olav Rud's avatar
Richard Olav Rud committed
79
* [ATMO-ACCESS project website](https://www.atmo-access.eu/)
80
81
82

## Overall Description
### 2.1 Product Perspective
Richard Olav Rud's avatar
Richard Olav Rud committed
83
84
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
85
![Rought sketch of the components in the system](img/figure1.png)
Richard Olav Rud's avatar
Richard Olav Rud committed
86
87
Figure 1: Rough sketch

88
### 2.2 Product Functions
Richard Olav Rud's avatar
Richard Olav Rud committed
89
90
91

#### ATMO-ACCESS Homeless data portal

Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
92
##### Form elements
Richard Olav Rud's avatar
Richard Olav Rud committed
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
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

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
Update    
Richard Olav Rud committed
162
##### Form functionality
Richard Olav Rud's avatar
Richard Olav Rud committed
163
164
165

* Submit form: If file is provide, save file to archive. Metadata will be stored and triggers a given workflow.

Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
166
167
168
169
170
171
172
173
174
175
176
177
#### Workflows

Depending on the selected paramters and other relevant metadata from the "Homeless data portal" form, different workflows will be triggered.

##### ACTRIS
###### ACTRIS InSitu

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.

Figure ![Rought sketch of the components in the system](img/figure2.png)
Figure 2: Rough sketch:

Richard Olav Rud's avatar
Richard Olav Rud committed
178

Richard Olav Rud's avatar
Update    
Richard Olav Rud committed
179
180
181
##### IAGOS
##### ICOS
##### Other
Richard Olav Rud's avatar
Richard Olav Rud committed
182
183
184
185
186
187
188
189
190

##### Storage

* Possibility to store submitted metadata and files via forms to a archive for backup and tracebility.

##### E-mail and feedback service

**Summarize the major functions the product must perform or must let the user perform. Details will be provided in Section 3, so only a high level summary (such as a bullet list) is needed here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or object class diagram, is often effective.**

191
### 2.3 User Classes and Characteristics
Richard Olav Rud's avatar
Richard Olav Rud committed
192
193
194
195
196

* 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

197
### 2.4 Operating Environment
Richard Olav Rud's avatar
Richard Olav Rud committed
198
199
200
201
202
203

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

204
### 2.5 Design and Implementation Constraints
Richard Olav Rud's avatar
Richard Olav Rud committed
205
206
207
208
209

The application will be develop in python on an nginx server where deploy is handled by gitlab and jenkins...

**Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).**

210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
### 2.6 User Documentation
List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.
### 2.7 Assumptions and Dependencies
List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).
## External Interface Requirements
### 3.1 User Interfaces
Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.
### 3.2 Hardware Interfaces
Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.
### 3.3 Software Interfaces
Describe the connections between this product and other specific software components (name and version), including 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 (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.
### 3.4 Communications Interfaces
Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.
## System Features
This template illustrates organizing the functional requirements for the product by system features, the major services provided by the product. You may prefer to organize this section by use case, mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.
### 4.1 System Feature 1
Don’t really say “System Feature 1.” State the feature name in just a few words.
4.1.1   Description and Priority
 Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).
4.1.2   Stimulus/Response Sequences
 List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases.
4.1.3   Functional Requirements
 Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available.
Richard Olav Rud's avatar
Richard Olav Rud committed
233

234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
 Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.

### 4.2 System Feature 2 (and so on)

## Other Nonfunctional Requirements
### 5.1 Performance Requirements
If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.
### 5.2 Safety Requirements
Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the product’s design or use. Define any safety certifications that must be satisfied.
### 5.3 Security Requirements
Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.
### 5.4 Software Quality Attributes
Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.
### 5.5 Business Rules
List any operating principles about the product, such as which individuals or roles can perform which functions under specific circumstances. These are not functional requirements in themselves, but they may imply certain functional requirements to enforce the rules.

## 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.
### Appendix A: Glossary
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.
### Appendix B: Analysis Models
Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.
### Appendix C: To Be Determined List
Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they can be tracked to closure.