Identifying How the Brazilian Software Industry

Specifies Legal Requirements

Dorgival Netto Carla Silva João Araújo
[email protected] [email protected] [email protected]
Centro de Informática - Universidade Centro de Informática - Universidade Faculdade de Ciências e Tecnologia -
Federal de Pernambuco / Instituto Federal de Pernambuco Universidade Nova de Lisboa
Federal de Mato Grosso do Sul Recife, Brasil (NOVA LINCS)
Recife / Corumbá, Brasil Caparica, Portugal

ABSTRACT KEYWORDS
[Background] Software requirements are usually specified Requirements Engineering, Legal Compliance, Ambiguity
in Natural Language, bringing challenges for Requirements
Engineering (RE) as these specifications are inherently am- ACM Reference Format:
biguous. These challenges become bigger when dealing with Dorgival Netto, Carla Silva, and João Araújo. 2019. Identifying How
software requirements that must comply with regulations, the Brazilian Software Industry Specifies Legal Requirements. In
the so-called legal requirements. The state of practice to XXXIII Brazilian Symposium on Software Engineering (SBES 2019),
tackle ambiguity of legal requirements and their compli- September 23–27, 2019, Salvador, Brazil. ACM, New York, NY, USA,
ance with regulations is missing. [Goal] This work investi- 6 pages. https://doi.org/10.1145/3350768.3352730
gates how ambiguity in legal requirements specification is
addressed and how the software development industry per-
forms legal compliance. [Method] We followed a qualitative 1 INTRODUCTION
approach based on semi-structured interviews involving nine Software development companies must comply with a large
professionals from different companies who presented their number of regulations and ensure that their business and
views on the RE process, including legal compliance and am- system requirements are in legal compliance [11]. Legal texts
biguity resolution of legal requirements. Data was collected are full of ambiguities, often planned, called intentional am-
using audio-recorded and analyzed using Grounded Theory. biguity [15, 20]. This type of ambiguity allows laws and reg-
[Results] Findings revealed that customer and legal expert ulations to avoid dependence on technologies or practices
support during the project could reduce the risk of misinter- that may change over time [5, 19].
preting the legislation. Verification and Validation of Legal Although many works were developed to help engineers
Compliance are customer assignments. [Conclusions] Am- to address ambiguity in software requirements and to align
biguity resolution and legal compliance of requirements are system requirements with legal constraints [2, 6, 11, 14, 19],
based on the tacit knowledge of experienced team members they have not performed empirical studies to describe how
or discussions between the team and the customer. the industry deals with ambiguity in legal requirements spec-
ification and compliance.
CCS CONCEPTS A recent mapping study evidenced that current litera-
· Software and its engineering → Software creation ture does not present the state of practice related to how
and management; Designing software; Requirements the industry deals with legal requirements ambiguity and
analysis; legal compliance in the development of software systems
[17]. Thus, this paper presents the results of an exploratory
Permission to make digital or hard copies of all or part of this work for
study to collect evidence about how Information Technology
personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear
(IT) organizations address ambiguity in legal requirements
this notice and the full citation on the first page. Copyrights for components specification and how they ensure legal compliance of the
of this work owned by others than ACM must be honored. Abstracting with developed software systems. To achieve this, we performed
credit is permitted. To copy otherwise, or republish, to post on servers or to nine semi-structured interviews with professionals of Brazil-
redistribute to lists, requires prior specific permission and/or a fee. Request
ian public and private software companies in the Midwest
permissions from [email protected].
(2), Northeast (4) and Southeast (1) regions. Collected data
SBES, 2019, Salvador, Brazil
© 2019 Association for Computing Machinery.
were analyzed using Grounded Theory (GT) [9].
ACM ISBN 978-1-4503-7651-8/19/09. . . $15.00 The remaining of this paper is structured as follows. Sec-
https://doi.org/10.1145/3350768.3352730 tion 2 describes the research methodology, Section 3 presents

181
SBES, 2019, Salvador, Brazil Netto, Silva and Araújo

