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

701 lines
46 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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 View Git Blame Copy Permalink