What’s Your Purpose? An Approach to Incorporating GDPR Purposes

into Requirements Analysis

Evangelia Vanezi, Georgia Kapitsaki and Anna Philippou

Department of Computer Science, University of Cyprus, Cyprus

Keywords:

GDPR Purpose, Privacy by Design, System Requirements, Use Case Diagrams, Sequence Diagrams.

Abstract:

Protecting personal data within software systems is crucial, and as such, several privacy regulations have been

enacted, one being the EU’s General Data Protection Regulation (GDPR). While GDPR emphasizes “Purpose

Limitation” for rightful personal data handling, the concept of purpose lacks clarity in software development

practices. Building on our previous work on Di

alogoP, which supports the deﬁnition of formal processing

purposes, this study introduces purpose-aware system requirements. We present An

alisisP, a methodology for

integrating processing purposes into the software engineering requirements analysis phase and visual repre-

sentations of these enhanced requirements by extending the Uniﬁed Modeling Language (UML) Use Case and

Sequence diagrams. We show how our approach enables the integration of An

alisisP with Di

alogoP towards

formal models whose compliance with processing purposes is rigorously validated. Additionally, we show-

case how the proposed extended diagrams assist in addressing further GDPR-related system design queries.

1 INTRODUCTION

The Problem. Protecting personal data within soft-

ware systems is crucial, and as such, several privacy

regulations have been enacted, including the Califor-

nia Consumer Privacy Act (CCPA) (Goldman, 2020)

and more recently the European Union (EU) General

Data Protection Regulation (GDPR) (European Par-

liament and Council of the European Union, 2015).

The GDPR stands as a pivotal framework, empow-

ering individuals with rights over their data and im-

posing strict guidelines on organizations regarding its

collection, processing, and storage. One very impor-

tant principle of the GDPR, deﬁned in Article 5, is

‘Purpose Limitation’, indicating that data collected

should be handled only in ways explicitly stated and

agreed beforehand between the user and the system.

In Software Engineering, purpose is meant to charac-

terize the usage of personal data by the system entities

processing, and therefore, it should comprise a cru-

cial part of a system’s functional requirements. An-

other important principle is Privacy by Design (PbD),

which advocates that privacy should be incorporated

into systems by default and should be a priority from

the beginning of a system’s design. Even though the

above are signiﬁcant for privacy, the notion of pur-

pose is still not clearly deﬁned, and software engi-

neers do not explicitly address it during the develop-

ment process, as some developers indicated in a previ-

ous work (Alhazmi and Arachchilage, 2021), let alone

in a proactive way, as indicated by PbD.

Our Contribution. In our previous work (Vanezi

et al., 2020), we presented Di

alogoP, a methodol-

ogy including a formal language for deﬁning process-

ing purposes of systems as the communication ex-

changes between a system’s entities, and a tool for

supporting this deﬁnition through a visual interface.

In this work, we formalise the underlying layer on

which Di

alogoP is based: the purpose-aware sys-

tem requirements. We discuss and present our def-

inition of what purposes are in software engineer-

ing. We present An

alisisP, a methodology applied

during the requirements analysis step of the software

engineering process, integrating processing purposes

with the requirements. Purpose-aware requirements

can be depicted through textual format; however, they

are better demonstrated through the use of UML dia-

grams. We present an extension for visualising such

requirements for two of the most popular diagrams:

(i) Uniﬁed Modeling Language (UML) Use Case Di-

agrams (Gemino and Parker, 2009) and (ii) UML

Sequence Diagrams (Booch et al., 1996). This no-

tation allows the representation, deﬁnition and han-

dling of processing purposes in software engineering.

We then present the direct mapping and integration

of An

alisisP with Di

alogoP in a framework towards

Vanezi, E., Kapitsaki, G. and Philippou, A.

What’s Your Purpose? An Approach to Incorporating GDPR Purposes into Requirements Analysis.

DOI: 10.5220/0012474400003648

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 10th International Conference on Information Systems Security and Privacy (ICISSP 2024), pages 907-914

ISBN: 978-989-758-683-5; ISSN: 2184-4356

907

formally validated purpose-compliant system mod-

els. Additionally, we demonstrate how our extended

purpose-aware diagrams can assist in addressing fur-

ther important GDPR-related system design queries.

