requirements catalogue - eionet portal · 1.0 05/12/2018 persefoni kampa incorporating final list...

TRASYS International

Requirements Catalogue

Scoping Study of Reportnet 3.0

Date: 24/05/2019 Doc. Version: v1.2

.

Date: 24/05/2019 2 / 27 Doc. Version: v1.2

Document Control Information

Settings Value

Document Title: Requirements List

Project Title: Scoping Study of Reportnet 3.0

Document Author: Persefoni Kampa

Leader: Spasojevic Dijana

Reviewer: Spasojevic Dijana

Project Owner (PO): Stefan Jensen

Business Manager (BM): Jonathan Maidens

Solution Provider (SP): Søren Roug

Project Manager (PM): Christian-Xavier Prosperini

Doc. Version: v1.2

Sensitivity: Public

Date: 24/05/2019

Document Approver(s) and Reviewer(s):

Name Role Action Date

Spasojevic Dijana Leader Review 05/12/2018

Christian Xavier

Prosperini

Project manager Review/Approve 13/12/2018

Jonathan Maidens Business manager Review/Approve 13/12/2018

Stefan Jensen Project owner Review/Approve 13/12/2018

Document history:

The Document Author is authorized to make the following types of changes to the document without

requiring that the document be re-approved:

Editorial, formatting, and spelling

Clarification

To request a change to this document, contact the Document Author or Owner.

Changes to this document are summarized in the following table in reverse chronological order (latest

version first).

Revision Date Created by Short Description of Changes

1.0 05/12/2018 Persefoni Kampa Incorporating final list of requirements.

1.1 11/12/2018 Deniz Aydemir Final revisions

1.2 20/05/2019 Eduardo Perdomo Changes made as per analysis and review

comments from the Reportnet 3.0 Development

Project Kick-off meeting

1.2 23/05/2019 Christian-Xavier Prosperini Approval of changes

Configuration Management: Document Location

The latest version of this controlled document is stored in

https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-

study/scoping-study-deliverables/requirements-catalogue-final.


TABLE OF CONTENTS

1. INTRODUCTION .....................................................................................................................................4

2. REQUIREMENTS MANAGEMENT PROCESS ..................................................................................4

3. TOOLS AND TECHNIQUES ..................................................................................................................5

3.1. REQUIREMENTS ELICITATION TECHNIQUES ..........................................................................5

3.2. REQUIREMENTS’ PRIORITISATION METHOD ..........................................................................6

4. REQUIREMENTS’ ATTRIBUTES DEFINITION ...............................................................................7

5. REQUIREMENTS LIST ..........................................................................................................................9

6. APPENDIX 1: REFERENCES AND RELATED DOCUMENTS ...................................................... 27


1. INTRODUCTION

In order to design and deliver a successful software product of high quality, it is important to collect and document a list of the requirements of the stakeholders involved. In order to assure quality, the requirements collected must be:

Clear

Concise

Consistent

Relevant

Unambiguous

Correct

Testable

Traceable

The purpose of this document is to outline the final set of requirements of the different stakeholders for the Scoping Study of the Reportnet 3.0 project, classified based on a set of attributes and prioritized to reach a common understanding between all involved parties on the importance of delivering each requirement.

2. REQUIREMENTS MANAGEMENT PROCESS

The requirements management process is the process of capturing, assessing and justifying what the stakeholders want and need; namely their requirements.

The first phase of the Scoping study for the Reportnet 3.0 project was the analysis of the “AS-IS” situation of the Reportnet 2.0 system. The main objectives of this phase was to launch the project, review and analyze the existing body of information related to the Reportnet 2.0 system and also to describe the existing business processes together with description of the IT systems that supply or use Reportnet. The outputs of this phase were the Business process evaluation and the Reportnet Architecture of As-Is document. These two deliverables served as an input for the second phase of the project, which aimed to define a set of high-level requirements.

Figure 1 - Scoping study project phases

However, the final set of high-level requirements was decided to be formed in two steps. The first one produced the initial version of requirements (V1) coming solely from the deliverables of the first phase of the project. The Requirements Catalogue V1 was shared among the core operational stakeholders (Reportnet 3.0 Steering Committee, Business Implementation Group, Project Core Team consisting of experts in the European Commission services and the EEA as well as IT consultants) in order to review them and provide useful feedback and additional requirements.

In parallel with the Scoping study, two other feasibility studies were conducted regarding the data harvesting using INSPIRE infrastructure and reporting directly to a database (the replacement of the files (XML) with a Database as a storage format). The second step in the requirements collection phase


(Phase 2) produced the final requirements version (V2) taking into account the results of the two aforementioned studies and the reviewed Requirements Catalogue V1. The Requirements Catalogue V2 was consulted among the broader Eionet and shared among National Focal Points (NFP), Reportnet 3.0 Steering Committee (RSC), Business Implementation Group (BIG), Advisers to the Steering Committee, Project Core Team (PCT) consisting of experts in the European Commission services and the EEA as well as IT consultants, NFP User Group on Eionet Information and Communication Technology Tools Developments (NFP ICT UG), National Reference Centres on Environmental Information System (NRC EIS) and relevant European Topic Centres (ETC). The feedbacks gathered have produced the final Requirements Catalogue. The whole process is outlined in the following figure.

Figure 2 – Reportnet 3.0 analysis processes

3. TOOLS AND TECHNIQUES

3.1. REQUIREMENTS ELICITATION TECHNIQUES

The following techniques were used for requirements definition:

Document analysis – The document analysis technique constitutes one of the most effective ways of kick-starting the requirements elicitation phase. Document analysis involves studying any relevant business, system and project documentation with the objective of understanding the business, the project background and identifying requirements or opportunities for improvement. In our case, we studied and analysed the available documentation (i.e. user manuals, development manuals, reporting guidelines, architecture documents, legal documents, etc.) in order to thoroughly understand the following:

