601 lines
41 KiB
Plaintext
601 lines
41 KiB
Plaintext
|
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
|
|||
|
|
FREQ.15 UC2 Must City Data, Platform
|
|||
|
|
data transmission or receipt occurs
|
|||
|
|
|
|||
|
|
FREQ.16 UC2 Enable the semantic description of connected devices Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.17 UC2 Gather data from authenticated and authorized devices Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.18 UC2 Validates automatically the successful transfer of the data Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.19 UC2 Performs virus checking on data Must City Data, Platform
|
|||
|
|
|
|||
|
|
Verifies the validity of the submission based on submitter, expected
|
|||
|
|
FREQ.20 UC2 Must City Data, Platform
|
|||
|
|
format, data quality, and completeness
|
|||
|
|
Platform should have built-in checks on the incoming metadata. Data
|
|||
|
|
FREQ.21 UC2 not containing the minimally defined set of attributes should be Must City Data, Platform
|
|||
|
|
returned to the publisher for metadata enhancement.
|
|||
|
|
System should have a user-friendly method of mapping non-standard
|
|||
|
|
FREQ.22 UC2 Should City Data, Platform
|
|||
|
|
metadata elements into approved standard elements.
|
|||
|
|
Once ingested, metadata should be stored in a single common format.
|
|||
|
|
FREQ.23 UC2 This format should be one that ensures against data loss, and allows a Must City Data, Platform
|
|||
|
|
variety of access/distribution options
|
|||
|
|
Data in the repository shall have sufficient technical metadata to
|
|||
|
|
FREQ.24 UC2 assure functionality (e.g. viewing and display) to ensure accessibility Must City Data, Platform
|
|||
|
|
and reusability.
|
|||
|
|
Allows publishers to display and perform manual/visual quality control Business Needs, City
|
|||
|
|
FREQ.25 UC2 Could
|
|||
|
|
assurance via a user-friendly GUI Data, Platform
|
|||
|
|
Business Needs, City
|
|||
|
|
FREQ.26 UC2 Any errors shall prompt a request for resubmission of data Should
|
|||
|
|
Data, Platform
|
|||
|
|
|
|||
|
|
FREQ.27 UC3 Enable data providers to manage their resources Must Business Needs
|
|||
|
|
|
|||
|
|
A minimal set of identifying information/metadata concerning data Business Needs,
|
|||
|
|
FREQ.28 UC3 Must
|
|||
|
|
publication submission must be recorded Platform
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 20
|
|||
|
|
|
|||
|
|
|
|||
|
|
Stores and tracks versions of data. Links /connections between
|
|||
|
|
FREQ.29 UC3 Must City Data, Platform
|
|||
|
|
versions are created and maintained
|
|||
|
|
Give service and data providers access to anonymized data of the Business Needs
|
|||
|
|
FREQ.30 UC3 Should
|
|||
|
|
subscribers of their data or services
|
|||
|
|
City Data, Platform,
|
|||
|
|
FREQ.31 UC3 Enable data providers to maintain and repair data and metadata Should
|
|||
|
|
Business Needs
|
|||
|
|
Tracks data publication agreements between Data and Platform Business Needs,
|
|||
|
|
FREQ.32 UC3 Must
|
|||
|
|
Providers Platform
|
|||
|
|
Store terms of agreements, and use them to monitor/review/process
|
|||
|
|
FREQ.33 UC3 Must City Data, Platform
|
|||
|
|
data submissions.
|
|||
|
|
Able to add and edit terms of agreement, based on access of level of Business Needs,
|
|||
|
|
FREQ.34 UC3 Must
|
|||
|
|
user. Platform
|
|||
|
|
|
|||
|
|
FREQ.35 UC3 Submission volumes and schedules are managed and monitored Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.4 SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
|||
|
|
Rationale: The urban platform enables users to publish, consume and commercialise data, as well
|
|||
|
|
as deploy and manage services all in a secure and privacy protected manner.
|
|||
|
|
|
|||
|
|
Achieve [City data is exploited
|
|||
|
|
to its full effect]
|
|||
|
|
Goal
|
|||
|
|
co-ena bles
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Maintain [Resources are managed in a
|
|||
|
|
safe and intelligent manner]
|
|||
|
|
S ub-Goal 1
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Achieve [Store Data] Achieve [Transmit Data] Achieve [Manage Infrastructure]
|
|||
|
|
UC4 UC5 UC6
|
|||
|
|
|
|||
|
|
|
|||
|
|
Figure 6. Sub-Goal 2 “City data is managed in a safe and intelligent manner” refinement.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Drivers: Ensure data is secured and the identity of users are preserved
|
|||
|
|
Actions: For Sub-Goal 2 to be maintained in the long-run it requires the efficient realisation of use
|
|||
|
|
cases: “Store City Data” and “Retrieve and Transmit City Data”, as shown in Figure 6.
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.4.1 Use Case: Store City Data
|
|||
|
|
ID: UC4
|
|||
|
|
Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
|||
|
|
Pre-condition: Data is successfully published in the platform
|
|||
|
|
Actors: Urban Platform
|
|||
|
|
Rationale: When data is successfully submitted (either via APIs or manual upload), it is
|
|||
|
|
processed/prepared for storage into the platform’s database. This procedure will include the
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 21
|
|||
|
|
|
|||
|
|
|
|||
|
|
generation of unique identifiers to the database, enrichment with ontologies (when applicable),
|
|||
|
|
encrypted (when applicable), signed with digital certificates (when applicable) to ensure that the
|
|||
|
|
data conforms to the platform data formatting, standards, security and regulation. Data may be
|
|||
|
|
converted to accepted formats, as needed (e.g. graph model). A primary goal of the conversion of
|
|||
|
|
content for the platform is the preservation of the content. Priority will be given to preserving the
|
|||
|
|
data accordingly to the policies defined in section (2.6.2). Access-control levels and license models
|
|||
|
|
are associated to data which is subject to restrictions relating to access and conditions of use.
|
|||
|
|
Refines into requirements: FREQ 28 – FREQ 39.
|
|||
|
|
|
|||
|
|
Use Case Basic Interactions and Responses
|
|||
|
|
1. Platform mechanisms converts submitted data into a standard format
|
|||
|
|
2. Security enforcement (e.g. anonymisation, cryptography) is placed on
|
|||
|
|
sensitive information.
|
|||
|
|
UC4. Store City 3. Platform associates with datasets the access-control definitions set by
|
|||
|
|
Data owner of resources.
|
|||
|
|
4. Data is enriched with semantics and is associated with other datasets
|
|||
|
|
5. Platform stores data in a scalable and secure database.
|
|||
|
|
6. End of data storage.
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.4.2 Use Case: Transmit Data
|
|||
|
|
ID: UC5
|
|||
|
|
Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
|||
|
|
Pre-condition: Data is successfully published in the platform
|
|||
|
|
Actors: Urban Platform
|
|||
|
|
Rationale: The platform accepts data retrieval request, validates user’s rights to access the data,
|
|||
|
|
retrieves city data from data storage, and moves a copy of the data to the relevant platform
|
|||
|
|
component for further processing. If special processing is required, the retrieval function accesses
|
|||
|
|
data in staging storage and applies the requested processes. The types of operations, which may
|
|||
|
|
be carried out, include sub-sampling in temporal or spatial dimensions, conversions between
|
|||
|
|
different data types or output formats, and other specialized processing (e.g., data visualisation).
|
|||
|
|
Once it is finalised data will be sent to the appropriate delivery channels (e.g. API’s, GUI). It also
|
|||
|
|
encompasses function to verify corruption during any internal data transfer. This function requires
|
|||
|
|
that all hardware and software within the platform provide notification of potential errors and that
|
|||
|
|
these errors are routed to standard error logs that are checked by the Platform Provider.
|
|||
|
|
Refines into requirements: FREQ 40 to 54.
|
|||
|
|
2.4.3 Use Case: Manage Infrastructure
|
|||
|
|
ID: UC6
|
|||
|
|
Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
|||
|
|
Pre-condition: The platform is available
|
|||
|
|
Actors: Urban Platform
|
|||
|
|
Rationale: Manage infrastructure provides the services and functions for the overall operation of
|
|||
|
|
the urban platform. Administration functions include monitoring quality of service agreements,
|
|||
|
|
auditing data publication to ensure that they meet archive standards, and maintaining configuration
|
|||
|
|
management of system hardware and software. In overall, it provides system engineering
|
|||
|
|
functions to monitor and improve platform operations, and to inventory, report on, and
|
|||
|
|
migrate/update the contents of the platforms’ databases.
|
|||
|
|
Refines into requirements: FREQ 55 to 62.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 22
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Use Case Basic Interactions and Responses
|
|||
|
|
1. Platform keeps monitoring services at run-time to ensure operation
|
|||
|
|
and integrity of city data
|
|||
|
|
o If system failure, the platform activates mechanisms for recovery
|
|||
|
|
UC6. Manage based on pre-defined rules
|
|||
|
|
Infrastructure o Platform logs issue and issue alert messages to platform providers
|
|||
|
|
2. Platform logs operation capabilities (e.g. performance, mean of time
|
|||
|
|
failure, issues, etc.)
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.4.4 Functional Requirements
|
|||
|
|
|
|||
|
|
Req. ID UC. ID Description Priority Domain
|
|||
|
|
A minimal set of identifying information/metadata concerning data Business Needs,
|
|||
|
|
FREQ.28 UC4 Must
|
|||
|
|
publication submission must be recorded. Platform
|
|||
|
|
Stores and tracks versions of data. Links /connections between
|
|||
|
|
FREQ.29 UC4 Must City Data, Platform
|
|||
|
|
versions are created and maintained.
|
|||
|
|
|
|||
|
|
FREQ.30 UC4 Converts data to accepted file formats Must City Data, Platform
|
|||
|
|
|
|||
|
|
Keep sensitive information secured and accessible only to authorized
|
|||
|
|
FREQ.31 UC4 Must City Data, Platform
|
|||
|
|
users
|
|||
|
|
|
|||
|
|
FREQ.32 UC4 Keep user’s personal information protected Should City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.33 UC4 Keep city data and meta-data secured Must Platform Needs
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.34 UC4 Enable privacy preserving mechanisms associated to data Must Platform Needs
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.35 UC4 Model data in accordance with defined standards Must City Data, Platform
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.36 UC4 Support the use of ontologies and semantic modelling of city data Could City Data
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.37 UC4 Support database-level provenance annotation Should City Data
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.38 UC4 Support data-level provenance annotation Should City Data
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.39 UC4 Enable data to be encrypted Should Platform Needs
|
|||
|
|
|
|||
|
|
System must have the ability to search and display metadata, preferably
|
|||
|
|
City Data, Platform
|
|||
|
|
FREQ.40 UC5 in a user-conformable, human readable display as well as in its native Must
|
|||
|
|
Needs
|
|||
|
|
format for machine harvesting and manipulation.
|
|||
|
|
Controls access to data in the repository based on multiple permission
|
|||
|
|
City Data, Platform
|
|||
|
|
FREQ.41 UC5 levels. These permission levels determine the create/edit/read/delete Should
|
|||
|
|
Needs
|
|||
|
|
privileges granted users.
|
|||
|
|
Access rights and conditions of use will be held for each data and its City Data, Platform
|
|||
|
|
FREQ.42 UC5 Should
|
|||
|
|
related metadata. Needs
|
|||
|
|
Access rights and conditions can be inherited from a parent data to any City Data, Platform
|
|||
|
|
FREQ.43 UC5 Could
|
|||
|
|
data designated as a child data (derived information). Needs
|
|||
|
|
Access rights and conditions of use will be machine readable and City Data, Platform
|
|||
|
|
FREQ.44 UC5 Should
|
|||
|
|
actionable. Needs
|
|||
|
|
Access mechanisms must be sufficiently granular to allow the Business Needs, City
|
|||
|
|
FREQ.45 UC5 identification of individual users, in order to maintain audit logs of actions Should
|
|||
|
|
Data, Platform
|
|||
|
|
performed by users.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 23
|
|||
|
|
|
|||
|
|
|
|||
|
|
Maintains the integrity of the database which contains both metadata
|
|||
|
|
FREQ.46 UC5 and system information. Must Platform Needs
|
|||
|
|
|
|||
|
|
Provides internal validation such as referential integrity of the contents of City Data, Platform
|
|||
|
|
FREQ.47 UC5 the database. Must
|
|||
|
|
Needs
|
|||
|
|
Creates and maintains schema definitions required to support data
|
|||
|
|
FREQ.48 UC5 management functions. Must Platform Needs
|
|||
|
|
|
|||
|
|
Monitors and ensures that data and metadata are not corrupted during
|
|||
|
|
FREQ.49 UC5 transfers. Must Platform Needs
|
|||
|
|
|
|||
|
|
Provides statistically acceptable assurance that no components of the
|
|||
|
|
FREQ.50 UC5 data are corrupted during any internal data transfer. Must Platform Needs
|
|||
|
|
|
|||
|
|
Performs routine and special data integrity checking for each dataset
|
|||
|
|
FREQ.51 UC5 and generates error reports. Must Platform Needs
|
|||
|
|
|
|||
|
|
Provides disaster recovery capabilities including data backup, off-site
|
|||
|
|
FREQ.52 UC5 data storage, data recovery, etc. Must Platform Needs
|
|||
|
|
|
|||
|
|
Refresh/replace data without service interruption, and update
|
|||
|
|
FREQ.53 UC5 corresponding metadata as appropriate. Must Platform Needs
|
|||
|
|
|
|||
|
|
Ensure that any associated unique identifiers of the updated data are not
|
|||
|
|
FREQ.54 UC5 altered. Must Platform Needs
|
|||
|
|
|
|||
|
|
Audits submissions to ensure that they meet archive/repository
|
|||
|
|
FREQ.55 UC6 standards. Must Platform Needs
|
|||
|
|
|
|||
|
|
Maintains configuration management of the system hardware and
|
|||
|
|
FREQ.56 UC6 software. Must Platform Needs
|
|||
|
|
|
|||
|
|
Has capability to inventory, report on and migrate the contents of the
|
|||
|
|
FREQ.57 UC6 repository. Must Platform Needs
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.58 UC6 Ensures data integrity for version upgrades and format migration. Must Platform Needs
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.59 UC6 Monitors functionality of the entire repository. Must Platform Needs
|
|||
|
|
|
|||
|
|
|
|||
|
|
FREQ.60 UC6 Maintains integrity of system configuration. Must Platform Needs
|
|||
|
|
|
|||
|
|
Audits system operations, performance and usage.
|
|||
|
|
FREQ.61 UC6 Must Platform Needs
|
|||
|
|
|
|||
|
|
Provides platform performance information and database holdings
|
|||
|
|
FREQ.62 UC6 inventory reports Must Platform Needs
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
2.5 SUB-GOAL 3: City data is orchestrated in a marketplace
|
|||
|
|
Rationale: The urban platform enables users to consume and publish data in a secure and privacy
|
|||
|
|
protected manner.
|
|||
|
|
Drivers: Ensure data is secured and the identity of users are preserved
|
|||
|
|
Actions: For Sub-Goal 3 to be maintained in the long-run it requires the efficient realisation of use
|
|||
|
|
cases: “Commercialise City Data” and “Commercialise Data Services”, as shown in Figure 7.
|
|||
|
|
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 24
|
|||
|
|
|
|||
|
|
|