Educational Software Requirements Elicitation Techniques:
Including Children with Autistic Spectrum Condition
Lucas N. Cabral
1a
, J. Antão B. Moura
1b
, Marcelo A. de Barros
1c
, Laurent Borgmann
2d
,
Uwe Terton
3e
and Carla C. M. Medeiros
4f
1
Systems and Computing Department, Federal University of Campina Grande (UFCG), Brazil
2
Business and Social Management, University of Applied Sciences, Koblenz, Germany
3
Faculty of Business, Arts and Law, Southern Cross University (SCU), Australia
4
Public Health Department, State University of Paraíba, Campina Grande (UEPB), Brazil
Keywords: Educational Software, Requirements Elicitation Techniques, Children with Autistic Spectrum Conditions.
Abstract: Although specialized literature and software engineering frameworks suggest techniques for elicitation of
software requirements, no elicitation technique works for all situations. Challenges arising from end users’
communication disabilities make choosing an adequate technique even more important to identify these users’
usability and accessibility needs and preferences. Children with such disabilities, e.g. Autistic Spectrum
Condition (ASC), are particularly challenging. The literature on software requirements elicitation for children
with ASC seems particularly scanty. Here, systematic mapping studies of the literature, analyses of some
software development frameworks and recommendations from practicing software engineers were considered
to create an initial catalogue of elicitation techniques. Specialists on software and autism were then invited to
evaluate the applicability of each of the catalogued techniques for children with an ASC. This paper brings
results of such evaluation. As such it may assist software requirements engineers in selecting techniques that
are more likely to successfully include children with ASCs in the requirements elicitation process. Future
work could experiment with such techniques in (educational) software development contexts.
1 INTRODUCTION
Poor definition of requirements is among the main
causes of software development failure (Standish
Group Int., 2015). Poor requirements can result from
software engineers’ inadequate choices of elicitation
techniques (Sabariah et al., 2019). An erroneous
choice can influence the elicitation results and thus
degrade the quality of the collected requirements and
have a negative impact on the final software product.
In the case of educational software, the impact can be
passed on to the stakeholders’ education (Sabariah et
al., 2019).
a
https://orcid.org/0000-0001-7741-5560
b
https://orcid.org/0000-0002-6393-5722
c
https://orcid.org/0000-0001-7437-0344
d
https://orcid.org/0000-0002-5025-3853
e
https://orcid.org/0000-0001-5177-8064
f
https://orcid.org/0000-0002-7994-7277
The choice of which technique to use can be more
complicated when one deals with stakeholders who
have conditions such as autistic spectrum conditions
(ASC), attention deficit hyperactivity disorder
(ADHD) or Down syndrome (DS), which affect about
15% of the world’s population (WHO, 2021). Such
conditions can include one or more impairments such
as communicative, cognitive, developmental,
intellectual, mental, physical, or sensory condition, or
a combination of these.
This paper focuses on techniques for eliciting
educational software requirements from children with
ASC (Autistic Spectrum Condition) because this
condition may make the elicitation process more
304
Cabral, L., Moura, J., A. de Barros, M., Borgmann, L., Terton, U. and Medeiros, C.
Educational Software Requirements Elicitation Techniques: Including Children with Autistic Spectrum Condition.
DOI: 10.5220/0011078200003182
In Proceedings of the 14th International Conference on Computer Supported Education (CSEDU 2022) - Volume 1, pages 304-313
ISBN: 978-989-758-562-3; ISSN: 2184-5026
Copyright
c
 2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