o The way users interact or should interact with the system; o The responsibilities of the users towards the legal framework; o The architecture of the system and the interactions between its components;

The document analysis technique consists, in general, of three stages: o Prepare Stage – involves identifying which materials are suitable and relevant for

analysis, o Review Stage – involves studying the material, taking notes of relevant information

and listing follow-up questions for the stakeholders o Wrap up Stage – involves reviewing notes with stakeholders, Organizing

requirements and seeking answers to follow-up questions In our case, concerning the wrap-up stage, the follow-up questions were asked during the interview sessions (interview process is outlined below) while the notes taken were


incorporated in the business processes evaluation document in which they were reviewed by the stakeholders.

Interviews – Interviews are a systematic approach for eliciting information from a person (or a group of people) by asking questions and documenting the responses and constitute one of the most popular requirements elicitation techniques. By conducting an interview the following three areas are considered:

o current functions that need to be fulfilled in the new system; o problems with the current operations that need to be addressed; o new features required from the new business system.

In our case, an indicative set of questions was prepared prior to the interview and distributed to the participants in order to be prepared about the scope of the interview and the information that had to be collected. The interview was carried out in an organised manner, usually by two analysts – one setting the questions and one taking notes – and apart from the standardized set of questions, a discussion adapted to the context of individual session followed. After the end of the interview session a report was produced which was sent to the interviewees for approval the soonest possible (usually after 1-2 working days). Finally, a consolidated interview report was created and distributed to all involved in the project parties.

Interface analysis - Interface Analysis constitutes a business analysis elicitation technique that helps to identify interfaces between solutions/applications to determine the requirements for ensuring that the components interact with one another effectively. In the current system, interface types range from user interfaces (human beings interacting directly with the system) to interfaces to and from external applications and the interface analysis was employed in order to discover the requirements needed to integrate the new software into its new environment.

3.2. REQUIREMENTS’ PRIORITISATION METHOD

In order to prioritize the requirements collected, we followed the MoSCoW method, a prioritization technique used in business analysis and software development to reach a common understanding with stakeholders on the importance of delivering each requirement. The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories, which are outlined below:

Must have requirements - critical to the current delivery time box in order to be considered successful. Failing to satisfy even one of the “Must have” requirements, renders the project delivery a failure. In order to identify these requirements, the answer to the question, “what happens if this requirement is not met?” is “cancel the project – there is no point in implementing a solution that does not meet this requirement”.

Should have requirements - important but not necessary for delivery in the current delivery time box. While “Should have” requirements can be as important as “Must have” ones, they are often not as time-critical or there may be another way to satisfy the requirement, allowing to include them in a future delivery.

Could have requirements - desirable but not necessary, which could improve user experience or customer satisfaction for little development cost. These requirements will typically be included if time and resources permit. A “Could have” may be differentiated from a “Sould have” by reviewing the degree of pain caused by it not being met, in terms of business value or numbers of people affected.

Won’t have requirements - agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time and therefore not planned for the next delivery time box. “Won't have” requirements are either dropped or reconsidered for inclusion in a later time box.


4. REQUIREMENTS’ ATTRIBUTES DEFINITION

The requirements collected are defined by a set of attributes, forming an organized requirements list throughout which navigation and review is rational and easy. The constituent attributes of each requirement are outlined below:

ID: the unique requirement identifier.

Date: the creation date of the requirement to be described.

Version history: the history of the requirement through the different versions that have been created. Each version should also record the reason for the change and a reference to the change-control documentation.

Name: short name of the requirement.

Priority: the level of priority of the requirement. The acronym stands for: o M – must have; o S – should have; o C – could have; o W – won’t have this time.

See 3.2 Requirements’ prioritisation method for details on the prioritisation categories.

Category: the requirements are organised in the following categories and sub-categories: o General - These are the requirements that define business policies, standards and needs.

Business policies – cover aspects such as standards and business policy decisions (often known as business rules) which ensure consistency of operations across the organisation.

Business constraints – cover aspects such as budget, timescale and resources. Legal – requirements that state relevant legal and regulatory constraints. Language – requirements set out the languages to be used and the ways of

communication between stakeholders. o Technical - These are the requirements that state the technical policies and constraints to be

adopted across the organisation. Hardware – covering aspects such as the make and model of hardware equipment to

be used in the organisation. Software – covering areas such as operating systems, software package applications,

networking and communications software. Interface – cover the standards for communication between systems when required

to exchange data. The interfaces may be with systems and equipment operated within the organisation or by other, external organisations.

o Functional – The functional requirements are those that set out the features that any solution should provide.

Data Entry – concerned with gathering and recording the data that is required in the solution.

Data maintenance – handle changes to the data used within the solution. Procedural – refer to the business rules to be applied during working procedures in

order for the solution to serve the needs of these procedures. o Non-Functional – The non-functional requirements are concerned with how well the solution

will operate. Performance – specify a performance characteristic that a system or system

component must possess; for example, speed, accuracy, frequency. Security – identify the security levels required for the organisation’s information and

data. The security levels are likely to differ for different types of information or data. Some will be highly confidential and will require extremely rigorous security; others may still be confidential while being subject to less security.

Back up – define the policy for protecting against the loss of data and information. Archiving and Retention – the retention of data and information within an

organisation may be subject to internal policies or external legal regulations. These requirements define aspects such as the duration of the retention, the nature of the archiving methods and the approaches to be taken to the disposal of information and data.


Maintainability – concern the approaches to be taken to maintaining the solution, including aspects such as servicing, problem investigation and correction.

Business Continuity – include those designed to prevent a disaster affecting the organisation to any great extent as well as contingency requirements that will be needed should a disaster occur. Note: There are likely to be several non-functional requirements associated with the business-continuity requirements, for example in the areas of backup and recovery.

Availability – concern the timeframe during which a solution must be available to stakeholders.

Usability – this area concerns the ease with which a stakeholder can learn, apply and use new processes and systems.

