Functional and Non-functional

requirements for the INSPIRE

Dashboard
Table of Contents
1. The Purpose of the Project...................................................................................................2
2. The Stakeholders.................................................................................................................2
3. Mandated Constraints..........................................................................................................3
4. Naming Conventions and Terminology...............................................................................6
5. Relevant Facts and Assumptions.........................................................................................6
6. The Scope of the Work........................................................................................................6
7. The Scope of the Product.....................................................................................................7
8. Functional and Data Requirements......................................................................................8
9. Look and Feel Requirements.............................................................................................15
10. Usability and Humanity Requirements..........................................................................15
11. Performance Requirements............................................................................................16
12. Operational and Environmental Requirements..............................................................17
13. Maintainability and Support Requirements...................................................................18
14. Security Requirements...................................................................................................18
15. Cultural and Political Requirements..............................................................................18
16. Legal Requirements.......................................................................................................19
17. Open Issues....................................................................................................................19
18. Off-the-Shelf Solutions..................................................................................................19
19. New Problems................................................................................................................20
20. Tasks..............................................................................................................................20
21. Migration to the New Product........................................................................................21
22. Risks...............................................................................................................................21
23. Costs...............................................................................................................................21
24. User Documentation and Training.................................................................................21
25. Waiting Room................................................................................................................21
26. Ideas for Solutions.........................................................................................................22
 1. The Purpose of the Project

1. The User Business or Background of the Project Effort

At the first meeting of the INSPIRE Maintenance and Improvement Group
(MIG) a work package was instigated to investigate and create a “dashboard”
that allowed information from Member States (MS) to be automatically
extracted from metadata to support the MS in making the Annual Report to
INSPIRE. The group commissioned to do this work is called MIWP-16 and is
chaired by Paul Hasenohr. The group has considered the information held in
metadata and asked member states for information via a questionnaire. This
specification is a result of the questionnaire and the work of the Group.

2. Goals of the Project

To provide the EC/EEA/MS with an automatic Dashboard tool that provides
access to all monitoring information and related indicators for every Member
State. The Dashboard shall be extensible by MS to allow the MS to use the
Dashboard at a MS level.

2. The Stakeholders

1. The Client
EC/EEA

2. The Customer
Member States INSPIRE NCPs + EC/EEA

3. Other Stakeholders
Members of the MIG policy sub-group
Members of the MIG technical sub-group
Members of the MIG/MIWP-5 sub-group

4. The Hands-On Users of the Product

INSPIRE Reporters/NCPs/MIG policy members
Technical experts acting on behalf of the INSPIRE Reporters/NCPs/ MIG
policy sub-group
European Commission / EEA “policy” staff
2
 European Commission / EEA “technical” staff
Spatial data user community

5. Priorities Assigned to Users

Key users
INSPIRE Reporters, MIG-P, NCPs and their technical experts
EC and EEA staff
Secondary users
Spatial data user community
Tertiary users
Public at large

6. User Participation
Users from the “key user” user group identified above will be required to test
the product both in terms of these functional arrangements but also in terms of
usability.

7. Maintenance Users and Service Technicians

EEA or JRC IT staff
EC/EEA INSPIRE team

3. Mandated Constraints

1. Solution Constraints
Issue 1
 Description: The product shall be web-based.

Rationale: The users are diverse and need to be able to use the product
without installing any extra software on their computer.

Fit criterion: Users shall be able to use the product from an internet browser
(FF, Chrome, Internet Explorer). The developer shall indicate for each
supported browser what the minimum supported version of the browser is
supported.

Issue 2
Description: The product shall take as input for Ancillary information and extra
information (ref. diagram) data formatted in a way suitable also for the official
monitoring.

REQUIREMENTS_ANALYSIS_V02
3
 Rationale: Not all data needed by the dashboard can be retrieved through
Discovery services. The extra data to be provided to the dashboard is also
needed for the official monitoring therefore the same (XML) template should
be used. MS will not work with two different templates largely overlapping.

Fit criterion: Users shall be able to use the same (XML) template for the
dashboard and for the official monitoring.

2. Implementation Environment of the Current System

As this is a new system, the hosting environment is not yet well defined.
It will either be JRC or EEA. Specific requirements from hosting organization
to be taken into account.