challenging, since it affects social interaction,
communication, interest, and behavior (Logan et al,
2022). The severity and impact of ASCs vary
significantly. As noted by an early reviewer of this
work [private communication, June 2019], “children
with high-functioning ASC can be articulate and
could potentially provide well specified
requirements; a low-functioning child with ASC will
not even be able to talk”. Similar observations have
been reported by Beutel et al. (2021). This is the
reason why the researchers decided to target children
with medium -to high- functioning ASC. Further, the
literature on elicitation techniques for
communication-challenged stakeholders is limited.
Some studies in this field detail the requirements
of an application which should be met to assist the
needs of children, but the main challenge is that
children are not included in the requirements
elicitation stage of the development process, only in
the validation process (Giullian et al., 2010). The
inclusion of stakeholders in the requirements
elicitation process should be one of the most
important factors in order to determine the success of
a software application (Sadiq & Jain, 2014). Of
course, relatives and professionals – e.g., caregivers
and educators working with children with an ASC –
may understand some of the needs and difficulties of
the children (Cheak-Zamora et al., 2015). However,
the children’s participation in the process can bring a
more complete perspective of necessary requirements
to an application, enhance the quality of the
application and therefore become more beneficial to
the user.
This paper describes the research results from an
evaluation of techniques and/or practices that help to
elicit requirements for educational software
applications aimed at children with ASC. The
discussion herein is meant to help guide developers
of specialized educational software applications
(“EduApps”) for ASC users. The results can support
the decision-making process of the selection,
combination or adjustment of EduApps’
requirements in order to better reflect the needs of
users with ASC.
2 RELATED WORK
The literature is rich in articles that seek to guide the
elicitation process of software requirements.
However, consensus exists that one elicitation
technique cannot work for all situations. For this
reason, papers and books on of the requirements of
engineering describe multiple requirements
elicitation techniques relevant to varied situations.
Gobov & Huchenko, (2021) have interviewed
hundreds of IT and business analysts about the
applicability of elicitation techniques used in software
development projects in corporations (companies).
Although their work does not specifically address
educational contexts nor ASC users, it does highlight
recent information on characteristics of elicitation
practices and techniques which the authors of this
paper had gathered and analyzed earlier and deemed
to be suitable for ASC users.
Interest in developing software applications for
users with ASC is on the rise with a good number of
recent papers published (Cabanillas-Tello &
Cabanillas-Carbonell, 2020) – most of which
concentrate on the applications themselves, i.e.,
guidance on “what” or which requirements to develop
(Aguiar et al. 2020; Zubair et al., 2021). They do not
seem to ask the question “how” or whether the
elicitation technique could include ASC users in the
development as it is of interest here.
Francis et al. (2009) discusses the issue of
involving users with autism and Asperger’s in the
design of assistive technologies. The main challenges
they found were concerns around misunderstandings
and difficulties in clarifying misconceptions.
Antona et al. (2009) have evaluated a set of
methods and techniques applying two criteria:
disability and age. In their work cognitive and
communication challenges were included among the
disabilities and a comparison of 12 requirements
elicitation techniques was made based on literature
studies. It can be noted that those comparisons did not
take the opinion of specialists into account.
Some studies propose an inclusive design
approach in order to develop therapeutic games for
children with disabilities – e.g., (Malinverni et al.,
2016). The methods applied present strategies to
integrate the expertise of clinicians, contributions
from children and the experience of designers through
a set of elicitation and merging techniques.
Sabariah et al. (2019) plan a framework for
eliciting requirements of applications for teaching
children. They note that it is important to select an
elicitation method that is aligned with children’s
characteristics, age in particular, but do not consider
the special needs of children with ASC, as done here.
Recent exceptions of attempts to consdier ASC
children’s needs include two reports. One, by
Pinheiro et al. (2020) report on an ad-hoc method they
used for the elicitation of interface requirements.
Another, by Groba et al., (2021), included ASC users
as direct contributors into their work albeit without
discussing characteristics of the specific elicitation
Educational Software Requirements Elicitation Techniques: Including Children with Autistic Spectrum Condition
305

techniques. Reflecting the specialized literature, these
two reports do not explicitly discuss selection of
elicitation techniques for education software
applications (EduApps) aimed at ASC children. They,
however, provide information for validation
experiments of interface requirements for mobile
apps aimed at ASC users.
Melo et al., (2021) advocate the elicitation of
general software requirements for low-functioning
users with ASC. The authors propose two artifacts (a
set of questions to interview users and a canvas model
to synthesize interview results) to be integrated into
the elicitation techniques. The artifacts were designed
with assistance from developers and caregivers, in a
complementary way to our research.
In this research we concentrate on how software
engineers may include a marginalized group of users
through elicitation techniques and other interactions
adapted to the needs of ASC children. Typically,
theonly advice from ASC children’s well-meaning
“proxies” (e.g. parents and carers) have been
considered in the software development
(specification) process. We evaluate the applicability
of techniques and/or practices to elicit requirements
of EduApps for children with ASC. The evaluation is
carried out with the assistance of parents, caregivers
and educators who work with children with ASC and
of software engineers who have had some
professional experience with these children.
3 RESEARCH METHODOLOGY
Results were produced following a 6-step
methodology:
1. A structured, systematic review of the literature,
analyses of some software development
frameworks, and recommendations from
practicing software engineers who were
employed to compile an initial catalog of
elicitation techniques was catalogued.
2. Depending on the means of elicitation used
(conversation, observation, documentation,
analysis, and synthesis), the catalogued
techniques were sorted into four classes:
conversational, observational, analytic, and
synthetic.
3. Once the catalogued techniques were classified,
an initial questionnaire on the applicability of
each technique to elicit requirements of EduApps
for ASC users was prepared for evaluation and
1
https://dl.acm.org/
2
https://ieeexplore.ieee.org/Xplore/home.jsp
possible adjustments by a group of (pretest)
participants who work with children with ASC.
4. Pre-test participants were interviewed to evaluate
the pre-test questionnaire. First, they were
informed by the interviewer on the research and
its objectives; next, they received explanations
on the catalogued techniques; and then, they
were asked to fill out a questionnaire. The
participants could clarify any questions and
doubts they had with the interviewer. The
interviewer took notes of required /
recommended changes that would help to the
enhance the quality of questions.
5. The questionnaire was adjusted as required, an
introductory briefing on the research was
included and a respondent’s (participant’s)
qualification section plus a consent form was
added. The questionnaire was then made
available to a second group of (test) participants
– some of whom answered it independently
online, while others participated in
questionnaire-structured interviews.
6. Test results were collected and analyzed to
provide insights into how to include children
with ASC in educational software requirements
elicitation.
Ethical approval for the research was received from
Paraíba State University’s (UEPB’s) Research Ethics
Committee, Campina Grande, PB, Brazil, under
Number 090469/2019. No participant was
compensated financially or otherwise.
Fortunately, sessions where close human contact
was required were conducted before the Covid-19
pandemic. Later activities of revision, completion,
updates, and validation of results for each step were
carried out in a way (e.g., by recent literature review
and comparison) that safeguarded participants.
Each methodological step is detailed next.
4 CATALOG OF TECHNIQUES
Four digital literature libraries were searched, and
relevant publications collated to produce a catalog of
useful elicitation. The libraries included:
1
ACM
Digital Library,
2
IEEE Xplore Digital Library,
3
Scopus, and
4
Google Scholar. These libraries were
chosen because of their wide coverage of engineering
related topics. Subsequently, conference proceedings,
journals and book chapters were studied and
3
https://www.scopus.com/
4
https://scholar.google.com/
CSEDU 2022 - 14th International Conference on Computer Supported Education
306