We validate our methodology with a running exam-

ple. Finally, our conclusions and future work are dis-

cussed. Our overall aim is to study purpose and pro-

pose a solution for formally integrating it into soft-

ware engineering following the principle of PbD.

Structure. In Section 2 we present our deﬁnition

for purpose and then in Section 3 we discuss related

work. In Section 4, we present our main contribution,

the An

alisisP methodology, in detail, presenting the

extended use case diagrams in Subsection 4.2 and the

extended UML sequence diagrams in Subsection 4.3.

Following, we present the integration with Di

alogoP

in Section 5, the additional privacy queries in Sec-

tion 6, concluding with a discussion in Section 7.

2 WHAT IS A PURPOSE?

The notion of ‘purpose’ was initially mentioned in the

declaration of the Protection of Personal Data as one

of the fundamental rights of the EU (European Par-

liament and Council of the European Union, 2012),

by declaring that “data must be processed fairly for

speciﬁed purposes”. Within the GDPR, purpose is

mainly mentioned in Article 5, ‘Purpose Limitation’

stating that “personal data shall be collected for spec-

iﬁed, explicit and legitimate purposes and not further

processed in a manner that is incompatible with those

purposes”. Additionally, it is mentioned in many

more articles of the GDPR.However, the regulation

does not explicitly deﬁne what a purpose is, despite

constituting such an important notion.

Access Control, Roles and Permissions. Although

GDPR and purpose is now taken much into account,

most existing studies that provide support for purpose

control are not appropriate for guaranteeing that data

is not going to be reused for purposes other than those

intended during the collection of data (Byun et al.,

2005; Yang et al., 2007). In the work of (Kouza-

pas et al., 2016), the authors focus on user roles and

formal veriﬁcation of permissions of access to spe-

ciﬁc data, capturing the sense of purpose at a certain

level, but do not control how these permissions and

roles will be used within the system. This is because

purpose contrasts with standard access control (Basin

et al., 2018), which regulates who may carry out an

operation in a system independently of context. For

example, if a courier service is allowed to access a

client’s mobile phone number, then they will be able

to do it for any purpose, both intended (delivery notiﬁ-

cation) and unintended (advertisement). Access con-

trol needs to be related to an explicitly stated purpose.

However, the question remains, how is a purpose de-

ﬁned?

Formal Semantics. Various works treat purposes us-

ing informal or semi-formal descriptions bearing lit-

tle or no semantics (Barth et al., 2006). This informal

treatment of the notion of purpose prohibits a precise

analysis to verify whether a system complies with its

purpose-aware speciﬁcation. The research commu-

nity recognized this shortcoming, and recently, var-

ious works have been concerned with providing se-

mantic foundations for the notion of purpose, asso-

ciating purposes with the actions towards a purpose.

In one such approach, Markov Decision Processes

were used in (Tschantz et al., 2011) and (Tschantz

et al., 2012) and a formalism based on planning was

proposed for auditing systems against privacy poli-

cies. This approach is also adopted by (Basin et al.,

2018), identifying a purpose with a business process,

and use formal models of inter-process communica-

tion to audit or derive privacy policies. Furthermore

in (Jafari et al., 2011), the authors deﬁne a seman-

tic model for purpose-based privacy policies, a modal

logic and the corresponding model checking algo-

rithm to verify whether a particular system complies

with them. Other related works include (Riahi et al.,

2017) specifying purposes as workﬂows modeled by

Petri nets and model-checked against actor models,

and (De Masellis et al., 2015), proposing semantics

of purpose-based privacy policies in temporal logic

and deﬁnes a run-time monitoring methodology.

Our Deﬁnition. Our proposed approach is comple-

mentary to other similar works, based on the obser-

vation that a purpose can be broken down and ex-

pressed as a simple sequence of actions describing the

allowed data processing by the system entities during

their internal activities (locally), and interactions be-

tween them (globally). For example, purpose “Notiﬁ-

cation for delivery” permits the usage of the client’s

mobile phone number. To deﬁne this purpose, we

should explicitly state which actions of which entities

preceded this processing (e.g., the shop informed that

the order is ready for delivery) and which actions are

to follow this processing by which entities, towards

