Exploring User-centered Requirements Validation and Verification
Techniques in a Social Inclusion Context
Emille Catarine Rodrigues Canc¸ado
a
, Ian Nery Bandeira
b
, Pedro Henrique Teixeira Costa
c
,
Jos
´
e Fortes Neto, Daniel Carvalho Moreira, Lu
´
ıs Amaral
d
and Edna Dias Canedo
e
Department of Computer Science, University of Bras
´
ılia (UnB), P.O. Box 4466, Bras
´
ılia, DF, Zip-cod 70910-900, Brazil
ednacanedo@unb.br
Keywords:
Former Inmates, Social Inclusion, Requirements Verification and Validation, Privacy, Prototyping.
Abstract:
The activities that comprise a requirements engineering process involve elicitation, modeling, validation, and
verification of requirements, and these activities tend to be more communication and interaction-intensive than
others during the software development process. This paper presents an experience report on requirements
validation and verification techniques applied to a mobile application project developed for the Brazilian prison
system’s former inmates, aiming to support them in their resocialization process. Besides, it presents the
decisions we made in agreement with the project stakeholders to guarantee the end-users data privacy. Our
results show that even with the Covid-19 pandemic and social isolation restrictions, it was possible to apply
the requirements validation techniques. Furthermore, the mobile application’s acceptance tests with both
stakeholders and the end-users demonstrate that the developers duly followed the privacy guidelines. Finally,
all privacy requirements comply with the stakeholders and the application’s end-users needs and are under the
Brazilian General Data Protection Law (LGPD).
1 INTRODUCTION
A software’s set of requirements must be validated
to ensure that the stakeholders’ needs are being ad-
dressed and that the defined quality criteria are being
fulfilled (Lampa et al., 2017). Therefore, it is nec-
essary to validate and verify the requirements to de-
tect any errors or inconsistencies in the team’s elicited
and documented requirements for this activity (Bjar-
nason et al., 2014). Software requirements valida-
tion encompasses validation and verification activities
(Nascimento et al., 2021). Verification is perceived
as sufficing the precepts of correction and complete-
ness of requirements, while validation is understood
as meeting users’ expectations (Fiorini et al., 1998;
do Prado Leite and Freeman, 1991).
Validation and verification of elicited require-
ments are related to the quality of the software. Thus,
as software systems become more complex, concerns
a
https://orcid.org/0000-0002-1283-8391
b
https://orcid.org/0000-0002-8083-7278
c
https://orcid.org/0000-0002-8385-8314
d
https://orcid.org/0000-0003-1236-3119
e
https://orcid.org/0000-0002-2159-339X
about validating and verifying requirements increase
since it is necessary to ensure that each error has
been identified and corrected (McMillan et al., 2019).
Therefore, the non-alignment of requirements engi-
neering with verification and validation can lead to
software deployment problems regarding the dead-
line, quality, and scope (Bjarnason et al., 2014).
The legal requirements of software also need to be
verified and validated (Santos et al., 2017), especially
in the current context. There is specific legislation to
guarantee users’ data privacy. In Brazil, the General
Data Protection Law (LGPD) came into force in 2020,
which establishes the rules for collecting, storage,
treatment, and sharing personal data, imposing more
protection and penalties for non-compliance with the
principles of the law by organizations (Macedo, 2018;
BRASIL, 2020). The LGPD covers all personal data
collected, stored, and processed by public and pri-
vate organizations with an international reach (Bax
and Barbosa, 2020; Ferr
˜
ao et al., 2021; Canedo et al.,
2021; Canedo et al., 2020).
This paper presents a case study of requirements
validation and verification techniques applied in soft-
ware development to support the Brazilian prison sys-
tem’s former inmates. As it is a more vulnerable
Cançado, E., Bandeira, I., Costa, P., Neto, J., Moreira, D., Amaral, L. and Canedo, E.
Exploring User-centered Requirements Validation and Verification Techniques in a Social Inclusion Context.
DOI: 10.5220/0010959900003179
In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 1, pages 85-92
ISBN: 978-989-758-569-2; ISSN: 2184-4992
Copyright
c
2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
85
group, our choices related to data privacy were re-
shaped so as not to be intimidating to the end-users,
for instance, not saving end-users personal informa-
tion and creating the possibility for former inmates to
use all the application services, even if one chooses
not to permit any of their device’s native tools in the
app, such as its location service. We also analyzed the
impact of using these techniques on an actual software
project amidst the period of social isolation caused by
the Covid-19 pandemic.
2 VALIDATION AND
VERIFICATION TECHNIQUES
The requirements validation and verification process
consist of reviewing, analyzing, and testing the re-
quirements to ensure that the designed system is com-
patible with the users’ needs (Laplante, 2017). Sev-
eral techniques in the literature address the validation
and verification of requirements (Bertini et al., 2006;
Kalinowski et al., 2007; Maalem and Zarour, 2016;
Bhatti et al., 2015; Pohl, 2016):
1. Review by a Specialist – This technique is based
on using a specialist’s knowledge to check the
quality of the requirements. The specialist re-
views all requirements and looks for problems
such as inconsistency or ambiguity. When the re-
viewer finds a problem, he/she comments on the
documentation for errors and possible solutions to
fix them.
2. Inspection of Requirements This technique
consists of a team with different responsibilities
(Pohl, 2016): Organizer: Plans and controls the
inspection process; Moderator: Lead the ses-
sions, always maintaining the inspection follow-
up as agreed in the initial stages; Author: Re-
sponsible for explaining the requirements to in-
spectors in the early stages of the project. The
author is also responsible for correcting the errors
identified in the process’s steps; Reader: Member
of the team that will guide inspectors in the face
of the various requirements to be inspected. The
reader’s job is to take the inspector’s responsibil-
ity away from interpreting what the author meant,
and they can focus on the requirement itself; In-
spectors: Responsible for detecting faults and
reporting them to other members of the project
team; Secretary: Responsible for taking the re-
sults of the session and compiling them, in addi-
tion to preparing the minutes of the session. In-
spection within the context of requirements val-
idation can be divided into the stages of plan-
ning, overview, fault detection, and fault collec-
tion: (Pohl, 2016):
(a) Planning: In this step, one defines the objec-
tive of the inspection, the planning of the pro-
cess, and the functions of each participant;
(b) Overview: In this phase, the author details all
the requirements for his/her team so that every-
one is aware of the system in question and can
clarify any doubts;
(c) Fault Detection: The inspectors effectively ex-
amine the requirements and document the pos-
sible faults for the next step. Fault finding can
be done either as a team or individually. The
group search has the advantage of communica-
tion and consequent synergy between inspec-
tors whilst the individual search makes every-
one focused on the work;
(d) Fault Collection: In this last step, all faults
presented in the detection stage are reevaluated
to avoid duplication or to remove faults classi-
fied incorrectly.
3. Walkthrough It is a technique similar to in-
spection, but it is a more straightforward and less
rigid version (Pohl, 2016). The division of the
team is simplified, in which the same person can
perform several functions. In this technique, the
functions of at least one reviewer, author, secre-
tary, and moderator are used. This technique aims
to identify flaws in the requirements and share
the project’s understanding among the people in-
volved in the inspection.
4. Verification in Different Perspectives This
technique validates the requirements through an
interpretation of the system, taking into account
different perspectives. The perspectives usually
vary from system to system, but it is possible to
elicit at least some types that usually occur in ev-
ery project, and that can be adapted:
(a) Perspectives of Stakeholders
User perspective: The user checks the re-
quirements from his/her perspective and
checks whether it matches the reality and
expected quality; Developer perspective: The
developer verifies that the requirements contain
all the information and properties necessary for
the project to be completed; Test perspective:
The tester verifies whether it is possible to
make test cases that satisfy the entire project
based on the elicited requirements.
(b) Perspectives of System Quality
Documentation perspective: From this per-
spective, it is ensured that the documentation
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
86
involving the requirements meets all the criteria
that have been defined;
Content perspective: Perspective that deals
with the content of the requirements itself and
focuses on the quality of that content;
Perspective of agreement: In this perspective,
the focus is on ensuring that everyone involved
in the project is following the elicited require-
ments and that there is no conflict to be re-
solved.
5. Prototyping Validation Prototype is a prelimi-
nary model of a complete system. Thus, what this
technique does is to use this model in favor of re-
quirements validation. Based on the project pro-
totype, requirements can be tested and validated
practically by the stakeholders, checking if they
meet the expectations. Prototypes can be divided
depending on their destination in disposable pro-
totypes or evolutionary prototypes (Pohl, 2016).
The disposables are only for the current test. They
will not be put into production again since the
evolutionary is a constantly evolving prototype as
the project develops and requires more work to
be done. For a prototype to be made, it is neces-
sary to select the requirements that it will contem-
plate. This set does not typically cover all docu-
mented requirements as it would bring very high
costs and complexities. Therefore, it is necessary
to make a selection criterion among the require-
ments and determine the most suitable to be used
in the prototype. Along with the prototype itself,
three more documents are needed to validate the
requirements (Pohl, 2016): a manual containing
all the usage and application information; a doc-
ument containing several scenarios for validating
requirements; and a checklist for each of the re-
quirements that will be validated. Scenarios that
are not included in the documents can and should
be tested after the entire process to verify the sys-
tem in different situations and circumstances that
were not planned initially. After the validation
is completed, the results are compiled and dis-
cussed. Changing, removing, or adding require-
ments are consequences during this step. If the
changes are very large or impactful, it is advisable
to remodel the prototype to cover these changes,
and it is possible to carry out a new validation
(Pohl, 2016).
6. Checklist Validation The checklist technique is
used in complex projects and when the system has
several issues that need to be taken into account.
Checklists can be used in conjunction with many
other techniques and are made up of questions or
statements to identify errors in the requirements.
The source for assembling the checklist can come
from both stakeholders and requirements quality
criteria. The list can constantly be updated as
the project progresses. New features and require-
ments emerge, so removing ambiguous questions,
editing, and adding information are always wel-
come as the project develops. The success of the
technique will depend on the length and complex-
ity of the checklist. A very long and complete list
of details can make the process slower and unfea-
sible for the inspector. The same thing can happen
if the list is very subjective, making the validation
process slow and susceptible to failures.
3 SOFTWARE REQUIREMENTS
The Virtual Social Office (ESVirtual) purpose is to fa-
cilitate access to services and support the former in-
mates and their families (de Mendonc¸a et al., 2020)
The mobile application provides access to informa-
tion on services and policies for assisting people from
the Brazilian prison system by giving opportunities
to take online courses, providing job advice, infor-
mation about Health Care, proof of compliance with
sentence conditionalities for people on semi-open and
open prison regimes, among other features.
Among the requirements validation and verifica-
tion techniques presented in Section 2, we used veri-
fication from different perspectives and validation by
prototyping in software development in this research.
In an effort to ensure that every possible necessity
of both the public and the creators of the Virtual So-
cial Office would be met, we opted to use verification
from different perspectives. Along with the develop-
ment, testing, and design leads, we analyzed the per-
spective of three different entities:
1. The Brazilian National Council of Justice (CNJ)
administrative staff, who have overall knowledge
of the resocialization process and which, despite
not working directly with the app’s target audi-
ence, have facilitating expertise in devising tools
for the final product’s deployment and dissemina-
tion;
2. Employees of the physical social office, who di-
rectly serve the app’s target audience, since the
physical social offices already provide assistance
to former inmates in their resocialization process;
3. Potential end-users, who have experiential knowl-
edge of their particular processes and might pos-
sess insight into critical issues and features not ad-
dressed by the other two parties.
Exploring User-centered Requirements Validation and Verification Techniques in a Social Inclusion Context
87
Validation by prototyping was employed in an at-
tempt to ensure ease of communication between the
different project stakeholders since suggestions could
be better understood and debated when embodied and
evaluated in a prototype. In addition, prototyping
might facilitate the communication process between
the project’s design and development teams to pre-
vent the idealization of any functionality that is not
feasible for development.
3.1 Verification in Different
Perspectives
In the ESVirtual development, we carried out the
validation and verification of requirements from the
stakeholders’ perspectives and the system’s quality.
Regarding the stakeholders’ perspectives, those re-
sponsible for the project are Brazilian National Justice
Council administrative staff, who regard this applica-
tion as a tool to support the re-socialization process
of former inmates. These executives have selected
some physical Social Office members to validate the
requirements along with three potential end-users.
The stakeholders’ and users’ validation was per-
formed through online meetings. The project lead de-
signer presented to the meeting participants the pro-
totypes proposed for the application’s functionalities.
The validation and verification meetings were held
one week after eliciting requirements for the respec-
tive functionality. In case an error was detected in
the understanding of the requirement, we recorded the
observations. In the following week, we presented the
proposed prototype’s updates to the stakeholders un-
til there were a consensus and the validation of the re-
quirement. Thus, the requirement was only forwarded
to the software development team after its validation
by the stakeholders.
From the test and developers’ perspectives, we
tested the functionalities using integrated technolo-
gies through programs that simulate the application’s
use from a user’s perspective. We created auto-
matic actions on the screen using command lines,
and through the answers presented, it was possible to
carry out a general analysis. Thus, we expected re-
sponsive activities on the screen according to the se-
quence of pre-established actions.
We could analyze the application’s response time,
the availability of features, and errors that may arise
without prior knowledge from the automated tests.
Also, these tests could reveal bugs in the features re-
sulting in a different procedure than expected, thus
predicting future errors that could come to the end-
user of the application. We tested all possible ac-
tions related to the application’s functionality to ex-
pose, predict and correct possible errors that could
occur through malfunction behavior. Error prevention
allows preventing failures from remaining in the ap-
plication and find possible improvements for the user
experience. We use some tools to perform this type of
tests, namely: Cucumber (Li et al., 2016; Fazzolino
et al., 2018), tool developed in the Java language, used
to describe all the scenarios and steps that were simu-
lated in the application.
The Appium (Alotaibi and Qureshi, 2017), tech-
nology responsible for integrating other tools into the
application and executing the steps defined in Cucum-
ber, promoting the communication and execution of
the commands to be executed on the screen automat-
ically. For the most part, the operation of Cucumber
occurs through references that are pre-labeled in the
front-end project through identifying each feature that
has an assigned reference name. It allows localization
on screen and the necessary action of the feature to
obtain the application’s expected response. In addi-
tion to the identification property, others such as po-
sitions of elements using height and width references
on the screen and the response time were considered
in the execution of the test sessions.
We used Cucumber to describe the steps that, the-
oretically, would be performed by an actual user of the
application, an emulator, or a physical device. The
Cucumber was responsible for running the applica-
tion, and the Appium tool was responsible for making
the communication between Cucumber and the appli-
cation on the device. Figure 1 shows one of the tests
performed to verify the functioning of the functional-
ity required for health facilities. This requirement is
responsible for providing information on basic health
units, emergency services, psychosocial care centers,
and hospitals to former inmates from the prison sys-
tem. We performed all the steps described in Cucum-
ber in an actual use scenario. Besides, we corrected
the found errors before the implementation phase, and
the specifications of the Virtual Social Office require-
ments were updated.
Figure 1: Verification of Health Facilities requirements.
The perspective of the system’s quality was real-
ized through the content, in which three researchers of
the project initially validated the screens of the proto-
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
88
type, developed from the elicited requirements. Sub-
sequently, we validated the prototypes again with the
project stakeholders to guarantee that all requirements
were in line with expectations and that there was no
conflict between the decisions adopted.
Figure 2 (a) presents the proposed prototype for
the specified requirement of the Health Facilities
functionality, also validated through the testing per-
spective (Figure 1). All inconsistencies/errors de-
tected in the verification from different perspectives
were corrected, and we implemented suggestions for
improvements in the prototypes before the next phase
of the software development process.
4 PROTOTYPING VALIDATION
The prototyping of the requirements can be used as a
validation technique, identifying the problems in the
specification of requirements from a visual perspec-
tive of the software under development (Bilal et al.,
2016). Aceituna et al. (Aceituna et al., 2011) stated
that prototyping could prevent more errors than re-
quirements validated in natural language. Prototyp-
ing allows us to include non-technical stakeholders in
the inspection process and validate, with less time and
cost, the hardware and software requirements of a sys-
tem (Aceituna et al., 2011).
We prototyped all the ESVirtual features to val-
idate with the stakeholders before going to the im-
plementation phase. First, the elicitation of require-
ments occurred in face-to-face meetings at the Na-
tional Council of Justice headquarters. Subsequently,
due to the Covid-19 pandemic, virtual meetings were
held using the Microsoft Teams tool
1
. We choose
this tool because both institutions involved in the de-
velopment of the project (National Council of Justice
(CNJ) and University of Bras
´
ılia (UnB)) adopted it.
Requirements elicitation meetings were held
weekly with various project stakeholders and re-
searchers and lasted an average of 02 hours. During
the meetings, the functionalities were discussed, and
the stakeholders passed on the necessary information.
Then the researcher Designer of the project later per-
formed the prototyping of the ESVirtual’s function-
alities. We prototyped all the functionalities of the
application using the tool Figma (Figma, 2021).
We carefully reviewed all functionalities with the
stakeholders in the prototyping phase, aiming to pro-
vide a solution according to the former inmates’ needs
and with a friendly interface because it is an applica-
tion that serves a fragile audience. After the proto-
1
https://teams.microsoft.com/
typing of the functionalities, we presented the newly
proposed solution to the stakeholders. During the
presentation, the meeting participants discuss doubts,
and in some situations, there were suggestions for im-
provements and reformulation of the proposed solu-
tion. These reviews allow the ESVirtual to be an ally
to the end-user searching for important information
for their re-socialization process.
As an example, it is worth mentioning the pro-
posed solution for the requirement “ Food ”. The pur-
pose of this functionality in the ESVirtual application
is to indicate to the user (former inmates) food facil-
ities to find meals at a popular price. If the user per-
mits the application to access their location, they will
have access to a list of places that offer food, ordered
by proximity, as shown in Figure 2 (b). Ordering by
proximity helps them to take the shortest route/path to
reach a community restaurant.
Figure 2: (a) Validation of the prototype of the health facil-
ities requirements and (b) “Food” functionality with access
to the user’s location.
However, sharing the location can be sensitive in-
formation for many users. Even if the application
does not save the location information, some may
choose not to provide this data. In this way, if the
users choose the application not to access their loca-
tion, they can indicate the state and city to consult
and access the complete list of community restaurants
in alphabetical order. Figure 3 presents the proposed
prototype for the requirement specified for this func-
tionality. Although the user does not know the dis-
tance of these restaurants concerning his current loca-
tion, he is not deprived of accessing the application’s
information.
All errors found in the validation activity in the re-
quirements elicitation phase were corrected, and we
implemented some suggestions for improvements in
the functionalities. Thus, we can conclude that us-
ing the techniques of validation and verification of
requirements was positive since all users could vali-
date the requirements elicited through different per-
spectives and the prototypes proposed for each func-
Exploring User-centered Requirements Validation and Verification Techniques in a Social Inclusion Context
89
Figure 3: “Food” functionality without access to the user’s
location.
tionality of the application.
In addition to using the techniques to perform the
validation and verification of requirements in the ini-
tial phases of the project, we also carried out a valida-
tion with the project stakeholders after implementing
all software requirements. The stakeholders and users
performed the validation by downloading the appli-
cation from Play Store stores (for Android platform
users) and Apple Store stores (for iOS users). Par-
ticipants in the validation activity performed all the
features provided and made available in the ESVir-
tual. We did not find impacting errors that could harm
the evolution of the ESVirtual. Thus, we can con-
clude that the verifications and validations before the
implementation phase were essential for the delivered
project’s quality.
5 DATA PRIVACY
We developed the ESVirtual for a vulnerable popula-
tion that seeks to re-socialize in society. Thus, we
elicited the software requirements to keep the end-
users’ information confidential to avoid embarrass-
ment on the former inmate or situations considered
difficult and/or embarrassing by them. Therefore, the
requirements elicitation ensure that users’ data were
not requested and maintained when using the appli-
cation’s functionalities. For this reason, according to
the ESVirtual specification, the system developed will
only attend queries to public data provided by differ-
ent government agencies. There is no need to keep a
register with users’ information since they carry out
the consultations anonymously to public data. As the
system does not store user information, no actions
were necessary to guarantee the user’s data privacy.
The functionality called “Legal Situation” allows the
former inmates to monitor their processes’ execution
through a private consultation using a personal access
key.
The project development team opted to use the
POST request method, from the HTTP (Tanenbaum
and Wetherall, 2011) protocol, to pass the query key
to the processes so that this data was not part of the
query URL. Besides, the HTTPS protocol was used,
which implements the HTTP protocol with an ad-
ditional layer of security over Secure Socket Layer
(SSL), so that all requests are encrypted, thus guaran-
teeing the security of the execution of the functional-
ity. The prototype of the “Legal Situation” function-
ality is shown in Figure 4.
Figure 4: “Legal Situation” functionality.
6 DISCUSSIONS
The Virtual Social Office application’s proposed re-
quirements stemmed from discussions and interviews
held with the National Council of Justice (CNJ) stake-
holders, prison system former inmates, and Social Of-
fice of Esp
´
ırito Santo employees. These requirements
guided the layout and usability solutions proposed by
the project designer, and the prototyping of the solu-
tions on the Figma Design Tool (Figma, 2021) facil-
itated the process of monitoring and validation of the
entire team and stakeholders, and through the visual
concept rendered by the prototype, stimulated further
discussions involving the gathering of new require-
ments and the validation of requirements already pro-
posed.
Using the validation technique involving multi-
ple perspectives enabled all parties involved in the
project to validate the requirements, whether from
the stakeholders’, end-users’, developers’, or project
researchers’ perspectives. The physical Social Of-
fice employees and the former inmates who partici-
pated in our meetings fulfilled essential development
roles. Their inputs and insights, which are from peo-
ple closely intertwined with the re-socialization pro-
cess, aligned the development and design teams for
features that effectively reach the application’s target
audience. Such interaction among the contributors al-
lowed for interesting exchanges related to user expe-
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
90
rience, solution usability, and possible technologies
which might be employed to support the application’s
acceptance by the end-users.
The validation by prototyping proved to be highly
adequate and enabled the project’s design team’s in-
volvement in the software release schedule and the
requirements prioritization. The prototypes were sub-
mitted to the Scrum master and the project devel-
opment team right after the stakeholder validation
to ensure that any concerns and features were ex-
plained to the team. Each solution proposed by the
design team is discussed with the project’s lead en-
gineer to ensure the proposed approach’s feasibility.
Errors found during the validation and requirements
verification phase and after the application was pub-
lished online were negligible and could be addressed
quickly. Furthermore, the use of prototypes proved
to be extremely important for the idealization of the
application’s functionalities by the entire team during
the Covid-19 pandemic, in which only non-presential
meetings were held. This graphic resource allowed
easier comprehension of all the proposed ideas, fil-
tered and represented by the design team, and then
discussed, reviewed, and validated by the entire team.
This process, along with the interaction between
the project members, reduced the risks of errors,
usability failures, or wrongly implemented require-
ments by the development team. Besides, the fin-
ished prototypes were of high graphic quality, facil-
itating the appraisal from every member involved and
accurately representing every detail of what was ex-
pected as an outcome from the development team. As
a result, this eased the entire process of implementing
new features. Also due to the social isolation period
resulting from the Covid-19 pandemic, meetings be-
tween the research team and the stakeholders became
more limited. This limitation resulted in the research
team having to make critical decisions to develop the
app without the stakeholders’ direct involvement. The
prototyping and requirements validation enabled all
such decisions to be easily identified, understood, and
validated before the app’s release in the stores.
Furthermore, the usability tests with end-users
were also impaired due to social isolation, especially
among sensitive groups with low education levels or
little to no familiarity with mobile devices. However,
the app’s alpha version allowed virtual usability tests
with three former inmates, which were able to con-
solidate the proposed solutions and point out not only
constructive criticism towards what had already been
implemented but also requirements that they deemed
relevant and that had not been addressed in the app so
far.
7 CONCLUSIONS
In this paper, we provide an experience report on the
use of software requirements validation and verifica-
tion techniques applied to real-world software devel-
opment. We conducted these processes using verifi-
cation from different perspectives and validation by
prototyping. These results have shown how the tech-
niques have mitigated the likelihood of errors during
the requirements engineering process. Furthermore,
performing the validation made it possible to pinpoint
possible errors in advance of the beta testing period,
as all members involved could assess the proposed so-
lutions in both functioning prototypes and the appli-
cation’s alpha version.
The requirements validation also allowed the
stakeholders and end-users to ensure that the privacy
of the user’s data was being guaranteed in the devel-
opment process, as per the requirements elicitation
performed, and whether it complied with the LGPD
standards. For future projects, we intend to work to-
wards the requirements elicitation for new applica-
tion functionalities based on interviews and discus-
sions with the CNJ stakeholders, former inmates of
the prison system, and employees of physical Social
Offices across the country. New tests will also be con-
ducted with stakeholders and former inmates, hope-
fully with more participants with varying age, edu-
cation, and gender profiles. Also, we will perform a
usability evaluation on the ESVirtual application em-
ploying the set of usability heuristics for quality as-
sessment of mobile applications on smartphones, pro-
posed by Ruyther et al. (da Costa et al., 2019). Simul-
taneously, we will investigate the application’s impact
on the re-socialization process of Brazilian prison sys-
tem former inmates.
ACKNOWLEDGMENTS
We want to thank the National Council of Justice for
supporting this research. This work has been partially
supported by FAP-DF (the Brazilian Federal District
Research Foundation).
REFERENCES
Aceituna, D., Do, H., and Lee, S. (2011). Interactive
requirements validation for reactive systems through
virtual requirements prototype. In First Model-Driven
Requirements Engineering Workshop, MoDRE 2011,
Trento, Italy, August 29, 2011, pages 1–10. IEEE
Computer Society.
Exploring User-centered Requirements Validation and Verification Techniques in a Social Inclusion Context
91
Alotaibi, A. A. and Qureshi, R. J. (2017). Novel framework
for automation testing of mobile applications using
appium. International Journal of Modern Education
& Computer Science, 9(2).
Bax, M. P. and Barbosa, J. L. S. (2020). Proposta de mecan-
ismo de consentimento na lei geral de protec¸
˜
ao a da-
dos - LGPD (consent mechanism proposal in LGPD).
In ONTOBRAS, volume 2728 of CEUR Workshop
Proceedings, pages 316–321, http://ceur-ws.org/Vol-
2728/doctorate4.pdf. CEUR-WS.org.
Bertini, L. A., Kirner, T. G., Montebelo, M. I., and Lara,
I. A. R. (2006). T
´
ecnicas de inspec¸
˜
ao de documentos
de requisitos de software: um estudo comparativo. In
Alencar, F. M. R., S
´
anchez, J., and Werneck, V., edi-
tors, Workshop on Requirements Engineering (WER),
Rio de Janeiro, RJ, Brasil, Julho 13-14, 2006, pages
67–74.
Bhatti, S. N., Usman, M., and Jadi, A. A. (2015). Validation
to the requirement elicitation framework via metrics.
ACM SIGSOFT Software Engineering Notes, 40(5):1–
7.
Bilal, H. A., Ilyas, M., Tariq, Q., and Hummayun, M.
(2016). Requirements validation techniques: An em-
pirical study. International Journal of Computer Ap-
plications, 148(14).
Bjarnason, E., Runeson, P., Borg, M., Unterkalmsteiner, M.,
Engstr
¨
om, E., Regnell, B., Sabaliauskaite, G., Locon-
sole, A., Gorschek, T., and Feldt, R. (2014). Chal-
lenges and practices in aligning requirements with
verification and validation: a case study of six com-
panies. Empir. Softw. Eng., 19(6):1809–1855.
BRASIL (2020). Guia de boas pr
´
aticas lei geral
de protec¸
˜
ao de dados (lgpd). Comit
ˆ
e Central de
Governanc¸a de Dados. Secretaria de Governo Digi-
tal, 1–65.
Canedo, E. D., Calazans, A. T. S., Masson, E. T. S., Costa,
P. H. T., and Lima, F. (2020). Perceptions of ICT
practitioners regarding software privacy. Entropy,
22(4):429.
Canedo, E. D., Cerqueira, A. J., Gravina, R. M., Ribeiro,
V. C., Cam
˜
oes, R., dos Reis, V. E., de Mendonc¸a, F.
L. L., and de Sousa Jr., R. T. (2021). Proposal of an
implementation process for the brazilian general data
protection law (LGPD). In ICEIS (1), pages 19–30.
SCITEPRESS.
da Costa, R. P., Canedo, E. D., de Sousa J
´
unior, R. T.,
de Oliveira Albuquerque, R., and Garc
´
ıa-Villalba,
L. J. (2019). Set of usability heuristics for quality
assessment of mobile applications on smartphones.
IEEE Access, 7:116145–116161.
de Mendonc¸a, W. L. M., Costa, P. H. T., Canc¸ado, E. C. R.,
Lima, F., Canedo, E. D., Bonif
´
acio, R., and Amaral, L.
H. V. (2020). From dusk till dawn: Reflections on the
impact of COVID-19 on the development practices of
a r&d project. In SBES, pages 596–605. ACM.
do Prado Leite, J. C. S. and Freeman, P. (1991). Require-
ments validation through viewpoint resolution. IEEE
Trans. Software Eng., 17(12):1253–1269.
Fazzolino, R., de Faria, H. M., Amaral, L. H. V., Canedo,
E. D., Rodrigues, G. N., and Bonif
´
acio, R. (2018). As-
sessing agile testing practices for enterprise systems:
A survey approach. In SAST, pages 29–38. ACM.
Ferr
˜
ao, S.
´
E. R., Carvalho, A. P., Canedo, E. D., Mota, A.
P. B., Costa, P. H. T., and Cerqueira, A. J. (2021). Di-
agnostic of data processing by brazilian organizations
- A low compliance issue. Inf., 12(4):168.
Figma (2021). The collaborative interface design tool.
Figma, accessed on march 5, 2021.
Fiorini, S. T., do Prado Leite, J. C. S., and de Lucena, C.
J. P. (1998). Organizando processos de requisitos. In
Workshop on Requirements Engineering(WER), pages
1–8.
Kalinowski, M., Sp
´
ınola, R. O., Dias-Neto, A., Bott, A.,
and Travassos, G. H. (2007). Inspec¸
˜
oes de requisitos
de software em desenvolvimento incremental: Uma
experi
ˆ
encia pr
´
atica. VI Simp
´
osio Brasileiro de Quali-
dade Software (SBQS), Porto de Galinhas, Brazil.
Lampa, I. L., de Godoi Contessoto, A., Amorim, A. R.,
Zafalon, G. F. D., Val
ˆ
encio, C. R., and de Souza, R.
C. G. (2017). Project scope management: A strategy
oriented to the requirements engineering. In Proceed-
ings of the 19th International Conference on Enter-
prise Information Systems - Volume 2: ICEIS,, pages
370–378. INSTICC, SciTePress.
Laplante, P. A. (2017). Requirements engineering for soft-
ware and systems. CRC Press.
Li, N., Escalona, A., and Kamal, T. (2016). Skyfire: Model-
based testing with cucumber. In ICST, pages 393–400.
IEEE Computer Society.
Maalem, S. and Zarour, N. (2016). Challenge of validation
in requirements engineering. J. Innov. Digit. Ecosyst.,
3(1):15–21.
Macedo, P. N. (2018). Brazilian general data protection law
(lgpd). Brazilian National, accessed on January 18,
2021, 1(1):1–16.
McMillan, C., Crapo, A., Durling, M., Li, M., Moitra,
A., Manolios, P., Stephens, M., and Russell, D.
(2019). Increasing development assurance for system
and software development with validation and veri-
fication using assert™. Technical Report 2019-01-
1370, SAE Technical Paper.
Nascimento, R., Souza, L., Targino, P., Siz
´
ılio, G., Kulesza,
U., and Lucena, M. (2021). Investigating information
about software requirements in projects that use con-
tinuous integration or not: An exploratory study. In
Proceedings of the 23rd International Conference on
Enterprise Information Systems - Volume 2: ICEIS,,
pages 303–312. INSTICC, SciTePress.
Pohl, K. (2016). Requirements engineering fundamentals:
a study guide for the certified professional for require-
ments engineering exam-foundation level-IREB com-
pliant. Rocky Nook, Inc.
Santos, I., Miranda, E., and Lucena, M. (2017). Rastrea-
mento e gerenciamento de requisitos em busca da con-
formidade legal. In Workshop on Requirements Engi-
neering(WER).
Tanenbaum, A. S. and Wetherall, D. (2011). Computer Net-
works. Prentice hall, 5 edition.
ICEIS 2022 - 24th International Conference on Enterprise Information Systems
92