1.
Methods and Tools for GDPR Compliance through
Privacy and Data
Protection 4 Engineering
Nicolás E. Díaz Ferreyra (UDE)
Patrick Tessier (CEA)
Gabriel Pedroza (CEA)
Maritta Heisel (UDE)
Requirements Engineering Tool and Method
(WP4)

2.
Introduction & Objectives
 WP4 Methods and tools for data protection requirements engineering
 Participants: CEA (leader), UDE, UPM, TECNALIA, Trialog
 Duration: M8 – M33
 Objectives:
 Leverage and integrate existing knowhow for requirements engineering and privacy:
o From methods like ProPAn
o From MDE techniques and tools like Papyrus
o From emerging regulations like GDPR
 Outputs:
 Deliverables:
o Specification of the tool architecture: D4.1, D4.2 and D4.3
o Method releases: D4.4 and D4.5
o Tool releases: D4.6 and D4.7
 Tool support:
o PDP4E-Req (also referred as PDP4E-ReqLite)
29/06/2021 2 PDP4E WP4

3.
Innovation Scenario
• Privacy engineering posits that privacy must be considered as a primary development aspect:
• Privacy must be addressed from the early stages of a systems’ life cycle (by-design)
• Requirements related to privacy and data protection must be properly elicited and documented!
• Requirement engineering methods and tools support software engineers in the identification and
documentation of privacy requirements.
• However, legal frameworks such as the GDPR introduce new requirement engineering challenges:
• Legal provisions are expressed in a jargon alien to most software developers
• As opposite to system requirements, provisions are described in a high-level
• Multiple interpretations leading to ambiguous/contradictory software requirements
• Mapping legal provisions to system requirements is not always straight-forward
29/06/2021 3 PDP4E WP4

4.
Scope and Objectives
• Develop requirements engineering methods and tools that:
• Support the elicitation of privacy and data protection requirements
• Systematically
• Structured
• Computer aided
• Aligned with the GDPR legal provisions
• Aligned with privacy and data protection standards (ISO 29100)
• Driven by privacy goals such as
• Integrity
• Confidentiality
• Transparency…
29/06/2021 4 PDP4E WP4

5.
Method Background
• Privacy scholars have introduced different requirement engineering methods and techniques
• ProPAn (Problem-based Privacy Analysis) is a computer-aided, model-driven method for privacy
requirements engineering.
• Analyses systematically the functional requirements of a system-to-be with regard to a set of privacy
engineering protection goals.
• Goals are represented through a taxonomy of high-level privacy requirements.
• The taxonomy is derived from the legal framework relevant for the data controller and the data
subject (e.g. the GDPR).
• The taxonomy guides the identification of critical points in the data flow of the system that may
rise privacy concerns from the stakeholders.
• Functional requirements are expressed as a collection of Problem Diagrams (Jackson) that capture
core aspects of the system-to-be and its environment.
29/06/2021 5 PDP4E WP4

6.
The ProPAn Method
29/06/2021 6
• The ProPAn method can be divided on two phases:
1. Identification of Privacy-Relevant Information Flows
2. Generation of privacy requirements
• In Phase 1, ProPAn elaborates on a set of software
artefacts following Jackson’s Problem Frame Notation
• Context and Problem Diagrams, Domain Knowledge…
• The “world” is modelled in terms of Domains, Interfaces,
and Phenomena (events) exchanged between domains.
• Phenomena can be causal (action, messages, operations)
or symbolic (data, states).
• Requirements are specified in an event-oriented fashion!
Context Elicitation
Graph Generation
Identification of Personal Data
Personal Data Flow Analysis
Functional Requirements
Context Diagram, Domain Knowledge,
Problem Diagrams
Detailed Stakeholder
Information Flow Graphs
Personal Information Diagrams
Available Information Diagrams
Method Step
External Input Internal Input/Output
Phase 1: Identification of
Privacy-Relevant Information Flows
PDP4E WP4

7.
The ProPAn Method
29/06/2021 7
• In order to perform an adequate privacy analysis over a set
of functional requirements, these should be expressed in a
data-oriented fashion.
• To represent the exchange of personal data, ProPAn
introduces a set of refinements and alternative data
structures to the original problem diagrams:
• Detailed Stakeholder Data Flow Diagrams (DSIFDs)
• Available Information Diagrams (AIDs)
• Personal Information Diagrams (PIDs)
• These new diagrams incorporate additional information
which is necessary to conduct a privacy analysis and,
therefore privacy requirements derivation.
Context Elicitation
Graph Generation
Identification of Personal Data
Personal Data Flow Analysis
Functional Requirements
Context Diagram, Domain Knowledge,
Problem Diagrams
Detailed Stakeholder
Information Flow Graphs
Personal Information Diagrams
Available Information Diagrams
Method Step
External Input Internal Input/Output
Phase 1: Identification of
Privacy-Relevant Information Flows
PDP4E WP4