analyzed. The review was structured around the
following search string:
(“elicitation” OR “requirements elicitation” OR
“requirements gathering” OR “requirements acquisition”)
AND
(“technique” OR “approach” OR “method” OR “practice”)
The search string was applied in accordance with
the digital libraries search mechanism and may be
adapted to execute properly.
Each technique (article) in the resulting database
was evaluated to decide whether it should be selected
for the research related catalog. Evaluation was
carried out in 5 stages: (Stage 1) Initial Search:
Collection of all the articles returned by the searches
of the databases. A total of 3.856 articles were
returned from searches. (Stage 2) Exclusion by title:
Exclusion of duplicate articles, articles that did not
have a full version available, articles that were not
related to the research, articles that were not published
in English. After this stage, 457 articles remained.
(Stage 3) Exclusion by abstract: Exclusion of articles
that were not within the scope of this research. After
that, 115 articles remained. (Stage 4) Exclusion by
diagonal reading: Reading abstract, introduction,
figures, and conclusions. After that, 67 articles
remained. (Stage 5) Exclusion by complete reading:
Complete reading of selected articles. Finally, 31
articles remained.
For a minimum level of quality, each of the 31
remaining articles underwent an evaluation based on
4 criteria: (C1) Does the work clearly define its
research objective? (C2) Does the work sufficiently
discuss the proposed/cited elicitation techniques or
merely mentions them? (C3) Does the work carefully
consider results of the elicitation technique
discussed? (C4) Does the work address more than one
elicitation technique? After applying C1 to C4 to the
31 publications, only 12 remained left for our study
(Table 1).
4.1 Data Extraction
The requirements elicitation techniques cited in the 12
articles were extracted for analysis and interpretation.
Note that a given selected article may yield one or
more techniques. Techniques that are applicable only
to specific contexts, different from the one of interest
here (inclusion of children with ASC) were excluded.
In addition, we also excluded techniques that derived
from already selected techniques or otherwise would
not produce new insights towards the research,
because they just underwent operational changes –
e.g., automation.
After listing the techniques, the most frequent
ones were identified. The main criterion for
classifying a given technique as “frequent” was the
number of references to it found in the literature and
based on the opinions of two participating software
engineers. As a result, a catalog of 23 potentially
applicable elicitation techniques was produced as
shown in Table 2. Details on each of the 23 techniques
in Table 2 may be found in any of the referenced
studies (E1 to E12) in Table 1.
Newer literature searches (January 2022),
including CSEDU 2021 publications, indicate that the
catalog in Table 2 reflects current practices
comprehensively and its contents correlate with those
of recent articles, and in special, the elicitation
techniques in the survey by Gobov & Huchenko
(2021),. Most recent research and development
(R&D) efforts seem to concentrate on making
existing techniques more efficient through
automation or gamification – e.g., (Kengphanphanit
& Muenchaisri, 2020; Dar, 2020), thus suggesting a
research gap that may be filled by our findings.
Table 1: Selected Articles.
Code Reference Type of work
E1 Al Mrayat et al., 2014 Comparative Study
E2 Zhang, 2007 Comparative Study
E3 Zowghi & Coulin, 2005 Survey
E4 Goguen & Linde, 1993 Survey
E5 Nuseibeh &
Easterbrook, 2000
Overview
E6 Ramingwong, 2012 Review
E7 Saeed et al., 2018 Review
E8 Sharma & Pandey, 2013 Review
E9 Hoffman et al., 1995 Review
E10 Cooke, 1994 Review
E11 Khan et al., 2014 Systematic Review
E12 Pacheco et al., 2018 Systematic Review
5 CLASSIFICATION
The techniques in the catalog are classified (Zhang,
2007) as conversational, observational, analytic, or
synthetic, depending on the specific manner in which
software requirements engineers interact with other
software stakeholders, in particular end-users.
Classifying the techniques helps developers
comprehend various elicitation alternatives and
select a suitable technique for a given requirements
elicitation context – e.g., EduApps. Classification
Educational Software Requirements Elicitation Techniques: Including Children with Autistic Spectrum Condition
307

