SRD SRS Document Sample

System Requirements Document
(SRD)
Prepared by: Glaciers_cci consortium

Contract: 400010177-8/10/I-AM
Name: Glaciers_cci-D5.1-SRD
Version: 1.0
Date: 12.07. 2012
Contact: Technical Officer:

Frank Paul Stephen Plummer
Department of Geography ESA ESRIN
University of Zurich
frank.paul@geo.uzh.ch
Contract: 4000101778/10/I-AM Name: Glaciers_cci-D51_SRD
Version: 1.0
System Requirements Date: 12.7. 2012
Document (SRD) Page: 2
Document status sheet
Version Date Changes Approval

V0.1 10.05.11 Document Initialisation
26.02.12 Update GIUZ
V0.3 27.02.12 Consolidation Gamma
V0.4 17.04.12 Integration of feedback from A. Chadwick and S. Plummer
and complemented with new information
V0.7 27.04.12 Integration of feedback from Gamma and GUIO
V0.8 14.06.12 Integration of Comments from Stephen Plummer 10.5.2012
19.06.12 Final input from Gamma, Eveo, GUIO included
10.07. 12 Final input from SEEL included
V0.9 12.07. 12 Final draft version fp
V1.0 Final full version
The work described in this report was done under ESA contract 4000101778/10/I-AM.
Responsibility for the contents resides with the authors that prepared it.
Author team:
Andreas Wiesmann (Gamma), Frank Paul (GIUZ), Christopher Nuth, Andreas Kääb (GUIO),
Thomas Nagler, Killian Scharrer (Enveo), Andrew Shepherd, Francesca Ticconi (SEEL),
Tazio Strozzi (Gamma)
Glaciers_cci Technical Officer at ESA:

Stephen Plummer
Version: 1.0
Table of Contents
1. Executive Summary ............................................................................................................. 4

2. Introduction .......................................................................................................................... 5
2.1 Background .................................................................................................................................... 5
2.2 Purpose of the document ............................................................................................................... 5
2.3 Approach and Key issues............................................................................................................... 6
2.4 Applicable Project Documents ...................................................................................................... 6
2.5 Reference Documents .................................................................................................................... 6
3. General Description ............................................................................................................. 7
3.1 System Context and High-Level Requirements ............................................................................. 8
3.2 Scenarios ...................................................................................................................................... 13
4. Data Storage Requirements............................................................................................... 17
4.1 General Considerations ................................................................................................................ 17
4.2 Sizing Requirements .................................................................................................................... 17
5. Production Requirements .................................................................................................. 20
5.1 Production .................................................................................................................................... 20
5.2 Reprocessing ................................................................................................................................ 21
5.3 Performance Requirements .......................................................................................................... 22
6. Quality Control Requirements .......................................................................................... 24
7. Monitoring and Control Requirements............................................................................ 25
7.1 Logging Requirements................................................................................................................. 25
7.2 Processing Control Requirements ................................................................................................ 25
8. Data Services Requirements .............................................................................................. 26
8.1 Data Access ................................................................................................................................. 26
8.2 Data Import .................................................................................................................................. 26
9. Other Requirements ........................................................................................................... 27
9.1 Operational Requirements ........................................................................................................... 27
9.2 Design and Development Requirements...................................................................................... 27
9.3 Verification Requirements ........................................................................................................... 28
10. Requirements Traceability .............................................................................................. 30
10.1 Statement of Work ..................................................................................................................... 30
10.2 User Requirements..................................................................................................................... 30
10.3 Product Specifications Document .............................................................................................. 30
10.4. Data Access Requirements Document ...................................................................................... 31
10.5 Best Practice .............................................................................................................................. 31
10.6 Scenario ..................................................................................................................................... 31
11. References ......................................................................................................................... 32
12. Acronyms .......................................................................................................................... 32
Version: 1.0
1. Executive Summary
This document is the full version of deliverable D5.1 (System Requirements Document) of
the Glaciers_cci project. Its purpose is to provide a structured definition of the requirements
on the end-to-end processor in an operational context.
Version: 1.0
2. Introduction
2.1 Background
The ESA CCI (Climate Change Initiative) stresses the importance of providing a higher
scientific visibility to data acquired by ESA sensors, especially in the context of the IPCC
(Intergovernmental Panel on Climate Change) reports and GCOS requirements. This implies
producing consistent time series of accurate ECV products, which can be used by the climate,
atmospheric and ecosystem scientists for their modelling efforts. Another aim is the archiving
of long-term observations and the links to 3rd party ECV data.
The Glaciers_cci project will address three types of products for the glaciers and icecaps
ECV: glacier outlines (area) as the primary product along with surface elevation changes
(ELC) and velocity (VEL) information as additional products.
The CCI programme will be progressively built up in three major phases. In Phase I a
prototype of the ECV system shall be built and requirements analysis (this document) and
system specifications shall be produced for the operational concept. Phase II implements the
operational systems defined in Phase I and undertake the ECV production. In Phase III the
scientific community feedback is expected on the overall impact of the CCI programme
results.
2.2 Purpose of the document

This is the System Requirements Document (SRD) of the Glaciers_cci project. It documents
the requirements for an End-to-End Processor System for each of the products as far as
feasible. The documents listed in Section 2.4 have been used as a source of information.
The SRD provides a structured definition of the characteristics of the complete end to-end
processor in an operational context and is a complete, structured collection of individual
requirements of the operational ECV production system from a user’s point of view. It
includes:
 a description of the scope and the context of the system
 descriptive operational scenarios for the system
 Specification of key parameters that define the required system size, complexity and