o Capacity – these requirements cover areas such as the volumes of data and information to be stored and the number of stakeholders to be supported.

Component: the name of the component (step out of the 10 - step model for the DG Environment) which is affected by the requirement. This might be the name of the business function or department.

Requirement description: a detailed description of the requirement for the new system.

Justification: the business justification for the requirement. The rationale entry for a requirement may be cross-referenced to specific challenges, positives or proposals in the Business Process Evaluation list.

Related documents: the documents to which the requirement is related or referred.

Related requirements: the name of any requirements that are related to this requirement.


5. REQUIREMENTS LIST

ID DATE VERSION NAME PRIORITY CATEGORY COMPONENT REQUIREMENT DESCRIPTION JUSTIFICATION RELATED

DOCUMENT RELATED

REQUIREMENTS

F-001 13.09.2018 0,2 User identity verification

M Functional: Procedural

S5 Helping MS to prepare their reports

Reportnet 3.0 will allow for user identity verification beyond Eionet, for example using EU login.

F-002 13.09.2018 0,2 User access

management M

Functional: Procedural


In Reportnet 3.0, by default a nominated user will represent the reporting authority, for example the country, under each agreement. The nominated user will manage the addition of other verified users to provide support to the reporting, and their level of access rights within the reporting. Reporters self-manage access controls. Requesters will have access to an overview.

Challenge #18 - The process of updating the access rights is very time consuming and complicated for the data stewards. The process of granting specific access rights per user is time consuming for the data stewards. In order to save time, the users will be able to request for access rights which will be approved by the respective authority each time.

Business Process

Evaluation

F-003 13.09.2018 0,2 Configurable

reporting commitment



Reporters must be provided with functionality to declare what they will actually report under an agreement and validation will react accordingly, but still ensure technical requirements are met.

Challenge #28: Manual effort required in WFD to separate legitimate blockers from non-legitimate. For the WFD reporting, when a country is not able to report specific data, a complementary document should be provided explaining the reasons for not being able to deliver this data. After the data have been delivered to the system for this country and the data validation process takes place, a manual validation must take place in order to identify blockers caused due to data that cannot be delivered according to the complementary file from blockers caused due to actual errors in the delivery. This manual process takes place outside of the system and requires too much time and effort.

Business Process

Evaluation

Reportnet 3 Principles


F-004 13.09.2018 0,2 Notification subscription



Reportnet 3.0 will have the capability for users to subscribe to alert notifications regarding submission agreements and submission status.

Proposal #55: Reporting reminders Since there are many reporting obligations and some of them happen at the same time (and even by the same reporters) it is important to provide notifications for pending submissions or resubmissions.

Business Process

Evaluation

F-005 13.09.2018 0,2

Workflow driven

delivery process


S6 Organizing the data for submission or harvesting

Reportnet 3.0 must guide the reporter through the series of steps from initiation to completion in the delivery process. Reportnet 3.0 must manage the reporting sequence within the submission agreement.

Challenge #16: Reporting sequence is not controlled by the system. Challenge #37: Reporting process is not streamlined In the reporting or resubmission process, there are differences between reporting obligations. In the current implementation, taking actions lies on the reporter and is not restricted by the system which leads to deviations from the defined by the obligation process.

Business Process

Evaluation

F-006 13.09.2018 0,2 Open

reporting frequency

M Functional: Data Entry


Reportnet 3.0 will support one-off and cyclic reporting periods, continuous reporting, e.g. competent authorities updates and up-to-date reporting, e.g. air quality.

Positive #23: Real time data reporting offers a good snapshot of the data to the reporter Challenge #34: Wrong technical decisions taken upon system design The reporting of the real time data provides insights about the data to the reporters concerning the current situation and can act as heads-up for inconsistencies. Therefore, apart from the normal data, the presence of the real time data to the system is essential and beneficial.

Business Process

Evaluation

F-007 13.09.2018 0,2 Inline

communication tools

S Functional: Procedural


Reporters would be able to submit comments to the submitted data (e.g. where they cannot report mandatory data or where they need to provide a justification for resubmitting) and the opportunity to provide systematic feedback post-reporting (email questionnaire or similar).

Proposal #47: Submit comments in data In cases where the reporter needs to provide clarifications or justifications for the reported dataset no streamlined way exists in the system. Currently additional documents in Word or PDF format are included in the deliveries which have to be manually reviewed.

Business Process

Evaluation


F-008 13.09.2018 0,2

Integrated manual review

capability


S7 Ensuring quality of the reported data

Reportnet 3.0 will provide process and functionality to facilitate integrated manual review of reported data, for example by ETCs.

Challenge #29: Upon final feedback status, EEA / ETCs / EC have to review the data reported and decide for next steps The final dataset approval by the EEA / ETCs / EC is a step which requires too much manual effort, causes delays in the final products delivery and it's not a task in the current system.

Business Process

Evaluation

F-009 13.09.2018 0,2

Efficient validation

check execution



Reportnet 3.0 will consider the whole dataflow to ensure validations checks are executed only once to be efficient and avoid redundancy.

Challenge #9: Duplication of QCs Challenge #32: An extra validation step takes place in the FME or the DB. Challenge #42: Additional validations are executed in FME after the envelope release Since there isn't a common set of validations in the system, same validations are re implemented for different dataflows. There are also validations which due to their complexity are implemented or manually executed outside the reporting system in which they cannot not be maintained in the same way.

F-015 T-004

F-010 8.10.2018 0,1 Collaborative

platform M Functional


Reportnet 3.0 must support collaboration between actors in the design and delivery processes to achieve common goals, share information and solve business problems more efficiently. Key functionality for a collaborative platform is sharing, rights management and inline communication tools

F-011 8.10.2018 0,1 Centralized

solution M Functional


