Refactored orchestrator for staged file handling, added structured prompt support, adjusted Feishu file handling
This commit is contained in:
whlaoding
604
files/core_requirements_part5.txt
Normal file
604
files/core_requirements_part5.txt
Normal file
@@ -0,0 +1,604 @@
|
||||
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.
|
||||
Reference in New Issue
Block a user