growth
 a specification of the number, type and qualification of users/operators and the nature
of their use of the system
 a complete list of functional, operational, reliability, maintainability, verification,
quality and documentation requirements
 detailed requirements for the processing functions, input-output data sets, resource
requirements including disk and memory storage volumes,
 archiving requirements (baseline data and interim products and outputs and their
safeguarding to allow for reprocessing)
 processing speed and performance requirements
 requirements for modularisation to allow for algorithm improvement or algorithm
change while minimising reprocessing temporal constraints, any fundamental
interdependencies with other systems, e.g. hosting platform or infrastructure.
Version: 1.0
The document is compiled by the System Engineers and commented and reviewed by the EO
Science Team.
2.3 Approach and Key issues

The aim of this document is to collect all requirements on the Glaciers_cci Processing System
(PS). Sources are the SOW with its Annex, the project proposal, the first project deliverables
(in particular the URD and PSD), and the CCI project guidelines.
The processing algorithms and output products are being defined to some degree in parallel to
this document. This affects some key areas such as the system performance and sizing.
Therefore the document is updated continuously but it is also kept generic to be independent
from the details of the algorithms to be implemented. When appropriate and necessary TBC
(To Be Confirmed) and TBD (To Be Defined) has been used.
At present even high-level CCI System requirements are not yet available. The specification
of the CCI System is ongoing using the available SRDs of the individual ECV projects. The
first goal will be to formulate high-level requirements. A purpose of this document is
therefore to provide high-level requirements for Glaciers_cci.
The requirements have a 3 level identifier GL-TYPE-ID. The GL stands for Glaciers_cci. The
type defined similarly as e.g. in the Ocean Colour SRD:
FUN functional
PER performance
SIZ sizing
INT interface
OPE operational
RAM availability, maintainability, security
The ID is a 4-digit number.
2.4 Applicable Project Documents
[AD-1] ESA Climate Change Initiative Phase 1 - Scientific User Consultation and Detailed
Specification - Statement of Work
2.5 Reference Documents
[RD-1] Glaciers_cci-D1.1-URD V1.1 11.10.2011

[RD-2] Glaciers_cci-D1.2_PSD V1.0 20.11.0211
[RD-3] CCI project guidelines
[RD-4] Glaciers_cci-D1.3_DARD
Version: 1.0
3. General Description
The Glaciers_cci project is focused on the glacier-related products: glacier outlines, surface
elevation changes, and velocity information. This implies the production of consistent, stable,
and error-characterised products, covering the 30-year period with available Landsat data
from 1984 to 2013.
The Glaciers_cci PS has to consider the following issues for each of the products:
 Data archive
 Data production
 Data services
Data archiving contains the need to retrieve and store the input data, auxiliary products (e.g.
DEMs), intermediate products from the applied algorithms, and output data (final products).
The data production deals with the generation of the final products, including meta-data and
log files. The data services issue is related to data accessibility of the final products for the
scientific community. For the first issue it has to be considered that for all products mandated
repositories exist (e.g. LPDAAC for USGS Landsat data, NSIDC for ICESat) so that the PS
only has to consider the datasets that are required for data production. For the glacier area
product there is also an established (freely accessible) repository for the final product, the
GLIMS glacier database hosted at NSIDC. Similar outlets for the elevation change (likely
WGMS database) and velocity (likely GLIMS database) products have yet to be defined.
Before diving into the glaciers specific requirements it has to be kept in mind that some effort
is made on ESA side to harmonize the various System requirement Documents (SRDs) and
also formulate common CCI requirements. While at this stage no specific requirements are
available some efforts and goals need to be kept in mind. One important question for the
design of the ocean colour (OC) system is the sharing of infrastructure, resources or functions,
or their independence. One option, favoured by the 2011 CCI collocation and the OC team, is
an approach depicted below in Fig. 1. Selected common services may be offered for sharing
among ECVs. Among them are a backup archive for the data, cloud services that can be used
by other ECVs, and outsourced hosting for bulk download. However, this is an initial
framework upon which more concrete solutions can be developed. The allocation of functions
and the degree to which basic services can be shared needs to be defined. An important issue
in this context is also the funding of such a service provision.
The common data access layer shared among all ECVs provides harmonised access to CCI
data for climate modellers (see Fig. 1). This shall lower the barrier for climate users to use
several of the ECVs. The individual production and data environments per ECV are close to
the scientific groups to support an agile, continuous development and nimble reaction to
issues with short cycles. The production environments are optimised for re-processing and
validation. Strict versioning ensures production of stable product releases. Optionally, sharing
of an environment by production and development allows for access to long time series also
for the scientific improvement cycle.
Version: 1.0
Fig. 1: Common data access and de-centralized production environments.
Another common topic identified in the Systems Engineer Working Group is the versioning
and improvement cycle. A favourite approach is suggested by the SST_cci Science Leader C.
Merchant and shown in Fig. 2.
Fig. 2: Model improvement and product versioning (by C. Merchant for SST_cci).
3.1 System Context and High-Level Requirements

As described in the URD [RD-1], the high-level requirement for the glacier area product is a
global glacier inventory. Creation of this product requires consideration of several
components that are closely interrelated. The resulting overall system context is depicted
schematically in Fig. 3. The system has four main components (1) space agencies (data
providers), (2) the GLIMS community (data producers), (3) various user groups (data users),
and (4) repositories for the generated data sets (data archives).
Version: 1.0
Fig. 3: General context of the system for the glacier area product. The given resolutions of
grid products (100 m, 10 km) refer only to orders of magnitude. The processing tools and the
supporting information will be developed and provided by Glaciers_cci.
In more detail, the four components are:

 Space agencies and other mandated organizations will provide the required input data