fulﬁlling the purpose (a message is sent from the no-

tiﬁcations station to the client regarding the upcom-

ing delivery). With this deﬁnition, we aim to fulﬁl

two objectives: (i) to avoid misuse of personal data

(as in access control) and (ii) to be able to formally

validate the compliance of a system to its processing

purposes by checking the actions and interactions of

the system entities, in comparison with the deﬁned

purposes. We then propose merging purpose directly

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

908

into the functional requirements sequence of ﬂow. We

deploy a simple example to demonstrate a compliant

and a non-compliant system.

Example: Ordering in an e-Shop. Let us assume the

following system requirement “The client can place

orders through the e-shop that will be delivered to the

provided address”. This speciﬁcation does not ex-

plicitly restrict the use of the client’s personal data for

any other purpose beyond delivering the products or

only after placing an order. We deﬁne the user’s ad-

dress as their personal data. We rephrase the above

requirement to include permission-based processing

of the personal data as follows: “The cart entity can

disclose the client’s provided address to the delivery

company.”. This speciﬁcation allows the user’s per-

sonal data to be sent to the delivery company anytime.

We rephrase the requirement in a purpose-aware man-

ner, as follows: “The client’s provided address can

only be sent from the cart to the delivery company

after the user conﬁrms an order, and then a delivery

needs to follow.” Based on this requirement, we ex-

amine a compliant and two non-compliant system ex-

ecutions: the ﬁrst is non-compliant as the address is

disclosed before conﬁrming the order, while the sec-

ond is non-compliant as the interaction ended without

resulting in the order delivery.

Compliant System Execution. The client adds ob-

jects to the cart → The client ﬁll-in their address →

The client conﬁrms the order → The cart discloses the

client address to the delivery company → The deliv-

ery company delivers the order → end.

Non-Compliant System Executions. (1) The client

adds objects to the cart → The client gives their ad-

dress → The cart discloses client address to the deliv-

ery company ≪violation≫; (2) The client adds ob-

jects to the cart → The client ﬁll-in their address →

The client conﬁrms the order → The cart discloses

the client address to the delivery company → end

≪violation≫

3 RELATED WORK

Several works have been discussing and supporting

the incorporation of processing purposes in the Soft-

ware Engineering process, in the requirements phase,

with the use of popular diagrams.

Data Flow Diagrams (DFDs). An important step to-

wards integrating privacy and purpose into a system

technical design, and speciﬁcally into DFDs, with the

aim of (i) supporting PbD, (ii) validating the system

design in comparison to the textual privacy regula-

tion prescriptions, and (iii) reducing the semantic gap

between engineers and law, was done in (Antignac

et al., 2016). They extend the DFD notation to sup-

port speciﬁc technical privacy concepts, resulting in

privacy-aware DFDs (PA-DFDs). They add an anno-

tation purpo in each process, to reﬂect the way regu-

lations expect all kinds of personal data processing to

be associated with a purpose. They distinguish data

ﬂows of “personal data” and generic data, and they

add the concept of personal data ownership by con-

necting personal data ﬂows with speciﬁc data subject

entities. This work deals with processing purposes of

“personal data”, however, they consider them a sin-

gle “textual” description in a high level of abstrac-

tion. This work is extended in (Antignac et al., 2018)

with model transformations, however the handling of

processing purposes remains the same as in the initial

work. In (Alshareef et al., 2021b) they provide an ex-

plicit algorithm and a proof-of-concept implementa-

tion to transform DFDs into PA-DFDs. In (Alshareef

et al., 2021a) they are concerned with formal reﬁne-

ment for PA-DFDs.

In (Alshareef et al., 2022) the work on PA-DFDs

is complemented with a focus on “Purpose Limita-

tion” that was previously handled abstractly. Aiming

to model “Purpose”, they extend DFDs with purpose

labels on data ﬂows to represent the intended purpose

for which a piece of data is to be used and privacy

signatures on activators to model the impact of pro-

cessing and storage on these purpose labels. They de-

ﬁne a formal mathematical framework for (1) annotat-

ing DFDs with purpose labels and privacy signatures,

(2) checking the consistency of labels and signatures,

and (3) inferring labels from signatures. They also

implement their theoretical framework in a proof-of-

concept tool. Once again, purposes, even handled in

more detail, are still addressed as textual labels.