will support the comparisons of the results of our
study.
5.1 Conversational
The techniques in the conversational (or verbal) class
provide a means of verbal communication between
two or more people. Conversation is a natural way to
express needs and ideas, and to ask and answer
questions. Classification is effective in developing
and understanding problems and help eliciting
generic product requirements (Zhang, 2007).
In general, conversational strategies are often
used in requirements development, however not on
their own: they usually need to be combined with
other techniques (Al Mrayat et al., 2014).
Considering the peculiarities of children with ASC,
conversational techniques seem less likely to be
recommended for the context of interest here.
Table 2: Classes of techniques for eliciting software requirements.
CLASS TECHNIQUE STUDY MODE MEDIAN
IT NON-IT OVRALL IT NON-IT OVRALL
CONVERSATIONAL
Interview
X X X X X X X X X X X X 4 4 4 4 4 4
Questionnaires
X X X X X X X X X X 1 2 1 1.5 2 2
Group work
X X X X X X 4 4 4 4 4 4
Brainstorming
X X X X X X X X 4 4 4 4 4 4
Role-Play
X 5 4 4 4.5 4 4
OBSERVATIONAL
Social Analysis
X X 5 4 5 5 4 5
Protocol Analysis
X X X X X X X X 3 4 3 3.5 4 3
Discourse Analysis
X X X X 4 5 5 4 4 4
Apprenticing
X X 5 4 5 5 4 4
ANALYTIC
Documents analysis
X X X X X X X X X 3 4 3 3.5 3 3
Task analysis
X X X X X X 4 4 4 4 4 4
Requirements reuse
X X X 2 4 4 2.5 3 3
Laddering
X X X X X X X 3 4 3 3 3 3
Card sorting
X X X X X X X X 2 4 4 2 4 4
Repertory Grid
X X X X X X X 3 4 4 3 4 4
Decision analysis
X X 3 4 4 3.5 4 4
Introspection
X X X X - 5 5 2.5 4 4
Soft System Analysis
X 3 4 4 3 4 4
SYNTHETIC
Scenarios
X X X X X X 5 4 4 4 4 4
Prototyping
X X X X X X X X X 5 4 5 5 4 5
Joint Application
Development
X X X X X X X - 4 4 3.5 4 4
Throwaway Paper
Prototype
X 3 4 4 3 4 4
Proximity Scaling
Technique
X X X 3 4 4 3 4 4
CSEDU 2022 - 14th International Conference on Computer Supported Education
308

5.2 Observational
An observational technique provides a means to
develop a rich understanding of the application
domain by observing human activities (Zhang, 2007).
Some requirements may be apparent to
stakeholders, but rather difficult to verbalize. These
are called tacit requirements. Verbal communication
is frequently weak when gathering tacit requirements.
As a consequence, observing how people perform
their regular work can facilitate the collection of
necessary information without the users actually
having to explain their actions in words.
5.3 Analytic
Analytic techniques provide ways to explore existing
documentation or knowledge to acquire requirements
from a series of deductions. The knowledge implied
even if not directly expressed, such as the expert’s
knowledge or the information about regulations or
legacy products, also provides engineers with rich
information about a product. Analytical techniques
are usually time-limited and task-limited and are used
only once to solve a specific issue.
Generally, analytic strategies are not essential to
requirements elicitation, because they could
potentially be obtained from sources other than the
clients (end-users) themselves. Nevertheless, they
form secondary variants that enhance the
performance and applicability of requirements
elicitation. This is particularly relevant when
heritage-based information or other relevant products
are reusable (Al Mrayat et al., 2014). This is
information one receives (“inherits”) from apps that
have been in use and need to be passed on for (co-
)processing by the new app being designed.
5.4 Synthetic
According to Browne and Ramesh (2002), synthetic
techniques incorporate various channels of
communication and offer models to illustrate the
characteristics and relationship of a system. As such
they can indicate requirement recognition, in the form
of abundant semantic models. As the purpose of
synthetic techniques is to enhance the communication
between programmers and users, they are appropriate
for various different phases of the software
development process (Al Mrayat et al., 2014).
6 EVALUATION
The pretest questionnaire was evaluated by a group of
11 interviewees: 8 health professionals, 2 educators
and 1 software engineer.
The adjusted, online (test) questionnaire had 23
closed questions (one for each technique in Table 2).
For each technique, the respondents were asked to
indicate the level of their (dis-)agreement (in a 5-
point Likert scale) with a statement of the suitability
of the technique formulating elicitation requirements
for medium- to high- functioning ASC users. This
way, all interview participants answered the same
questions by choosing from the same answer options
to yield more consistent results (Alencar, 1999). Each
response option was assigned a qualitative and a
quantitative scale: strongly disagree (1), disagree (2),
neutral (3), agree (4) and strongly agree (5). At the
end of the questionnaire, respondents had the option
to offer suggestions or more details (e.g., reason) for
their answers as discussed later in this section.
The 5-point Likert scale allowed for rankings of
the techniques in terms of their perceived adequacy in
regard to elicitation of EduApps requirements. Note
however, that the intervals between consecutive
values cannot be considered equal. Using the mean
(and standard deviation) of the response values is thus
inappropriate for the resulting data. As suggested by
Boone Jr. and Boone (2012), the mode and the
median are used here as evaluation measures.
Additionally, different weights may be attributed
towards the impressions of different respondents in
order to reflect the participants experiences with
ASC. For instance, a parent’s impression may weigh
more, than a software engineers’. In case a respondent
is said to come from class c ∈ C = {Parent, Educator,
Psychologist, Social Worker, Software Engineer},
one could use as evaluation measure, the Weighted
Median (WM) or the 50% weighted percentile -
proposed by Edgeworth (1888). For n distinct,
ordered respondent classes c
1
,c
2
,...,c
n
with respective
positive weights w
1
,w
2
,...,w
n
such that ,
the WM is class c
k
that satisfies inequalities 1.
𝑤




