Refactored orchestrator for staged file handling, added structured prompt support, adjusted Feishu file handling
This commit is contained in:
whlaoding
700
files/core_requirements_part4.txt
Normal file
700
files/core_requirements_part4.txt
Normal file
@@ -0,0 +1,700 @@
|
||||
city data via data API’s 5. Platform quickly process user’s request for data publication
|
||||
6. Platform validates data submitted
|
||||
o If valid data, platform acknowledges data publication has
|
||||
been successful
|
||||
o If non-valid data, platform shows error message and returns
|
||||
to step 1
|
||||
End of data publication
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 18
|
||||
|
||||
|
||||
2.3.3 Use Case: Manage Resources
|
||||
ID: UC3
|
||||
Refines: GOAL 1: City data is collected in an intelligent manner
|
||||
Pre-condition: User successfully authenticates in the platform
|
||||
Actors: City data publisher
|
||||
Rationale: Manage resources provides the services and functions for updating, maintaining and
|
||||
accessing both data and metadata, as well as tracking the usage of resources by users. Ideally
|
||||
the owners of the resources should be the only authorised user to manage resources, and other
|
||||
authorised users can track the usage of the resources in the platform. The platform must provide a
|
||||
database update response indicating the status of the update, avoid update errors to be
|
||||
propagated in the platform, and should keep an audit trail of all actions to enable rollback. Data
|
||||
usage tracking includes performing queries on the data management data to generate result sets,
|
||||
and producing reports from these result sets.
|
||||
Specialised Use Cases: The Use Case Manage Resources data is distinguished into two
|
||||
specialised Use Cases: “User manages resources (UC3.1)” and “User tracks resources usage
|
||||
(UC3.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 resources
|
||||
management (e.g. data and metadata, data usage)
|
||||
2. User chooses to edit or delete data
|
||||
3. If edit, user revise metadata associated with the data (license,
|
||||
provenance, ownership, access-control, semantics);
|
||||
UC3.1. User manages 4. If delete, user selects dataset(s) to be removed
|
||||
resources 5. User confirms action
|
||||
6. Platform quickly process user’s request
|
||||
7. 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.
|
||||
8. End of resources management
|
||||
1. Platform provides user with an interface for resources
|
||||
management (e.g. data and metadata, data usage)
|
||||
2. User chooses to visualise usage information of a dataset
|
||||
UC3.2. User tracks 3. Platform quickly process user’s request for data usage
|
||||
resources usage information
|
||||
4. Platform provides user with statistical information about data
|
||||
usage and data users anonymised information
|
||||
5. End of data usage tracking.
|
||||
|
||||
|
||||
2.3.4 Functional Requirements
|
||||
|
||||
Req. ID UC. ID Description Priority Domain
|
||||
Societal Needs,
|
||||
FREQ.1 UC1 Allow data publishers to register to submit data for publication Must
|
||||
Platform
|
||||
Tracks data publication agreements between Data and Platform Business Needs,
|
||||
FREQ.2 UC1 Must
|
||||
Providers Platform
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 19
|
||||
|
||||
|
||||
Store terms of agreements, and use them to monitor/review/process
|
||||
FREQ.3 UC1 Must City Data, Platform
|
||||
data submissions.
|
||||
Able to add and edit terms of agreement, based on access of level of Business Needs,
|
||||
FREQ.4 UC1 Must
|
||||
user. Platform
|
||||
|
||||
FREQ.5 UC1 Data publications are managed and monitored Must City Data, Platform
|
||||
|
||||
Allow authenticated users from across different organisations to City Data, Platform,
|
||||
FREQ.6 UC2 Must
|
||||
publish city data Business Needs
|
||||
Provide authorization mechanisms for users and sensors to publish
|
||||
FREQ.7 UC2 Must City Data, Platform
|
||||
city data
|
||||
City Data, Platform,
|
||||
FREQ.9 UC2 Provide mechanisms for static data publication Must
|
||||
Business Needs
|
||||
City Data, Platform,
|
||||
FREQ.10 UC2 Provide mechanisms for real-time data publication Must
|
||||
Business Needs
|
||||
|
||||
FREQ.11 UC2 Enable the publication of metadata Must City Data, Platform
|
||||
|
||||
|
||||
FREQ.12 UC2 Maintain temporal information about the data Must City Data, Platform
|
||||
|
||||
|
||||
FREQ.13 UC2 Support sensory data collection Must City Data, Platform
|
||||
|
||||
|
||||
FREQ.14 UC2 Accepts content in numerous file types/formats Must City Data, Platform
|
||||
|
||||
Prompts a request for resubmission to the data provider if an error of
|
||||
FREQ.15 UC2 Must City Data, Platform
|
||||
data transmission or receipt occurs
|
||||
|
||||
FREQ.16 UC2 Enable the semantic description of connected devices Must City Data, Platform
|
||||
|
||||
|
||||
FREQ.17 UC2 Gather data from authenticated and authorized devices Must City Data, Platform
|
||||
|
||||
|
||||
FREQ.18 UC2 Validates automatically the successful transfer of the data Must City Data, Platform
|
||||
|
||||
|
||||
FREQ.19 UC2 Performs virus checking on data Must City Data, Platform
|
||||
|
||||
Verifies the validity of the submission based on submitter, expected
|
||||
FREQ.20 UC2 Must City Data, Platform
|
||||
format, data quality, and completeness
|
||||
Platform should have built-in checks on the incoming metadata. Data
|
||||
FREQ.21 UC2 not containing the minimally defined set of attributes should be Must City Data, Platform
|
||||
returned to the publisher for metadata enhancement.
|
||||
System should have a user-friendly method of mapping non-standard
|
||||
FREQ.22 UC2 Should City Data, Platform
|
||||
metadata elements into approved standard elements.
|
||||
Once ingested, metadata should be stored in a single common format.
|
||||
FREQ.23 UC2 This format should be one that ensures against data loss, and allows a Must City Data, Platform
|
||||
variety of access/distribution options
|
||||
Data in the repository shall have sufficient technical metadata to
|
||||
FREQ.24 UC2 assure functionality (e.g. viewing and display) to ensure accessibility Must City Data, Platform
|
||||
and reusability.
|
||||
Allows publishers to display and perform manual/visual quality control Business Needs, City
|
||||
FREQ.25 UC2 Could
|
||||
assurance via a user-friendly GUI Data, Platform
|
||||
Business Needs, City
|
||||
FREQ.26 UC2 Any errors shall prompt a request for resubmission of data Should
|
||||
Data, Platform
|
||||
|
||||
FREQ.27 UC3 Enable data providers to manage their resources Must Business Needs
|
||||
|
||||
A minimal set of identifying information/metadata concerning data Business Needs,
|
||||
FREQ.28 UC3 Must
|
||||
publication submission must be recorded Platform
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 20
|
||||
|
||||
|
||||
Stores and tracks versions of data. Links /connections between
|
||||
FREQ.29 UC3 Must City Data, Platform
|
||||
versions are created and maintained
|
||||
Give service and data providers access to anonymized data of the Business Needs
|
||||
FREQ.30 UC3 Should
|
||||
subscribers of their data or services
|
||||
City Data, Platform,
|
||||
FREQ.31 UC3 Enable data providers to maintain and repair data and metadata Should
|
||||
Business Needs
|
||||
Tracks data publication agreements between Data and Platform Business Needs,
|
||||
FREQ.32 UC3 Must
|
||||
Providers Platform
|
||||
Store terms of agreements, and use them to monitor/review/process
|
||||
FREQ.33 UC3 Must City Data, Platform
|
||||
data submissions.
|
||||
Able to add and edit terms of agreement, based on access of level of Business Needs,
|
||||
FREQ.34 UC3 Must
|
||||
user. Platform
|
||||
|
||||
FREQ.35 UC3 Submission volumes and schedules are managed and monitored Must City Data, Platform
|
||||
|
||||
|
||||
|
||||
|
||||
2.4 SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
||||
Rationale: The urban platform enables users to publish, consume and commercialise data, as well
|
||||
as deploy and manage services all in a secure and privacy protected manner.
|
||||
|
||||
Achieve [City data is exploited
|
||||
to its full effect]
|
||||
Goal
|
||||
co-ena bles
|
||||
|
||||
|
||||
|
||||
|
||||
Maintain [Resources are managed in a
|
||||
safe and intelligent manner]
|
||||
S ub-Goal 1
|
||||
|
||||
|
||||
|
||||
|
||||
Achieve [Store Data] Achieve [Transmit Data] Achieve [Manage Infrastructure]
|
||||
UC4 UC5 UC6
|
||||
|
||||
|
||||
Figure 6. Sub-Goal 2 “City data is managed in a safe and intelligent manner” refinement.
|
||||
|
||||
|
||||
|
||||
Drivers: Ensure data is secured and the identity of users are preserved
|
||||
Actions: For Sub-Goal 2 to be maintained in the long-run it requires the efficient realisation of use
|
||||
cases: “Store City Data” and “Retrieve and Transmit City Data”, as shown in Figure 6.
|
||||
|
||||
|
||||
2.4.1 Use Case: Store City Data
|
||||
ID: UC4
|
||||
Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
||||
Pre-condition: Data is successfully published in the platform
|
||||
Actors: Urban Platform
|
||||
Rationale: When data is successfully submitted (either via APIs or manual upload), it is
|
||||
processed/prepared for storage into the platform’s database. This procedure will include the
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 21
|
||||
|
||||
|
||||
generation of unique identifiers to the database, enrichment with ontologies (when applicable),
|
||||
encrypted (when applicable), signed with digital certificates (when applicable) to ensure that the
|
||||
data conforms to the platform data formatting, standards, security and regulation. Data may be
|
||||
converted to accepted formats, as needed (e.g. graph model). A primary goal of the conversion of
|
||||
content for the platform is the preservation of the content. Priority will be given to preserving the
|
||||
data accordingly to the policies defined in section (2.6.2). Access-control levels and license models
|
||||
are associated to data which is subject to restrictions relating to access and conditions of use.
|
||||
Refines into requirements: FREQ 28 – FREQ 39.
|
||||
|
||||
Use Case Basic Interactions and Responses
|
||||
1. Platform mechanisms converts submitted data into a standard format
|
||||
2. Security enforcement (e.g. anonymisation, cryptography) is placed on
|
||||
sensitive information.
|
||||
UC4. Store City 3. Platform associates with datasets the access-control definitions set by
|
||||
Data owner of resources.
|
||||
4. Data is enriched with semantics and is associated with other datasets
|
||||
5. Platform stores data in a scalable and secure database.
|
||||
6. End of data storage.
|
||||
|
||||
|
||||
2.4.2 Use Case: Transmit Data
|
||||
ID: UC5
|
||||
Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
||||
Pre-condition: Data is successfully published in the platform
|
||||
Actors: Urban Platform
|
||||
Rationale: The platform accepts data retrieval request, validates user’s rights to access the data,
|
||||
retrieves city data from data storage, and moves a copy of the data to the relevant platform
|
||||
component for further processing. If special processing is required, the retrieval function accesses
|
||||
data in staging storage and applies the requested processes. The types of operations, which may
|
||||
be carried out, include sub-sampling in temporal or spatial dimensions, conversions between
|
||||
different data types or output formats, and other specialized processing (e.g., data visualisation).
|
||||
Once it is finalised data will be sent to the appropriate delivery channels (e.g. API’s, GUI). It also
|
||||
encompasses function to verify corruption during any internal data transfer. This function requires
|
||||
that all hardware and software within the platform provide notification of potential errors and that
|
||||
these errors are routed to standard error logs that are checked by the Platform Provider.
|
||||
Refines into requirements: FREQ 40 to 54.
|
||||
2.4.3 Use Case: Manage Infrastructure
|
||||
ID: UC6
|
||||
Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner
|
||||
Pre-condition: The platform is available
|
||||
Actors: Urban Platform
|
||||
Rationale: Manage infrastructure provides the services and functions for the overall operation of
|
||||
the urban platform. Administration functions include monitoring quality of service agreements,
|
||||
auditing data publication to ensure that they meet archive standards, and maintaining configuration
|
||||
management of system hardware and software. In overall, it provides system engineering
|
||||
functions to monitor and improve platform operations, and to inventory, report on, and
|
||||
migrate/update the contents of the platforms’ databases.
|
||||
Refines into requirements: FREQ 55 to 62.
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 22
|
||||
|
||||
|
||||
|
||||
Use Case Basic Interactions and Responses
|
||||
1. Platform keeps monitoring services at run-time to ensure operation
|
||||
and integrity of city data
|
||||
o If system failure, the platform activates mechanisms for recovery
|
||||
UC6. Manage based on pre-defined rules
|
||||
Infrastructure o Platform logs issue and issue alert messages to platform providers
|
||||
2. Platform logs operation capabilities (e.g. performance, mean of time
|
||||
failure, issues, etc.)
|
||||
|
||||
|
||||
2.4.4 Functional Requirements
|
||||
|
||||
Req. ID UC. ID Description Priority Domain
|
||||
A minimal set of identifying information/metadata concerning data Business Needs,
|
||||
FREQ.28 UC4 Must
|
||||
publication submission must be recorded. Platform
|
||||
Stores and tracks versions of data. Links /connections between
|
||||
FREQ.29 UC4 Must City Data, Platform
|
||||
versions are created and maintained.
|
||||
|
||||
FREQ.30 UC4 Converts data to accepted file formats Must City Data, Platform
|
||||
|
||||
Keep sensitive information secured and accessible only to authorized
|
||||
FREQ.31 UC4 Must City Data, Platform
|
||||
users
|
||||
|
||||
FREQ.32 UC4 Keep user’s personal information protected Should City Data, Platform
|
||||
|
||||
|
||||
FREQ.33 UC4 Keep city data and meta-data secured Must Platform Needs
|
||||
|
||||
|
||||
FREQ.34 UC4 Enable privacy preserving mechanisms associated to data Must Platform Needs
|
||||
|
||||
|
||||
FREQ.35 UC4 Model data in accordance with defined standards Must City Data, Platform
|
||||
|
||||
|
||||
FREQ.36 UC4 Support the use of ontologies and semantic modelling of city data Could City Data
|
||||
|
||||
|
||||
FREQ.37 UC4 Support database-level provenance annotation Should City Data
|
||||
|
||||
|
||||
FREQ.38 UC4 Support data-level provenance annotation Should City Data
|
||||
|
||||
|
||||
FREQ.39 UC4 Enable data to be encrypted Should Platform Needs
|
||||
|
||||
System must have the ability to search and display metadata, preferably
|
||||
City Data, Platform
|
||||
FREQ.40 UC5 in a user-conformable, human readable display as well as in its native Must
|
||||
Needs
|
||||
format for machine harvesting and manipulation.
|
||||
Controls access to data in the repository based on multiple permission
|
||||
City Data, Platform
|
||||
FREQ.41 UC5 levels. These permission levels determine the create/edit/read/delete Should
|
||||
Needs
|
||||
privileges granted users.
|
||||
Access rights and conditions of use will be held for each data and its City Data, Platform
|
||||
FREQ.42 UC5 Should
|
||||
related metadata. Needs
|
||||
Access rights and conditions can be inherited from a parent data to any City Data, Platform
|
||||
FREQ.43 UC5 Could
|
||||
data designated as a child data (derived information). Needs
|
||||
Access rights and conditions of use will be machine readable and City Data, Platform
|
||||
FREQ.44 UC5 Should
|
||||
actionable. Needs
|
||||
Access mechanisms must be sufficiently granular to allow the Business Needs, City
|
||||
FREQ.45 UC5 identification of individual users, in order to maintain audit logs of actions Should
|
||||
Data, Platform
|
||||
performed by users.
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 23
|
||||
|
||||
|
||||
Maintains the integrity of the database which contains both metadata
|
||||
FREQ.46 UC5 and system information. Must Platform Needs
|
||||
|
||||
Provides internal validation such as referential integrity of the contents of City Data, Platform
|
||||
FREQ.47 UC5 the database. Must
|
||||
Needs
|
||||
Creates and maintains schema definitions required to support data
|
||||
FREQ.48 UC5 management functions. Must Platform Needs
|
||||
|
||||
Monitors and ensures that data and metadata are not corrupted during
|
||||
FREQ.49 UC5 transfers. Must Platform Needs
|
||||
|
||||
Provides statistically acceptable assurance that no components of the
|
||||
FREQ.50 UC5 data are corrupted during any internal data transfer. Must Platform Needs
|
||||
|
||||
Performs routine and special data integrity checking for each dataset
|
||||
FREQ.51 UC5 and generates error reports. Must Platform Needs
|
||||
|
||||
Provides disaster recovery capabilities including data backup, off-site
|
||||
FREQ.52 UC5 data storage, data recovery, etc. Must Platform Needs
|
||||
|
||||
Refresh/replace data without service interruption, and update
|
||||
FREQ.53 UC5 corresponding metadata as appropriate. Must Platform Needs
|
||||
|
||||
Ensure that any associated unique identifiers of the updated data are not
|
||||
FREQ.54 UC5 altered. Must Platform Needs
|
||||
|
||||
Audits submissions to ensure that they meet archive/repository
|
||||
FREQ.55 UC6 standards. Must Platform Needs
|
||||
|
||||
Maintains configuration management of the system hardware and
|
||||
FREQ.56 UC6 software. Must Platform Needs
|
||||
|
||||
Has capability to inventory, report on and migrate the contents of the
|
||||
FREQ.57 UC6 repository. Must Platform Needs
|
||||
|
||||
|
||||
FREQ.58 UC6 Ensures data integrity for version upgrades and format migration. Must Platform Needs
|
||||
|
||||
|
||||
FREQ.59 UC6 Monitors functionality of the entire repository. Must Platform Needs
|
||||
|
||||
|
||||
FREQ.60 UC6 Maintains integrity of system configuration. Must Platform Needs
|
||||
|
||||
Audits system operations, performance and usage.
|
||||
FREQ.61 UC6 Must Platform Needs
|
||||
|
||||
Provides platform performance information and database holdings
|
||||
FREQ.62 UC6 inventory reports Must Platform Needs
|
||||
|
||||
|
||||
|
||||
|
||||
2.5 SUB-GOAL 3: City data is orchestrated in a marketplace
|
||||
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 3 to be maintained in the long-run it requires the efficient realisation of use
|
||||
cases: “Commercialise City Data” and “Commercialise Data Services”, as shown in Figure 7.
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 24
|
||||
|
||||
|
||||
|
||||
Achieve [City data is exploited
|
||||
to its full effect]
|
||||
Goal
|
||||
|
||||
|
||||
|
||||
|
||||
co-ena bles
|
||||
Maintain [City data is orchestrated in
|
||||
a marketplace]
|
||||
S ub-Goal 3
|
||||
|
||||
|
||||
|
||||
|
||||
Achieve [Commercialise Data
|
||||
Achieve [Commercialise City Data]
|
||||
Services]
|
||||
UC7 UC8
|
||||
|
||||
|
||||
|
||||
|
||||
Figure 7. Sub-Goal 3 “City data is orchestrated in a marketplace” refinement.
|
||||
|
||||
|
||||
|
||||
2.5.1 Use Case: Commercialise City Data
|
||||
ID: UC7
|
||||
Refines: SUB-GOAL 3: City data is orchestrated in a marketplace
|
||||
Pre-condition: Data is successfully published in the platform, both publisher and consumers of
|
||||
city data are authenticated in the platform, and there are billing capabilities available.
|
||||
Actors: Data Publishers, Data Consumers
|
||||
Rationale: The providers of city data can commercialise city data based on the policies and
|
||||
financial models defined in the platform. After publishing their data, publishers can define which
|
||||
data can be available as open data and which data should be available with the payment of a
|
||||
subscription fee. Once publishers define which data is to be commercially exploited, the platform
|
||||
will associate the data with their respective financial models and let it ready for subscription. City
|
||||
data consumer chooses which data to purchase and is redirected to a billing interface where the
|
||||
subscription payment is taken. The platform must provide an update response indicating the status
|
||||
of the payment. If successful, data is ready available to be consumed by humans and machines,
|
||||
otherwise the user can re-try the payment or cancel transaction.
|
||||
Commercialise city data also involves the function of managing commercial data. It provides
|
||||
services and functions for updating, maintaining and accessing both data and its respective
|
||||
commercial transactions. Furthermore, it enables data providers to track the usage of commercial
|
||||
data by users. Ideally the owners of the data should be the only authorised user to manage
|
||||
resources, and other authorised users can track the usage of the data in the platform. Data usage
|
||||
tracking includes performing queries on the data management data to generate result sets, and
|
||||
producing reports from these result sets. Data consumers are provided with functions which enable
|
||||
them to manage their subscriptions and financial transactions on the platform. These functions
|
||||
include updating, maintaining and accessing financial transactions. For all these functions and
|
||||
services, the platform must provide a database update response indicating the status of the
|
||||
update, avoid update errors to be propagated in the platform, and should keep an audit trail of all
|
||||
actions to enable rollback.
|
||||
Specialised Use Cases: The Use Case Commercialise City Data is distinguished into four
|
||||
specialised Use Cases: “Commercialise Data (UC7.1)”, “Consume Commercial City Data (UC7.2)”,
|
||||
“Manage Commercial Data (UC7.3)” and “Manage Data Subscription (UC7.4)”.
|
||||
Refines into requirements: FREQ 63 to 68.
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 25
|
||||
|
||||
|
||||
|
||||
|
||||
Use Case Basic Interactions and Responses
|
||||
1. User selects the data to be commercialised
|
||||
2. User selects the commercial model for data consumption
|
||||
UC7.1. 3. Platform validates selection
|
||||
Commercialise 4. Platform associates data to subscription model
|
||||
Data 5. Platform releases data for commercial exploitation in the marketplace
|
||||
6. End of data commercialisation set up.
|
||||
1. User selects the data to be subscribed to
|
||||
2. User request subscription to data
|
||||
UC7.2. 3. Platform validates selection
|
||||
Consume 4. Platform redirects user to billing system
|
||||
Proprietary 5. Billing system deals with user request
|
||||
Data o If successful, user is redirected to a GUI where data is ready to use
|
||||
o If unsuccessful, user can try payment again or cancel request
|
||||
2. End of data subscription.
|
||||
1. Platform provides user with an interface for commercial data
|
||||
management
|
||||
2. User chooses to edit or delete commercial data
|
||||
o If edit, user revise commercial models, licenses, access-control,
|
||||
semantics;
|
||||
o If delete, user selects dataset(s) to be removed (following policies
|
||||
UC7.3. Manage defined in the platform for data removal)
|
||||
commercial 3. User confirms action
|
||||
Data 4. Platform promptly process user’s request
|
||||
5. 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.
|
||||
6. End of resources management
|
||||
1. Platform provides user with an interface for data subscription
|
||||
management
|
||||
2. User chooses to edit or cancel data subscription
|
||||
o If edit, user revise payment and subscription timeframe;
|
||||
o If cancel, user selects dataset(s) to have subscription cancelled
|
||||
UC7.4. Manage (following policies defined in the platform for data subscription)
|
||||
data 3. User confirms action
|
||||
subscription 4. Platform promptly process user’s request
|
||||
5. Platform confirms execution of request
|
||||
o If valid request, platform updates acknowledges request has been
|
||||
processed successfully
|
||||
o If non-valid request, platform returns to step 1.
|
||||
6. End of data subscription management
|
||||
|
||||
|
||||
|
||||
2.5.2 Use Case: Commercialise Data Services
|
||||
ID: UC8
|
||||
Refines: SUB-GOAL 3: City data is orchestrated in a marketplace
|
||||
Pre-condition: Data is successfully published in the platform, both publisher and consumers of
|
||||
city data are authenticated in the platform, and there are billing capabilities available.
|
||||
Actors: Data Service Providers, Data Publishers and Consumers
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 26
|
||||
|
||||
|
||||
Rationale: After deploying data services in the platform, the providers of data services can choose
|
||||
to commercialise services based on the policies and financial models defined in the platform. Once
|
||||
data service providers define which service(s) is (are) to be commercially exploited, the platform
|
||||
will associate the services with their respective financial models and let available in the platform
|
||||
applications module ready for use. User (either publisher or consumer) chooses which data
|
||||
services to use, and in case a charged service is selected the platform redirects the user to a
|
||||
billing interface where the payment is taken. The platform must provide an update response
|
||||
indicating the status of the payment. If successful, service is ready available to be used, otherwise
|
||||
the user can re-try the payment or cancel transaction. Note that data service owners should be
|
||||
able to waive the payment of tariff to certain users’ categories.
|
||||
Data services providers are offered with functions to manage their commercial services. The
|
||||
platform provides functions for updating, maintaining and accessing both service and its respective
|
||||
commercial transactions. Furthermore, it enables data services providers to track the usage of
|
||||
services by users. Services usage tracking includes performing queries on the platform to
|
||||
generate result sets, and producing reports from these result sets. The consumers of data services
|
||||
are provided with functions which enable them to manage their subscriptions and financial
|
||||
transactions. These functions include updating, maintaining and accessing financial transactions.
|
||||
For all these functions and services, the platform must provide a database update response
|
||||
indicating the status of the update, avoid update errors to be propagated in the platform, and
|
||||
should keep an audit trail of all actions to enable rollback.
|
||||
Specialised Use Cases: The Use Case Commercialise Data Services is distinguished into four
|
||||
specialised Use Cases: “Commercialise Data Services (UC8.1)”, “Consume Data Services
|
||||
(UC8.2)”, “Manage Commercial Services (UC8.3)” and “Manage Services Subscription (UC8.4)”.
|
||||
Refines into requirements: FREQ 68 to 73.
|
||||
|
||||
Use Case Basic Interactions and Responses
|
||||
1. User selects the data services to be commercialised
|
||||
2. User selects the commercial model for data service usage based on the
|
||||
category of users
|
||||
UC8.1. 3. Platform validates selection
|
||||
Commercialise 4. Platform associates data services to subscription model
|
||||
Data Services 5. Platform enables data service to be commercially exploited in the
|
||||
marketplace
|
||||
6. End of services commercialisation set up.
|
||||
1. User selects the data service to be subscribed to
|
||||
2. User request subscription to service
|
||||
3. Platform validates selection
|
||||
UC8.2. 4. Platform validates user’s category its respective commercial models
|
||||
Consume Data 4. If applicable, platform redirects user to billing system
|
||||
Services 5. Billing system deals with user’s request
|
||||
o If successful, user is redirected to a GUI where data is ready to use
|
||||
o If unsuccessful, user can try payment again or cancel request
|
||||
6. End of data subscription.
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 27
|
||||
|
||||
|
||||
1. Platform provides user with an interface for commercial data
|
||||
management
|
||||
2. User chooses to edit or delete commercial data
|
||||
o If edit, user revise commercial models, licenses, access-control,
|
||||
semantics;
|
||||
o If delete, user selects dataset(s) to be removed (following policies
|
||||
UC8.3. Manage defined in the platform for data removal)
|
||||
commercial 3. User confirms action
|
||||
services 4. Platform promptly process user’s request
|
||||
5. 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.
|
||||
6. End of resources management
|
||||
1. Platform provides user with an interface for data subscription
|
||||
management
|
||||
2. User chooses to edit or cancel data subscription
|
||||
o If edit, user revise payment and subscription timeframe;
|
||||
o If cancel, user selects dataset(s) to have subscription cancelled
|
||||
UC8.4. Manage (following policies defined in the platform for data subscription)
|
||||
services 3. User confirms action
|
||||
subscription 4. Platform promptly process user’s request
|
||||
5. Platform confirms execution of request
|
||||
o If valid request, platform updates acknowledges request has been
|
||||
processed successfully
|
||||
o If non-valid request, platform returns to step 1.
|
||||
6. End of data subscription management
|
||||
|
||||
|
||||
2.5.3 Functional Requirements
|
||||
|
||||
Req. ID UC. ID Description Priority Domain
|
||||
City Data, Platform,
|
||||
FREQ.63 UC7 Support the commercialization of city data Should Business Needs
|
||||
City Data, Platform,
|
||||
FREQ.64 UC7 Enable users to subscribe to city data through the payment of a tariff Should Business Needs
|
||||
City Data, Platform,
|
||||
FREQ.65 UC7 Enable users to manage their data subscriptions Should Business
|
||||
Provide platform providers mechanisms to define the terms and
|
||||
FREQ.66 UC7 Must Platform Needs
|
||||
conditions for platform data usage
|
||||
Enable data providers to manage the subscription models of their City Data, Platform,
|
||||
FREQ.67 UC7 Should
|
||||
data Business
|
||||
UC7/ City Data, Platform,
|
||||
FREQ.68 Utilise secure and reliable billing and payment management systems Must
|
||||
UC8 Business
|
||||
City Data, Platform,
|
||||
FREQ.69 UC8 Support the commercialization of data services Should Business Needs
|
||||
Enable data providers to manage the commercial models of their City Data, Platform,
|
||||
FREQ.70 UC8 Should
|
||||
services Business Needs
|
||||
Provide service providers mechanisms to define the terms and City Data, Platform,
|
||||
FREQ.71 UC8 Should
|
||||
conditions of platform services Business Needs
|
||||
Allow users to pay a tariff for using certain advanced services (e.g. City Data, Platform,
|
||||
FREQ.72 UC8 Should
|
||||
Data manipulation, enrichment) Business Needs
|
||||
City Data, Platform,
|
||||
FREQ.73 UC8 Enable users to manage their data services subscriptions Should Business Needs
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 28
|
||||
|
||||
|
||||
2.6 SUB-GOAL 4: City data is offered in an accessible manner
|
||||
Rationale: The urban platform provides city data in both human and machine (e.g. sensors,
|
||||
actuators, systems) readable and understandable formats.
|
||||
Drivers: Ensure data understandability and machine-to-machine data transaction.
|
||||
Actions: For Sub-Goal 3 to be maintained in the long-run it requires the efficient realisation of use
|
||||
cases: “Register Consumer”, “Discover City Data”, and “Consume City Data” as shown in Figure 8.
|
||||
|
||||
Achieve [City data is exploited
|
||||
to its full effect]
|
||||
Goal
|
||||
|
||||
|
||||
|
||||
|
||||
co-ena bles
|
||||
Maintain [City data is offered in an
|
||||
accessible manner]
|
||||
S ub-Goal 1
|
||||
|
||||
|
||||
|
||||
|
||||
Achieve [Register Consumer] Achieve [Discover City Data] Achieve [Consume City Data]
|
||||
UC9 UC10 UC11
|
||||
|
||||
|
||||
|
||||
|
||||
Figure 8. Sub-Goal 4 “City data is offered in an accessible manner” refinement.
|
||||
|
||||
|
||||
|
||||
2.6.1 Use Case: Register Data Consumer
|
||||
ID: UC9
|
||||
Refines: SUB-GOAL 4: City data is offered in an accessible manner
|
||||
Pre-condition: User is not logged in the platform
|
||||
Actors: Data Consumers
|
||||
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. Users must accept the terms and conditions of platform usage and define
|
||||
how their personal data can be used by the Platform Owner. Users can manage and alter their
|
||||
registration information at any time they want to.
|
||||
Refines into requirements: FREQ 64.
|
||||
|
||||
Use Case Basic Stimulus and Responses
|
||||
1. The platform prompts the user for a username and password or register
|
||||
new account.
|
||||
2. The user selects registration option.
|
||||
3. The platform prompts user for data consumer registration information
|
||||
UC1. Register 4. The user enters in their information.
|
||||
Consumer 5. Platform verifies information and creates account.
|
||||
o If non-valid information, platform shows error message and returns to
|
||||
step 1.
|
||||
6. Platform acknowledges registration has been successful
|
||||
7. End of registration
|
||||
Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 29
|
||||
|
||||
|
||||
2.6.2 Use Case: Discover City Data
|
||||
ID: UC10
|
||||
Refines: SUB-GOAL 4: City data is offered in an accessible manner
|
||||
Pre-condition: User has access to either platform GUI or API
|
||||
Actors: Data Consumers
|
||||
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.
|
||||
Refines into requirements: FREQ 64.
|
||||
|
||||
Use Case Basic Stimulus and Responses
|
||||
1. Users access specialised data query end-points (e.g. SPARQL)
|
||||
2. Users provides information for pre-defined parameters for search
|
||||
3. Users request data search
|
||||
4. Platform quickly process users request for data
|
||||
Reference in New Issue
Block a user