• 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 <> Deploy Data Services rules S ub-Goal 5 Authenticate in the Manage Resources <> Platform Platform S ub-Goal 1 Provider Database <> Manage Infrastructure System S ub-Goal 2 Utlise Data Services City Data <> Publisher S ub-Goal 5 Store City Data Management <> S ub-Goal 2 Systems Services System <> City Data Consumer QoS Monitoring Transmit Data System Register in the Platform S ub-Goal 2 <> rules <> rules Platform Provider rules Commercialise Data Consume City Data Services City Data S ub-Goal 3 S ub-Goal 4 Consumer <> 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