Reportnet 3.0 must be Centralized to enable all processes to be performed in a central point and future users will perform actions on their single computers without interaction with other systems. This requirement also includes the solution on having common web interface, collaboration in reporting design and collaboration in reporting submissions between primary and delegated reporting authorities.


F-012 30.11.2018 0,3 Flexible data

delivery format

M Functional S6 Organizing the data for submission or harvesting

Reportnet 3.0 must allow flexibility for the user to self-decide the format of data delivery (e.g. Web forms, XML, CSV, JSON) including use of web services. Reportnet 3.0 must be able to handle spatial data from (but not limited to) shapefile, GML and OGC GeoPackage for supporting INSPIRE needs.

Principle: Open data formats The XML format was the preferred format for the reporting and the QA rules implementation due to its independence of vendors and application environments. However, it was difficult for reported data in other formats than the XML to declare the schema against which validations should take place. Furthermore, the XML schema definition requires much effort and for some reporting obligations XML format is not convenient and various conversions must take place to assure a dataset that can be validated and processed.

F-013 8.10.2018 0,1 Immediate

quality feedback

M Functional S7 Ensuring quality of the reported data

Reportnet 3.0 must provide immediate feedback to the user on data issues in clear language. Definition of quality rules should be on records, datasets and collections with outcomes stored at the same level. Configuration of quality rules should be widely understood to non-developers. Data visualization tools should be integral to the QC checks.

F-009 T-004

F-014 30.11.2018 0,2 Maintainabili

ty of codelists



Reportnet 3.0 must enable versioning and maintenance of codelists. Codelists should be managed under clear governance. Codelists can also come from external registries. This requirement regarding CODELISTS should be regarded as High Priority – it will enable enhance data consistency and is critical considering reference data shared (or used) across different data flows

Reportnet 3.0 Kick-off meeting – Requirements review and observations: The system should permit a user to create a Code List and associate it to a Data Flow, and that the created code list is available for other data flows existing and future. The architecture for the new system should consider including Microservice for Code Lists.

F-015 30.11.2018 0,3 Subscribe to

reporting agreement



Reportnet 3.0 should allow for reporting agreements not requiring a nominated representative, where verified users subscribe and report their information, for example industry reporters.


F-016 12.10.2018 0,1 Test

environment M Functional


Reportnet 3.0 must have a test environment for reporters to gain understanding of the data requirements and test against the quality checks.

F-017 12.10.2018 0,1 Snapshots M Functional S6 Organizing the data for submission or harvesting

Reportnet 3.0 must have the capability to create snapshots of reported data

F-018 12.10.2018 0,1 Quality

blockers M Functional


Reportnet 3.0 must block deliveries when the data does not meet a specified minimum acceptable technical quality

F-019 12.10.2018 0,1

Facilitate guidance

document generation

C Functional S5 Helping MS to prepare their reports

Reportnet 3.0 should be able to generate a standard set of documentation, which describes the data model, QC steps and workflow without significant configuration by the workflow owner. The data model structure needs to be made available (exported) as scripts so MS can easily create the data model on their own systems


F-020 30.11.2018 0,2

Inspire spatial

dataset and download

service identification



Requirement related to the Reportnet Reportnet must include the means to provide / identify the Inspire dataset(s)/services that contain the correct data related to the reporting obligation in non-ambiguous way. It shall be mandatory for MS to provide this information.

The Reportnet should provide the means to collect such information. With the metadata currently available in the Inspire Geoportal, it is often impossible to identify automatically the correct datasets and / or services providing the geometry of the reported features. The Member States are responsible to communicate and maintain the correct and complete list of relevant data sources (e.g. direct download, Atom data feeds, WFS Stored Queries, applicable query parameters and values). The complete data for reporting must include all relevant data that cover the national level. Tests with Natura 2000 reporting identified this problem. For example: complete national Natura 2000 coverage (SPA/SCI/SAC).

Feasibility study on data

harvesting using INSPIRE

infrastructure - Use case 1, Use

case 2

F-021 12.10.2018 0,2

Possibility to download only data related to

the reporting obligation (e.g. using

stored query)

C Functional S6 Organizing the data for submission or harvesting

Requirement related to the Reportnet If an Inspire dataset contains features related to different reporting obligations, make sure it is possible to download only the part of the dataset related to that reporting.

As an example, Natura 2000 features are only a small part of the INSPIRE Protected Sites dataset. Filtering on Natura 2000 features alone would reduce the amount of data to be downloaded. This could be done also by using Natura 2000 stored query.



infrastructure - Use case 2

Inspire spatial dataset and download service

identification

F-022 12.10.2018 0,2 Inspire

service test M Functional


Requirement related to the Reportnet If the Inspire service is indicated in the reporting data flow, testing the availability of that service should be part of the reporting workflow. Secondly, it must be tested if the returned data follows the expected schema

If the Inspire services (providing geometry) replaces the current delivered data (mostly Shapefiles), it must be guaranteed that the given services do exist and are available. Secondly, if the schema of the returned features is wrong, it might become complicated to get the geometry. As an example, during Natura 2000 reporting tests (in the feasibility study), not all data initially found followed the expected INSPIRE Protected Sites schema




Inspire spatial dataset and download service

identification

F-023 30.11.2018 0,2

Testing the references between

spatial and non-spatial data (report

entry to Inspire feature

matching test)

M Functional S6 Organizing the data for submission or harvesting

Requirement related to the Reportnet Test of each reported entry can be reached in the Inspire dataset through the given service(s)

The Reportnet should include quality procedures to test the data and matching and to provide the notification on findings. If the Inspire geometry replaces the current delivered Shapefiles, it must be guaranteed that each reported entry has a corresponding feature in the Inspire dataset. Otherwise the report cannot be complete. For example, in Natura 2000, in a few cases a typo in the InspireID on the Natura SDF dataset prevented finding the correct Inspire feature





F-024 12.10.2018 0,2

Inspire feature

identification in Natura 2000 SDF



