Paper presented in the CBSoft 2018 - IX Brazilian Conference on Software, September 17-21, São Carlos - SP, Brazil

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

8. Background
 Requirements Specification for Developers (RSD) [Medeiros et al.
2017]
8
Figure 1. Practices of RSD Approach. Medeiros (2017).

9. Background
9
Figure 2. Example of requirements specification using RSD approach. Medeiros (2017).

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

14. Current Status
 First Exploratory Study:
14
Figure 3. Privacy Conceptual Model.

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