sets (satellite data and DEMs in appropriate formats) for product generation
 Based on supporting information and given processing tools, the GLIMS community
will perform the data processing (periodic survey or filling gaps in the existing data).
 The interested user groups will download the generated data products, use them in
their respective applications, and will give feedback (e.g. on data quality) to the data
producers
 The products will be archived within the system of the mandated organizations
(GLIMS/WGMS) and required updates will be communicated to data providers and
data producers
Based on the general context developed for the glacier area product (cf. Fig. 3), the following
set of hierarchic system requirements were identified:
GL-FUN-0010 The Glaciers_cci system shall provide tools and guidelines to generate a
global glacier inventory. They should allow to complement and improve the
existing inventory, but also to create more consistent data sets.
Version: 1.0
GL-INT-0020 Its creation shall be coordinated with advice from a strategic operations
team. This team need to be in close contact with the relevant organizations
(e.g. GTN-G (WGMS, GLIMS, NSIDC), GTOS/GCOS, CEOS, GCW).
GL-INT-0030 The global GLIMS community shall play an active role in its creation
according to given guidelines and advice from a strategic operations team.
They shall also give feedback from the implementation to the strategic team.
GL-FUN-0040 The system shall implement a data production line that is sufficiently
flexible to continously update and extend the database (e.g. with data from
new sensors or better acquisitons).
GL-INT-0050 The available data shall be frequently reported and properly disseminated to
the interested user communities.
Glaciers_cci will also create glacier elevation change (ELC) and velocity (VEL) products (see
GL-FUN-0060). As these products are more science driven, only GL-FUN-0040 and GL-
INT-0050 applies and the general system context of these two products is more hierarchical
(Fig. 4). Data users (e.g. the glaciological community) shall give a feedback on the products.
Fig. 4: General context of the Glaciers_cci system for the glacier elevation change (ALT) and
velocity products (OPT: optical, MW: microwave, ALT: altimetry).
Version: 1.0
Schematic processing workflows for all three products are illustrated in Figs. 5 (area), 6 and 7
(elevation change), and 8 (velocity) in more detail. The graphs demonstrate that each of the
products requires a rather specific treatment.
Fig. 5: High-level workflow for the glacier area product.
Fig. 6: High-level workflow for the elevation change from DEM differencing product.
Version: 1.0
Satellite
Altimeter DEM
Archive hDEM
halt
check the projection of the input data

and convert to a common one if
necessary
interpolate the DEM for determining

the elevation at each footprint location,
h’DEM
group h’DEM into seasons (3- month

epochs)
create a reference grid-space

resampling the DEM
for each season compute the

difference:
dh=halt - h’DEM
create time-series grids of the

difference dh (with a cell of the same
size of the reference grid)
apply measurement density thresholds
apply statistical filtering (median, 3-s

clipping) on the time-series grids
calculate the dh/dt trend through a

glacier mask
regression approach
dh/dt map
Fig. 7: High-level workflow for the elevation change from satellite altimetry product.
Version: 1.0
Fig. 8: High-level production diagram for the velocity products. Left: SAR offset tracking,
right: image matching with optical data.
Overall, the PS developed by Glaciers_cci will generate three different products.
GL-FUN-0060 The Glaciers_cci system shall generate three different products:

1. Glacier Area (area)
2. Glacier Elevation Change (ELC)
3. Glacier Velocity (VEL)
3.2 Scenarios
In the following, scenarios for CCI phase 2 and optionally beyond are identified and
discussed. The basis is the available prototype. Discussed aspects are available sensors,
generated products, the interaction between ECVs and users, and features to improve the
products and the processes. In the discussion a Minimal (Min), an Advance (Adv) and an
Ideal (Ide) scenario are considered. This section needs to be updated when more information
becomes available and is in its current state just considered as a first draft.
3.2.1 EO data availability

EO data availability scenarios are listed in the following per product. Note that these are
preconditions to run the system rather than requirements for the system itself.
Version: 1.0
Glacier area
Min: as in 2011 - Landsat type sensor with regular acquisition and free download
- everything orthorectified with the DEM used available as well
- easy to use data browser (minimum standard: glovis.usgs.gov)
Adv: as Min + improved orthorectification of scenes in the archive & extension of the
archive with scenes from not yet included data holders (e.g. Eurimage)
replacement or update, respectively, of Landsat 5/7 with LDCM/Sentinel 2
- operational coverage of all glacierised regions during melt season
Ide: automated feed when good data for a missing/poor region were acquired
 free availabilty of historic outlines from national mapping agencies
ELC (altimetry)
Min: as in 2011
- Archived laser altimeter data (ICESat)
Adv: - as min + automated feed when data for a glaciated region were acquired;
- operational coverage of all glaciated regions;
Ide: - introduction of Cryosat and Sentinel 3 data
VEL (OPT):
Min: as in 2011 - Landsat / ASTER type sensor with regular acquisition and free download
- orthorectified with the DEM used available as well
- easy to use data browser (minimum standard: glovis.usgs.gov)
Adv: as Min + replacement or update, respectively, of Landsat 5/7 or ASTER with
LDCM/Sentinel 2
- operational coverage of all glacierized regions during melt season with
suitable gain settings
Ide: automated feed when good data for a missing/poor region were acquired
VEL (microwave):
Min: as in 2011
- archived SAR data (ERS-1/2, ENVISAT, Radarsat-1/2, TerraSAR-X, ...) for
reprocessing
- programming with VHR SAR data (TerraSAR-X, Radarsat-2, Cosmo-
SkyMed)
- easy to use data browser
Adv: - operational coverage of all glacierized regions
Ide: - automated feed when image pair data for a glacierized region is acquired
GL-FUN-0110 The PS shall include Sentinel 2 and LDCM products.