Requirement related to the reporting data and service providers (MS) and specific for Natura 2000 and INSPIRE Protected sites The way the InspireID in the Natura 2000 SDF should be filled in must be detailed, tackling the namespace/localID issue

In Inspire datasets, the inspire ID is a composition of Namespace, LocalID and Version. In the Natura 2000 SDF the InspireID is a single field. Ideally, the Natura 2000 SDF should be changed (to better correspond with the Inspire identifier data type), if that is not possible the way the inspireID is filled in must be standardized.




F-025 12.10.2018 0.1

Inspire feature

identification V2 - thematic

identifier should be

added to the INSPIRE

Protected sites

S Functional: Data Entry


Requirement related to INSPIRE In general, it would be very useful if the Inspire data models would include thematic identifiers that would allow to relate the features to the corresponding reporting obligations. For the purpose of the Natura 2000 reporting, the thematic ID (Natura2000 siteCode) should be added to the INSPIRE Protected sites (PS) schema. Together with the designation value this ID will be unique

This is an easier solution for feature identification but it requires change in the INSPIRE PS data schema. If the INSPIRE Protected Site schema would contain the Natura2000 site code, there is no need to include other information from Inspire into Natura2000 data.




alternative for: Inspire feature identification

F-026 30.11.2018 0,2

Inspire and reporting

synchronization

S Functional: Data Entry


Requirement related to the reporting data and service providers (MS) The features present in the Inspire dataset and downloadable by the INSPIRE services should match the data in the reporting data flow at the moment of the reporting. Responsibility to ensure this synchronization lies with the MS. However, while checking the data, there should be a mechanism to indicate the discrepancies to the MS reporting contact person (reporter).

For example, if Natura 2000 features in the Inspire PS dataset do not have the same update time as the Natura 2000 reported data, changes in the dataset between the two different dates might cause discrepancies between them




F-027 12.10.2018 0,2

Simple, direct and uniform Inspire feature

extraction

C Functional: Data Entry


Requirement related to the reporting data and service providers (MS) and INSPIRE All Inspire data are identified with the InspireID. Sometimes a thematic ID is available. It should be easy and straightforward to extract a single feature using this ID. This should be possible in a uniform way for all themes

The obligatory GetFeatureByID relates to the gml:id attribute of a feature. There is no obligation that this gml:id is the same as the Inspire ID or a thematic ID. In an Inspire context it would be much more useful to allow a standardized query on the InspireID or, if it is available in the Inspire dataset, on the thematic identifier. As a possible solution, making available a stored query returning a feature with the specific Inspire ID would be very useful. Alternatively, (in case of Inspire feature identification V2), a getFeatureByThematicID could be used





F-028 01-05-2019 0,3

Handle Peak Reporting

Data Upload Times



The new System will handle peak reporting data loading/import events from multiple reporters that tend to converge at the last minute (data flow reporting deadlines). Currently in RN2, this causes the system to be overloaded and there is insufficient visibility for reporters regarding the progress and success for the reported data.

Reportnet 3.0 Kick-off meeting – Requirements review and observations: reporters wait until the last minute to upload at the same time and this is causing the system to be overloaded

F-29 01-05-2019 0,3 Reporting Process Visibility



Reports and dashboards should cater for the need of better visibility for reports regarding what phase or stage of the reporting process they are at. E.g. Reporting Data Status, Overview of Reported Data, and Days Left for Reporting Deadline.

Reportnet 3.0 Kick-off meeting – Communication – reports should have easy visibility as to what phase or stage of the reporting process they are at. (Need to address in RN3)

F-30 01-05-2019 0,3

Reporting Process and

Data Collection

Status



The new System will provide visibility regarding Reporting Data Sets and Data Collections that are pending and for whatever reason to not evolve to a “Final/Ready Status”. The system should provide a dashboard or visualizations which include warning or alerts regarding these situations.

Reportnet 3.0 Kick-off meeting – Need better/enhanced visibility for Reporting Data Sets or Data Collection when they “get stuck”, ..Or for some reason there status does not evolve to “Final” and are set in a previous status without evolving.


F-31 01-05-2019 0,3 One-Stop Shop ROD Interface


S4 Explaining reporting obligations in practice

The new System will provide a single interface (avoiding multiple interfaces) for ROD. Ideally it will implement a single interface for ROD3, available for any user (with corresponding access rights). It will integrate ROD3 with Reportnet 3.0 for searching and viewing obligation details, viewing associated Data Flows and Data Collections in Reportnet 3.0. It should consider compatibility with Reportnet 2 (i.e. Reportnet 2 users should be able to access for search and view, additionally Reportnet 2 users should be able to associate Reportnet 2 Data flows, Data collections or Products using the same interface). Login to ROD will admit EU Login and EIONET Login

Reportnet 3.0 Kick-off meeting – Need to ensure that ROD is compatible with RN2 and RN3. (Avoid different interfaces, user login, etc.,…)

F-32 01-05-2019 0,3 Reusable

Entities Data Set Design



The new system should provide tools provide support during Data Set Design, where a Data Custodian can incorporate entities/data from existing data flows, which may be of use to the new Data Flow…as an example ID&Name for Rivers and Lakes, Protected Spaces, etc…

Reportnet 3.0 Kick-off meeting – this refers to the need or opportunity to be able to reutilize entities (and the entities data) that have been defined and reported in other data flows (that are not static – may change form one reporting cycle to another), as an example IDs and Names for Rivers and Lakes, Protected Spaces, etc.…. Reportnet 3.0 should provide tools which allow a Data Custodian to earmark or tag data from an existing Data Flow as Reusable (pre-load data, or data that can be used for validation purposes), and consequently search tools that can be used by a Data Custodian when design a Data Set, so that they can be aware of and potentially reuse these elements.

N-001 13.09.2018 0,2 Explanatory

error messages

M Non

Functional: Usability


