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 ...... 5
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 ...... 7
9.Non-functional Requirements...... 10
10.Look and Feel Requirements ...... 10
11.Usability and Humanity Requirements...... 10
12.Performance Requirements...... 10
13.Operational and Environmental Requirements...... 11
14.Maintainability and Support Requirements...... 12
15.Security Requirements...... 12
16.Cultural and Political Requirements...... 13
17.Legal Requirements ...... 13
18.Open Issues ...... 13
19.Off-the-Shelf Solutions...... 13
20.New Problems...... 14
21.Tasks...... 14
22.Migration to the New Product...... 15
23.Risks...... 15
24.Costs...... 15
25.User Documentation and Training...... 15
26.Waiting Room...... 15
27.Ideas for Solutions...... 15
requirements_analysis_v01 adr update.docx
1
requirements_analysis_v01 adr update.docx
1
1.The Purpose of the Project
1.a.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.
1.b.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.
- The Stakeholders
2.a.The Client
EC/EEA
2.b.The Customer
Member States INSPIRE NCPs + EC/EEA
2.c.Other Stakeholders
Members of the MIG policy sub-group
Members of the MIG technical sub-group
Members of the MIG/MIWP-5 sub-group
2.d.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
European Commission / EEA “policy” staff
European Commission / EEA “technical” staff
Spatial data user community
2.e.Priorities Assigned to Users
2.f.User Participation
Users 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.
2.f.2.g.Maintenance Users and Service Technicians
3.Mandated Constraints
3.a.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 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 shallcould[Marc Leob1] 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 3
- 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).
3.b.Implementation Environment of the Current System[Alexander2]
As 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 organisationorganization to be taken into account.
Only at EEA or JRC (and then the MS modules/specialisations are installed there)? Or also in MS?[Marc Leob3]
3.b.3.c.Partner or Collaborative Applications
Linked to 3b. E.g. at EEA we have an online application ( generate graphs/charts etc. which would likely be used if this is installed at EEA.[Alexander4]
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.[Alexander5]
3.c.3.d.Off-the-Shelf Software
Could the system developed in Germany be re-used? If technically ok, issues in terms of governance to be analysed...
3.d.3.e.Anticipated Workplace Environment
Any standard office environment. No specific constraint.
3.e.3.f.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. [Marc Leob6]
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.
3.f.3.g.Budget Constraints[Alexander7]
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 might have a great impact (dashboard developed by Germany).
4.Naming Conventions and Terminology
4.a.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.
4.a.4.b.Data Dictionary for Any Included Models
5.Relevant Facts and Assumptions
5.a.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.
5.b.Assumptions
The ongoingon 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.[Alexander8]
6.The Scope of the Work
6.a.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.b.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.
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.
6.a.6.c.Work Partitioning
7.The Scope of the Product
7.a.Product Boundary
7.b.Product Use Case Table
7.c.Individual Product Use Cases
8.Functional and Data Requirements
8.a.Functional Requirements
Content
This is a specification for each atomic functional requirement. As for all types of atomic requirements(requirements (functional, non-functional, constraint), use the requirements shell as a guide for which attributes should be specified. A full explanation of the atomic requirement and its attributes is included in this template’s introductory material.
Motivation
To specify the detailed functional requirements to be carried out by the product.
Examples
Fit Criterion
Each functional requirement should have a fit criterion or a test case. In any event, the fit criterion is the benchmark so that the tester can objectively determine whether or not the implemented product has met the requirement.
Considerations
If you have produced an event/use case list (see sections 6c and 8a/b), then you can use it to help you trigger the functional requirements for each event/use case. If you have not produced an event/use case list, give each functional requirement a unique number and, to help with traceability, partition these requirements into event/use case–related groups later in the development process.
Note that if you have not identified the product boundary and are not in a position to determine the product use cases (PUC’s), then write the functional and non-functional requirements for the business use cases (BUC’s). This is an especially good strategy if you are writing business requirements and asking suppliers to tell you which of your business requirements can be satisfied by their product/s.
Form
The form that you use to capture and maintain your atomic requirements (functional, non-functional and constraint) depends on the tools that you have available to you. Volere snow cards are often a useful aid to help you in discovering requirements but, due to volume and need to be able to make changes, some kind of automated form is the best way to manage and maintain your atomic requirements. Common forms for atomic requirements are:
• A spreadsheet (a sample is included with this template)
• A database provided with whatever requirements tool/s you have available. There is a wide variety of tools on the market, refer to for a list
• An intranet set up by you to maintain and make accessible the atomic requirements and their attributes
• A custom built database
Whatever form you use to record and maintain your requirements, it is important to be consistent with your numbering and terminology so that you can check for completeness and respond to change.
8.b.Data Requirements
Content
A specification of the essential subject matter, business objects, entities, and classes that are germane to the product. It might take the form of a first-cut class model, an entity-relationship model, or any other kind of data model.
Motivation
To clarify the system’s subject matter, thereby triggering recognition of requirements not yet considered.
Example
This is a model of the business system’s business subject matter using the Unified Modelling Language (UML) class model notation. This is all the data that is Created, Referenced, Updated and Deleted by processes within the scope of the work being studied. See section 6 for more about the scope of the work.
Each of the rectangles represents a class of business data. The attributes of that class are defined in the data dictionary.
e.g.: District = District Name + District Size
You can use any type of data or class model to capture this knowledge. The issue is to capture the meaning of the business subject matter and the connections between the individual parts, and to show that you are consistent within your project. If you have an established company standard notation, use that, as it will help you to reuse knowledge between projects.
Considerations
Are there any data or object models for similar or overlapping systems that might be a useful starting point? Is there a domain model for the subject matter dealt with by this system?
Form
There are many different types of data models that you can use to model the business data. The ones you are most likely to come across are:
• UML class model
• Crow’s foot diagrams
• Entity Relationship diagrams
• A table showing: Class Name, Relationships between classes, Attributes for each class.
If your organization prefers a particular model then you must use that one. The important thing is that the data model that you build is a business data model, not a design for a database. Your model is concerned with identifying business classes by making a logical partitioning of all the data within the work context and the necessary business relationships between those business classes. Your model is used as input to designing how the data will be implemented. The definitions of the attributes in each business class is in the data dictionary (see section 7b).
9.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.
10.Look and Feel Requirements
10.a.Appearance Requirements
Are there any EU/EEA house styles that we need to comply with?
10.a.10.b.Style Requirements
11.Usability and Humanity Requirements
This section is concerned with requirements that make the product usable and ergonomically acceptable to its hands-on users.
11.a.Ease of Use Requirements
The 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[Marc Leob9] – 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.
11.b.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 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.
11.a.11.c.Learning Requirements
11.b.11.d.Understandability and Politeness Requirements
11.e.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.
12.Performance Requirements
12.a.Speed and Latency Requirements
12.b.Safety-Critical Requirements
12.c.Precision or Accuracy Requirements
12.d.Reliability and Availability Requirements
The product shall be available xx% [Do we have such a requirement?] of the time.
12.e.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 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)
12.f.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.
12.f.12.g.Scalability or Extensibility Requirements
12.g.12.h.Longevity Requirements
The product shall be expected to operate for a minimum of XXX years.
13.Operational and Environmental Requirements
13.a.Expected Physical Environment
N/A
13.b.Requirements for Interfacing with Adjacent Systems
The 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...)
13.c.Productization Requirements
13.d.Release Requirements
14.Maintainability and Support Requirements
14.a.Maintenance Requirements
14.b.Supportability Requirements
14.c.Adaptability Requirements
The product (server part) is expected to run under Windows and Linux. Again, this will be influenced by decision on hosting etc.
15.Security Requirements
15.a.Access Requirements
15.b.Integrity Requirements
15.c.Privacy Requirements
15.d.Audit Requirements
15.e.Immunity Requirements
16.Cultural and Political Requirements
16.a.Cultural Requirements
16.b.Political Requirements
17.Legal Requirements
17.a.Compliance Requirements
17.b.Standards Requirements
Whenever applicable, INSPIRE IR, ISO standards and OGC specifications shall be followed.
18.Open Issues
18.a.
19.Off-the-Shelf Solutions
19.a.Ready-Made Products
19.b.Reusable Components
19.c.Products That Can Be Copied
20.New Problems
20.a.Effects on the Current Environment
20.b.Effects on the Installed Systems
20.c.Potential User Problems
20.d.Limitations in the Anticipated Implementation Environment That May Inhibit the New Product
20.e.Follow-Up Problems
21.Tasks
21.a.Project Planning
21.b.Planning of the Development Phases
22.Migration to the New Product
22.a.Requirements for Migration to the New Product
22.b.Data That Has to Be Modified or Translated for the New System
23.Risks
24.Costs
25.User Documentation and Training
25.a.User Documentation Requirements
25.b.Training Requirements
26.Waiting Room
27.Ideas for Solutions
[Marc Leob1]From our point of view, the dashboard is downstream of the monitoring process. It will be fed by the national monitoring (as you wrote in your 6.b). Or am I misunderstanding?