𝑆
2
𝑎𝑛𝑑 𝑤




𝑆
2
1
For simplicity but without loss of generality, we
assume equal weights in this study.
The test questionnaire was answered online by 19
respondents: 6 parents of children with medium- to
high-functioning ASC, 5 health professionals, 4
educators and 4 software engineers. Among the
Educational Software Requirements Elicitation Techniques: Including Children with Autistic Spectrum Condition
309

respondents 94.7% had professional experience with
children facing some cognitive difficulty which
impairs communication and 78.9% had experience
with children with ASC. The professionals who
participated in our research had been practicing their
professions for an average of 9.13 years, with a
minimum of 6 months and a maximum of 20 years.
Table 2 shows the Mode and Median of the
quantitative values of their responses for each of the
23 elicitation techniques. We calculated the
measurements separately for IT professionals
(developers) and non-IT in addition to overall
measures.
Non-IT professionals (in this case, parents, health
professionals and educators) who work with children
with ASC seem to be (naturally) too favorable of
these children’s ability and willingness to play a
software client. Software engineers (synonymously
called developers or IT professionals here) seem to
have a less favorable view as results illustrate. In fact,
in 18 of the 23 techniques, the median for IT
professionals was lower or equal than for non-IT
professionals (see Table 2). An aspect worth noting
was the low evaluation of the Requirements Reuse
and Introspection techniques by IT professionals.
These two techniques give the software engineer a
greater freedom in relation to the requirements
Because the programmer decides on the requirement
by herself, without consulting the end-user. In the
case of Introspection, the analysts work out how a
system design should be put into practice by
themselves without any input from the end-user. This
negative evaluation may be the result of IT
professionals believing that they are not in the
position to define the targeted (children with ASC)
user needs without additional information.
Even when the overall average of each class is
considered, as expected, the techniques classified as
conversational have a lower average than the other
classes (Conversational = 3.6; Analytic = 3.7;
Observational = 4; Synthetic = 4.2;). As discussed
earlier, conversational techniques are characterized
by verbal communication between two or more
people. Therefore, respondents believe that children
with ASC will not find these techniques attractive.
In addition to the 23 closed questions, the test
questionnaire included 2 groupings of open questions:
1. - How would you rank the 23 techniques in
decreasing order of the applicability potential?
- Which characteristics of the techniques (would)
make them more (or less) adequate to elicit
requirements of software for children with ASC?
2. - Do you believe that adjusting or mixing some
of the techniques would make it easier to elicit
requirements of software for children with ASC?
- Which techniques and which adjustments come
to your mind?
Answers to these 2 groupings of open questions are
summarized next.
6.1 Ranking of Techniques
By analyzing the rankings performed by the
respondents answering the first open question, a
series of highly ranked techniques became apparent:
Group Work, Prototyping, Apprenticing, Social and
Discourse Analysis. As expected, the techniques with
high value of mode and median were positioned at the
top.
For the Group Work technique, groups are
brought together to discuss some topics of interest
with their researcher. In market research, this is often
accomplished by using stimulus materials such as
videos, storyboards, or product mock-ups as a focus,
and is commonly applied to receive opinions on new
products from a group of selected potential customers
(Goguen & Linde, 1993). The idea of using visual
materials to stimulate the responses of opinions was
one of the factors that resulted in this particular
technique to show a high level of agreement amongst
participants. Indeed, our newer literature searches
revealed that this idea is already being successfully
explored: the work of Zhu et al., (2022) mentions
experiments that use this technique, making use of
drawings with a group of six ASC adolescents.
Although the Prototyping technique was ranked
positively, it is important to point out that to
build the
prototype to show the end-ser one need to have a set
of requirements – which may have been defined by
the software engineers themselves and not by the end-
user. The end-user would be biased by what is
presented to him. As such, this seems a more
appropriate technique for the validation of a set of
requirements.
Regarding the Social and Discourse Analysis,
many of the participants stressed the need to
understand the social and cultural context
surrounding the child, and the fact that such
techniques do not require a direct response from the
child. On the other hand, it was pointed out that
simple analysis may not often elucidate the reasons
for a child’s behavior and attitudes, given that each
child is unique in the way they address levels of
difficulty?
The respondents took into consideration whether
there was a need for the child to read and interpret
texts to receive a clearer picture of the level of
difficulties. In this context, techniques such as
CSEDU 2022 - 14th International Conference on Computer Supported Education
310