Validation error messages must be indited in a human readable format to be easily understood and corrected by the reporters. The user shall also have access to a log of errors to keep track of the correction (possibility to export the log locally).

Challenge #10: Delays and difficulties in data correction due to technical vocabulary Errors in data validation are in general too technical and not user friendly and therefore, it is difficult for the data stewards who, usually, do not have a technical background to understand them and correct them. As a result the error identification and data correction processes take too much time.

Business Process

Evaluation

N-002 13.09.2018 0,3

Notification for new

reporting deadlines

M Non



The defined countries or companies in the reporting obligation should be notified by the system as soon as reporting cycle of a specific year is open and as the deadline is approaching. Notifications should also be sent for updates in the reporting data model even though reporting hasn't started yet.

Proposal #55: Reporting reminders It is important to notify the countries as soon as possible about the deadline of a reporting obligation in a streamlined way through the system in order to be able to prepare the delivery the earliest possible.

F-004


N-003 13.09.2018 0.1 Log

submission history

S Non



History of the submissions and the included files per reporting obligation should be logged by the system and be displayed to the users.

Challenge #25: Reported data should be visualized and their real time status should be displayed Proposal #45: Landing page for reporters Currently, resubmissions are performed either in the envelope of the initial delivery or in new ones. Furthermore, there are cases when the whole dataset for an obligation does not happen at the same time and the reporter is not able to see the history in one page.

N-004 13.09.2018 0,4

Dashboards for

monitoring reporting

status

M Non



Dashboards could be provided to the users having relevant access to the system allowing for easier monitoring of the reporting status highlighting the pending actions. A capability of simple visualization of data (maps, charts) as standard, and optional for more complex visualization configuration will be available. Users must be able to interact with the data (sort, filter, and group).

Proposal #45: Landing page for reporters Using dashboards, the reporter will be enabled to monitor and identify pending tasks for submission or resubmission and check from the status of the reporting obligations in a user friendly way in the application.

N-005 13.09.2018 0.1 User friendly environment

M Non



The new system should follow EU styleguides to be more user-friendly, modern and output oriented. Indicative styleguides found under the following URLS and should be explored upon implementation: https://ec.europa.eu/info/resources-partners/guidelines-websites-under-eceuropaeu_en http://blogs.ec.europa.eu/eu-digital/design-principles_en https://eui.ecdevops.eu/screen/app/prototypes-opsys

Challenge #7: Reporting through web forms is time consuming Challenge #10: Delays and difficulties in data correction due to technical vocabulary Challenge # 16: Reporting sequence is not controlled by the system Positive #49: System easy to navigate Proposal #51: User friendly system The reporters complain that the system is not user friendly. For example, reporting through the web forms is time consuming and not flexible, error handling is too technical to serve it, sequential reporting is neither guided nor controlled by the user interface. Furthermore, it is not modern and does not follow a consistent style guide throughout all the different modules.

Business Process

Evaluation

N-006 13.09.2018 0,3

Archive non-active

reporting obligations

M Non



Non-active reporting obligations could be organized to enable the users to search and find active obligations in a quick way. Moreover, active reporting obligations could be organized thematically and by frequency/ deadlines.

Challenge #17: Terminated obligations should not be displayed in ROD When searching in the ROD module of the current system for an obligation by its name, both active and non-active obligations are displayed (without any identification for non-active ones).

Business Process

Evaluation

https://ec.europa.eu/info/resources-partners/guidelines-websites-under-eceuropaeu_en



http://blogs.ec.europa.eu/eu-digital/design-principles_en

http://blogs.ec.europa.eu/eu-digital/design-principles_en

https://eui.ecdevops.eu/screen/app/prototypes-opsys

https://eui.ecdevops.eu/screen/app/prototypes-opsys


N-007 13.09.2018 0,2

Central storage point

for documentati

on

S Non



A centralized point of storage should exist in the system for the supporting documents of the reporting process (guidelines, specifications, schemas, ...) which should be accessible by everyone.

Positive #4: Explanatory user manuals Challenge #5: Central point of storage for guidance material Although there are user manuals available for the reporting process of each obligation, which are valuable for the reporters, they are not collected in a single agreed point of the system and as a result the users should search for them.

Business Process

Evaluation

N-008 13.09.2018 0,2

Provide a landing page giving easy access to all the platform

C Non



Navigation process could be facilitated for the reporters by having a structured landing page with direct redirections to actions-pending-to-be-done and explanatory messages. The landing page is different from the dashboard and can be different depending on the roles of the users.

Proposal #45: Landing page for reporters Reporters are not guided while browsing for pending tasks or pending reporting deadlines and have to perform many actions in order to find the relevant country folders.

Business Process

Evaluation

N-009 13.09.2018 0.1

Prefill capability

from previous

data

S Non



The system should allow a pre-filling functionality (i.e. with past data and other dataflows) to support reporting process and allow data comparison.

Proposal #46: Pre filled forms from previous data The current system is missing an efficient way to pre-populate data in forms of previous reporting especially in case commitment is changed there is no efficient way to check whether the pre-populated data remains unchanged.

Business Process

Evaluation

N-010 13.09.2018 0,2 High

availability of the system

M Non

functional: Availability


The system must be available for use 24/7 and it must achieve 99% up time. Maintenance breaks must be scheduled outside working hours and the system shall present appropriate user notifications before becoming unavailable.

N-011 13.09.2018 0,2 Performance M

Non functional: Performan

ce


The system's user facing components must achieve response times with their 98th percentile not exceeding 300ms as measured from the user interface.

Proposal #56: Legislation deadlines in same period As it has been reported, the system suffers from performance issues due to simultaneous reporting by many countries in cases when different obligations have the same reporting deadlines. Currently the system included 106 dataflows but those could be increased to more than 300 in the next years.

Business Process

Evaluation


N-012 13.09.2018 0.1 Scalability M

Non functional: Performac

e