Business Process Model and Notation (BPMN).

Many works are concerned with validating GDPR

compliance of Business Process Models like in (Kala,

2019), (Matulevi

cius et al., 2020), (Sing, 2018),

where a GDPR UML Model is adopted from the work

in (Tom et al., 2018), in which (among others) a 1-to-

many relationship is shown between “Consent” and

“Purpose”, and a many-to-many relationship is shown

between “Purpose” and “Data Processing”. Also, the

ownership of “Personal data” from a “Data Subject”

is modelled. The BPMNs should be designed follow-

ing the UML Model restrictions, e.g., each data pro-

cessing should be connected to at least one purpose.

Again, purposes are deﬁned on a more abstract and

textual level.

In (Basin et al., 2018), the authors suggest that a

business process model, by its very nature, explicitly

represents one or more purposes and speciﬁes at what

points data is collected and used. They show how for-

What’s Your Purpose? An Approach to Incorporating GDPR Purposes into Requirements Analysis

909

mal models of inter-process communication can be

used to audit or even derive privacy policies. Each

purpose is represented by the name of the business

process prescribing the actions that use the personal

data towards that purpose. In this case, Purposes are

deﬁned similarly to how we deﬁne them. However,

BPMNs are not extended to highlight personal data

or their ownerships on the same model. Instead, a

process collection is deﬁned to show more abstractly

which process collects and uses each personal data.

An algorithm is presented to infer privacy policies

(“we use d for p”) based on data usage.

In (Petkovi

c et al., 2011), they propose a pur-

pose representation model, which connects each in-

tended purpose of data (included in the privacy pol-

icy) to a business model and detects privacy infringe-

ments by determining whether the data have been pro-

cessed only for the intended purpose, by determining

whether the audit trail is a valid execution of the or-

ganizational processes representing the purposes for

which data are meant to be used. Similar wise to our

work, they advocate that it is necessary to extend the

current preventive approach by implementing mecha-

nisms for verifying the actual use of data. However, in

contrast, they do not perform the validation on system

models but in audit trails collected from the systems

logs, thus they do not follow the principle of PbD.

4 An

alisisP METHODOLOGY

In this section we present An

alisisP, a methodol-

ogy for enhancing a system’s functional requirements

with processing purposes, i.e. how and why personal

data are used by each system entity, resulting in the

purpose-aware system requirements. The methodol-

ogy includes the following steps:

• Step 1. Deﬁne the system functional requirements

and deﬁne the set of all system entities, e.

• Step 2. Deﬁne the system purpose (how entities

handle personal data and for which reason) in a

textual format.

• Step 3. Integrate purpose (from Step 2) with func-

tional requirements (from Step 1) in an allowed

sequence of actions, visualising them using the

extended use case and sequence diagrams pro-

posed in this work.

Example: a Simple Task Management Application

- Requirements. To demonstrate our methodology,

we deploy a simple case study. Table 1 lists the re-

quirements for a simple task management application.

Table 1: Example System Requirements.

1 Users should be able to create a new task

2 Users should be able to view a list of all their tasks.

3 Users should be able to edit and update existing tasks.

Users should receive notiﬁcations for approaching

task deadlines.

The application should support multiple users

with individual task lists.

The set of entities for this system is deﬁned as e =

{User, Authorisation, Tasks, Notiﬁcations, DB}. A

User is an external entity, while Tasks, Notiﬁcations,

Authorisation and DB are internal entities of the sys-

tem. This completes Step 1.

4.1 Deﬁning the System Purpose

In order to deﬁne the system’s purpose (Step 2), one

needs to: (1) List all personal data (2) For each en-

tity of the system, e

, deﬁne which personal data

they will be providing, collecting, and processing, and

how exactly they will be processing them (deﬁne pre-

ceding and succeeding actions), and if needed deﬁne

under which circumstances (i.e., conditions) this will

be done.

Example: a Simple Task Management Application

- Purpose. For our running example, we (1) deﬁne

the following personal data: fullname, email address,

username, password.

We then proceed with (2) deﬁning the following

simple description of the processing purpose, omit-

ting some details for the sake of brevity:

- A User will be providing their username

and password during the login process to the

Authorisation entity, expecting to either receive an

authorisation message and proceed with accessing

their tasks, or a denial message and abort the system.