Questionnaire and Repertory Grid ended up being
ranked negatively, especially considering that
children with ASC, in general, do not concentrate on
a particular subject for long. The need to describe
actions while performing an activity in the Protocol
Analysis technique was considered unfeasible, given
the fact that children with ASC sometimes have great
difficulties in expressing themselves clearly.
6.2 Adjusting and Mixing Techniques
After the analysis of the open question answers it
became clear that modifications and adaptations were
required in order to implement modified techniques
and apply them to our target audience. Some
suggestions for adaptations were found to be more
general, i.e., they could be applied to more than one
technique, such as:
(a) Ask the user to point, observe her/his body
language or other type of communication instead of
(or in addition to) speech. In the case of techniques
such as Interviews, Questionnaires and
Brainstorming, the response necessary to extract
information from the child can be given through
expressions or gestures replacing the need for verbal
communication.
(b) The use of images will facilitate a better
understanding of the children. If the technique
requires the child to perform some activity, this
activity should be described and explained through
images, facilitating the child’s ways of understanding.
In addition, when using techniques that present some
information to children through lists or cards, such as
Card Sorting and Repertory Grid, the information
should also be presented via images.
(c) More direct commands. Techniques that involve
analysis such as Social Analysis, Discourse Analysis,
Task Analysis and Decision Analysis, require the
software engineer to provide the child (user) with
more specific and direct commands in order for the
child to understand and perform.
Before initiating an activity such as Group Work,
participants highlighted the need to introduce the
children to the session schedule and planned
activities. This will be particularly important for the
design of interview sessions with the child to prevent
disruptions of their normal daily routines. In these
Group Work activity sessions, techniques, such as
Throw-away Paper Prototype, Task Analysis and
Discourse Analysis can be used as part of the activity
to obtain more information from the children.
An interesting and thought-provoking suggestion
from the respondents was to ask the software
engineers to first experiment themselves with
particular tasks that the user with ASC would have to
perform. This way the software engineer will be given
an opportunity to imagine how it would feel to be a
child with ASC. The experiment should be under the
supervision of a therapist expert on ASC to
determine, guide, comment, adjust tasks the software
engineer is to perform, much the same way ASC kids
are supervised. To understand the excess of sensory
stimuli that the child with ASC routinely experiences,
the software engineer could perform elicitation in a
stressful environment, for example in a room that is
too cold, hot, bright, noisy, full of frequent
interruptions and distractions), or to receive orders
and commands from a therapist so that the
interactions with the therapist are deliberately
confusing, incomplete or plainly meaningless. This
type of experience might enable the engineer to better
develop techniques such as Learning, Reuse of
requirements and Introspection.
7 THREATS TO VALIDITY
One external limitation to the generalization of our
study is the validation sample size. Although we
obtained valuable information and insights from 30
(11+19) participants, they may not be representative
of the larger population. As research efforts about
requirements needed for the software development
aiming at ASC children continues, information and
insights from more experts may be needed. It is worth
noting however, that this threat was somewhat
mitigated by engaging with participants that have an
average of close to 10 years’ experience in working
with ASC children.
Another external limitation to generalization
regards the underlying research methodology. The
methodology may be applicable to requirements of
software in general, but the use of parents who
prioritized educational software (vs. entertainment
software such as games) and validators who
specialize in educating children with ASC implicitly
sets the context of the paper to that of educational
software for children with ASC. On the other hand,
discussions, results, and guidelines for software
development sighted in related work - e.g., (Zhu et al.,
2022; Aguiar et al., 2020; Silva & Teixeira, 2019)
provide evidence that the insights and
recommendations made through this study align well
with those made by other researchers.
Another limitation observed is that some
information in the consent form or provided in
introductory briefings may have given unintended
hints about the research intentions and expectations.
Educational Software Requirements Elicitation Techniques: Including Children with Autistic Spectrum Condition
311