The system must be able to sustain its performance characteristics during usage peaks resulting from external factors such approaching deadlines. For that purpose, it shall be possible to increase the system's load capacity horizontally without disrupting its operation (zero downtime).

N-013 13.09.2018 0,2 Security by

design M

Non functional:

Security


The system must be developed following the OWASP secure coding practices and the system's security mechanisms shall be verified regularly through a well-established security testing process. Also, Reportnet 3.0 will comply to the relevant requirements for the COMMISSION DECISION 2017/46 on the security of communication and information systems in the European Commission The security plan shall be documented and accessible to the users.

N-014 13.09.2018 0,2

Test driven development

and continuous

testability of features

M

Non functional: Maintaina

bility


The new system must be developed following a behavior-driven development approach (BDD) where the expected software behaviors (scenarios) are to be specified in a logical language that everyone can understand and verified during the software delivery process by automated acceptance tests.

N-015 13.09.2018 0.1 Fault

tolerant M

Non functional: Business

continuity


The system must continue operating properly in the event of the failure of some (one or more) of its components.

Related to N-010

N-016 13.09.2018 0,2

Centralize the

preformance monitoring

process

M


bility


The system's components must expose measurable behavior indicators (metrics) which shall be managed (collected, stored, parsed and visualized) centrally and monitored by the technical support personnel.


N-017 12.10.2018 0,1

Centralize the logs for

easy auditability

of Reportnet 3

M Non

functional: Security


Reportnet 3's components must produce all the necessary audit trails of actions performed by its users following uniform logging patterns and all produced logs shall be managed (collected, stored, parsed and visualized) centrally. The logs shall be inline with standards already used at the EEA.

N-018 12.10.2018 0,1

Integrate modular

architecture in the design of Reportnet

3.0.

M


bility

S1 Designing intervention logic and reporting products S2 Drafting reporting obligations in legislation S3 Preparing implementing acts on reporting

The new system must be break into components to be able to manage easier and extend. Moreover a modular architecture will enable the new system to be upgraded (e.g. add or remove any component) with the minimum impact to the rest system.

G-001 13.09.2018 0,2

Deliveries are

associated with an

agreement

M General: Business

constraints


All deliveries in Reportnet 3.0 must be linked to a submission agreements (e.g. obligation or request for national delivery).

Principle: Reporting obligations The submission agreement captures the definition on what and when to report. Linking the delivery with the corresponding obligation or agreement allows to easily check whether the reporting is fulfilled or not. Challenge #1: Reporting the same data multiple times

G-002 30.11.2018 0,2

Use existing standards in

reporting data model

design

M General: Business policies


Prioritise existing legal standards (e.g. INSPIRE) in design to assure reuse and interoperability of data.


G-003 13.09.2018 0,1 Multilingual

system C

General: Language


Reportnet 3.0 could be multilingual and even provide a framework for easy translation from the countries side.

Principle: Reportnet is English only Reportnet 2.0 is available only in English apart from some web forms which support multilinguality.

G-004 13.09.2018 0,1 GDPR

compliant M

General: Legal


Reportnet 3.0 will need to be compliant to the applicable parts of GDPR and also the regulations for EC institutions

Principle: GDPR compliance General Data Protection Regulation applies to Reportnet system because personal data are included in some deliveries. The data processing conducted in the system can be done lawfully since almost all data flows have a legal obligation.

G-005 13.09.2018 0,2 Confidentialit

y handled appropriately

M General:

Legal


Reportnet 3.0 should be designed to handle confidential information appropriately with access managed through rights.

Proposal # 54: Additional confidential data in future Sensitive information is currently handled in the BDR system, which is separate from the core reporting tool used by the countries, namely the CDR.

G-006 30.11.2018 0,3

Provide metadata

catalogue of dataflows


S9 Presenting and disseminating results

Reportnet 3.0 will provide a catalogue API that provides the metadata about the dataflows and the data that is being collected. This metadata should preferably be based on a simple and widely used open standard (as required by the EEA Data policy). A good candidate is the DCAT profile https://ec.europa.eu/isa2/solutions/dcat-application-profile-data-portals-europe_en, which is used for the EU Open Data portal. The data provided for dissemination must respect the confidentiality requirements.

Data reported can be textual, statistics and time series or geographic and geospatial. They are processed differently to produce final products which are disseminated to interested parties. The types of the final products must be suitable for the type of the data included.

G-007


G-007 30.11.2018 0.1

Provide access to reported

data through API



The system will provide data access through API in various formats, for download or integration into downstream dissemination platforms and products.

Same as G-006 G-006

G-008 01-05-2019 0,3

Linking Obligations

and Data Flows

S General: Business policies


The system will provide search functionality that enables a user to easily identify data flows and the associated Obligations. (i.e. view data flow and associated Obligation and view Obligation and associated data Flows.)

Reportnet 3.0 Kick-off meeting – Requirements Review and Suggestions: User should be offered features that enable them to easily identify / trace what obligations are tied to what Data Flows

T-001 13.09.2018 0,2

Promote a common

data model design

M Technical: Software


An application must be provided to enable and assist the thematic experts to define, design and maintain the data models (with minimum technical resources). A common vocabulary must be established and reused on data model definition.

Challenge #2: Lack of vocabulary or processes reusability Challenge #21: Reporting requirements definition lasts too long and time available for reporters to prepare deliverable decreases Proposal #59: Generic steps of reporting process The reporting definition process lasts too long. One reason for that is the fact that the data model is designed every time from scratch, without reusing existing code or attributes.

Business Process

Evaluation T-008; G-002

T-002 13.09.2018 0,2

Universal platform for

delivery preparation



A universal platform with an easy-to-use interface must be available to all reporting parties for all obligations to streamline the reporting preparation process. The same system (with customization) has to be made available for other economic operators as well.

