Consume City o If authentication is successful, users are provided with requested Data via APIs data streams 3. Users are provided with requested data via APIs 2.6.4 Functional Requirements Req. ID UC. ID Description Priority Domain Allow users to register to use services and consume proprietary city Societal Needs, FREQ.74 UC9 Should data and open data (optional) Platform Keep sensitive information secured and accessible only to Societal Needs, FREQ.75 UC9 Should authorized users Platform Societal Needs, FREQ.76 UC9 Provide authentication mechanisms for users Must Platform Societal Needs, FREQ.77 UC9 Keep user’s personal information protected Must Platform Allow users to control which data they are willing to provide and how Societal Needs, FREQ.78 UC9 Must their data should be used Platform Societal Needs, FREQ.79 UC10 Allow users to format data in any supported data formats Must Platform The query request may require data to be sourced from different Societal Needs, FREQ.80 UC10 Must storage locations Platform Allows query requests against all metadata used to manage the Societal Needs, FREQ.81 UC10 repository. Should Platform Provide users information about the legal aspects of the data Societal Needs, FREQ.82 UC11 Must (license, ownership) City Data Societal Needs, FREQ.83 UC11 Keeps an audit trail of all actions. Must City Data Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 31 2.7 SUB-GOAL 5: User’s experience is enhanced by the provision of value-added services 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 5 to be maintained in the long-run it requires the efficient realisation of use cases: “Deploy Data Services”, “Manage Services”, and “Utilise Data Services” as shown in Figure 8. Achieve [City data is exploited to its full effect] Goal co-ena bles Maintain [User s experience is enhanced by the provision of value-added services] S ub-Goal 1 Achieve [Deploy Data Services] Achieve [Manage Services] Achieve [Utilise Data Services] UC12 UC13 UC14 Figure 9. Sub-Goal 5 “User’s experience is enhanced by the provision of value-added services” refinement 2.7.1 Deploy Data Services ID: UC12 Refines: SUB-GOAL 5: User’s experience is enhanced by the provision of value-added services Pre-condition: Data Services Providers are provided with credentials, are authorised to deploy their services in the platform, and have access to technical specifications of the platform interfaces. Actors: Data Services Providers Rationale: Data Services can register in the platform and request approval to deploy services in the platform. They provide valid registration details (to be defined) and wait for registration confirmation. Platform Providers may authorise or not data services providers to offer both open and proprietary services in the platform. Data services providers must formally agree with service deployment agreement with the Urban Platform. This agreement defines terms of the content, policies, regulations, license agreement. The Urban Platform will proactively work with Service Providers to agree on the technical specifications of interfaces and platform openness level. Agreements between Platform and Data Service Providers may be renegotiated on a periodic or ad-hoc basis. Refines into requirements: FREQ.1 to FREQ.5. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 32 Use Case Basic Stimulus and Responses 1. User authenticates in the platform 2. User is provided access to platform interfaces for service deployment 3. User deploy services 4. Platform checks compatibility and any technical issues arising from the UC12. Deploy new service Services 5. If approved the service is ready to be used and managed in the platform o If deployment is not approved, platform shows error message and returns to step 1. 6. End of deployment 2.7.2 Use Case: Manage Services ID: UC13 Refines: GOAL 5: User’s experience is enhanced by the provision of value-added services Pre-condition: User successfully authenticates in the platform Actors: Data Services Providers Rationale: Manage services provides the functions for updating, maintaining and accessing services as well as tracking their usage by users. Ideally the owners of the services should be the only authorised user to manage them, and other authorised users can track the usage of the services in the platform. In case of updates the platform must log in the database update details and send to service providers a response indicating the status of the update. The platform should also ensure update errors are not propagated nor affect the health of other services provided in the platform, and should keep an audit trail of all actions to enable rollback. Data services usage tracking includes performing queries on the data management data to generate result sets, and producing reports from these result sets. All user’s information provided to service providers must follow regulations of data protection and the user’s defined rules for their data use. Specialised Use Cases: The Use Case Manage Services is distinguished into two specialised Use Cases: “User manages services (UC13.1)” and “User tracks service usage (UC13.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 services management 2. User chooses to edit or delete services 3. If edit, user revise service information (access-control, commercial models, parameters) and deployment; If delete, user selects services to be removed / disabled UC13.1. User manages 4. User confirms action services 5. Platform quickly process user’s request 6. 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. 7. End of services management Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 33 1. Platform provides user with an interface for services management 2. User chooses to visualise usage information of a service 3. Platform quickly process user’s request for data usage UC13.2. User tracks information services usage 4. Platform provides user with statistical information about services usage and data users anonymised information 5. End of data services tracking. 2.7.3 Use Case: Utilise Data Services 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: Data Consumers can register in the platform and request approval to consume city data via GUI or APIs. They provide valid registration details (to be defined) and wait for platform to confirm their registration. Subordinated Use Cases: “Commercialise Data Services (UC8)” Refines into requirements: FREQ 6 to FREQ.26. Specialised Use Cases Basic Interactions and Responses 1. Users / Machines select data service to be utilised 2. Users / Machines are redirected to authentication mechanism in UC2.1. User utilises data case of registration is needed for the particular service services o If authentication is successful, users are provided with requested data streams 3. Users are provided with requested service either via API or GUI 2.7.4 Functional Requirements Req. ID UC. ID Description Priority Domain Provide stable and well-defined interfaces to ensure interoperability Societal Needs, FREQ.84 UC12 between the platform, services and the applications provided by Should Platform services providers Ensure the interfaces of the architecture are open to reduce entry Societal Needs, FREQ.85 UC12 Should barriers and integration issues Platform Provide multi-purposed and network intelligent interfaces to Societal Needs, FREQ.86 UC12 Must providers and consumers of services Platform Provide service providers mechanisms to define the terms and Societal Needs, FREQ.87 UC12 Must conditions of platform services deployment Platform Business Needs, FREQ.88 UC13 Provide statistical information of user’s feedback on service usage Must Platform Allow users to use services to manipulate city data (e.g. Create Societal Needs, FREQ.89 UC10 Must mash ups, integrate) Platform Allow users to provide feedback on usability, and quality of data Societal Needs, FREQ.90 UC14 Must and services provided by the platform Platform Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 34 3. Non-functional Requirements 3.1 Run-time Quality Requirements 3.1.1 Scalability Requirements Rationale: The ability of the system to execute its task within its expected performance profile and to handle on-demand increased processing volumes of data and service requests Drivers: Provide ready access to all data that underpins decision making processes in smart cities, and accommodate users and data usage patterns Refines into requirements: NFREQ.1, NFREQ.2, NFREQ.3, NFREQ.4 Relevance: Urban platforms have ambitious performance requirements. Such platforms must cope with user’s demand for data and services, capture real-time data that will be catalysed by a myriad of sensors. The demand for urban platform is very likely to significantly increase over time. It is very difficult to have clear performance characteristics due to the ubiquity, heterogeneity high connectivity of devices and end users. SCALABILITY MEASURES Actions Capture the performance requirements Create service level agreements Predict scalability using software simulation Analyse the performance of the platform overtime Conduct practical testing Strategy Prioritize service and data requests Distribute processing over time Scale up or scale out as necessary Reuse resources and results Partition and parallelize Constantly monitor Quality of Service at runtime 3.1.2 Availability and Reliability Requirements Rationale: The ability of the system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability Drivers: Build a reliable foundation for “on demand” exploitation of data Refines into requirements: NFREQ.5, NFREQ.6, NFREQ.7, NFREQ.8 Relevance: Any system that has complex or extended availability requirements, complex recovery processes, or a high profile (e.g., is visible to the public) AVAILABILITY AND RELIABILITY MEASURES Actions Capture the availability requirements Produce the availability schedule Estimate platform availability Estimate functional availability Assess against the requirements Rework the architecture Strategy Adopt fault-tolerant hardware Use reliable infrastructure database Log transactions Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 35 Develop adaptive software to cope and recover from faults Design and test for failure Deploy load balancing Identify suitable backup and disaster recovery solution 3.1.3 Trust Requirements Rationale: A quality related to the user’s belief in the reliability, integrity and ability of the functional behaviour of the platform Drivers: Gain understanding of what influences user’s experience while interacting with services provided Requirements: NFREQ.16, NFREQ.17 Relevance: Relevant to the systems that share and collect information that may raise public concern. In some cases, trust has to do with the reliability of data and their providers, whereas in other cases trust can be associated with the security and privacy of the technology that was deployed. Trust affects the reputation of the platform besides its dissemination and maturity on the market. TRUST MEASURES Capture trust requirements Perform risk analysis so measures can be implemented Actions Explore the vulnerability aspects of city data Check whether extensibility requirements impact on trust Define a trust model Adopt trust model Deploy monitoring capabilities and assess its impact on scalability Manage the data in a way that ensures its compliance with data Strategy protection regulations Implement tampering and data misuse detection Make use of Cryptography when necessary Allow Federation of trust between platforms 3.1.4 Security Requirements Rationale: Ability of the system to enforce the intended confidentiality, trust, integrity and service and data access policies, and to detect and recover from failure in these security mechanisms. Drivers: Manage the data and services in a way that ensures its integrity, and compliance with data protection regulations Relevance: Relevant to the systems that share and collect information that may raise public concern. Urban platforms may become a valuable target for attackers which can potentially leave huge swathes of information exposed. It could potentially undermine trust in the government and damage its reputation. Refines into requirements: NFREQ.9 to NFREQ.15 Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 36 SECURITY MEASURES Elicit the security requirements Cross-check security requirements’ impact on services offered by different providers Verify security impact on service composition Conduct risk analysis and impacts of security breach Use scalable and efficient user authentication components Use authentication and authorization components to secure interfacing with Actions external services Address aspects of data collection, storage and distribution Address aspects of service and communication security among devices Identify security requirements of the physical infrastructure Balance and prioritize scalability (performance) and security requirements Evaluate trade-offs between privacy considerations and preventing abuse. (While anonymous access guarantees privacy of users, traceability of users due to abuse of the service is not possible.) Toughen user’s functional components Authenticate subjects Define and enforce access policies Secure communication infrastructures Secure interfaces with external systems and services Strategy Secure databases Check data integrity for critical services User digital certificates and encryption where necessary Secure monetary transactions Secure user’s personal information 3.1.5 Privacy Requirements Rationale: Ability of the system to ensure that the collection and transmission of personal data is minimized and handled in accordance with user’s expectation and regulations. Drivers: Protect the vulnerability aspects volunteered citizen’s data Requirements: NFREQ.18, NFREQ.19, NFREQ.20, NFREQ.21, NFREQ.22 Relevance: Ensuring users privacy is protected positively influences user’s experience, acceptance and continuous use of the platform. Besides other factors, the reputation of the platform depends on how well user’s information is secure and preserved. PRIVACY MEASURES Capture trust requirements Perform risk analysis so measures can be implemented Actions Explore the vulnerability aspects of city data Check whether extensibility requirements impact on trust Define a trust model Allow users to interact with the platform anonymously in given circumstances Manage users identification securely Strategy Anonymize data whenever necessary to comply with data regulations Cryptograph personal identifiers during data transmission when that is necessary Avoid unauthorized access to implicit information (e.g. location) Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 37 Verify the impact of security, trust and scalability requirements trade-offs on privacy Allow the user to control how personal information is used Empower user to control the data disclosure mechanism 3.2 Non Run-time Quality Requirements 3.2.1 Evolvability Requirements Rationale: The ability of the platform to withstand and easily adapt when new requirements and changes is introduced. Drivers: Ensure the platform is able to accommodate additional functionality and emerging technologies at later stage at a fair and transparent cost Refines into requirements: NFREQ.23 Relevance: Important for longer- lived and more widely used systems. Urban platforms are expected to be highly evolvable in order to accommodate future emerging technologies and avoid interoperability issues. EVOLVABILITY MEASURES Actions Characterize and assess the evolution needs Consider the evolution trade-offs Balance and negotiate potential conflicting requirements emerging from the evolution capability. Strategy Adopt standards and open interfaces Design loose-coupled components Preserve the platform resilience 3.2.2 Extensibility Requirements Rationale: The flexibility of the system to allow services and functionality to be extended and augmented by service providers in order to increase value of services to both platform providers and end-users. The extension of the platform services is determined by the Platform Openness strategy. Drivers: Stakeholders can extend the services provided by the urban platform, so that partnerships can be built to deliver holistic and interoperable solutions. Identify integrated approaches to design and service delivery which ensures that services fit together and that synergies can be exploited. Refines into requirements: NFREQ.24, NFREQ.25 Relevance: Important for longer- lived and more widely used systems. Urban platforms are expected to be highly evolvable in order to accommodate future emerging technologies and avoid interoperability issues. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 38 EXTENSIBILITY Actions Characterize and assess the extensibility needs Trace the impacts and cost of extensions Negotiate potential conflicting requirements emerging from adding extensions in the platform Strategy Develop a modular architecture with standard interfaces that reduces entry barriers due to increased transparency and integration Share technical information about interfaces will help service providers in targeting opportunities around the platform 3.3 List of Non-Functional Requirements ID # Description Concern Priority Domain Platform, NFREQ.1 Support different service level agreements (SLA) Scalability Should Infrastructure Platform, NFREQ.2 Process services and events on a set of distributed nodes Scalability Should Infrastructure Platform, NFREQ.3 Continuously monitor Quality of Service at runtime Scalability Should Infrastructure Platform, NFREQ.4 Balance its load at runtime Scalability Should Infrastructure Platform, NFREQ.5 Provide high availability Availability Should Infrastructure Platform, NFREQ.6 Guarantee infrastructure availability Availability Should Infrastructure Platform, NFREQ.7 Ensure network availability Availability Should Infrastructure Platform, NFREQ.8 Be able to perform self-healing Availability Should Infrastructure City Data, NFREQ.9 Expose data and services to authorized users Security Must Platform City Data, NFREQ.10 Ensure services are always accessible to entitled users Security Must Platform NFREQ.11 Ensure Data Freshness Security Must Platform NFREQ.12 Support access control mechanisms Security Must Platform Platform, NFREQ.13 Have security mechanisms to protect data transmission Security Should Infrastructure Platform, NFREQ.14 Make it difficult to spy on communicated messages Security Should Infrastructure Platform, NFREQ.15 Be able to perform to detect threats at runtime Security Should Infrastructure Provide trusted and secure communication and information Platform, NFREQ.16 Trust Should management Infrastructure NFREQ.17 The platform infrastructure and services shall be trustable Trust Should Infrastructure Societal Needs, NFREQ.18 Allow users to use free services anonymously Privacy Should Platform Societal Needs, NFREQ.19 Allow people to use free services anonymously Privacy Should Platform Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 39 Allow users to control which data they are willing to provide Societal Needs, NFREQ.20 Privacy Should and how their data should be used Platform NFREQ.21 Keep users access-control rights/ policies secured. Privacy Should Platform Provide privacy protection for users interacting with the Societal Needs, NFREQ.22 Privacy Should platform Platform Platform, NFREQ.23 Provide communication confidentiality Privacy Should Infrastructure Societal Needs, NFREQ.24 Be extensible for future technologies. Evolvability Must City Data, Platform, Infrastructure Platform, NFREQ.26 Provide standard interfaces for service providers Extensibility Should Business Needs NFREQ.26 Be able to provide services in an interoperable manner Extensibility Should Platform 4. Other Requirements 4.1 Minimal Descriptive Metadata Required from Data Provider Minimal Descriptive Metadata Required from Data Provider Attribute Required Definition Notes Examples Database Name Y A name given to the resource Author Name of a person or body associated with Y the creation of the resource Maintainer Name of the entity responsible for making Y the resource available Date Created Y Date the dataset was created Date Modified Y Date the dataset was modified Last Revision Y Date the dataset was last revised Update Frequency Y Frequency of data maintenance Mode of Release Y Open/Proprietary Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 40 4.2 Urban Platform Supported Data Formats MIME type Description Extensions Level application/json JavaScript Object Notation json supported application/xml eXtensible markup language file xml supported text/csv Comma separated values file csv supported 5. Conclusion & Forward Plans This document represents the first set of requirements specification for urban platform. Future activities will collaboratively assess, resolve requirements conflicts, prioritize, and validate the requirements of the urban platform. Ultimately, this document will become a complete final requirements specification document to guide and speed up the development open platform for cities. Table below shows the milestones, deliverables and engagement activities completed and yet to be completed by the Demand Side Engagement Stream. Milestones, deliverables and engagement activity Forecast date Status Stakeholders invitation Late Completed September/2015 Online Workshop 1: Project Scope and Outcomes 20/11/2015 Completed Online meeting held with city members to communicate goals, expected outcomes, time commitment and required actions. Start of Collaborative Requirements Engineering Process 20/11/2015 Completed Participants reviewed the first draft of urban platform requirements, provided comments, and suggested new requirements and changes. Online Workshop 2: Review and Refine Requirements 08/12/2015 Completed Participants had a conference call to review the requirements specification document and provide their comments. Deliverable: Requirements Specification Document v2.1 shared 05/01/2016 Completed across the Working Streams for consultation Online Workshop 3: Review Requirements Specification 12/01/2016 Completed Document and discussion of Letter of Intent Participants had a conference call to review the requirements specification document and provide their comments, and discussed the Letter of Intent to be signed by Mayor/Equiv of EU cities to commit to application of common U.P. approach. Urban Platforms Workshop in Brussels 19/01/2016 Completed Participants provided feedback on the requirements specification document and recommended changes in the document Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 41 Deliverable: Updated Requirements Specification Document v2.2 29/01/2016 Completed shared with Industry and Standardisation Working Streams Deliverable: Online release of the Requirements Specification Early Document and open calls for wider consultation on the Requirements February/2016 Online Workshop 4: Engagement with Industry Side Early Capture industry feedback on the Requirements Specification February/2016 Document to assess its suitability to drive the development of the first draft reference architecture. Online Workshop 5: Review Requirements Specification Mid Document v2.2 and discuss requirement prioritization and February/2016 balancing Collectively determine which candidate requirements of urban platforms should be prioritized as high importance to all the cities (use of Value Oriented Prioritization Method). Requirements are also prioritized to minimize risk during development of urban platforms so that the most important requirements are made explicit and considered in the reference architecture. Capture of case studies from cities intended to support requirements Mid March/2016 validation (City of Porto), and learning and confidence building amongst cities.