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.
|