DECODE/DEC03 use case
Contents
- 1 Use Case ID - Use Case title
- 2 Owner of Use Case
- 3 Description
- 4 Requirements
- 5 Component(s)
- 6 Types/classes of data involved
- 7 Actors
- 8 Preconditions
- 9 Postconditions
- 10 Normal Flow
- 11 Alternate Flows
- 12 Evaluation of UC and requirements realisation
- 13 Categories of personal data involved
- 14 Purposes for personal data handling
- 15 Different kinds of processing involved
- 16 Data subjects, controllers, processors, and recipients involved
- 17 Storage & security aspects
- 18 Means of legitimation for personal data processing
Use Case ID - Use Case title
DEC03 - Sharing sensor data
Owner of Use Case
Stefano Bocconi - DECODE project
Description
Residents of a particular square are concerned about noise generated at night by the clients of the venues in the square. They decide to measure with low-cost sensors the noise level, either inside or outside their residence. To be able to provide a global picture of the situation in the square, users might be willing to share their measurements, but possibly not about particular periods (like during the day) or not the exact location of the sensors.
Moreover, users want to be able to share the data only with particular groups
Is Sub-Use Case of
Has Sub-Use Cases
Requirements
Related functional requirements
- Users must be able to register their sensors to a platform and indicate a sharing policy for the data generated
- Policy must be enforced by platform collecting sensor data.
Related non-functional requirements
Requirement conflicts (if any)
Requirement similarities (if any)
Requirement subsets/refinements (if any)
Component(s)
- A sensor generating noise measurements
- A platform that can register the measurements, and offers options for data sharing in the form of data policies
Types/classes of data involved
- Sensor data
- Policies of data sharing
Actors
- A local community that wants to measure noise pollution in a particular area
- A platform owner that offers data visualisation subject to sharing policies.
Preconditions
- Users have a sensor, want to register it and choose a sharing policy
- Platform offering data sharing and policies
Postconditions
- Noise pollution can be visualised on a map respecting the privacy of the users.
Normal Flow
- User acquires and register a noise sensor with the platform
- User specifies a sharing policy
- Sensor generates data
- Data is filtered on the platform to remove what the user does not wishes to share
- Data is encrypted on the platform so that only particular recipient can see it
- Platform reveals aggregated data for the recipients authorised to see it.
Alternate Flows
Evaluation of UC and requirements realisation
(e.g. manual, automatically...)
Categories of personal data involved
The following data is only marginally personal (location mostly):
- Attribute stating holder is owner of a sound sensor
- Location of the sensor
- Noise measurement of the sensor (level, time)
No other data such as name, date of birth, etc is necessary.
Data is stored according to the policy chosen by the user and visualised also according to the same policy.
Purposes for personal data handling
The purpose of the processing is to assess the noise level in a neighbourhood (in particular, in a square).
This data can be used to assess whether particular policies have effect in reducing noise pollution for residents.
Different kinds of processing involved
Once the data is sent by the sensor to a platform, before storing it the policy chosen by the user is applied and the data is processed for example to:
- Remove the exact location and substitute with a random point within a radius of the real location
- Remove the timestamp
- Drop data in particular intervals of time, such as during the day.
After storage, the data is visualised on a map.
Data subjects, controllers, processors, and recipients involved
The data subjects are the citizens owners of a sound sensor.
Data controller is the entity running the visualisation platform.
Recipients is every viewer of the visualisation. Again, the data is only marginally personal as it is about sound levels.
Storage & security aspects
Noise level data will likely be kept for a long term in order to support policy making and also citizen science.
Security is responsibility of the platform owner.
All this data is not directly linked to a person, so we can say that it is at least in pseudonymisation form.
Means of legitimation for personal data processing
The data is gathered on the basis of a policy chosen by the user and with its informed consent.