- Authorisation entity receives the personal data sent

by the User during the login process, checks them

with the DB and either grants or denies access.

- The Tasks entity, receives a request from a User ac-

companied by the user unique identiﬁer (username),

checks with the DB, and returns a list of the tasks that

are owned by the speciﬁc user. The User can only edit

and add tasks on this list.

- The Notiﬁcations entity, in case a deadline is ap-

proaching, retrieves from the DB the user’s email ad-

dress and then uses the email address to send a mes-

sage to inform the User for the upcoming deadline.

The above is a strict speciﬁcation of the process-

ing purpose to respect privacy. For example, the

Notiﬁcations entity purpose explicitly states that the

retrieval and use of the user’s email address should

only occur when there are upcoming task deadlines.

Therefore, if the system retrieves or uses the email

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

910

address in other scenarios, or when there are no ap-

proaching task deadlines, it would be considered non-

compliant. We proceed to present with the proposed

visualisations.

4.2 Purpose-Aware Use Case Diagrams

In the ﬁrst level, we selected to exploit Use Case

Diagrams to demonstrate a high-level overview of

the purpose-aware requirements (Gemino and Parker,

2009). Use case diagrams are Behavioral Uniﬁed

Modeling Language (UML) diagrams showing how

users and other external entities interact with a sys-

tem in a simple way. They do not include a high

level of detail regarding these interactions or demon-

strate interactions between the system’s internal enti-

ties. They cannot replace the detailed textual descrip-

tion; they can, however, complement it visually.

They consist of the following elements (Figure 1

/ left side): (a) Use Cases, represented by an oval

shape; (b) Actors, i.e., users and external entities, rep-

resented by ﬁgures; (c) Associations, lines between

the Actors and the Use Cases; (d) System Boundary

Box, that sets the system scope.

Figure 1: Use Case Diagrams (basic, extended).

We extend Use Case Diagrams with two more ele-

ments: (e) “Personal Data” to be shown in the associa-

tions between Actors and the System, (f) “Ownership

of Personal data” to be shown next to the actor they

belong to, as shown in Figure 1 / right side.

We then present a methodology for deﬁning

purpose-aware use case diagrams during the require-

ments capture stage as follows:

1. Deﬁne the “Personal Data” given by the user ac-

tors and other actors towards the system.

2. Deﬁne the “Personal Data” sent from the system

to other actors (external systems or users).

3. Deﬁne the “Personal Data” used within use cases

and on associations.

4. Deﬁne the “Ownership” for each “Personal Data”.

Example: a Simple Task Management Application

- Use Case Diagram. We demonstrate our methodol-

ogy by creating the use case diagram for the running

example, before and after the extension, presented in

Figures 2 and 3, respectively.

Figure 2: Example Basic Use Case Diagram.

We consider only User to be an external actor and

we recognize ﬁve use cases: Log-in, View all tasks,

Create new task, Edit tasks, and Receive notiﬁcations.

Figure 3: Example Extended Use Case Diagram.

The personal data given by the User towards the

system are: full name, username, email address, and

password. No personal data is sent from the system

to other external entities. The association between the

User and the Log-in use case carries on personal data

(username and password). The Log-in use case pro-

cesses the user’s password and username, the View all

Tasks, Create New Task, Edit Task use cases process

the username, while Receive Notiﬁcations processes

the user email address. If the registration operation

were also included in our example, we would notice

the User sending their full name and email address

towards the system. However, for this example, we

consider that this data already exists in the DB.

What’s Your Purpose? An Approach to Incorporating GDPR Purposes into Requirements Analysis

911

4.3 Purpose-Aware Sequence Diagrams

To accommodate our methodology and deﬁnition of

purpose, we needed to provide a second level of de-

tail and reﬁnement. To do so, we exploited UML Se-

quence Diagrams (Micskei and Waeselynck, 2011).

Sequence diagrams are Interaction Behavioral UML

diagrams, capturing the interaction in a collaboration

to realise a use case or an operation. Interactions can

be between the user and the system, between subsys-

tems (entities of the system), or between the system

and other external entities. They detail how function-

alities should be carried out and are also used in re-

quirements engineering. Such diagrams demonstrate

the order (in time) of the interactions between system

entities and the messages exchanged.