Challenge #7: Reporting through web forms is time consuming Challenge #11: Conversion tools should be maintained. Challenge #50: National tools for data collection Proposal #60: New system to serve all DGs The reporting countries are allowed to collect the data in any tool (and therefore format) they wish but they have to convert the file in case it differs from the one required by the reporting obligation. As a result national reporting tools are maintained or conversion tools are used which requires effort.

Business Process

Evaluation


There have been attempts to provide tools to the countries for data reporting like web forms, however, the countries have complained about their usability and as a result they use alternative methods for reporting.

T-003 13.09.2018 0,1

Create a data validation system for

delivery preparation

S Technical: Software


Reporters should be able to validate the data early enough in the delivery preparation process through visualisation techniques (e.g. maps). The system has to be clear and easy-to-use and available on-line to both MS and other economic operators.

Challenge #13: Reporters should be able to review the data submitted in visualized reports Since the reporters of the data have a good understanding of the data they report, they are able to identify errors in their datasets if they are provided with a visual representation of them upon delivery preparation.

Business Process

Evaluation

F-009 F-015

T-004 30.11.2018 0,3

Efficiently handle the delivery of

files



The system must be able to handle efficiently reported files of at least 3GB. Various options can be considered such as asynchronous process and/or delivering files in multiple time. In the last case, the system has to be able to handle files with up to 15k records. The file system folder use must be able to handle more than 100k files (as it was the case with the old envelopes)

Challenge #22: System handles big GML files inefficiently (timeouts and retries) When reporting big GML files, timeouts are thrown to the reporters obliging them to retry even many times.

Business Process

Evaluation N-011; N-012; N-013

T-005 13.09.2018 0,1 Real time

data reporting



The system must be able to support data load coming from real time data reporting

Challenge #23: Real time data reporting offers a good snapshot of the data to the reporter Challenge #34: Wrong technical decisions taken upon system design A system has to be thoughtfully designed in order to be able to serve such a heavy load of data since the reporting of the real time data provides insights about the data to the reporters concerning the current situation and can act as heads-up for inconsistencies.

Business Process

Evaluation


T-006 13.09.2018 0,2

Assure the best possible interoperabil

ity with third-party

systems

M Technical: Interface


The system must provide a set of well-defined, documented and versioned public Restful APIs allowing third-party systems to easily integrate with it (read/write). Technological Standards shall be use to ensure that.

Proposal #57: Interoperability of systems The system should be aligned with DIGIT Strategy 2025, which aims at maximizing the interoperability of the systems together with principles of re-use and share.

Business Process

Evaluation

T-007 12.10.2018 0,1

Relational database storage

platform



Relational database must be used in the new solution for the following major reasons: 1. Ability to have data integrity checks; 2. Ability to relate stored data; 3. Handling of a lot of complicated querying, database transactions and routine analysis of data.

T-008 12.10.2018 0,2 Re-use of existing

capabilities M

Technical: Software


The system should support the duplication of existing dataflows or system capabilities to be used as a new starting point for the design of new dataflows.

T-009 12.10.2018 0,1

INSPIRE download service -

Atom feeds

S Technical S6 Organizing the data for submission or harvesting

Requirement related to the Reportnet Requirement related to the reporting data and service providers (MS) Supplied Atom feeds should be datasets feeds (not top feeds).

The Reportnet should include quality procedures to test the service and to provide the notification on findings. Reviewing Atom feeds in scope of this study has revealed that top feeds will also contain entries to non-Natura 2000 data feeds.





T-010 12.10.2018 0,1

INSPIRE download service -

Atom feeds coverage

W Technical S6 Organizing the data for submission or harvesting

Requirement related to the Reportnet Requirement related to the reporting data and service providers (MS) Atom dataset feeds supplied for harvesting could contain only the entries for the datasets under the specific reporting obligation.

The Reportnet should include quality procedures to test the service and to provide the notification on findings. Although Reportnet QA checks will verify that only required datasets are reported, supplying only relevant information will reduce the load on both national services and Reportnet infrastructure.




T-011 30.11.2018 0,2

Support for manual

reporting fallback

C Technical S6 Organizing the data for submission or harvesting

Requirement related to the Reportnet Reportnet workflows should continue to accommodate manual uploading of datasets where services are not available.

Member States should be able to provide data under the reporting obligation within the reporting window where national INSPIRE services are not available.

T-012 12.10.2018 0.1

INSPIRE download

service - WFS - should provide

ListStoredQueries feature for reporting

datasets


Requirement related to the Reportnet Requirement related to the reporting data and service providers (MS) WFS Download Service must provide the ListStoredQueries feature for further interrogations.

The spatial datasets can be easily harvested using pre-defined StoredQueries. Before using them, Reportnet must be able to check if they exist, therefore the ListStoredQueries feature is mandatory.




T-013 12.10.2018 0,1

INSPIRE download service - Unique

filenames in archives


Requirement related to the Reportnet Requirement related to the reporting data and service providers (MS) Filenames in archived datasets should be unique.

The Reportnet should include quality procedures to test the service and to provide the notification on findings. Non-flat (with folders) zip archived contents are supported but upon download the files will be extracted in a flat structure therefore unique names are required to avoid overwriting files.





6. APPENDIX 1: REFERENCES AND RELATED DOCUMENTS

ID Reference or Related Document Source or Link/Location

1 Business Process Evaluation https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-study/scoping-study-deliverables/business-process-evaluation-report

2 Architecture of As-Is https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-study/scoping-study-deliverables/architecture

3 Requirements Catalogue V.1 https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-study/consultations/requirements-v1

4 Requirements Catalogue V.2 https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-study/consultations/requirements-v2

https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-study/scoping-study-deliverables/business-process-evaluation-report




https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-study/scoping-study-deliverables/architecture



https://projects.eionet.europa.eu/reportnet-3.0/library/03-executing/02-projects/01-scope-study/consultations/requirements-v1



requirements catalogue - eionet portal · 1.0 05/12/2018 persefoni kampa incorporating final list...

Documents