This could have led to what is called hypothesis
guessing where participants respond to questions
based on what they think the researcher wants to hear.
Another threat is that, despite providing explanations
to the participants that some non-IT professionals
amongst the participants may not have been familiar
with terms and definitions of requirements
engineering, thus they might have given some
answers without a very clear understanding of the
topic at hand.
Yet another threat to internal validity is the risk
that our searches of the literature and filtering
procedures may have missed or discarded material
that should have been considered. Backchecking
filtered results, scanning references lists of
considered articles and repeated new searches may
have reduced such risks, but not eliminated it.
8 CONCLUSIONS, NEXT STEPS
This paper collated elicitation techniques from the
specialized literature into a catalog of classes of
common and current techniques and practices. A
team of parents, experts in the care, education, and
software development for children with autistic
spectrum condition (ASC) evaluated and ranked the
catalogued classes of techniques according to their
adequacy for the context of educational software.
Findings indicate that when perceptions of team
members are attributed equal weights the most
adequate techniques were Group Work, Prototyping,
Apprenticing, Social and Discourse Analysis
followed by techniques such as Questionnaires.
Participants also suggested that the use of visual
artifacts such as drawings would help to make the
process of feedback more accessible to children with
ASC. These findings correlate well with recent R&D
efforts to build more attractive (educational)
applications for ASC users. Findings contribute to
requirements engineering since they may guide
developers in selecting the most adequate techniques
for eliciting software requirements from ASC
children. One pragmatic recommendation that comes
out of this study is that software developers should try
out working in simulated stressful working conditions
so that they can empathize better with ASC children.
Findings offer evidence that there are ways to
include children with ASC in the educational
software requirements elicitation process. The
research reported in this paper creates paths for future
research and the practical use of results to manage the
development of educational software tools for
children who are on the ASC spectrum.
Next steps in future work on the paper’s topic
could experiment with hybrid or adjusted elicitation
techniques based on respondents’ suggestions and to
include children on the ASC spectrum, not just their
well-meaning proxies.
ACKNOWLEDGEMENTS
The authors thank the volunteers who answered the
questionnaires. This work was supported by the
Research Council, the Fund for Education
Development, and the Ministry of Health of Brazil.
REFERENCES
Al Mrayat, O. I., Norwawi, N. M. and Basir. N. (2014).
Requirements elicitation techniques: Comparative
study. In International Journal of Recent Development
in Engineering and Technology.
Alencar, E. (1999). Introduction to social research
methodology. (Introdução à Metodologia de Pesquisa
Social. In Portuguese.) Lavras: UFLA/FAEPE, page
125.
Aguiar, Y. P. C., Galy, E., Godde, A., Trémaud, M., Tardif,
C. (2020). AutismGuide: a usability guideline to design
software solutions for users with autism spectrum
disorder. In Behaviour and Information Technology.
Antona, M., Adami I./, Ntoa, S., and Stephanidis, C. (2009).
User requirements elicitation for universal access. In
Stephanidis, C. (ed.) The Universal Access Handbook.
Boone Jr., H. N. & Boone, D.A. (2012). Analyzing Likert
data. In Journal of Extension, 50(2). Article 2TOT2.
Bottema-Beutel, K., Kapp, S., Lester, N., Sasson, N. and
Hand, B. (2021). Avoiding Ableist Language:
Suggestions for Autism Researchers. In Autism in
Adulthood. In Vol3 Issue
1.http://doi.org/10.1089/aut.2020.0014
Cabanillas-Tello, A. & Cabanillas-Carbonell, M. (2020).
Application Software Analysis for Children with
Autism Spectrum Disorder: a Review of the Scientific
Literature from 2005 - 2020, In International
Conference on e-Health and Bioengineering (EHB),
2020, (pp. 1-4).
Cheak-Zamora, N. C., Teti, M. and First, J. (2015).
Transitions are Scary for our Kids, and They're Scary
for us’: Family Member and Youth Perspectives on the
Challenges of Transitioning to Adulthood with Autism.
In JARID) Vol28, Issue6. https://doi.org/10.1111/
jar.12150
Cooke, C. (1994). Varieties of knowledge elicitation
techniques. In Int. J. Hum.-Comput. Stud., 41 (pp. 801–
849).
Dar, H. S. (2020) "Reducing Ambiguity in Requirements
Elicitation via Gamification," In IEEE 28th
CSEDU 2022 - 14th International Conference on Computer Supported Education
312