They consist of the following entities (Figure 4 /

left side): (a) Objects, representing participants in-

volved in the interactions; (b) Lifeline, showing the

passage of time for a speciﬁc participant (order, not

duration); (c) Activation box, representing the period

the participant is active in an interaction; (d) Actors,

representing external entities interacting with the sys-

tem, including the user; (e) Messages, representing

the communications between two participants.

We extend sequence diagrams to highlight the pro-

cessing of personal data, with two elements: (f) “Per-

sonal Data“ sent along with messages, with annota-

tions as identiﬁers, i.e., to demonstrate that it is the

same piece of data moving on to the sequence of inter-

actions, e.g. Phone

; (g) ”Personal Data Ownership”,

in a similar manner as in extended use case diagrams.

We present the extended sequence diagrams in Fig-

ure 4 / right side.

Figure 4: Sequence Diagrams (basic, Extension).

We then present a methodology for deﬁning

purpose-aware sequence diagrams as follows:

1. Deﬁne the “Personal Data” to be exchanged be-

tween objects and actors to fulﬁl an operation.

2. Deﬁne the exact messages on which personal data

are sent.

3. Deﬁne the “Ownership” for each “Personal Data”.

Example: a Simple Task Management Application

- Sequence Diagram. We demonstrate our methodol-

ogy by creating the sequence diagram for the running

example before and after the extension, presented in

Figures 5 and 6, respectively. The use case and se-

quence diagrams form the result of Step 3 of our

methodology.

We only present the login functionality diagram

for the sake of brevity, which operates as follows:

the user requests to login, sending their username

and password towards the system authorisation entity,

which then in turn sends these personal data to the

database of the system to check if log-in can be autho-

rised. The database informs the authorisation entity

that the user is either authorised or denied, returning

only the userame, so that the authorisation entity can

identify the user for which this message goes. Once

the user is successfully logged-in the authorisation en-

tity informs the tasks management entity, asking it to

display all the tasks of the speciﬁc user while accom-

panying the request with the user username.

Figure 5: Example Basic Sequence Diagrams.

To model the above-described operation, we have

the User as an external actor and the Authorisation

Entity, Database, and Tasks Management Entity as

objects. The personal data to be exchanged be-

tween the object and actors in the speciﬁc operation

are: username, password. Both will be sent from

the User towards the Authorisation entity on the Re-

quest Log-in message, and from the Authorisation en-

tity towards the DB on the Check Log-in message,

while the username will be send from the DB to the

Authorisation entity on the Auth/Deny Log-in mes-

sage, and from the Authorisation entity to the Tasks

Management entity on the Display all tasks message.

All mentioned personal data are owned by the User.

With the above, we deﬁne the global purpose, i.e.,

prescribing the interactions of a number of system en-

tities, instead of individually. However, a number of

different sequence diagrams might be needed to com-

pile the total interactions of the complete system. The

prescribed sequence of actions is the only one allowed

regarding the personal data involved.

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

912

Figure 6: Example Extended Sequence Diagrams.

5 INTEGRATING An

alisisP WITH

alogoP

The proposed purpose-aware sequence diagrams have

a direct one-to-one mapping to our Di

alogoP formal

purpose language.

On the top level, we have purpose, which is the

same case for An

alisisP. Then, in Di

alogoP each pur-

pose consists of many sessions that correspond di-

rectly with sequence diagrams in An

alisisP. Subse-

quently, each session of DialogoP includes commu-

nicating entities, corresponding to actors and objects

in An

alisisP. The entities in DialogoP exchange mes-

sages and can be distinguished in sending entities and

receiving entities. In An

alisisP, we do not explicitly

distinguish the actors and objects as sending or re-

ceiving; we do, however, indicate the arrow direc-

tion, therefore implying sending and receiving par-

ties. Messages can carry text or numerical values, but

both methodologies also have a special type of per-

sonal data. Moreover, personal data stores deﬁne the

personal data ownership. A summary of these rela-

tionships can be seen in Table 2.

Table 2: Mapping Between An

alisisP and Di

alogoP.

alogoP An

alisisP

1 Purpose Purpose

2 Session Sequence Diagram

3 Communicating Entity Object, Actor

3a Sending Entity Object, Actor if sending

3b Receiving Entity Object, Actor if receiving