data collection and analysis. Section 4 presents our prelimi- Table 1: Characterization of the Companies
nary results. Finally, Section 5 presents the conclusions and
future directions of this research. Co. Public / National or Age Employees
no. Private Multinational (yrs)
2 RESEARCH METHODOLOGY 1 Public National 50+ 1000-5000
This section describes the methodology used to perform this 2 Public National 20-30 1000-5000
research, including the participants’ characterization. 3 Public National 20-30 51-200
Research Goal. The purpose of this paper is to contribute 4 Private Multinational 5-10 11-50
to a better understanding of how companies (public and pri- 5 Private National 10-20 51-200
vate) perform the legal requirements specification and how 6 Private Multinational 20-30 10000+
they deal with the inherent ambiguity in this type of require- 7 Private National 5-10 11-50
ment besides performing the verification of legal compliance.
Design study. Benbasat et al. [4] state that a case study Table 2: Characterization of the Participants
examines a phenomenon in its natural setting, employing
various methods of collecting data to capture information
Co. Participant Experience Position
from one or more entities (individuals, groups, or organiza-
no. ID with IT (yrs)
tions). The case studies carried out in this article have the
exploratory purpose, as they aim to discover what is hap- 1 01 31 IT Director
pening, seeking new knowledge, and generating ideas and 1 02 10 Project Manager
hypotheses for new research [21]. After, the interviews will 4 03 5 Programmer Analyst
be transcripted and, later, codified and analyzed using GT. 2 04 18 Senior Manager
Sample. The unit of analysis of this study is composed of 3 05 22 Programmer Analyst
public and private companies consolidated in the software 5 06 3 Deployment Analyst
development market. To increase data diversity, we looked 6 07 3 Requirements Analyst
for companies with different characteristics regarding size 1 08 15 Project Manager
and sector (public or private) (see Table 1). The purpose of 7 09 7 Product Owner
using a non-probabilistic sample lies in the selection of the
information because it is possible to choose relevant cases
for the study [16]. and Q3), for example, or how the process of extracting re-
We invited the potential participants by e-mail. About 40 quirements from legal texts occurs (Q6 and Q7). Next, the
IT professionals, of different profiles (developers, require- interviewee describes its participation in a software project
ments analysts, project manager, legal specialists, among that needs compliance with legislation (Q4 and Q5). Then,
others), were invited. From these, only nine agreed to be we investigate the company’s procedures when ambiguity
interviewed. The mean of participants’ experience is 11.81 is identified (Q8 and Q9). Afterward, we analyze how the
years, with values ranging from 3 to 31 years (see Table 2). Requirements Specification occurs (Q10), and how verifica-
tion and validation of current requirements are performed
to ensure legal compliance (Q11). Also, we inquired how
3 DATA COLLECTION AND ANALYSIS
to deal with the personal data protection laws that are in
Data Collection evidence, the EU General Data Protection Regulation (GDPR)
A semi-structured interview was performed using an in- [10] (Q12) and the Brazilian General Data Protection Law
terview script specifically designed and composed of open- [8] (Q13). Moreover, we wanted to know how Privacy Poli-
ended questions [18]. More general questions were presented cies are defined (Q14) for the systems that are developed,
at the beginning, followed by the more specific ones [22]. knowing that the policies establish an agreement between
Two professors with more than 15 years of experience in supplier and user regarding the capture, storage and use of
the Requirements Engineering field analyzed the interview the data of the individual.
script. A pilot interview was performed with a senior IT Before each interview, the participants received by e-mail
professional and served to validate the interview script and the Consent Term and a detailed explanation about the re-
to latter improve it. However, we discarded those answers. search goals. We conducted the interviews using a phone call,
The Interview Script, available in [18], initially discusses Skype, Google Meet, or Hangouts. They occurred between
how Requirements Elicitation is carried out, either from the November 2018 and March 2019. The first author conducted
interviews, brainstorming or documentation analysis (Q2 and recorded all interviews, with the permission of each

182
Identifying How the Brazilian Software Industry Specifies Legal Requirements SBES, 2019, Salvador, Brazil

interviewee. Each interview lasted an average of 47 min and, companies. The companies use the project structure, allocat-
altogether, it resulted in 7h and 30 min of audio time. ing each development team to work in a specific project. The
Collected data were discussed between the authors, and in- teams follow agile principles [3] and are composed of five
consistencies were addressed in discussions and complemen- to nine members, cross-functional, with all the specialized
tary explanations provided by the participants. When doubts skills necessary to create a product release.
arose regarding answers, we contacted the respondent again łThese teams are multidisciplinary have 4 to 6 people,
and asked him to clarify the authors’ understanding. and they work together for the period necessary to de-
velop that scope there. We work basically with projects
Data Analysis
for great demands and maintenance for minor demands.ž
We followed the guidelines provided by Strauss and Corbin (Interviewee 02).
[9] to categorize and synthesize data in order to identify łI usually say that our team is multi-hat. Within the
the points that influence the legal requirements specifica- team, we have the role of developer, business analyst and
tion and the verification and validation of legal compliance. have the role of quality analyst and; we change the hat
The first author transcribed each audio interview, and QDA constantly depending on the activity.” (Interviewee 03).
Miner 1 was used to support the analysis process. The inter- łIn addition to the project team, formed by software
views transcription lasted an average of 2h and 12 min and, developers, we have technical support areas, specialized
altogether, it lasted a total of 19h and 8 min. support, which provide consulting. However, they also
Portions of text were labeled using codes (we started with audit, raise non-compliance, and verify their resolution
open coding, then we did axial coding and, finally, we used during the project life cycle.” (Interviewee 07).
selective coding) [9]. Coding consists of giving a label to RE practices. Interview is the most commonly used re-
essential portions of the interview transcriptions. Open cod- quirements elicitation technique. As companies use agile
ing was used at the beginning of the analysis to identify methods, customer engagement is critical. However, they
relevant portions of the interview transcriptions and create also use document analysis, brainstorming, sprint design,
codes. Axial coding is used to identify relevant portions of and lean startup.
the interview transcriptions based on codes identified in the
“We seek to interview these users, study how they work
open coding [9]. Subsequently, the relationships between
[...] document analysis technique to gather what they
categories were mapped to identify their influences about the
produce or receive to try to elicit their work process and
requirements specification process with reduced ambiguity
where it could be improved and automated with the help
and legal compliance. Figure 1 illustrates the category cre-
of systems.” (Interviewee 04).
ation process. The transcription step was performed only by
“Today we use some techniques based on sprint design,
the first author; in the coding stage, two authors participated,
and we also use techniques that involves lean startup,
and the third author only solved the conflicts.
which helps us to do the requirements survey today.”
(Interviewee 09).
“So the interviews, the meetings, are more to clarify
doubts about the documentation we received[...]. In an-
other project, we did not receive documentation, and it
was more with brainstorming. I had a macro idea, but
nobody knew what I was going to do.” (Interviewee 05).
The roles of the individuals who participated in the re-
quirements elicitation session were the most varied.
łThe business analyst, responsible for elicitation, the
analyst of services, which is, from the perspective of the
Figure 1: Construction of a category using open coding
company, the person who knows the best service, right?
The client, effectively, and our development team who
Findings will write the code [...] depending on the solution, we can
call a specific architect, an Information Security Analyst
Companies characterization. The companies have three and there depends on the solution.ž (Interviewee 01).
sectors: one responsible for new solutions design, another for łProduct Owner (PO), we also have a facilitator who is
software’ maintenance/evolution and a third for Quality and like Scrum Master, and we have developers and designers,
IT Governance. The name of these sectors varies between and today we are also inserting a tester in that first step.ž
1 https://bit.ly/2gGLnTP (Interviewee 09).

183
SBES, 2019, Salvador, Brazil Netto, Silva and Araújo

łWe talk a lot with the PO of our team, and from the “the person who owns the process is responsible for the
conversations, we have with the PO, we define the scope compliance [...], the requirement we are specifying will
that iterations, and it is from there that elicits these have a section in the document [...] and we write the
requirements.ž (Interviewee 03). complete reference of the Law there. ž (Interviewee 04).
The techniques used to document the requirements related “We assume that the customer’s acceptance of the re-
to the Requirements Specification step are user stories, use quirements and of the product itself already attends to
cases, and requirements templates. this verification question, because that customer is re-
sponsible for meeting the demand, even of its adherence
“traditional requirements we do through user stories. Per- to the client’s normative apparatus. The company specif-
sonas are used to design some system functionality when ically does not make a legal compliance assessment on
it impacts a vast number of users. A few requirements demand. We trust, within our process... trust the infor-
that do not, you can write a user story, we write it in an mation and accept the customer.” (Interviewee 06).
IEEE requirements template.” (Interviewee 04).
“We have a tool to support the agile development as a To validate and verify legal compliance of the requirement,
whole since the beginning of the demand to the registra- the customer plays a determinant role.
tion of meetings, interviews.” (Interviewee 02).
“This document is validated by the customer itself to
Legal compliance. The companies carry out the extrac-
ensure that... to seek the commitment there that what
tion of the requirements from a legal section by identifying
we understand is really what the customer needs. At
relevant legal excerpt to the software. This excerpt must be
least in the perspective of that person who is detached to
reflected in the requirements which, therefore, comply with
accompany us.” (Interviewee 05).
the legislation.
“The team allocated to the project along with customer Ambiguity resolution. Procedures for resolving ambi-
technical support, who is the łunderstanderž of the regu- guity vary among organizations. Some have specialized legal
lation, they will together study this legislation and make support that can be consulted to try to resolve the identified
the extractions of requirements, both software function- ambiguity. Others bring together the members of the team or
ality, and work processes.” (Interviewee 04). consult customers to reach a consensus on the understanding
“The development team itself analyzes the material, stud- of the identified ambiguity.
ies the material and, from this analysis plus the infor-
mation coming from the interviews with the clients, the “The local test team does a review of requirements, in a
team can decide whether use cases or user stories are line to eliminate ambiguities, [...] to make the text more
needed there." (Interviewee 02). objective, try to eliminate any possibility of misunder-
standing.” (Interviewee 02).
Legal texts have some characteristics that make them “We can not work with redundant fonts, usually the
unique when compared to other sources of requirements: client has to define, and this is recorded in the meeting
laws can complement, overlap, or contradict each other; minutes or the requirements document itself that infor-
some areas of law go through constant changes; regulations mation was originated from that document, that law
may also refer to other sections of a specific regulation [20]. specifically.” (Interviewee 02).
Compliance with regulations is a source of non-functional “When you have information that might be shallow or
requirements [12] that need to be adequately considered. Ac- relative, what happens a lot is getting everyone together.
cording to Boella et al. [7], legal requirements are the form Anyway, the entire team as a whole decides to define the
found by RE to make it possible for standards relevant to the interpretation for that text.” (Interviewee 03).
application domain to be correctly encoded in Information “if it is a question like this, a little more sensitive to deal-
Systems. According to Akhigbe et al. [1], the 103 revised ing directly with the customer, we trigger our operations
studies dealing with legal or legal compliance cover four managers, he will contact a person from the customer
tasks: 41% modeling, 44% checking, 13% analysis, and 2% area, and he solves all these issues.” (Interviewee 08).
publication of compliance (enactment). “Normally, if you have something a bit confusing, speak-
When a requirement must follow the legislation, each ing of legislation... we have a legal support person, who
organization adopts a different procedure. is a lawyer, that is when it is something very critical, and
“for all the demands the client highlights a specialized there is a very high risk that we will do something non-
team to provide the necessary inputs for the development. compliant, we will put it into a kind of consultancy. Then,
However, the team interpretation is always verified by this person will get out, and we will develop according to
the specialized customer.” (Interviewee 05). what we understood after consulting.” (Interviewee 09).

184
Identifying How the Brazilian Software Industry Specifies Legal Requirements SBES, 2019, Salvador, Brazil

When the client knows there is ambiguity either in a legal and, from this analysis, the team asks the developer to
section or in the requirements specification, “he gets frus- make corrections." (Interviewee, 02).
trated. However, from the beginning we make it clear that, even Only one company has discussed the GDPR, even if it is
we are specialists, changes may happen. Because when we talk a theme in force since 2016. In other companies, some em-
about law, for example, if I am developing a software for six ployees are still unaware of its importance not only to the
months, this law can be changed. So, we always try to work IT industry but to the institution as a whole. This lack of
with a slightly longer schedule.” (Interviewee 09). knowledge about the GDPR may happen because the discus-
sion remains restricted to the area of Information Security or
4 DISCUSSION Law Department. As Interviewee 01 said, "I do not know how
After analyzing the understanding of participants on the RE to speak to you. Maybe [anonymity preserved], from the area
process, including legal compliance and ambiguity resolution of Information Security, can help you more". Alternatively,
of legal requirements, the codes were grouped into categories. because some companies deal only with the local market and
Moreover, excerpts from interviews with evidence related are not concerned with international regulations, according
to each category were used to identify the factors affecting to Interviewee 08: "I do not have this knowledge because, as
positively and negatively each category. This section shows far as I know, the company in our country develops systems
the identification of core categories, which emerged from only for users who are in our country".
the data by connecting the most recurrent categories, as well
as how they are related (see Figure 2). 5 FINAL REMARKS & FUTURE DIRECTIONS
Four basic categories (Requirements Elicitation, Require- Ambiguity in legal requirements is a well-known problem
ments Specification, Working with Law, Sensitive Personal both to academic and industry communities. Nevertheless,
Data) and three core categories (Communication between by analyzing the cases presented in this paper, we could not
the Team and the Customer, Legal Requirements and, Am- identify a systematic process to detect and resolve the ambi-
biguity) were found. The core categories are highlighted by guity of legal requirements or to ensure they are compliant
the rectangle with the dashed border in red. The arrows that with the law. One company uses a catalog of requirements
relate a factor to a category have a signal plus or minus rep- [13], but without using this nomenclature, to register recur-
resenting, respectively, positive or negative influences from ring situations. However, the process to deal with ambiguity
the factors to these categories. For example, Change in the and legal compliance is based on the tacit knowledge of ex-
Law is a negative factor for those Working with Law because perienced team members or discussions between the team
this change has an impact on the development processes. and the customer.
The contribution (positive or negative) of each category over Next steps of this research includes to interview more
the main categories were derived from the interpretation of people from different organizations to get as diverse views
the interviews and data analysis performed by the authors. and roles as possible. Moreover, we intend to conduct a cross-
The smaller bidirectional arrows between the categories rep- sectional survey through a self-administered questionnaire
resent that they relate, in interviews. The larger bidirectional via Internet, since the participants belong to different states
arrows connecting only core categories, represent the rela- of the country. The survey has the goal to evaluate the rele-
tionships with higher importance, i.e., to address ambiguity vance of the findings presented in this paper. We also intend
in legal requirements, the Communication between the Team to relate systematic literature review results, such as [1], to
and the Customer is critical. To ensure a successful Require- the findings from the interviews (presented in this study)
ments Elicitation and Requirements Specification, Communi- and the survey to be applied. The purpose is to corroborate
cation between the Team and the Customer is critical. Figure the practices present both in the literature and industry to
2 presents the categories and their related factors. tackle ambiguity in legal requirements specification and legal
The study revealed that only one company has a special- compliance in the early stages of the software development
ized department for ambiguity analysis. process.

"One thing that makes it quite interesting in the way REFERENCES

people work is the advent of having a department or [1] Okhaide Akhigbe, Daniel Amyot, and Gregory Richards. 2018. A
specialized team trained in ambiguity analysis. Because systematic literature mapping of goal and non-goal modelling methods
the developer is involved with the demand, involves with for legal and regulatory compliance. Requirements Engineering 1, 766
the client, gets involved with the context. When we have (2018), 1–23.
[2] Vanessa Ayala-Rivera and Liliana Pasquale. 2018. The Grace Period
a separate team that will read the text produced, with Has Ended: An Approach to Operationalize GDPR Requirements. In
techniques, with training to perceive that the text is not 26th International Requirements Engineering Conference (RE). IEEE,
objective, not clear, gives room for double interpretation Banff, AB, Canada, 136–146.

185
SBES, 2019, Salvador, Brazil Netto, Silva and Araújo

Figure 2: Central categories and their relationships

[3] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward 21–26.
Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew [13] Luis Gonçalves and Alberto Rodrigues da Silva. 2018. A Catalogue
Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert Martin, Steve Mellor, of Reusable Security Concerns: Focus on Privacy Threats. In 20th
Ken Schwaber, Jeff Sutherland, and Dave Thomas. 2001. Manifesto for Conference on Business Informatics (CBI), Vol. 2. IEEE, Vienna, Austria,
agile software development. http://agilemanifesto.org/ 52–61.
[4] Izak Benbasat, David K Goldstein, and Melissa Mead. 1987. The case [14] Aaron Massey, Eric Holtgrefe, and Sepideh Ghanavati. 2017. Modeling
research strategy in studies of information systems. MIS quarterly 11, regulatory ambiguities for requirements analysis. In International Con-
3 (1987), 369–386. ference on Conceptual Modeling (ER). Springer Intl. Publishing, Cham,
[5] Daniel Berry and Erik Kamsties. 2004. Ambiguity in requirements spec- 231–238.
ification. In Perspectives on software requirements, Julio C. S. do P. Leite [15] Aaron Massey, Richard Rutledge, Annie Antón, and Peter Swire. 2014.
and Jorge H. Doorn (Eds.). Springer US, Boston, MA, 7–44. Identifying and classifying ambiguity for regulatory requirements. In
[6] Jaspreet Bhatia, Travis Breaux, Joel Reidenberg, and Thomas Norton. 22nd International Requirements Engineering Conference (RE). IEEE,
2016. A theory of vagueness and privacy risk perception. In 24th Karlskrona, Sweden, 83–92.
International Requirements Engineering Conference (RE). IEEE, Beijing, [16] Sharan Merriam and Elizabeth Tisdell. 2015. Qualitative research: A
China, 26–35. guide to design and implementation. Jossey-Bass, San Francisco, CA.
[7] Guido Boella, Llio Humphreys, Robert Muthuri, Piercarlo Rossi, and [17] Dorgival Netto, Mariana Peixoto, and Carla Silva. 2019. Privacy and
Leendert van der Torre. 2014. A critical analysis of legal requirements Security in Requirements Engineering: Results from a Systematic Lit-
engineering from the perspective of legal practice. In 7th International erature Mapping. Anais do WER19 - Workshop em Engenharia de
Workshop on Requirements Engineering and Law (RELAW). IEEE, Karl- Requisitos, Recife-PE, Brasil, Agosto 13-16, 2019 (2019).
skrona, Sweden, 14–21. [18] Dorgival Netto, Carla Silva, and Jo ao Araújo. 2019. Supplementary
[8] BRASIL. 2018. Lei Geral de Protecao de Dados n. 13.709, 14/Ago. http: Material. https://dorgivalnetto.github.io/SBES2019/
//www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm [19] Paul Otto. 2009. Reasonableness meets requirements: Regulating secu-
[9] Juliet Corbin and Anselm Strauss. 2014. Basics of qualitative research. rity and privacy in software. Duke LJ 59 (2009), 309.
sage, Thousand Oaks, California, CA. [20] Paul Otto and Annie Antón. 2007. Addressing legal requirements in
[10] EU. 2016. General Data Protection Regulation. https://eugdpr.org/ requirements engineering. In 15th International Requirements Engi-
[11] Sepideh Ghanavati, Daniel Amyot, and André Rifaut. 2014. Legal goal- neering Conference (RE). IEEE, Delhi, India, 5–14.
oriented requirement language (legal GRL) for modeling regulations. [21] C Robson. 2002. Real World Research 2nd edition Blackwell Oxford.
In 6th International Workshop on Modeling in Software Engineering. Blackwell Publishing 2nd, 2 (2002), 587.
ACM, NY, USA, 1–6. [22] Per Runeson, Martin Höst, Austen Rainer, and Björn Regnell. 2012.
[12] Martin Glinz. 2007. On non-functional requirements. In 15th Interna- Case study research in software engineering. In Guidelines and exam-
tional Requirements Engineering Conference (RE). IEEE, Delhi, India, ples. Wiley Online Library, Hoboken, New Jersey.

186