Version: 1.0
3.2.2 DEM data availability

A DEM is required in the production of the glacier area, ELC and VEL products.
Min: as in 2011 free availability of global data sets with easy access and clear description
Adv: as Min + including TanDEM-X data, acquisition date / processing clearly reported
regional coverage extended to all polar regions
Ide: free availability of historic DEMs from national mapping agencies
The new global DEM currently produced from TanDEM-X acquisitions will extend the
coverage of the currently available global DEMs and will have a higher quality.
GL-FUN-0120 The PS shall include the capability to ingest TanDEM-X products when
available.
3.2.3 Product generation
Glacier Area
Min: as in 2011: free availability of scripts / tools and instructions for consistent processing
Adv: Min + illustrated guidelines to improve consistency
more automated and improved algorithms (debris, shadow, cloud detection)
Ide: outlines produced operationally and are only quality checked
ELC (altimetry)
Min: as in 2011: manual extraction of the laser data over a specific glacier from the full
archive; manual import of this extraction and manual import of DEM
Adv: min+quality attributes
Max: automatic extraction of the laser data from the archive and its ingestion; automated
search of the most update DEM; automated flagging of potential quality attributes
VEL (OPT)
Min: as in 2011: manual reading-in of scene pairs, automated matching
Adv: Min + flagging of outliers (or quality attributes)
Ide: fully automated ingestion and offset tracking of manually or automatically selected
scene pairs + automated flagging of potential outliers (or quality attributes); operator
driven production of displacement subsets, e.g. based on glacier outlines
3.2.4 Product availability
Glacier area
Min: meta data browser (to see what is available and who has contributed what)
Adv: annual reporting on database status/statistics, usage and key regions to be considered
Ide: automated web-based refreshing of status, multiple format choices
Version: 1.0
ELC (altimetry)
Min: meta data browser of available data sets
Adv: min + annual reporting on database status/statistics, usage and key regions to be
considered
Max: adv + automated web-based refreshing of status, multiple format choices
VEL(OPT)
Min: meta data browser of available data sets
Adv: Min + annual reporting on database status/statistics, usage and key regions to be
considered
Ide: Adv + automated web-based refreshing of status, quicklooks of offset fields, multiple
format choices
3.2.5 User interaction
General
Min: user surveys of data and sites to be processed (with priority),
improved citation requirements
Adv: user feedback on processing requests and priorities (web form),
regular update of the database status quo, meta-data browser available
Ide: automated processing of scenes/regions requested by users
GL-FUN-0160 The PS shall provide a user feedback functionality.

Version: 1.0
4. Data Storage Requirements

4.1 General Considerations
The main purpose of the Data Archive is to provide a long-term storage for all the glacier
products produced by the PS, but also all input and auxiliary data. The input data can also
reside in a ground segment (e.g USGS glovis or ESA EOLI). In that case the PS has to ensure
the links are maintained and functionality is checked regularly.
GL-FUN-1010 All data stored in the system shall be available for the long-term (at least 15
years).
GL-FUN-1011 If input data is retrieved directly from a third party ground segment, the PS
has to ensure that links are maintained and functionality is regularly
checked.
It is essential to differentiate products even if they cover the same temporal series using the
same inputs.
GL-FUN-1020 The Products shall be uniquely identified.
GL-FUN-1030 The PS shall store data in a structured way using type, revision, date.
GL-RAM-1050 The PS shall provide means against data loss of its input / output products.
4.2 Sizing Requirements

Sizing is directly related to the amount of data processed and generated. The following data
categories are considered:
1. Input products
2. Auxiliary data
3. Output products
The main difficulties/error sources in estimating the size of the data are that the input data are
dependent on the algorithm and the unpredictable data compression ratio. For the time being
data compression is not taken into account. The provided file sizes are considered for one
product. e.g. if a global glacier inventory shall be updated regularly, its about 2 TB of input
data for each update. The same applies to the output created.
Version: 1.0
Full specifications of the sensors and data to be used for product generation (including their
access conditions) are described in the Data Access Requirements Document (DARD) [RD-
4].
4.2.1 Input Products

According to [RD-1] the glacier products will be based on:
Product Main Input Data Additional Input Data Data Size (uncompressed)
Area Landsat TM/ETM+ none (Google Earth) 300 (1000) MB per full scene
c. 2000 scenes globally (2 TB)
Elevation DTM (SRTM, GLS, Cryosat2, GLAS depends on source (resolution)
Change (DD) USGS, national) about 100-500 MB per DEM, 2
DEMs required for an elevation
change.
Elevation ICESat GLAS DEM (SRTM, GDEM2) or depends on source (resolution)
Change (ALT) better about 100-500 MB per DEM.
Velocity (OPT) Landsat TM/ETM+, DEM (SRTM, GDEM2, GLS) 300 (1000) MB per full scene.
ASTER, SPOT, Sentinel-2 or better At least 2 scene coverages
required. for each displacement
period (2 x 2000 scenes; 4 TB).
Velocity (MW) TSX, ENVISAT + ERS, DEM of sufficient quality 100 MB per full raw scene
PALSAR
Table 1: Input data description.
GL-SIZ-1110 The PS shall provide storage space for its input products of about 10 TB.
4.2.2 Auxiliary Data
According to [RD-2] the glacier products will need the auxiliary data:
Product Main Auxiliary Data Data Size