International Requirements Engineering Conference,
(pp. 440-444).
Edgeworth, F. Y. (1888). XIII. On a new method of
reducing observations relating to several quantities. In
The London, Edinburgh, and Dublin Philosophical
Magazine and Journal of Science, 25(154) (pp. 154-
191). Published online 29 Apr 2009.
Francis, P., Balbo, S., and Firth, L. (2009). Towards co-
design with users who have autism spectrum disorders.
In Information technology for cognitive support, The
Human-Computer Interaction Handbook.
Giullian, N., Ricks, D., Atherton, A., Colton, M., Goodrich,
M., and Brinton, B. (2010). Detailed requirements for
robots in autism therapy. In IEEE International
Conference on Systems, Man and Cybernetics.
Gobov, D. & Huchenko, I. (2021). Software Requirements
Elicitation Techniques Selection Method for the Project
Scope Management. In 2nd International Workshop IT
Project Management (ITPM 2021).
Goguen, J. A. & Linde, C.. (1993). Techniques for
requirements elicitation. In Proceedings, Requirements
Engineering '93, edited by Stephen Fickas and Anthony
Finkelstein, IEEE Computer Society (pp. 152–164).
Groba, B., Nieto-Riveiro, L., Canosa, N., Concheiro-
Moscoso, P., Miranda-Duro, M.d.C., Pereira, J. (2021)
Stakeholder Perspectives to Support Graphical User
Interface Design for Children with Autism Spectrum
Disorder: A Qualitative Study. Int. J. Environ. Res.
Public Health 2021, 18, 4631.
Hoffman, R., Nigel, R. S., and Burton, A. M (1995)
Eliciting knowledge from experts: A methological
analysis. In Organizational behavior and human
decision processes, 62.2 (pp. 129-158).
Kengphanphanit, N. & Muenchaisri, P. (2020). Automatic
Requirements Elicitation from Social media
(ARESM)). In International Conference on Computer
Communication and Information Systems (pp.57-62).
Khan, S., Dulloo, A. B., and Verma, M. (2014). Systematic
review of requirement elicitation techniques. In
International Journal of Information and Computation
Technology, (pp. 133– 138).
Logana, K., Teresa Iaconoa, T. and Trembathb, D. (2022).
A systematic search and appraisal of intervention
characteristics used to develop varied communication
functions in children with autism who use aided AAC.
In Research in Autism Spectrum Disorders. Vol 90.
https://doi.org/10.1016/j.rasd.2021.101896.
Malinverni L., Guiard J., Padillo V., Valero, L. An
inclusive design approach for developing video games
for children with Autism Spectrum Disorder.
Computers in Human Behavior, January 2016.
DOI:10.1016/j.chb.2016.01.018
Melo, A., Oran, A., Santos, J., Rivero, L., Barreto, R.
(2021). Requirements Elicitation in the Context of
Software for Low-Functioning Autistic People: An
Initial Proposal of Specific Supporting Artifacts. In
SBES 21, Brazilian Symposium on Software
Engineering. (pp. 291–296).
Nuseibeh B. & Easterbrook S. (2000). Requirements
engineering: a roadmap. In Proceedings of the
Conference on the Future of Software Engineering (pp.
35–46).
Pacheco, C., Garcia, I. and Reyes, M. (2018). Requirements
elicitation techniques: a systematic literature review
based on the maturity of the techniques. IET Software,
12(4) (p. 365–378).
Pinheiro, V., & Marques, A. (2021). Accessibility-oriented
design with a focus on autism aspects: designing a
mobile application for autistic children's daily routine.
In ACM Proceedings of 19th Brazilian Symposium on
Software Quality, Article 27 (pp. 1-10). Online Mar 6
th
,
2021.
Ramesh, V. & Browne, G. J. (2002). Improving information
requirements determination: a cognitive perspective. In
Information Management. 39(8).
Ramingwong, L. (2012). A review of requirements
engineering processes, problems and models. In
International Journal of EST.
Sabariah, M. K., Santosa, P. I., Ferdiana, R. (2019).
Requirements Elicitation Framework for Child
Learning Application – A research Plan. In ICISM.
2019, 2
nd
International Conference on Software
Engineering and Information Systems. Pages 129-133.
Saeed, S., Fatima, U. and Iqbal, F. (2018) A review of
requirement elicitation techniques in OSSD.
International Journal of Computer Science and
Network Security, 18(3).
Sadiq M. and Jain S.K. (2014). Applying fuzzy preference
relation for requirements prioritization in goal oriented
requirements elicitation process. In International
Journal of System Assurance Engineering and
Management, 5(4) (pp.711–723).
Sharma, S. & Pandey, S. K. (2013). Revisiting requirements
elicitation techniques. In International Journal of
Computer Applications, 75 (pp.35–39).
Silva, S. & Teixeira, A. (2019). Design and Development
for Individuals with ASD: Fostering Multidisciplinary
Approaches Through Personas. In J Autism Dev Disord
49, 2156–2172.
Standish Group International. Chaos summary 2015.
Retrieved from http://www.standishgroup.com/, 2015.
World Health Organization -WHO (2021). World report on
disability. www.who.int. Accessed: January 2021.
Zhang, Z. (2007) Effective requirements development a
comparison of requirements elicitation techniques.
British Computer Society.
Zhu, R., Hardy, D. and Myers, T. (2022). Community Led
Co-Design of a Social Networking Platform with
Adolescents with Autism Spectrum Disorder. In J
Autism Dev Disord 52, (pp.38–51).
Zowghi, D. and Coulin, C. (2005). Requirements
elicitation: A survey of techniques, approaches, and
tools. Aurum A., Wohlin C. (eds) Engineering and
Managing Software Requirements.
Zubair, M.S., Brown, D.J., Hughes-Roberts, T., Bates, M.
(2021). Designing accessible visual programming tools
for children with autism spectrum condition. In
Universal Access in the Information Society.
Educational Software Requirements Elicitation Techniques: Including Children with Autistic Spectrum Condition
313