Bosch_Demo/LaodingBot
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
52b8dbb8358fbb41c579e14cec2c39c80d0ae790
LaodingBot/files/core_requirements_part5.txt

605 lines
37 KiB
Plaintext
Raw Normal View History

Refactored orchestrator for staged file handling, added structured prompt support, adjusted Feishu file handling
2026-03-08 22:38:29 +08:00
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 Copy Permalink