605 lines
37 KiB
Plaintext
605 lines
37 KiB
Plaintext
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.
|