8.
ProPAn Requirements Taxonomies
29/06/2021 8
• ProPAn’s taxonomies and semantic templates are build upon a set of privacy goals (Hansen):
Intervenability, Unlinkability, Transparency, Confidentiality, Integrity, Availability
Taxonomies and templates are instantiated for each specific software project
PDP4E WP4

9.
ProPAn: Issues and Disadvantages
29/06/2021 9
• The meta-requirement taxonomies of ProPAn may not be exhaustive (w.r.t. GDPR).
• There is a high amount of redundancy across the ProPAn diagrams:
• The attribute Linkability appears in the PID and in the AID
• The attribute Origin appears in the PID and the AID
• Stakeholders (including data subjects), data-storages and processes are represented all together in a
same diagram (as consequence of starting from contextual information)
• In terms of context modelling this representation is adequate
• In terms of privacy analysis, a more structured representation is necessary!
We want to maintain the level of granularity achieved by ProPAn
but improving its interpretability and eliminate redundancy.
PDP4E WP4

10.
PDP4E-Req: A Lightweight Method
29/06/2021 10
• A light-weigh methodology whose main goals are:
 Harmonize the current approach in order to eliminate redundancy across artifacts
 Reduce documentation overhead to optimize the method’s applicability
 Achieve a broader scope and compliance with legal provisions and privacy standards to come
• PDP-ReqLite introduces and adapts a set of data structures to support the methodology:
• Requirements Data Flow Diagrams (RDFDs)
• Personal Information Diagrams (PIDs) similar to the ones of ProPAn
• It also introduced a set of validation conditions for the generated models
• The method and its data structures are tool-supported in Papyrus*
• The tool was validated through a case study (Smart Grids)
*https://www.eclipse.org/papyrus/ PDP4E WP4

11.
PDP4E-Req: Method Overview
29/06/2021 11 PDP4E WP4

12.
Create Requirements Data Flow Diagrams
29/06/2021 12
• Functional requirements are translated into one or more RDFD elements:
• Data Record Requirement (DRR): Collection of
data records (e.g. personal data)
• Data Process Requirement (DPR): Activities
that are performed over data records.
• Data Flow Requirement (DFR): Exchange of
information between DRR and DPR.
• The RDFD elements are annotated with attributes
such as data sensitivity, degree of linkability and
retention time.
PDP4E WP4

13.
Personal Information Diagrams
29/06/2021 13
• Models the data of the stakeholders processed by the system-to-be.
Allows the identification of personal data and relationships between such data
PDP4E WP4

14.
Generation of Privacy Requirements
29/06/2021 14
Analyse the artifacts with references to the
stakeholder S and the counter-stakeholder C
Make inferences over the documented
private information flows of the system
Instantiate the corresponding requirement
semantic template
PDP4E WP4

15.
PDP4E-Req Tool
29/06/2021 15
TOOL DEMO
PDP4E WP4

16.
Outlook
29/06/2021 16
• This is a first attempt to bridge the accountability gap in requirement engineering.
• Harmonization between legal provisions and technical requirements is an ongoing challenge:
• New legal provisions will appear in future.
• Privacy requirement taxonomies are elaborated manually.
• Methodological point of view
• Update the methodology accordingly.
• Have a better coverage of the GDPR.
• Tool point of view
• Extend taxonomies coverage, e.g., ISO-29100 standard.
• Apply to industry-size use cases from other application domains: health-care, automotive, IoT.
• Implement filters to help the prioritization and navigation through the model, and requirements.
PDP4E WP4

17.
Acknowledgements
29/06/2021 17
This project has received funding from the European Union’s Horizon 2020 research and innovation
programme under grant agreement No 787034.
Purpose and IPR Notice: the material in this support has been mostly prepared by CEA and UDE in the scope of PDP4E for
explanatory and training purposes. Any partial or full usage of this material in a different context requires written and explicit
consent from the respective partners. The property of the contents herein referred (including methods, tools and trademarks)
belongs to the respective IPR and copyright holders.
PDP4E WP4

18.
Methods and Tools for GDPR Compliance through
Privacy and Data
Protection 4 Engineering
For more information, visit:
www.pdp4e-project.org
Thank you for your attention
Questions?
WP Leader: CEA
gabriel.pedroza@cea.fr
patrick.tessier@cea.fr
nicolas.diaz-ferreyra@uni-due.de