Functional and Non- functional requirements for the INSPIRE Dashboard Table of Contents 1. THE PURPOSE OF THE PROJECT..................................3 2. THE STAKEHOLDERS............................................3 3. MANDATED CONSTRAINTS........................................4 4. NAMING CONVENTIONS AND TERMINOLOGY..........................6 5. RELEVANT FACTS AND ASSUMPTIONS..............................7 6. THE SCOPE OF THE WORK.......................................7 7. THE SCOPE OF THE PRODUCT....................................8 8. FUNCTIONAL AND DATA REQUIREMENTS............................8 9. LOOK AND FEEL REQUIREMENTS.................................12 10. USABILITY AND HUMANITY REQUIREMENTS.....................12 11. PERFORMANCE REQUIREMENTS................................13 12. OPERATIONAL AND ENVIRONMENTAL REQUIREMENTS..............14 13. MAINTAINABILITY AND SUPPORT REQUIREMENTS................14 14. SECURITY REQUIREMENTS...................................15 15. CULTURAL AND POLITICAL REQUIREMENTS.....................15 16. LEGAL REQUIREMENTS......................................16 17. OPEN ISSUES.............................................16 18. OFF-THE-SHELF SOLUTIONS.................................16 19. NEW PROBLEMS............................................17 1 REQUIREMENTS_ANALYSIS_V02
Transcript
Functional and Non-functional requirements for the INSPIRE Dashboard
Table of Contents1. THE PURPOSE OF THE PROJECT.........................................................................................3
2. THE STAKEHOLDERS.........................................................................................................3
26. IDEAS FOR SOLUTIONS............................................................................................18
2 document.docx
1. The Purpose of the Project
1a. The User Business or Background of the Project EffortAt 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.
1b. 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
2a. The Client EC/EEA
2b. The Customer Member States INSPIRE NCPs + EC/EEA
2c. Other StakeholdersMembers of the MIG policy sub-groupMembers of the MIG technical sub-groupMembers of the MIG/MIWP-5 sub-group
2d. The Hands-On Users of the Product INSPIRE Reporters/NCPs/MIG policy members
3 requirements_analysis_v02
Technical experts acting on behalf of the INSPIRE Reporters/NCPs/ MIG policyEuropean Commission / EEA “policy” staffEuropean Commission / EEA “technical” staffSpatial data user community
2e. Priorities Assigned to UsersKey users
INSPIRE Reporters, NCPs and their technical expertsEC and EEA staff
Secondary usersSpatial data user community
Unimportant usersPublic at large
2f. User ParticipationUsers from the user group identified above will be required to test the product both in terms of these functional arrangements but also in terms of usability.
2g. Maintenance Users and Service TechniciansEEA or JRC IT staffEEA/JRC INSPIRE staff
3. Mandated Constraints
3a. 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.
4 document.docx
Description: The product shall have completed all testing and acceptance by the 15th December 2014.
Rationale: The purpose of this product is to support MS in the production of the Monitoring and Reporting for calendar year 2014.
Fit Criterion: Users shall be able to use the product to populate a significant proportion of the Monitoring and Reporting (M&R) spread sheet. [In order for this constraint to be met – we should provide the spread sheet that is used for M&R]
Issue 2 Description: The product shall take as input data formatted in a
way suitable also for the official monitoring.
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.
Description: The software produced will be open-source allowing the free re-use of the product as required.
Rationale: Given the need to extend the software for MS use in the second or subsequent phases, creating the product with COTS software will make it difficult for the community to extend.
Fit Criterion: Once created the Product will be deposited in a manner that anyone that complies with the license for the Product (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).
3b. Implementation Environment of the Current SystemAs this is a new system, the hosting environment is not yet well defined. [Do we want to make the hosting of the product part of the service the developer provides. These are questions that we will need to consider prior to procurement.]
Where will the system be hosted? Requirements from hosting organization to be taken into account.
requirements_analysis_v02 5
Alexander Ramage, 14/06/14,
This is an area that we need to concentrate on at the next meeting.
Only at EEA or JRC (and then the MS modules/specialisations are installed there)? Or also in MS?
3c. Partner or Collaborative ApplicationsLinked to 3b. E.g. at EEA we have an online application (http://daviz.eionet.europa.eu to generate graphs/charts etc. which would likely be used if this 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 + INSPIRE Geoportal
Web services at MS level providing ancillary information to the MD provided through discovery services or providing extra information (e.g. description of metadata records not included in the discovery service)
Validation services provided by MIWP-5.
3d. Off-the-Shelf SoftwareNo requirement identified so far about software that must be embedded in the product.
3e. Anticipated Workplace EnvironmentAny standard office environment. No specific constraint.
3f. Schedule Constraints First version planned by the end of the year. This first version MUST be useable to help a MS create 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 shall have completed all testing and acceptance by the 15th December 2014. Thus, users shall be able to use the product to populate a significant proportion of the Monitoring and Reporting (M&R) spread sheet. [In order for this constraint to be met – we should provide the spread sheet that is used for M&R]
6 document.docx
Paul Hasenohr, 14/06/14,
Adapted from AR document.I do not think that it is realistic unless we focus on data input mainly now and leave the chart/map display to next year.
Alexander Ramage, 14/06/14,
Given the timescale we are working to can we really wait for MIWP-5?
All technical specifications applying to MS shall be ready by end of Q3/2014 in order to leave enough time for development/adaptation of services (and also to have it included in the sw dvpt planning for 2015).
Our first phase development indicates that we will have this done by the end of 2014. 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.
3g. Budget ConstraintsEEA 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 might have a great impact (dashboard developed by Germany).
4. Naming Conventions and Terminology
4a. 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.
4b. Data Dictionary for Any Included Models
5. Relevant Facts and Assumptions
5a. Relevant FactsParticipation 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
requirements_analysis_v02 7
Alexander Ramage, 14/06/14,
We need to understand the funding available to the Work Packages. This is an issue that needs to be flagged to the MIG and then possibly further up the tree.
this MS (driven by Commission Decision 2009/442/EC) unless the MS explicitly requests it.
5b. AssumptionsThe on going INSPIRE evaluation will not alter significantly the need and purpose of the dashboard.
EEA or JRC agrees to host the dashboard.
A process for dashboard maintenance is established.
6. The Scope of the Work
6a. The Current SituationAt 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.
6b. The Context of the WorkAs 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.
8 document.docx
Alexander Ramage, 14/06/14,
This is not a trivial assumption and the result of the assumption will colour the implementation of the system. This needs some detailed consideration at the next meeting.
MSMD
Discov
MSExtra info
MSAncillary info MD
Discov
Harvesting date + access to history for same UID
MD + AI Validation results from all relevant MIWP-5 tests
id. MD id.id. id.id. EI (nb of
complaints)N/A
id. EI (e.g. dataset without metadata)
N/A
MDUID
AIUID
EI
EI
MDi DSi NSiMS1 MS1/MS1 MS1MS2 MS2 MS2
calculate
AI: service protected, service statistics, dataset area...EI: value for an indicator, description of a dataset/service without metadata
Facetted search: MS, Annex, Theme,Validation results, Conformance declared, Service type
6c. Work PartitioningList of business events to which the work/product responds.TBD
7. The Scope of the Product
7a. Product BoundaryOut of the product:
Generation or edition 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 edition of metadata records which have been harvested
7b. 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 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
requirements_analysis_v02 9
System validates network services periodically and stores the result
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.
7c. Individual Product Use Cases
8. Functional and Data Requirements
8a. Functional Requirements
Requirement: UK1
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
Fit criterion: …
Requirement: SE1
Description: The dashboard shall store all monitoring information submitted by the Member States, year by year
Rationale: In order to be able to retrieve monitoring information from different Member States, themes and years in a simple and comparative way, for further analysis and dissemination
10 document.docx
Fit criterion: The information in the dashboard should correspond to the information in the monitoring Excel-sheet
Requirement: SE2
Description: The dashboard shall annually harvest required monitoring information from the INSPIRE Geoportal
Rationale: In order to minimise the need for each Member State to carry out the monitoring requirements
Fit criterion: The information in the dashboard should agree with the implementation status in respective Member State on the 31st of December each year.
Requirement: SE3
Description: It shall be possible for the Member States to edit harvested information prior to approving it as final monitoring result
Rationale: In order to correct information harvested from the INSPIRE Geoportal, for instance add datasets and services that not have metadata as yet, before approving the result as an “official” monitoring report
Fit criterion: …
Requirement: SE4
Description: It shall be possible to query the dashboard using selection criteria’s (country, theme, year, etc.) through a web interface
Rationale: In order 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: …
requirements_analysis_v02 11
Requirement: SE5
Description: The results of a query shall be presented in tabular form in the web interface
Rationale: In order to provide a quick and readably overview of the results of a particular query
Fit criterion: …
12 document.docx
Requirement: SE6
Description: Where possible and if required by the user, is shall be possible to present the results graphically
Rationale: In order 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 13
Requirement: SE7
Description: It shall be possible to download the results of a query as an Excel-file
Rationale: In order to allow the user to further process the results of a query
Fit criterion: …
Requirement: EEA1
Description: It shall be possible to have an up-to-date monitoring (e.g. based on metadata and ancillary information updated every week)
Rationale: In order to allow users to see the current status of implementation of INSPIRE in MS and to show that things are moving
Fit criterion: …
Requirement: EEA2
14 document.docx
Description: It shall be possible to see for each data set or service its metadata, its declared conformity and its evaluated conformity (with associated report)
Rationale: In order 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: …
Requirement: EEA6
requirements_analysis_v02 15
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: …
8b. Data RequirementsSection to further detail
Parameters related to the operation of the dashboard
Discovery services and AI/EI endpointsFilter parameters to use to retrieve the correct records from each discovery service...
Metadata records, Ancillary Information, Extra Information
16 document.docx
Results of validations from MIWP-5
Snapshots
requirements_analysis_v02 17
Non-functional RequirementsThe 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
9a. Appearance Requirements Are there any EU/EEA house styles that we need to comply with?
9b. Style Requirements
10. Usability and Humanity RequirementsThis section is concerned with requirements that make the product usable and ergonomically acceptable to its hands-on users.
10a. Ease of Use RequirementsThe product shall start up with a default front screen, that displays “high level” detail. The detail we want to see here needs 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.
10b. Personalization and Internationalization RequirementsGiven 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 behavior and set the language to any of the European languages. The selection of a language shall have no effect on the data that can be viewed.
18 document.docx
10c. Learning Requirements
10d. Understandability and Politeness Requirements
10e. Accessibility RequirementsThe 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
11a. Speed and Latency Requirements
11b. Safety-Critical Requirements
11c. Precision or Accuracy Requirements
11d. Reliability and Availability RequirementsThe product shall be available xx% [Do we have such a requirement?] of the time.
11e. Robustness or Fault-Tolerance RequirementsThe product or its content shall not become corrupted if one or more of the services it depends upon (e.g. database) becomes unavailable or if the server hosting it is not shut down properly.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)
requirements_analysis_v02 19
11f. Capacity RequirementsThe 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.
The product should be able to handle at least 15 concurrent users.
11g. Scalability or Extensibility Requirements
11h. Longevity RequirementsThe product shall be expected to operate for a minimum of XXX years.
12. Operational and Environmental Requirements
12a. Expected Physical EnvironmentN/A
12b. Requirements for Interfacing with Adjacent SystemsThe product shall work on IE9+ and similar versions of FF and Chrome browsers.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...)
12c. Productization Requirements
12d. Release Requirements
20 document.docx
Paul Hasenohr, 14/06/14,
No idea about the number... how popular will the service be!?
Paul Hasenohr, 14/06/14,
Isn’t it a little bit exagerated?
13. Maintainability and Support Requirements
13a. Maintenance Requirements
13b. Supportability Requirements
13c. Adaptability RequirementsThe product (server part) is expected to run under Windows and Linux. Again, this will be influenced by decision on hosting etc.
14. Security Requirements
14a. Access Requirements
14b. Integrity Requirements
14c. Privacy Requirements
14d. Audit Requirements
14e. Immunity Requirements
15. Cultural and Political Requirements
15a. Cultural Requirements
requirements_analysis_v02 21
15b. Political Requirements
16. Legal Requirements
16a. Compliance RequirementsDescription: The software produced will be open-source allowing the free re-use of the product as required.
Rationale: Given the need to extend the software for MS use in the second or subsequent phases, creating the product with COTS software will make it difficult for the community to extend.
Fit Criterion: Once created the Product will be deposited in a manner that anyone that complies with the license for the Product (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).
16b. Standards RequirementsWhenever applicable, INSPIRE IR, ISO standards and OGC specifications shall be followed.
17. Open Issues
17a.
22 document.docx
18. Off-the-Shelf Solutions
18a. Ready-Made Products
18b. Reusable ComponentsThe German registry client is available under a 3-clause BSD licence. If the functionalities are ok, issues in terms of governance to be analysed...
18c. Products That Can Be Copied
19. New Problems
19a. Effects on the Current Environment
19b. Effects on the Installed Systems
19c. Potential User Problems
19d. Limitations in the Anticipated Implementation Environment That May Inhibit the New Product
19e. Follow-Up Problems
requirements_analysis_v02 23
20. Tasks
20a. Project Planning
20b. Planning of the Development Phases
21. Migration to the New Product
21a. Requirements for Migration to the New Product
21b. Data That Has to Be Modified or Translated for the New System
