Separation of Lanthanides/ Lanthanides and Actinides
Privacy Requirements Engineering in Agile Software Development
1. www.cin.ufpe.br/~ler
Laboratório de Engenharia
de Requisitos
Universidade
Federal de
Pernambuco
Privacy Requirements Engineering in Agile
Software Development
Mariana Peixoto and Carla Silva (Supervisor)
{mmp2, ctlls}@cin.ufpe.br
Degree: Doctoral
Year of Entry: March/2016
Conclusion Expectation: March/2020
VIII Workshop on Thesis and Dissertations of CBSoft (WTDSoft 2018)
09/2018
2. Outline
Problem Characterization
Background
Contributions
Current Research Status
Description and Evaluation of Results
Related Work
2
3. Problem Characterization
Increase in software applications
Digital data reveal large quantities of personal information
[Van Der Sype and Maalej, 2014].
People may not be aware of when and for what purpose their
personal information has been or will be collected, analyzed or
transmitted [Omoronyia et al., 2013].
The exposure of such information in an unregulated way can
threaten user privacy [Omoronyia et al., 2013].
Privacy concerns have some impact on consumer behavior and
the acceptability and adoption of new technologies
[Spiekermann and Cranor 2009].
3
4. Problem Characterization
it is necessary to approach the privacy issues from the
requirements discovery, that is, in the Requirements
Engineering (RE) when requirements elicitation and
specification occurs [Tun et al. 2012; Kalloniatis et al. 2008;
Ayed and Ghernaouti- Hélie 2011].
Many developers do not have sufficient knowledge and
understanding about privacy [Hadar et al. 2018].
There is a gap between designers’ and stakeholders’
understandings of what privacy means [Gharib et al. 2017].
4
5. Problem Characterization
The increasingly adoption of Agile Software Development
(ASD)
Short iterations and active stakeholders
Flexibility to deal with requirements changes
It is necessary to address privacy issues also in ASD
[Viitaniemi, 2017].
In ASD non-functional requirements are sometimes neglected
5
6. Background
Privacy is a concept that is not easily defined.
There is still no unified view on privacy requirements engineering yet
[Backers 2012; Gharib et al. 2017].
Privacy is the right to determine when, how and what conditions it
is permitted to disclose personal information and to transmit such
information to third parties [Kalloniatis et al., 2008].
6
7. Background
Traditional RE consists of a process with four high level activities:
Feasibility Study, Elicitation and Analysis, Specification and
Validation.
ASD methods do not adopt the structured phases of the traditional
RE process [Heikkilä et al. 2015].
Common practices regarding requirements (228 companies in 10
countries) [Wagner et al. 2018].
Requirements elicitation: interviews, facilitated meetings, prototyping,
scenarios and observation;
Documentation: free-form textual, structured requirements lists, semi-
formal use case models and free-form textual domain/business
process models.
7
10. Contributions - Objective
Main objective: Provide a process to guide the elicitation and
specification of privacy requirements in the context of Agile
Software Development.
How to elicitate and specify privacy requirements in agile
development?
Specific objectives
How to create a unified view of privacy for RE?
1. Define a set of privacy concepts;
2. Define a set of relationships among privacy concepts;
3. Define a set of capabilities to specify privacy.
10
11. Current Status
To achieve the objectives, the four phases for conducting studies
proposed by Glass (1995), are used:
Informational Phase;
Analytical Phase;
Propositional Phase;
Evaluative Phase.
11
12. Current Status
Informational Phase:
Systematic Literature Review (SLR) on domain-specific
modeling languages [Peixoto and Silva 2018a].
Collect an overview of the privacy domain (privacy concepts
and relationships)
i) an overview of the existing languages that supports privacy
concepts;
ii) the languages taxonomy and requirements analysis
techniques;
iii) a catalog of privacy concepts extracted from the papers.
12
13. Current Status
Analytical Phase: Two Exploratory Studies (ES)
First Exploratory Study:
Survey with 8 privacy experts
Average age of respondents (38.63 years);
Educational level: Masters 1 (12.5%) - PhDs 7 (87.5%);
Experience with privacy: 5 (62.5%) theoretical experience; 1
(12.5 %) practical and theoretical experience; and 2 (25.0 %)
practical experience;
Years of experience: 7 more than 3 years of experience with
privacy and 1 less than 1 year.
13
15. Current Status
Second Exploratory Study:
14 privacy specification capabilities (C) framework [Peixoto
and Silva 2018b]
(i) Conceptual model;
(ii) Information technology - Security techniques - Privacy
framework [ISO29100, 2011];
(iii) General Data Protection Regulation [GDPR, 2018];
(iv) Guidelines proposed by Organisation for Economic Co-
operation and Development [OECD, 2013].
15
16. Current Status
Privacy specification capabilities (C) framework
C1 - Specify the purpose of tasks;
C2 - Specify different types of actors;
C3 - Specify relationships of actors;
C4 - Specify trust relationship;
C5 - Specify different types of personal information;
C6 - Specify privacy machanims/goals;
C7 - Specify users’ privacy preferences and contexts;
C8 - Specify privacy risks;
C9 - Specify privacy threats;
C10 - Specify privacy harms;
C11 - Specify privacy vulnerability;
C12 - Specify to connect risk, threat, harms and vulnerability;
C13 - Specify consent;
C14 - Specify privacy constraint.
16
17. Current Status
Propositional Phase:
Privacy Elicitation - Guided interviews to answer a series of
structured questions that cover the concepts of the privacy
conceptual model
Privacy Specification - RSD approach in a guided way to cover
the privacy specification capabilities (C1 to C14)
17
18. Current Status
Evaluative Phase
Interviews with privacy and ASD experts
Illustrative scenarios
Controlled experiment
18
19. Description and Evaluation of
Results
Interviews with Experts
Quantitative questions (5-point Likert scale)
Privacy Experts
How correct are the privacy specification capabilities (C1 to
C14)?
How complete are the privacy specification capabilities (C1 to
C14)?
Agile Experts
How suitable for ASD is the proposed approach for privacy
elicitation and specification?
19
20. Description and Evaluation of
Results
Illustrative Scenarios:
Real illustrative scenarios will be used to evaluate the quality of the
generated specifications according to Complete, Consistent,
Affordable and Bounded criteria [ISO-IEEE 29148 2011].
Controlled Experiment:
Complete, Consistent and Bounded, which are characteristics for a
good requirements specification [ISO-IEEE 29148 2011].
20
21. Description and Evaluation of Results
Controlled Experiment:
21
Criteria/
Metric
Symbol Meaning
Complete NMRPA Number (#) of missing requirements using the proposed
approach (PA).
NMROA # of missing requirements using the other approach
(OA).
Consistent NDRPA # of duplicate requirements specified with the PA.
NDROA # of duplicate requirements specified with the OA.
NARPA # of ambiguous requirements specified with the PA.
NAROA # of ambiguous requirements specified with the OA.
Bounded NWRPA # of wrong requirements specified with the PA.
NWROA # of wrong requirements specified with the OA.
Time TSPA Time spent (minutes) with the PA.
TSOA Time spent (minutes) with the OA.
Questions NQPA # of questions asked with the PA.
NQOA # of questions asked with the OA.
Table 2. Controlled experiment metrics.
22. Related Work
Gharib et al. (2017) proposed an ontology for privacy
requirements as a mean to conceptualize privacy
requirements in their social and organizational context.
Kalloniatis at al. (2009) provide an overview of requirements
engineering approaches which focus on privacy
requirements and have ways to accomplish requirements
specification.
NFR (Non-Functional Requirement Framework), i*
Framework, Tropos
Labda et al. (2014) and Pullonen et al. (2017) extend BPMN as a
mean to incorporate visual constructs for modeling privacy
requirements.
22
23. Related Work
Antón and Earp (2000) focus on the initial specification of
security and privacy policy and their operationalization (goal
and scenario-driven requirements engineering methods).
Viitaniemi (2017) proposes to deal with privacy in agile
software development through the privacy by design
paradigm which is the idea that for a system ensures the
privacy of personal data, privacy should be considered from
the beginning of the software project.
23
24. www.cin.ufpe.br/~ler
Laboratório de Engenharia
de Requisitos
Universidade
Federal de
Pernambuco
Privacy Requirements Engineering in Agile
Software Development
Mariana Peixoto and Carla Silva (Supervisor)
{mmp2, ctlls}@cin.ufpe.br
Degree: Doctoral
Year of Entry: March/2016
Conclusion Expectation: March/2020
VIII Workshop on Thesis and Dissertations of CBSoft (WTDSoft 2018)
09/2018