Area DEM (SRTM, GDEM2, GLS) depends on source (resolution),
about 100-500 MB per scene
Elevation Change DEM depends on source (resolution),
about 100-500 MB per scene, 2
grids per scene = 200-1000 MB
Velocity DEM (only MW) depends on source (resolution),
about 100-500 MB per scene
Table 2: Auxiliary data description.
Version: 1.0
GL-SIZ-1120 The PS shall provide storage space for its auxiliary data of about 2 TB.
4.2.3 Output Products

According to [RD-2] the following Level 3 glacier products will be produced:
Product Main Output Format Data Size

Area Outline in shapefile format < 10 GB (globally complete)
Attributes in GLIMS format
Elevation Change (ELC) Maps of elevation change (geotiff) Mean Depending on source (resolution),
value per glacier (text) about 100-500 MB per scene (grid)
Time series at point locations (text)
Velocity (VEL) MW: Displacement in geotiff and vector Grid format: about 300 MB
format (point location) depending upon window size
OPT: two-dimensional displacement (dx, Vector data: about 10 MB per scene
dy) with quality attribute (CC, SNR, filter
result); vector format.
Per file: input scenes, algorithm and version
Table 3: Output data description.
GL-SIZ-1130 The PS shall provide storage space for its output products of about 5 TB.
Documentation of the products is an important issue and was also explicitly stated in the
Appendix to the SOW
GL-FUN-1140 To facilitate the use of these data by the climate research community, a self-
standing 6-8 pages explanation of the products shall be generated. This shall
detail the algorithm, input data, description of the processing steps,
geophysical data product content, flags, metadata, data format, grid,
software tools for decoding and exploiting the data.
Version: 1.0
5. Production Requirements
The PSD is the reference for all product specifications.
5.1 Production
The PS shall produce products in agreement with the PSD.
GL-FUN-2110 The PS shall produce glacier outlines (inventory data) compliant with the
GLIMS database (GDB) format specifications.
GL-FUN-2111 The PS shall produce elevation changes in agreement with WGMS (sheets
D and EEE) requirements.
GL-FUN-2112 The PS shall produce velocity information over glaciers in agreement with
GDB or the WGMS requirements. (TBD)
For assimilation in climate models, the glacier area product has also to be produced in
netCDF format.
GL-FUN-2120 The PS shall produce the area product (global map of glacier-covered area)
in netCDF format and compliant with the CF metadata standards.
The CCI Data Standards Working Group (DSWG) is also generating requirements that apply
to all ELCVs. While not yet fully formalised at the time of writing, they include detailed
requirements on metadata, both usage (CF-compliance) and discovery (Unidata metadata
discovery standard), and on versioning and full traceability (probably via a UUID). These
requirements can be expected to become a part of the PSD for each ELCV, possibly just
referring to DSWG documents. These ultimately resolve into system requirements to follow
CCI project data standards and to support versioning and traceability. Only one product (a
global map of glacier-covered area) will be produced by Glaciers_cci for that purpose.
Full specifications of the sensors and data to be used for product generation (including their
access conditions) are described in the DARD [RD-4].
GL-FUN-2130 The PS shall use the input data as outlined in the DARD.
Version: 1.0
In the URD it states that the glacier inventory data created by Glaciers_cci will include full
topographic information for each individual glacier according to the guidelines prepared by
Paul et al. (2009).
GL-FUN-2140 The glacier area product shall be produced according to the guidelines given
in Paul et al. (2009).
From the Annex to the SoW
GL-OPE-2150 A hierarchical approach shall be taken to the production of the glacier

products based on their complexity, data availability and contribution to the
worldwide glacier inventory. Priority is on data availability, contribution
(community request), complexity.
To ease update implementation
GL-RAM-2160 Where possible, calibration and other values should be configurable to

facilitate easier processing updates.
From the Appendix to the Statement of Work (SoW):
GL-FUN-2170 The PS shall include the generation of consistent quantified errors and
biases per pixel for the subsequent use of the glacier products in climate
impact studies and water resource management models.
5.2 Reprocessing
Various reasons can make reprocessing necessary. The two most important are improved
input data or algorithms and change assessment. Therefore reprocessing is a requirement:
GL-FUN-2210 The PS shall have the capability to reprocess already successfully processed
products as well as products generated with errors in a transparent and
comparable way.
GL-FUN-2211 The PS shall have the capability to reprocess already successfully processed
products with new data for change assessment.
Version: 1.0
Also the availability of proper input data is crucial:
GL-FUN-2220 The PS shall store its input data optimised for reprocessing, i.e. in such a
way that storage is not a bottleneck for reprocessing.
Reproducibility of products requires documentation of input data and algorithms
GL-RAM-2230 All output products will contain sufficient information to ensure full
traceability of any product to all inputs involved in its generation.
5.3 Performance Requirements