4 Message Message, Return Message

5 Personal Data Type Personal Data

6 Personal Data Stores Ownership

Integration. In An

alisisP, the two types of diagrams

are created. Then, sequence diagrams are fed from

alisisP to Di

alogoP, where they are ﬁrst converted

into visual purposes and automatically transformed

into formal language purposes. Additionally, the ﬁg-

ure illustrates a future addition, Mod

eloP, aimed to

receive the formal purpose and transform it into a

formal process calculus model validated for purpose

compliance. All three tools, together, comprise the

ADMP Framework.

6 PRIVACY QUERIES

The deﬁned purpose-aware use case (UCD) and

sequence diagrams (SD) can further assist in re-

sponding to a set of additional important privacy

queries, as follows:

Q1. Does the system send personal data towards any

external entities, and if so, to which entities? (UCD)

Q2. Which personal data does the system collect

from users? (UCD)

Q3. Which system entities are processing a speciﬁc

piece of personal data? (SD)

Q4. Which pieces of personal data are processed by

a speciﬁc system entity? (SD)

Q5. Are the personal data collected from the users

indeed processed by the system entities, i.e. are they

used? Correlation with Data Minimisation principle.

(combination from both diagrams)

Example: a Simple Task Management

Application - Privacy Queries. We return to

the previous running example to collect the responses

to the above queries.

Q1: we observe that the system does not send any

personal data towards external entities.

Q2: we observe that the system collects the pass-

word, username, full name, and email of the User.

Q3: we observe that (a) the username is being

processed by the Authorisation entity, the DB, and

the Tasks entity; (b) the password is processed by

the Authorisation entity, and the DB; (c) the email is

used by the Notiﬁcations entity.

Q4: we observe that (a) the Authorisation entity

processes the username and password; (b) the Tasks

entity processes the username; (c) the Notiﬁcations

entity processes the email.

Q5: we observe that all data collected from the

User are indeed processed by some system entities,

except the user’s full name. This raises a ﬂag for the

system’s privacy, as the system collects personal data

that is not somehow used in the offered operations.

7 CONCLUSIONS

This work presents the integration of GDPR process-

ing purposes into system requirements, resulting in

purpose-aware system requirements. A visualisation

What’s Your Purpose? An Approach to Incorporating GDPR Purposes into Requirements Analysis

913

through extended use case and sequence diagrams is

proposed. In our previous work of (Vanezi et al.,

2020), we presented Di

alogoP, a formal language and

tool that allows the transformation of visual purpose-

aware requirements into a formal type language pur-

pose speciﬁcation, which has the potential to be rig-

orously checked and validate the compliant behaviour

of a system model. As an immediate next step, we

plan on presenting Mod

eloP, an algorithm for trans-

forming the formal type purpose into a pi-calculus

formal model that is guaranteed to comply with its

purpose-aware requirements. This model then has

the potential to be used in model-driven engineering

to produce a system’s code. We also aim, as a fu-

ture work, to conduct an extensive evaluation of our

methodology with software engineers, and a valida-

tion through a real-life case study.

REFERENCES

Alhazmi, A. and Arachchilage, N. A. G. (2021). I’m

all ears! listening to software developers on putting

GDPR principles into software development practice.

Personal and Ubiquitous Computing, 25(5):879–892.

Alshareef, H., Stucki, S., and Schneider, G. (2021a). Reﬁn-

ing privacy-aware data ﬂow diagrams. In Proceedings

of SEFM 2021, pages 121–140. Springer.

Alshareef, H., Stucki, S., and Schneider, G. (2021b). Trans-

forming data ﬂow diagrams for privacy compliance.

MODELSWARD, 21:207–215.

Alshareef, H., Tuma, K., Stucki, S., Schneider, G., and

Scandariato, R. (2022). Precise analysis of purpose

limitation in data ﬂow diagrams. In Proceedings of

ARES 2022. ACM.

Antignac, T., Scandariato, R., and Schneider, G. (2016). A

privacy-aware conceptual model for handling personal

data. In Proceedings of ISoLA (1) 2016, pages 942–

957. Springer.

Antignac, T., Scandariato, R., and Schneider, G. (2018).

Privacy compliance via model transformations. In

Proceedings of EuroS&P Workshops 2018, pages