There will be an EC/EEA central installation with extensions possible at central

node to meet MS needs. The code will be open-source and will rely on open-
source components to ensure possible reuse by Member States.

Decision on hosting at JRC or EEA to be taken by agreement between EEA

and JRC.

3. Partner or Collaborative Applications

• Linked to 3b. E.g. EEA has an online application
(http://daviz.eionet.europa.eu to generate graphs/charts etc.) which
would likely be used if the product is installed at EEA.

• An application to create/edit/merge XML files used for reporting is

maintained at EEA and routinely used:
http://webforms.eionet.europa.eu

• INSPIRE Discovery services in all MS and INSPIRE Geoportal

• Web services at MS level providing ancillary information [AI] to the MD

provided through discovery services or providing extra information [EI]
(e.g. description of metadata records not included in the discovery
service) as described in the figure of section 6.2

• Validation services available through API if/when they become

available.

4. Off-the-Shelf Software
No requirement identified so far about software that must be embedded in the
product.

4
 5. Anticipated Workplace Environment
Any standard office environment. No specific constraint.

6. Schedule Constraints
First version planned by the end of the year. This first version MUST be
usable to help a MS to fulfil their M&R requirements.

Considering that the purpose of this product is to support MS in the

production of the Monitoring and Reporting for calendar year 2014, the
product [input (AI, EI, Discov), output and indicator calculation modules]
shall have completed all testing and acceptance by the 15th December
2014.
By end March 2015, first version of the charts and maps part of the dashboard
shall be completed and tested.

All technical specifications applying to MS shall be ready by end of October

2014 in order to leave enough time for development/adaptation of services
(and also to have it included in the software development planning for 2015).

Thus, users shall be able to use the product to populate a significant

proportion of the Monitoring and Reporting (M&R) XML.

The first phase development indicates that what above will be done by the end
of 2014 according to the ToR, but it has been agreed to extend the work period
until end March 2015. Additional requirements and changes to metadata/M&R
requirements will be put forward by the MIWP-16 group to the MIG which may
require the dashboard to be updated.

7. Budget Constraints
EEA can contribute around 10k€ through a consulting company for a first
prototype.

MS contribute time and expertise.

Financing of the central dashboard to be discussed. This is also linked to the

decision on hosting (a tighter integration with existing components will reduce
costs). The possibility of reusing existing systems with marginal
customisations might have a great impact (dashboard developed by
Germany).

REQUIREMENTS_ANALYSIS_V02
5
 4. Naming Conventions and Terminology

1. Definitions of All Terms, Including Acronyms, Used in the Project

This should be an Annex or Appendix of this document. At a first step the
names of the reporting measures should be included here.
Also Acronyms from this document should also be included.

2. Data Dictionary for Any Included Models

5. Relevant Facts and Assumptions

1. Relevant Facts
Participation in the dashboard is voluntary. It is not envisioned that there will
be a charge made for use of the product – either to the EU/EEA or the MS.

Data provided to the dashboard by a MS (and the indicators derived from

those data) cannot be used by the EC in lieu of the official monitoring of this
MS (driven by Commission Decision 2009/442/EC) unless the MS explicitly
requests it.

2. Assumptions
The on going INSPIRE evaluation (process?) will not alter significantly the
need and purpose of the dashboard.

The adoption of the dashboard will positively impact on the current INSPIRE
automation process.

EEA or JRC agrees to host the dashboard.

A process for dashboard development is established.

A process for dashboard maintenance is established.

6. The Scope of the Work

1. The Current Situation

At present the MS are required to make reports to the EC on the use of
INSPIRE within the MS. The collation of this information is both complex and
time consuming with information being manually collated from returns from
data providers and publishers.

6
 2. The Context of the Work
As identified in Section 1, the MIG has requested that MIWP-16 consider how
the collation and production of the reports for MS can be automatically (if this
is achievable) extracted, stored in some way and then displayed as a
dashboard.

Harvesting MD + AI Validation
MS MD date + access results from all
MD UID to history for relevant
Discov
same UID MIWP-5 tests
id. MD id.
id. id.
AI id. EI (nb of N/A
MS
UID complaints)
Ancillary info MD
Discov id. EI (e.g. N/A
dataset
without
metadata)
EI Facetted search: MS, Annex, Theme,

calculate
Validation results, Conformance declared, Service type

MS
Extra info
EI MDi DSi NSi
MS1 MS1/MS1 MS1
MS2 MS2 MS2
AI: service protected, service statistics, dataset area...
EI: value for an indicator, description of a dataset/service without metadata

3. Work Partitioning
List of business events to which the work/product responds.
TBD

7. The Scope of the Product

1. Product Boundary
Out of the product:
• Generation or editing of XML files related to EI and AI [an online tool is
available for this at EEA and the dashboard could link to it]
 Generation or editing of harvested metadata

2. Product Use Case Table

- MS registers/tests/configures the discovery services and AI/EI endpoints
 MS configures a scheduled harvesting or an ad-hoc harvesting
REQUIREMENTS_ANALYSIS_V02
7
  MS uploads ad-hoc AI/EI
 System computes indicators periodically and stores the result
 System validates metadata periodically and stores the result
 System validates spatial data sets periodically and stores the result [not
now]
 System validates network services periodically and stores the result
[not now]
 A policy end-user wants to have an overview of indicators and
underlying variables at EU and MS level (+ regional if configured by
MS?)
 A ‘spatial data user community’ end-user wants to search through all
records by MS, spatial data theme, etc. and read the validation status
reported by MS and the corresponding automatic validation reports
coming from MIWP-5 [not now].
 An INSPIRE reporter wants to see at MS level the differences in time.
What was the situation last year, what is difference between the
situation this year. But also between two arbitrary dates.

3. Individual Product Use Cases

8. Functional and Data Requirements

1. Functional Requirements
Requirement Aalborg1

Description: The dashboard should provide the possibility to have indicators

calculated at different dates and when the latest available data underpinning
an indicator is available. Furthermore availability of underlying data on long
term should be guaranteed.

Requirement: UK1 [low]

Description: The dashboard should have some high level information as part
of the starting display (these will need to be defined) and mechanisms to allow
for the drilling into further detail.
The “High Level” information may be at all MS level and then information could
be drilled into by MS or by measure.

Rationale: To provide a “simple” starting display for the policy type of user

8
 Fit criterion: …

Requirement: SE1

Description: The dashboard shall store all [indicators on areas should not be
visualised] monitoring information submitted by the Member States, year by
year

Rationale: to retrieve monitoring information from different Member States,

themes and years in a simple and comparative way, for further analysis and
dissemination

Fit criterion: The information in the dashboard should correspond to the

information in the monitoring Excel-sheet

Requirement: SE2

Description: The dashboard shall harvest periodically, or on request, the

required monitoring information from the INSPIRE Geoportal or from national
DISC services.

Rationale: to minimise the need for each Member State to carry out the
monitoring requirements

Fit criterion:

Requirement: SE3

Description: It shall be possible for the Member States to export content of the
dashboard for a specific date in XML following the Monitoring XML template.
Then MS can edit the XML in the web-forms application.

Rationale: MS can use the dashboard (in combination with other applications
as needed) to prepare their official monitoring report.

Requirement Aalborg 2

Description: Possibility to define an entry as official monitoring (either

snapshot of the content of the DB for one MS at a certain date or XML file
[conformant with the official Monitoring template] uploaded by MS)

Rationale: MS can use the dashboard (in combination with other applications
as needed) to prepare their official monitoring report.

REQUIREMENTS_ANALYSIS_V02
9
 Requirement: SE4

Description: It shall be possible to query the dashboard using selection

criteria’s (country, theme, year, organisation, etc.) through a web interface

Rationale: to allow a user to retrieve only information of interest for a particular

purpose, for instance number and names of datasets within the scope of a
particular theme

Fit criterion: …

Requirement: SE5

Description: The results of a query can be presented in tabular form in the web
interface. This does not exclude other representations.

Rationale: to provide a quick and readably overview of the results of a

particular query

Fit criterion: …

10
 Requirement: SE6

Description: Where possible and if required by the user, it shall be possible to

present the results graphically

Rationale: to get a graphic overview of the distribution of the results of a

particular query, for instance number of data sets reported by theme and
country

Fit criterion: …

REQUIREMENTS_ANALYSIS_V02
11
 Requirement: SE7

Description: It shall be possible to download the results of a query as an

Excel-file, XML, CSV, PDF...

Rationale: to allow the user to further process the results of a query

Fit criterion: …

Requirement: EEA2

12
 Description: It shall be possible to see for each data set or service its
metadata retrieved from the national DISCOV service or Inspire geoportal, its
declared conformity and its evaluated conformity (with associated report). It
must be made very clear that declared conformity and evaluated conformity (a
copy of the evaluation report from MIWP-5 should be available) are different
things (i.e. evaluated conformity has no legal value, only a matter of
interoperability).

Rationale: to allow advanced users to understand how to improve their

metadata / data / services

Fit criterion: …

Requirement: EEA3

Description: It shall be possible for a MS to extract from the dashboard an

XML file suitable for submission as official monitoring data.

Rationale: For some MS, the dashboard contains all the information which is
needed for the official monitoring therefore they should be able to reuse it. The
quality of the reported data is also greatly improved (no syntax error, no
creative editing of an XLS file etc.).

Fit criterion: …

Requirement: EEA4

Description: It shall be possible to compute and map indicators at regional

level if a MS wishes so and there is an unambiguous way to assign metadata
from this MS to a region.

Rationale: To allow MS to use the European dashboard for national purposes

Fit criterion: …

Requirement: EEA5

Description: It shall be possible to complement the metadata with Ancillary

Information and Extra Information (see chart in 6b)

Rationale: To circumvent the limitations arising from the sole use of metadata
and to allow MS to create ad-hoc indicators for national use.

Fit criterion: …

REQUIREMENTS_ANALYSIS_V02
13
 Requirement: EEA6

Description: It shall be possible to provide all indicator variables and the

indicators themselves as Extra Information (see chart in 6b).

Rationale: To allow MS to provide their own indicators in case they differ from
the ones calculated by the dashboard based on the data contained in it.

Fit criterion: …

Requirement: EEA7

Description: It shall be possible to compute new indicators based on the data

contained in the dashboard

Rationale: To allow MS to create ad-hoc indicators for national use and spatial
data user community to perform some analysis.

Fit criterion: …

Requirement: EEA8

Description: It shall be possible to store in the dashboard a snapshot of its

content at a certain time for a given MS

Rationale: To allow MS to keep a history of their monitoring status.

Fit criterion: …

2. Data Requirements

Parameters related to the operation of the dashboard

• Discovery services and AI/EI endpoints
• Filter parameters to retrieve the correct records from each discovery
service
• ...

Metadata records, Ancillary Information, Extra Information

Results of validations from MIWP-5 [not now]

Snapshots

14
Non-functional Requirements
The following sections 10-17 describe the non-functional requirements. The
form of these requirements is the same as for the functional requirements as
described above.

9. Look and Feel Requirements

1. Appearance Requirements
The dashboard shall comply with EEA or EC visual identity requirements.

2. Style Requirements

10. Usability and Humanity Requirements

This section is concerned with requirements that make the product usable and
ergonomically acceptable to its hands-on users.

1. Ease of Use Requirements

The product shall start up with a default front screen, that displays “high level”
detail. The details displayed need to be agreed. The information that is
displayed shall also relate to the user and the access to the data that they are
entitled to.

The user shall – with no training – be able to navigate the product in an

intuitive manner to allow them to drill into the detail of the information collected
by the tool.
The fit criterion is that a secretary without any training in using the tool could
get a graph of a given indicator for a MS.

2. Personalization and Internationalization Requirements

Given the use of the product by all MS in the EU, the product shall detect the
language in use by the user and self configure itself to that language. The
user shall have a facility to override this default behaviour and set the
language to any of the European languages. The selection of a language shall
have no effect on the displayed data.
Possible translations will have to be provided by MS.

3. Learning Requirements
For user of statistics and charts, no learning requirement.
REQUIREMENTS_ANALYSIS_V02
15
 For reporter (in charge of configuring the DB to connect to the MS endpoints),
a small learning curve is acceptable.

4. Understandability and Politeness Requirements

5. Accessibility Requirements
The product should aim to meet the W3C AAA requirement for Web Sites;
however this requirement can be scaled back to AA, for those screens that
use graphs or maps for which achieving the AAA rating would prove to be
expensive and counter to the visual impact we are looking for.

11. Performance Requirements

1. Speed and Latency Requirements

2. Safety-Critical Requirements

3. Precision or Accuracy Requirements

4. Reliability and Availability Requirements

The product shall be available 95% of the time.

5. Robustness or Fault-Tolerance Requirements

The product or its content shall not become corrupted if one or more of the
services it depends upon (e.g. database) becomes unavailable or because of
a system failure.
The product shall continue to operate (possibly in degraded mode) in case the
external services it interfaces with become unavailable or deliver incorrect
data (e.g. a discovery service from a MS is suddenly returning non
syntactically correct answers to the requests from the dashboard)

6. Capacity Requirements
The product supplied shall have enough capacity to process data from
Metadata for 10 times the current total number of the Discovery Datasets,
View and Download Services that are currently declared in the EU.

16
 The product should be able to handle at least 50 concurrent users out of which
20 are active.
The product should be able to harvest XXXX metadata records per hour [Ask
Angelo]

7. Scalability or Extensibility Requirements

The product should be modular.

8. Longevity Requirements
The product shall be expected to operate for a minimum of XXX years.

12. Operational and Environmental Requirements

1. Expected Physical Environment

N/A

2. Requirements for Interfacing with Adjacent Systems

The product shall work on the most used web browsers (IE9+ FireFox,
Chrome and Safari).
The product shall work with INSPIRE Discovery services.
Based on the decision on hosting and extension at central level or at MS level,
requirements might be added (e.g. interface with the EIONET authentication
system...)

DB should be able to get data either via pull with an authentication mechanism
(foresee use of HTTPS).

3. Productization Requirements

4. Release Requirements

REQUIREMENTS_ANALYSIS_V02
17
 13. Maintainability and Support Requirements

1. Maintenance Requirements

2. Supportability Requirements

3. Adaptability Requirements
The product (server part) is expected to run under Linux. Again, this will be
influenced by decision on hosting etc.
In order to facilitate the reuse by Member States, a cross-platform
implementation (e.g. servlet) would be preferable.

14. Security Requirements

1. Access Requirements
Only the MS reporter should have access to add missing or extra information.

2. Integrity Requirements

3. Privacy Requirements

4. Audit Requirements

5. Immunity Requirements

15. Cultural and Political Requirements

1. Cultural Requirements

18
 2. Political Requirements

16. Legal Requirements

1. Compliance Requirements
Description: The software produced will be open-source allowing the free re-
use of the product as required.

Rationale: Considering that MS may want to have the possibility to install (and
possibly extend) the software at their premises, creating the product with
COTS software would make it difficult or impossible.

Fit Criterion: Once created the Product will be deposited in a manner that
anyone that complies with the license for the Product can reuse it (this license
should be as open as possible – the only restriction that is envisaged is that
any updates to the product are licensed in the same way as the original
product).

2. Standards Requirements
Whenever applicable, INSPIRE IR, ISO standards and OGC specifications
shall be followed.

17. Open Issues

1.

18. Off-the-Shelf Solutions

1. Ready-Made Products

REQUIREMENTS_ANALYSIS_V02
19
 2. Reusable Components
The German registry client is available under a 3-clause BSD licence. If the
functionalities are ok, issues in terms of governance to be analysed...

3. Products That Can Be Copied

19. New Problems

1. Effects on the Current Environment

2. Effects on the Installed Systems

3. Potential User Problems

4. Limitations in the Anticipated Implementation Environment That

May Inhibit the New Product

5. Follow-Up Problems

20. Tasks

1. Project Planning

2. Planning of the Development Phases

20
 21. Migration to the New Product

1. Requirements for Migration to the New Product

2. Data That Has to Be Modified or Translated for the New System

22. Risks

• Lack of funding
• Issue with MIG-P
• MIWP-5 will not release a MD validator
• Risk of delay in development

23. Costs

24. User Documentation and Training

1. User Documentation Requirements

2. Training Requirements

25. Waiting Room

REQUIREMENTS_ANALYSIS_V02
21
 26. Ideas for Solutions

22