The performance requirements for glacier area are more related to human resources than to
computer power, hard disk capacity or software. For a system that should provide a global
update of glacier outlines all ten years, one can determine the effort by dividing the number of
glaciers by the required workload for creating an outline. Of course, both numbers largely
differ as the numbers of glaciers is highly ill-defined (e.g. depend on the minimum size
considered) and glacier size varies over six orders of magnitude (resulting in very different
editing times). As a starting point and based on the available literature, we assume that we
have 250’000 glaciers globally and each glacier requires a 5 min workload. This gives 2600
days of work (8 hours per day), or 11 years (240 days per year for one person). As the work is
largely performed by a global consortium of experts with regional knowledge (maybe 50)
contributing to GLIMS, a decadal repeat interval is at least feasible. Of course, payment of the
work is done by a variety of (third party) projects, and a long-term (or governmental) funding
is in general not secured. As a most important part of the system, database maintenance has to
be considered.
Considerable improvements in the quality of the glacier outlines for debris-covered glaciers
can be expected when coherence images (acquired over summer) from microwave sensors are
included in the processing system. However, sufficient contrast was only given for ALOS
PALSAR image pairs and this sensor is no longer available. We thus exclude this additional
input dataset here from being a part of the processing system.
The processing system for glacier elevation changes from DEM differencing is related to
the tools that implement specific algorithms to merge the various DEMs. Selection of the
DEMs from the global archives (ASTER, SPOT, SRTM, TanDEM-X etc) requires initial
expert investigation to determine whether DEM quality is feasible for change detection.
Provided two Global DEMs are available, with a large time step inbetween, DEM selection
has the potential to be automated though with expert intervention at a later stage. Co-
registration and re-sampling (merging the DEMs) will have to be performed in small
subsections surrounding glaciers in order to minimize constructive/destructive overlay of
various scale biases that may exist. Co-Registration can be performed automatically for each
local subsection, but has to be analyzed by experts afterwards to determine if any further
adjustments are required. Depending upon the size of the sample selection, co-registration
Version: 1.0
should not require more than 5 min (considering the feasibility of using smaller sample sizes),
while the manual post-processing and analysis could require anywhere from 30 min (i.e. no
other adjustment required) to 1 week (i.e. further bias adjustments necessary). The latter are
are strongly related to the DEM acquisition systems and will typically have to be analyzed
and developed for adjacent local subsections (regionally). Finally, the entire processing chain
should be performed within one system, as switching between systems to perform different
tasks increases the potential to induce new (mis-registration) biases.
The surface elevation change system from altimetry data has to able to initially process
measurements of elevation from the existing ICESat/GLAS archive (GLA06 data level) and
then to update it based on new forthcoming data (e.g. Sentinel-3, Cryosat). The initial step
required is the processing of the ICESat/GLAS archive in order to extract the acquisitions
performed on the glacier of interest. Subsequently it is necessary to extract from the relative
files, available in a binary format, the information needed for running the elevation change
repeat track algorithm (i.e. date of acquisition, geografic coordinates, elevation, correction to
apply, gain). This selection and data extraction takes on average about 15 min (once the full
archive is available), using the NGAT software provided by the NSIDC. This pre-processing
step is specific for the ICESat/GLAS data, but it is necessary to take into consideration a
similar pre-processing procedure for the new data of the Sentinel-3 and the Cryosat missions.
In addition, the selection of the DEM over the glacier of interest is necessary. The DEM
chosen constitutes the surface of reference for providing a time-series of relative
measurements of elevation. The surface elevation change system has to be able to provide the
information contained in the DEM in a grid format of 1 km x 1 km, independently on how the
DEM has been created, on its spatial resolution and the format used to saved the data. This
will be the cell size of the reference grid used to provide the elevation change map. The
system also needs to provide a glacier mask of the area under analysis. An additional
performance requirement is the creation of a time series of elevation measurements at each
grid cell with a seasonal sampling interval.
The glacier velocity system from optical data has to be able to initially process displacement
fields from the existing Landsat archives and then update annually based on new data (e.g.
Sentinel-2). For the initial processing, the archives have to be investigated by an expert to
select the most suitable image pairs for offset tracking. For each Landsat path/row this
selection might take about 15 min. For a number of the ca. 2000 glacierized Landsat path/row
tiles image matching might not work properly due to local clouds or strong changes. If not
available as a L1T product, the selected scenes have to be ordered and downloaded. In an
automated step, selected scene pairs then have to be matched and filtered, and result statistics,
quicklooks and metadata to be produced.
For glacier velocity from microwave data the same system as for the optical data will be used,
as the general set-up of the processing steps and the output product is very similar. Of course,
the details of the pre-main and post processing differ, but temporal requirements for each
processing step, computational resources and required human interaction are rather similar to
the optical data described above.
Version: 1.0
6. Quality Control Requirements

Quality control is an important aspect in product generation. This section aims at assuring
consistent generation of products and early detection of numerical problems in the datasets.
Early detection of erroneous data saves time and resources. The requirements ensure the
necessary capabilities for the scientific quality of the generated products.
From the Appendix of the SOW:
GL-RAM-3110 Strict quality control procedures shall be followed during processing: the
production shall be interrupted and the implementation checked and
corrected if the resulting products do not meet previously agreed (scientific)
quality standards. This shall include internal quantitative validation tests for
each processing step.
Comment on product accuracy

For the glacier area product, uncertainty information is a mandatory entry in the attribute table
for each glacier when submitting the outlines to GLIMS. However, this value is difficult to
determine as appropriate reference data are often not available. The given values are thus
generally based on results from more detailed assessments in previous studies (e.g. +/-1 pixel)
rather than the dataset under consideration. For assimilation of the product in climate or
hydrological models with a focus on regional or global scale modeling, the somehow
uncertain error characterization is unproblematic, as the spatial resolution of the models (km)
by far exceed the product accuracy. Of a much higher imporatnce for these applications is
spatial completeness.
In regard to the GL-RAM-3110 requirement for the system, it has to be added that visual
control and (if required) correction of all glacier outline products is a core part of the data
production process, for glacier area as well as for the other products (see Fig. 4). The current
production system for glacier area (the GLIMS Analysis Tutorial) already includes this step.
Version: 1.0
7. Monitoring and Control Requirements