120–126. IEEE.

Barth, A., Datta, A., Mitchell, J. C., and Nissenbaum, H.

(2006). Privacy and contextual integrity: Framework

and applications. In Proceedings of S&P’06, pages

184–198.

Basin, D., Debois, S., and Hildebrandt, T. (2018). On pur-

pose and by necessity: Compliance under the GDPR.

In Proceedings of FC’18, pages 20–37. Springer.

Booch, G., Jacobson, I., Rumbaugh, J., et al. (1996). The

uniﬁed modeling language. Unix Review, 14(13):5.

Byun, J., Bertino, E., and Li, N. (2005). Purpose based ac-

cess control of complex data for privacy protection. In

Proceedings of SACMAT’05, pages 102–110. ACM.

De Masellis, R., Ghidini, C., and Ranise, S. (2015). A

declarative framework for specifying and enforcing

purpose-aware policies. In Proceedings of STM’15,

LNCS 9331, pages 55–71. Springer.

European Parliament and Council of the European Union

(2012). Charter of fundamental rights of the european

union. Ofﬁcial Journal of the European Union.

European Parliament and Council of the European Union

(2015). General data protection regulation. Ofﬁcial

Journal of the European Union.

Gemino, A. and Parker, D. (2009). Use case diagrams in

support of use case modeling: Deriving understanding

from the picture. Journal of Database Management,

20(1):1–24.

Goldman, E. (2020). An introduction to the California Con-

sumer Privacy Act (CCPA). Santa Clara Univ. Legal

Studies Research Paper.

Jafari, M., Fong, P. W., Safavi-Naini, R., Barker, K., and

Sheppard, N. P. (2011). Towards deﬁning semantic

foundations for purpose-based privacy policies. In

Proceedings of CODASPY’11, pages 213–224. ACM.

Kala, K. (2019). Reﬁnement of the general data protection

regulation (GDPR) model: administrative ﬁnes per-

spective. Master’s thesis, University of Tartu.

Kouzapas, D., Dardha, O., Perera, R., and Gay, S. J. (2016).

Typechecking protocols with Mungo and StMungo. In

Proceedings of PPDP’16, pages 146–159. ACM.

Matulevi

cius, R., Tom, J., Kala, K., and Sing, E. (2020). A

method for managing GDPR compliance in business

processes. In CAiSE Forum 2020, pages 100–112.

Springer.

Micskei, Z. and Waeselynck, H. (2011). The many mean-

ings of UML 2 sequence diagrams: a survey. Software

& Systems Modeling, 10(4):489–514.

Petkovi

c, M., Prandi, D., and Zannone, N. (2011). Pur-

pose control: Did you process the data for the intended

purpose? In Workshop on Secure Data Management,

pages 145–168. Springer.

Riahi, S., Khosravi, R., and Ghassemi, F. (2017). Purpose-

based policy enforcement in actor-based systems. In

Proceedings of FSEN’17, LNCS 10522, pages 196–

211. Springer.

Sing, E. (2018). A meta-model driven method for establish-

ing business process compliance to GDPR. Master’s

thesis, University of Tartu.

Tom, J., Sing, E., and Matulevi

cius, R. (2018). Concep-

tual representation of the GDPR: model and applica-

tion directions. In Proceedings of BIR 2018, pages

18–28. Springer.

Tschantz, M. C., Datta, A., and Wing, J. M. (2011). On the

semantics of purpose requirements in privacy policies.

arXiv preprint arXiv:1102.4326.

Tschantz, M. C., Datta, A., and Wing, J. M. (2012). For-

malizing and enforcing purpose restrictions in privacy

policies. In Proceedings of SP’12, pages 176–190.

IEEE Computer Society.

Vanezi, E., Kapitsaki, G. M., Kouzapas, D., Philippou, A.,

and Papadopoulos, G. A. (2020). Di

alogop-a language

and a graphical tool for formally deﬁning GDPR pur-

poses. In Proceedings of RCIS 2020, pages 569–575.

Springer.

Yang, N., Barringer, H., and Zhang, N. (2007). A purpose-

based access control model. In Proceedings of IAS’07,

pages 143–148. IEEE Computer Society.

ICISSP 2024 - 10th International Conference on Information Systems Security and Privacy

914