601 lines
42 KiB
Plaintext
601 lines
42 KiB
Plaintext
|
• City data found in existing data catalogues may require special consideration concerning the
|
|||
|
|
type of formats and datasets that must be stored within the platform.
|
|||
|
|
• Requirements mismatch due to increased number of stakeholders involved in the design
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.10.2 Implementation Constraints
|
|||
|
|
|
|||
|
|
• Evaluation and testing of software options is expected to occur prior to selection and
|
|||
|
|
implementation of a production urban platform.
|
|||
|
|
• Budget costs are unknown until evaluation of software options is completed.
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.11 Assumptions, Alignment with other Action Clusters and Policies
|
|||
|
|
1.11.1 Assumptions
|
|||
|
|
|
|||
|
|
The assumptions in Table 3 have been identified by the Demand Side Engagement Stream as
|
|||
|
|
relevant to this Requirements Specification.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 11
|
|||
|
|
|
|||
|
|
|
|||
|
|
Table 3. Assumptions
|
|||
|
|
|
|||
|
|
# ASSUMPTION
|
|||
|
|
|
|||
|
|
1 The providers of city data and services will be responsible to maintain their resources in the platform.
|
|||
|
|
|
|||
|
|
2 All city data must meet the minimum metadata requirements and use the standards adopted by the platform.
|
|||
|
|
|
|||
|
|
3 The platform shall consider open Source as an optional commercial model, with open standards as a principle
|
|||
|
|
|
|||
|
|
4 The system design and architecture should minimize fragmentation of city data in the urban platform.
|
|||
|
|
|
|||
|
|
5 To the extent possible, automation should be used for the extraction of descriptive and technical metadata.
|
|||
|
|
|
|||
|
|
6 The platform must be designed in a way it accommodates additional functionality at later stage at a fair and transparent cost.
|
|||
|
|
|
|||
|
|
The platform must be a modular based architecture which relies on stable and well-defined open interfaces to ensure
|
|||
|
|
7
|
|||
|
|
interoperability between the platform, services and the applications provided by service providers.
|
|||
|
|
|
|||
|
|
The platform will offer open and well-documented API’s and clear service descriptions and contracts that is offered for reuse by
|
|||
|
|
8 another party to foster open innovation in the city, which means that developers and interested individuals openly utilize the
|
|||
|
|
resources provided.
|
|||
|
|
|
|||
|
|
9 Adopt open and published European and International standards where possible.
|
|||
|
|
|
|||
|
|
The platform must be flexible enough to accommodate different local, National and International data protection, licensing and
|
|||
|
|
10
|
|||
|
|
commercialization regulations.
|
|||
|
|
|
|||
|
|
11 Platform providers will monitor emerging technologies in order to maintain and improve the architecture.
|
|||
|
|
|
|||
|
|
|
|||
|
|
12 Platform providers will monitor emerging information standards, including metadata standards and data interface standards.
|
|||
|
|
|
|||
|
|
|
|||
|
|
13 Platform providers will monitor new commercial models for city data exploitation
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.11.2 Alignment with Citizen’s Focus Action Cluster
|
|||
|
|
This specification document is aligned with the principles defined in the Citizen Focus5 Action
|
|||
|
|
Cluster of the European Innovation Partnership on Smart Cities and Communities. Citizen Focus’ is
|
|||
|
|
about “working together with citizens to realize public interests at the intersection of ICT, mobility
|
|||
|
|
and energy in an urban environment”. We recognize citizens as owners of and participants in
|
|||
|
|
the creation and delivery of city data and digital services, and we specify requirements to deliver
|
|||
|
|
new digital services that will address the societal needs of cities in a positive manner that relates to
|
|||
|
|
political narratives. Societal needs and wants are considered the starting point for city data service
|
|||
|
|
offering by the urban platform. The requirements in this document were elicited considering
|
|||
|
|
|
|||
|
|
• Human behaviour and needs as important as technology;
|
|||
|
|
• The services and data that solve social problems and drive innovation;
|
|||
|
|
• The mechanisms that make data and services more accessible to users;
|
|||
|
|
• The factors that influences user’s experience while interacting with services provided (e.g.
|
|||
|
|
usability, feeling of security and trust);
|
|||
|
|
|
|||
|
|
|
|||
|
|
5
|
|||
|
|
https://eu-smartcities.eu/node/1333
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 12
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.11.3 Policies to be developed
|
|||
|
|
|
|||
|
|
The following policies have been identified by the Demand Side Engagement Stream as relevant to
|
|||
|
|
this Requirements Specification.
|
|||
|
|
|
|||
|
|
• Data formatting and Metadata Schemes: Urban platforms will require more expansive, robust
|
|||
|
|
and useful data encoding and conversion that what is available in existing data catalogues.
|
|||
|
|
Data preservation policies should be developed to allow data to be stored in formats that can
|
|||
|
|
be migrated, associated with metadata and ontologies to become both humans and machines
|
|||
|
|
readable and understandable, ongoing monitoring for data obsolescence, and migrating data to
|
|||
|
|
systems environments as needed to ensure their continued availability. Current Metadata
|
|||
|
|
schemes (e.g. open data, sensory data ontologies) should be reviewed to see if it meets
|
|||
|
|
current needs for city data management. It is possible that the needs of the urban platform
|
|||
|
|
designed here may require new or additional schemas.
|
|||
|
|
|
|||
|
|
• Data commercialisation: The commercial exploitation of city data and their funding models
|
|||
|
|
are unexplored concepts that we are committed to address. There is an urgent need to define
|
|||
|
|
license agreements and fair commercial and subscription models to allow interoperable open
|
|||
|
|
and proprietary data to co-exist in the platform.
|
|||
|
|
|
|||
|
|
• Data publication and services deployment: Policy development will be needed regarding
|
|||
|
|
ingesting data and deploying data services into the platform, including which users/machines
|
|||
|
|
will be authorized to submit data for publication, the minimum requirements for data submitted
|
|||
|
|
by open and proprietary data publishers, and the removal of resources and services from the
|
|||
|
|
platform.
|
|||
|
|
|
|||
|
|
|
|||
|
|
2. Urban Platform Value Proposition, Use Cases and
|
|||
|
|
Functional Requirements
|
|||
|
|
2.1 From Value Proposition to Platform Specifications
|
|||
|
|
This document uses goal-oriented modelling for eliciting, elaborating, structuring, specifying,
|
|||
|
|
documenting, and modifying requirements. Goals represent the objectives which the urban
|
|||
|
|
platform should achieve through cooperation of actors in the intended system and in the
|
|||
|
|
environment. They capture, at different levels of abstraction, the various objectives the urban
|
|||
|
|
platform under design should achieve. Through goals modelling we consider how the value
|
|||
|
|
proposition and intended solutions connects across the stack, how the urban platform meets city
|
|||
|
|
goals, why the system and its functionality are needed, and how the stakeholders’ interests may be
|
|||
|
|
addressed.
|
|||
|
|
|
|||
|
|
In our specification, we present the overall goal (the value proposition) that the urban platform
|
|||
|
|
should aim to achieve in order to be considered as a viable final product, and a set of sub-goals
|
|||
|
|
(intended solutions) it should maintain in the long run so that the overall goal can be unceasingly
|
|||
|
|
achieved. By using this approach, the low-level technical requirements can be traced back to high-
|
|||
|
|
level strategic objectives of the urban platform. The formal notations used in this document are:
|
|||
|
|
Achieve [“Name of Overall Goal”] and Maintain [“Name of Sub-Goal”]. The requirements of the
|
|||
|
|
Urban Platform are noted for each of the sub-goals, and are presented as a series of statements
|
|||
|
|
regarding the capabilities needed in to achieve the overall goal of the Urban Platform.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 13
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2 Overall Goal: “City data is exploited to its full potential”
|
|||
|
|
An urban platform is an organization of people and systems, which has accepted the responsibility
|
|||
|
|
to preserve city data and make it available for all the stakeholders of smart cities. Ultimately, an
|
|||
|
|
urban platform is a foundation for the full exploitation of city data. Hence, the major goal an Urban
|
|||
|
|
Platform must achieve is “city data is exploited to its full potential”. To achieve this high level goal,
|
|||
|
|
the urban platform must maintain in the long run the five sub-goals illustrated in Figure 3.
|
|||
|
|
|
|||
|
|
Each one of the defined sub-goals co-enables the achievement of the specified high-level (overall)
|
|||
|
|
goal of the urban platform. The sub-goals include the ingestion of city data, metadata generation,
|
|||
|
|
data management, data storage, access, preservation, and administration, provision of engaging
|
|||
|
|
services in the smart cities. These sub-goals are discussed in details in the following sections.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Achieve [City data is exploited How we achieve the platform overall goal?
|
|||
|
|
Why do we need the sub-goals?
|
|||
|
|
to its full effect]
|
|||
|
|
Goal
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Maintain [User s experience is
|
|||
|
|
Maintain [City data is provided
|
|||
|
|
enhanced by the provision of
|
|||
|
|
in a harmonised way]
|
|||
|
|
S ub-Goal 1 S ub-Goal 5 value-added services]
|
|||
|
|
co-ena bles
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Maintain [Resources are managed in Maintain [City data is offered
|
|||
|
|
a safe and intelligent manner] in an accessible manner]
|
|||
|
|
S ub-Goal 2 S ub-Goal 4
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Maintain [City data is orchestrated
|
|||
|
|
in a market place]
|
|||
|
|
S ub-Goal 3
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Figure 3. Platform High-Level Goal and its respective sub-goals.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.2.1 Urban Platform Boundary
|
|||
|
|
|
|||
|
|
The use case diagram illustrated in Figure 4 identifies the boundaries between the actors (either
|
|||
|
|
automated or human) and the urban platform. We have arrived at the urban platform boundary by
|
|||
|
|
inspecting each business use case and determining, in conjunction with the stakeholders needs,
|
|||
|
|
which part of the business use case should be implemented and what part should be done by an
|
|||
|
|
outsourced product (e.g. Billing System) using the framework 4.
|
|||
|
|
|
|||
|
|
This task is technology agnostic and takes into account the abilities of the users/actors, the
|
|||
|
|
constraints, the goals of the urban platform. Table 4 maps out the use cases with their respective
|
|||
|
|
sub-goals and actors.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 14
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Manage Services
|
|||
|
|
|
|||
|
|
S ub-Goal 5
|
|||
|
|
|
|||
|
|
|
|||
|
|
Data Service
|
|||
|
|
Publish City Data
|
|||
|
|
Provider
|
|||
|
|
S ub-Goal 1
|
|||
|
|
|
|||
|
|
|
|||
|
|
<<include>> Deploy Data Services
|
|||
|
|
rules
|
|||
|
|
S ub-Goal 5
|
|||
|
|
|
|||
|
|
Authenticate in the
|
|||
|
|
Manage Resources <<include>>
|
|||
|
|
Platform Platform
|
|||
|
|
S ub-Goal 1 Provider Database
|
|||
|
|
<<include>> Manage Infrastructure System
|
|||
|
|
S ub-Goal 2
|
|||
|
|
|
|||
|
|
Utlise Data Services
|
|||
|
|
City Data <<include>>
|
|||
|
|
Publisher S ub-Goal 5
|
|||
|
|
|
|||
|
|
Store City Data Management
|
|||
|
|
<<include>>
|
|||
|
|
S ub-Goal 2
|
|||
|
|
Systems Services
|
|||
|
|
System
|
|||
|
|
|
|||
|
|
<<include>>
|
|||
|
|
City Data
|
|||
|
|
Consumer
|
|||
|
|
QoS Monitoring
|
|||
|
|
Transmit Data
|
|||
|
|
System
|
|||
|
|
Register in the Platform S ub-Goal 2
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
<<include>>
|
|||
|
|
rules
|
|||
|
|
|
|||
|
|
<<extend>>
|
|||
|
|
rules
|
|||
|
|
Platform
|
|||
|
|
Provider
|
|||
|
|
rules
|
|||
|
|
|
|||
|
|
Commercialise Data
|
|||
|
|
Consume City Data
|
|||
|
|
Services City Data
|
|||
|
|
S ub-Goal 3 S ub-Goal 4
|
|||
|
|
Consumer
|
|||
|
|
<<extend>>
|
|||
|
|
|
|||
|
|
|
|||
|
|
Commercialise
|
|||
|
|
City Data Discover City Data
|
|||
|
|
S ub-Goal 3
|
|||
|
|
S ub-Goal 4
|
|||
|
|
|
|||
|
|
Billing
|
|||
|
|
Management
|
|||
|
|
System
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Authenticate in the Register in the
|
|||
|
|
Platform Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Authenticate Authenticate
|
|||
|
|
Register Consumers Register Publishers
|
|||
|
|
Consumers Publishers
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Figure 4. Simplistic overview of the use cases identified in the early stages of the platform design.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Table 4. Use Cases Mapping with Sub-Goals and Actors
|
|||
|
|
Sub-Goals Use Cases ID Specialised Use Cases Actors
|
|||
|
|
HIGH-LEVEL GOAL: City data is exploited to its
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Publish City Data UC1 User publishes city data via data API’s
|
|||
|
|
City Data Publisher
|
|||
|
|
1. City data is Register as a publisher
|
|||
|
|
UC2 User manually uploads datasets
|
|||
|
|
provided in a in the Platform
|
|||
|
|
harmonised way
|
|||
|
|
full effect
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
User manages resources
|
|||
|
|
Manage Resources UC3 City Data Publisher
|
|||
|
|
User tracks resources usage
|
|||
|
|
|
|||
|
|
Store City Data UC4
|
|||
|
|
2. City data is
|
|||
|
|
managed in a safe Transmit Data UC5 - Management Systems
|
|||
|
|
and intelligent
|
|||
|
|
manner
|
|||
|
|
Manage Infrastructure UC6
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 15
|
|||
|
|
|
|||
|
|
|
|||
|
|
City Data Publisher
|
|||
|
|
Set commercial city data
|
|||
|
|
Platform Provider
|
|||
|
|
Subscribe to proprietary data City Data Consumer
|
|||
|
|
Commercialise City
|
|||
|
|
UC7
|
|||
|
|
Data
|
|||
|
|
Manage commercial data City Data Publisher
|
|||
|
|
|
|||
|
|
3. City data is Manage data subscription City Data Consumer
|
|||
|
|
orchestrated in a
|
|||
|
|
Data Services Provider
|
|||
|
|
market place Set commercial data services
|
|||
|
|
Platform Provider
|
|||
|
|
Subscribe to commercial services Data Services Consumer
|
|||
|
|
Commercialise Data
|
|||
|
|
UC8
|
|||
|
|
Services
|
|||
|
|
Manage commercial services Data Services Provider
|
|||
|
|
|
|||
|
|
Manage services subscription Data Services Consumer
|
|||
|
|
UC9
|
|||
|
|
Register in the Platform City Data Consumer
|
|||
|
|
-
|
|||
|
|
4. City data is Discover City Data City Data Consumer
|
|||
|
|
UC10
|
|||
|
|
offered in an
|
|||
|
|
User consumes city data via data
|
|||
|
|
accessible manner
|
|||
|
|
API’s
|
|||
|
|
Consume City Data UC11 City Data Consumer
|
|||
|
|
User downloads datasets
|
|||
|
|
5. User’s Data Services Provider
|
|||
|
|
Deploy Data Services UC12
|
|||
|
|
experience is Platform Provider
|
|||
|
|
enhanced by the
|
|||
|
|
Manage Services UC13 - Data Services Provider
|
|||
|
|
provision of value-
|
|||
|
|
added services
|
|||
|
|
Utilise Data Services UC14 City Data Consumer
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.3 SUB-GOAL 1: City data is collected in an intelligent manner
|
|||
|
|
Description: The urban platform enables the owners of city data to easily publish both historic and
|
|||
|
|
data streams in the platform, as well as their associated metadata.
|
|||
|
|
Rationale: This sub-goal is maintained by the services and functions to accept the publication of
|
|||
|
|
city data from data providers (of both open and proprietary data) and prepare the contents for
|
|||
|
|
storage and management within the urban platform. Functions include receiving data, performing
|
|||
|
|
quality assurance on data, verifying data formatting and document standards, associating meta-
|
|||
|
|
data information, and coordinating updates to databases and resources management.
|
|||
|
|
|
|||
|
|
Achieve [City data is exploited
|
|||
|
|
to its full effect]
|
|||
|
|
Goal
|
|||
|
|
co-ena bles
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
How we achieve the platform overall goal?
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Maintain [City data is provided in
|
|||
|
|
a harmonised manner]
|
|||
|
|
S ub-Goal 1
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
What actions can maintain the sub-goal?
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Achieve [Register Publisher] Achieve [Publish City Data] Achieve [Manage Resources]
|
|||
|
|
UC1 UC2 UC3
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Figure 5. Sub-Goal 1 “City data is collected in an intelligent manner” refinement.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Drivers: Ensure data is published in an easy and uniform way.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 16
|
|||
|
|
|
|||
|
|
|
|||
|
|
Actions: For Sub-Goal 1 to be maintained in the long-run it requires the efficient realisation of use
|
|||
|
|
cases: “Publish City Data” and “Manage Resources”, as shown in Figure 5.
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.3.1 Use Case: Register Publisher
|
|||
|
|
ID: UC1
|
|||
|
|
Refines: SUB-GOAL 1: City data is collected in an intelligent manner
|
|||
|
|
Pre-condition: Data Publisher is not logged in the system
|
|||
|
|
Actors: Data Publishers
|
|||
|
|
Rationale: Data Publishers can register in the platform and request approval to submit city data.
|
|||
|
|
They provide valid registration details (to be defined) and wait for registration confirmation.
|
|||
|
|
Platform Providers may authorise or not data publishers to offer both open and proprietary city data
|
|||
|
|
in the platform. Data submission agreement is a formal agreement between the Data Provider and
|
|||
|
|
the Urban Platform defining the terms of the content, standards, metadata creation, and license
|
|||
|
|
agreement. The Urban Platform will proactively work with Data Providers to agree on the content,
|
|||
|
|
quality and format of city data. Agreements between Platform and Data Providers may be
|
|||
|
|
renegotiated on a periodic or ad-hoc basis.
|
|||
|
|
Refines into requirements: FREQ.1 to FREQ.5.
|
|||
|
|
|
|||
|
|
Use Case Basic Stimulus and Responses
|
|||
|
|
1. The platform prompts the user for a username and password or
|
|||
|
|
register new account.
|
|||
|
|
2. The user selects registration option.
|
|||
|
|
3. The platform prompts user for publisher registration information (e.g.
|
|||
|
|
username, password, organisation)
|
|||
|
|
4. The user enters in their information.
|
|||
|
|
UC1. Register 5. Platform verifies information and creates account.
|
|||
|
|
Publisher o If non-valid information, platform shows error message and
|
|||
|
|
returns to step 1.
|
|||
|
|
6. Platform provider is requested to approve the account
|
|||
|
|
o Platform acknowledges registration has been successful
|
|||
|
|
o If non approved, platform shows error message and returns to
|
|||
|
|
step 1.
|
|||
|
|
7. End of registration
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.3.2 Use Case: Publish City Data
|
|||
|
|
ID: UC2
|
|||
|
|
Refines: SUB-GOAL 1 - City data is collected in an intelligent manner
|
|||
|
|
Pre-condition: User is authenticated in the platform
|
|||
|
|
Actors: City data publisher
|
|||
|
|
Rationale: The Publish City Data function provides the appropriate mechanisms to receive city data from
|
|||
|
|
authorized data providers. Data may be manually uploaded or submitted via APIs. In general, data providers
|
|||
|
|
with whom the Urban Platform negotiates submission agreements are the providers of proprietary city data
|
|||
|
|
(those producing published material, i.e. publishers) and open data, and they can be either humans or
|
|||
|
|
machines. The providers of the Urban Platform will provide data providers with specifications on the content,
|
|||
|
|
quality and format of data, and publication terms and conditions.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 17
|
|||
|
|
|
|||
|
|
|
|||
|
|
The Publish City Data function may represent a legal transfer of custody for the data in the urban platform,
|
|||
|
|
and may require that special access controls be placed on the contents. This function provides a
|
|||
|
|
confirmation of receipt of data publication to the Producer, which may include a request to resubmit data in
|
|||
|
|
the case of errors resulting from the submission.
|
|||
|
|
Once data has arrived, it must undergo several reviews, including virus checking, format compliance,
|
|||
|
|
metadata minimum requirement agreement, quality and anticipated content and data formatting. The
|
|||
|
|
platform must include the ability to record all actions and decisions made concerning the publication of city
|
|||
|
|
data. The reasons for publication failure (e.g. missing metadata information, non-valid dataset) will be
|
|||
|
|
provided back to the city data publisher. In some cases, the provider can then resubmit corrected data and
|
|||
|
|
metadata information, while in other instances data publication refusal criteria should prevent the publisher
|
|||
|
|
from submitting the same dataset at a later time period (e.g. in cases of suspicious datasets – copyrights
|
|||
|
|
violation, viruses). When data is successfully submitted (either via APIs or manual upload), it will be
|
|||
|
|
processed/prepared for storage into the platform’s database.
|
|||
|
|
Specialised Use Cases: The Use Case Publish City Data data is distinguished into two
|
|||
|
|
specialised Use Cases: “User publishes city data via data API’s (UC2.1)” and “User manually
|
|||
|
|
uploads datasets (UC2.2)”.
|
|||
|
|
Subordinated Use Cases: “Store City Data (UC4)”
|
|||
|
|
Refines into requirements: FREQ 6 to FREQ.26.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Specialised Use Cases Basic Stimulus and Responses
|
|||
|
|
1. Platform provides user with an interface for static data
|
|||
|
|
publication
|
|||
|
|
2. User selects datasets to be uploaded
|
|||
|
|
3. User provides metadata associated with the data (license,
|
|||
|
|
provenance, ownership, semantics) in accordance with defined
|
|||
|
|
standards
|
|||
|
|
UC2.1. User manually 4. User requests data publication
|
|||
|
|
uploads datasets 5. Platform quickly process user’s request for data publication
|
|||
|
|
6. Platform validates data submitted
|
|||
|
|
o If valid data, platform acknowledges data publication has
|
|||
|
|
been successful
|
|||
|
|
o If non-valid data, platform shows error message and returns
|
|||
|
|
to step 1.
|
|||
|
|
7. End of data publication
|
|||
|
|
1. Platform provides user with an interface for real-time data
|
|||
|
|
publication
|
|||
|
|
2. User input data API information
|
|||
|
|
3. User provides metadata associated with the data (license,
|
|||
|
|
provenance, ownership, semantics) in accordance with defined
|
|||
|
|
standards
|
|||
|
|
UC2.2. User publishes 4. User confirm information and request data publication
|
|||
|
|
city data via data API’s 5. Platform quickly process user’s request for data publication
|
|||
|
|
6. Platform validates data submitted
|
|||
|
|
o If valid data, platform acknowledges data publication has
|
|||
|
|
been successful
|
|||
|
|
o If non-valid data, platform shows error message and returns
|
|||
|
|
to step 1
|
|||
|
|
End of data publication
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 18
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.3.3 Use Case: Manage Resources
|
|||
|
|
ID: UC3
|
|||
|
|
Refines: GOAL 1: City data is collected in an intelligent manner
|
|||
|
|
Pre-condition: User successfully authenticates in the platform
|
|||
|
|
Actors: City data publisher
|
|||
|
|
Rationale: Manage resources provides the services and functions for updating, maintaining and
|
|||
|
|
accessing both data and metadata, as well as tracking the usage of resources by users. Ideally
|
|||
|
|
the owners of the resources should be the only authorised user to manage resources, and other
|
|||
|
|
authorised users can track the usage of the resources in the platform. The platform must provide a
|
|||
|
|
database update response indicating the status of the update, avoid update errors to be
|
|||
|
|
propagated in the platform, and should keep an audit trail of all actions to enable rollback. Data
|
|||
|
|
usage tracking includes performing queries on the data management data to generate result sets,
|
|||
|
|
and producing reports from these result sets.
|
|||
|
|
Specialised Use Cases: The Use Case Manage Resources data is distinguished into two
|
|||
|
|
specialised Use Cases: “User manages resources (UC3.1)” and “User tracks resources usage
|
|||
|
|
(UC3.2)”.
|
|||
|
|
Subordinated Use Cases: “Transmit Data (UC5)”
|
|||
|
|
Refines into requirements: FREQ.27 to FREQ.25.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Specialised Use Cases Basic Interactions and Responses
|
|||
|
|
1. Platform provides user with an interface for resources
|
|||
|
|
management (e.g. data and metadata, data usage)
|
|||
|
|
2. User chooses to edit or delete data
|
|||
|
|
3. If edit, user revise metadata associated with the data (license,
|
|||
|
|
provenance, ownership, access-control, semantics);
|
|||
|
|
UC3.1. User manages 4. If delete, user selects dataset(s) to be removed
|
|||
|
|
resources 5. User confirms action
|
|||
|
|
6. Platform quickly process user’s request
|
|||
|
|
7. Platform confirms execution of request
|
|||
|
|
o If valid request, platform acknowledges request has been
|
|||
|
|
processed successfully
|
|||
|
|
o If non-valid request, platform returns to step 1.
|
|||
|
|
8. End of resources management
|
|||
|
|
1. Platform provides user with an interface for resources
|
|||
|
|
management (e.g. data and metadata, data usage)
|
|||
|
|
2. User chooses to visualise usage information of a dataset
|
|||
|
|
UC3.2. User tracks 3. Platform quickly process user’s request for data usage
|
|||
|
|
resources usage information
|
|||
|
|
4. Platform provides user with statistical information about data
|
|||
|
|
usage and data users anonymised information
|
|||
|
|
5. End of data usage tracking.
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.3.4 Functional Requirements
|
|||
|
|
|
|||
|
|
Req. ID UC. ID Description Priority Domain
|
|||
|
|
Societal Needs,
|
|||
|
|
FREQ.1 UC1 Allow data publishers to register to submit data for publication Must
|
|||
|
|
Platform
|
|||
|
|
Tracks data publication agreements between Data and Platform Business Needs,
|
|||
|
|
FREQ.2 UC1 Must
|
|||
|
|
Providers Platform
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 19
|
|||
|
|
|
|||
|
|
|
|||
|
|
Store terms of agreements, and use them to monitor/review/process
|
|||
|
|
FREQ.3 UC1 Must City Data, Platform
|
|||
|
|
data submissions.
|
|||
|
|
Able to add and edit terms of agreement, based on access of level of Business Needs,
|
|||
|
|
FREQ.4 UC1 Must
|
|||
|
|
user. Platform
|
|||
|
|
|
|||
|
|
FREQ.5 UC1 Data publications are managed and monitored Must City Data, Platform
|
|||
|
|
|
|||
|
|
Allow authenticated users from across different organisations to City Data, Platform,
|
|||
|
|
FREQ.6 UC2 Must
|
|||
|
|
publish city data Business Needs
|
|||
|
|
Provide authorization mechanisms for users and sensors to publish
|
|||
|
|
FREQ.7 UC2 Must City Data, Platform
|
|||
|
|
city data
|
|||
|
|
City Data, Platform,
|
|||
|
|
FREQ.9 UC2 Provide mechanisms for static data publication Must
|
|||
|
|
Business Needs
|
|||
|
|
City Data, Platform,
|
|||
|
|
FREQ.10 UC2 Provide mechanisms for real-time data publication Must
|
|||
|
|
Business Needs
|
|||
|
|
|
|||
|
|
FREQ.11 UC2 Enable the publication of metadata Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.12 UC2 Maintain temporal information about the data Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.13 UC2 Support sensory data collection Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.14 UC2 Accepts content in numerous file types/formats Must City Data, Platform
|
|||
|
|
|
|||
|
|
Prompts a request for resubmission to the data provider if an error of
|