7.1 Logging Requirements
A good logging and reporting system is invaluable in operational systems for proper error
detection.
GL-FUN-4010 The PS has a logging mechanism
GL-RAM-4020 The following events and parameters must be reported:

a) start of processing
b) end of processing
c) significant processing events
d) termination status (terminated safely, aborted etc)
GL-RAM-4040 The following significant processing events shall be reported:

a) input data missing, corrupt or invalid
b) product cannot be fully produced
c) product generation failed
7.2 Processing Control Requirements

Processing controls are needed in an operational system. Information is needed in order to
transparently control the processing:
GL-INT-4110 The PS provides information of the processing status:

a) Status (in progress, finished, stopped)
b) Progress
c) Errors
Version: 1.0
8. Data Services Requirements

Data service requirements are split in:
 Data Access services

 Data Import services
8.1 Data Access

Data access services are necessary to provide the scientific community access to the data
products.
GL-INT-5010 The PS provides a web site presenting the objectives of the project and
describing data access.
The GLIMS database is freely accessible via the internet (http). As the database is meanwhile
integrated in the LPDAAC, long-term maintenance is guaranteed. The required data storage
volume is actually very low and the database structure is well documented so that it can also
be copied to other hosting services. Depending on user needs or future requirements by ESA
also other channels such as THREDDS (http://www.unidata.ucar.edu/projects/THREDDS/)
might have to be considered.
GL-INT-5020 Data access shall be through the Internet.
8.2 Data Import

Data import services are necessary to incorporate new (not yet processed) input data to the
PS.
GL-INT-5510 There is a possibility to inject new input data into the system.
GL-RAM-5520 Data import is logged.

Version: 1.0
9. Other Requirements
9.1 Operational Requirements
The aim is a PS that works in an autonomous manner. Ideally the system is able to process
end-to-end without operator intervention. However, the glacier product chains will also
depend in the near future on operator decisions and therefore on operator interaction.
GL-FUN-6010 The PS has an interface for commanding all the subsystems, including
archive and data services. This commanding interface can be a command
line interface (CLI) or graphical user interface (GUI).
Data Safety:
GL-FUN-6020 The operational processor shall not overwrite existing data. Versioning shall
be used instead.
9.2 Design and Development Requirements

In accordance with the SoW [AD-1], the PS must be cost effective. A way to achieve this is to
avoid the fees to be paid for COTS (Commercial off-the-shelf) software and IPRs
(Intellectual Property Rights). Also, maintenance costs and operational costs are to be
considered.
GL-OPE-6310 Software re-use shall be limited as much as possible to Public Domain

software
GL-OPE-6320 The PS design shall ensure minimal maintenance and operational costs.
The version used in the PS must be known at all times for traceability and error tracking:
GL-OPE-6330 Development of the PS shall be under version control.
In order to have a defined system independent of individual interests the PS shall be

decoupled from research (and the prototype).
GL-OPE-6340 The system should be decoupled from the own research.

Version: 1.0
The PS should be flexible in order to be able to include new sensor data, a new item in the
product specification or a new algorithm at a later stage.
GL-INT-6340 The PS shall have the capability and interfaces to extend for future
adaptations.
The Annex to the SoW held some important requirements on the system development:
GL-OPE-6410 Development of the system shall be based on the the user requirements, the
selected algorithms and the validation protocols used to generate the
baseline products for the worldwide glacier inventory.
GL-OPE-6411 The system shall be developed including all necessary steps for generating
each product with the potential to produce the complete set of parameters
(e.g. drainage divides and topographic attributes) for each glacier.
The data and the processing system must be well documented and retrievable, so that another
person or institution can take over the system.
GL-RAM-6420 The system developed shall be detailed as a separate self-standing document

providing an overview of the system and its components, functionality of
the system and its subsystems, inputs, outputs, resource key interfaces, and
resource requirements.
GL-OPE-6430 The PS development shall be overseen by a science team that drives the
development process interacts with the GLIMS community and is using the
system to improve and evaluate methods and algorithms.
9.3 Verification Requirements

A set of tests shall be included for the prototype-systems to check interfaces and integration
between (stand-alone) components. These tests will only apply to the end-to-end systems to
be developed (e.g. not to the glacier area and ELC-dDEM products).
GL-OPE-6610 Each PS installation includes a set of test tools, data and benchmark data to
test PS integrity (end-to-end, interfaces)
Version: 1.0
Verification Success Criteria:
GL-OPE-6611 The verification is regarded as successful, when all tests agree within TBD
limits.
Verification Documentation:
GL-RAM-6611 The verification shall be documented in a Verification Report. It shall

contain the chosen approach and the justification, the selected verification
data set and the verification results.
As indicated in Section 3 versioning and improvement cycles must be possible and the new
PS module must be validated against the corresponding prototype. Therefore the prototype
state has to be frozen until the module passed the validation.
GL-OPE-6620 If a module is based on a prototype, the prototype state has to be frozen until
it is implemented.
From the Appendix to the SOW:
GL-FUN-6710 Verification of the correct implementation of the prototype system against

the algorithms developed in Task 2 is a fundamental part of the process.
Version: 1.0
10. Requirements Traceability

This section traces input requirements to sections of the document (§) or to particular
glacier_cci system requirements (GL-xxxx) that implement them.
10.1 Statement of Work

Title Reference
Scope and context of the system §3.1
Descriptive operational scenarios §3.2
Key parameters §3.1
Users and operators §8.1
§9.1
Production requirements §5
Processing functions, input, output §5.1
Archiving requirements §4.1
Processing speed and performance §5.3
Modularisation, improvement, interdependencies §9.2
10.2 User Requirements

Title Reference
Error specification §9.1
Spatial and temporal resolution §5.1
Accuracy and precision §5.1
Products/variables §3.1
Formats and access §8.1
Tools §3.2.3
Quality control §9.3
10.3 Product Specifications Document

Title Reference
Glacier Area §3.1
§4.2.3
Glacier Elevation Change §3.1
§4.2.3
Glacier Velocity §3.1
§4.2.3
Version: 1.0
10.4. Data Access Requirements Document

Title Reference
Glacier Area §8.1
Glacier Elevation Change §8.1
Glacier Velocity §8.1
In-situ datasets §8.1
10.5 Best Practice

Title Reference
EO science team GL-OPE-6430
Product versions GL-FUN-120
GL-FUN-1030
Optimised for repeated reprocessing GL-FUN-2220
10.6 Scenario
Title Reference
Sensor §3.2
Products and variables §3.2
ECV cross-fertilisation TBD
Reprocessing capability GL-FUN-2220
Improvement cycle TBD
Interaction with users GL-FUN-0160
Version: 1.0
11. References
Paul, F., R.G. Barry, J.G. Cogley, H. Frey, W. Haeberli, A. Ohmura, C.S.L. Ommanney, B.
Raup, A. Rivera, M. Zemp (2009): Recommendations for the compilation of glacier inventory
data from digital sources. Annals of Glaciology, 50 (53), 119-126.
12. Acronyms
AD Applicable Document
ALT Altimetry
ATBD Algorithm Theoretical Basis Document
CCI Climate Change Initiative
CDR Climate Data Record
DARD Data Access Requirements Document
dDEM DEM differencing
DEM Digital Elevation Model
ECV Essential Climate Variable
ELC Elevation Change
ELCSS European Committee for Space Standardisation
EO Earth Observation
ESA European Space Agency
ESRIN European Space Research Institute
GCOS Global Climate Observing System
GDB GLIMS Database
GLIMS Global Land Ice Measurements from Space
IPR Intellectual Property Rights
LPDAAC Land Processes Distributed Active Archive Center
MW Microwave
NSIDC National Snow and Ice Data Center
OC Ocean Colour
OPT optical
PS Processing System
PSD Product Specification Document
RD Reference Document
SAR Synthetic Aperture Radar
SLC Single Look Complex Radar Image
SoW Statement of Work
SRD System Requirements Document
URD User Requirements Document
USGS United States Geological Survey
UUID Universally Unique Identifier
VEL Velocity
WGMS World Glacier Monitoring Service

SRD SRS Document Sample

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRD SRS Document Sample

Uploaded by

Copyright:

Available Formats

System Requirements Document

Prepared by: Glaciers_cci consortium

Contact: Technical Officer:

Document status sheet

Version Date Changes Approval

Glaciers_cci Technical Officer at ESA:

1. Executive Summary ............................................................................................................. 4

2.2 Purpose of the document

2.3 Approach and Key issues

2.4 Applicable Project Documents

2.5 Reference Documents

[RD-1] Glaciers_cci-D1.1-URD V1.1 11.10.2011

Fig. 1: Common data access and de-centralized production environments.

3.1 System Context and High-Level Requirements

In more detail, the four components are:

Fig. 5: High-level workflow for the glacier area product.

check the projection of the input data

interpolate the DEM for determining

group h’DEM into seasons (3- month

create a reference grid-space

for each season compute the

create time-series grids of the

apply measurement density thresholds

apply statistical filtering (median, 3-s

calculate the dh/dt trend through a

Overall, the PS developed by Glaciers_cci will generate three different products.

GL-FUN-0060 The Glaciers_cci system shall generate three different products:

3.2.1 EO data availability

GL-FUN-0110 The PS shall include Sentinel 2 and LDCM products.

3.2.2 DEM data availability

3.2.3 Product generation

3.2.4 Product availability

3.2.5 User interaction

GL-FUN-0160 The PS shall provide a user feedback functionality.

4. Data Storage Requirements

GL-FUN-1020 The Products shall be uniquely identified.

4.2 Sizing Requirements

4.2.1 Input Products

4.2.2 Auxiliary Data

Product Main Auxiliary Data Data Size

4.2.3 Output Products

Product Main Output Format Data Size

From the Annex to the SoW

GL-OPE-2150 A hierarchical approach shall be taken to the production of the glacier

To ease update implementation

GL-RAM-2160 Where possible, calibration and other values should be configurable to

From the Appendix to the Statement of Work (SoW):

Also the availability of proper input data is crucial:

Reproducibility of products requires documentation of input data and algorithms

5.3 Performance Requirements

6. Quality Control Requirements

From the Appendix of the SOW:

Comment on product accuracy

7. Monitoring and Control Requirements

GL-FUN-4010 The PS has a logging mechanism

GL-RAM-4020 The following events and parameters must be reported:

GL-RAM-4040 The following significant processing events shall be reported:

7.2 Processing Control Requirements

GL-INT-4110 The PS provides information of the processing status:

8. Data Services Requirements

 Data Access services

8.1 Data Access

GL-INT-5020 Data access shall be through the Internet.