An Empirical Evaluation of Requirements Elicitation from Business

Models through REMO Technique

Jônatas Medeiros de Mendonça

, Pedro Garcêz de Moura

, Weudes Evangelista

, Hugo Martins

Rafael Reis

, Edna Dias Canedo

, Rodrigo Bonifácio

, Carla Silva

and Fernando Wanderley

University of Brasília (UnB), Brasília, Brazil

Faculty of Gama (FGA), University of Brasília (UnB), Gama, DF, Brazil

Department of Computing, University of Brasília (UnB), Brasília, DF, Brazil

Center of Informatics, Federal University of Pernambuco (UFPE), Recife, PE, Brazil

University New of Lisboa (UNL), Lisboa, Portugal

Keywords:

Business Process Model, Requirement Elicitation, Empirical Evaluation, REMO Technique.

Abstract:

The Requirements Elicitation oriented by business process MOdeling (REMO) technique presents a set of

heuristics to support the elicitation of requirements based on business process models. Although empirically

validated only in controlled environments, the literature does not report evidence regarding the applicability

of the technique in real scenarios. In this context, this paper presents an empirical evaluation applied in an

industrial settings, using a multimethod approach, where a quantitative analysis measured the applicability

of the technique and a qualitative analysis the utility and ease of use according to requirements analysts. As

for the results, the quantitative analysis made it clear that the REMO technique can bring real beneﬁt in the

context of the study, identifying a higher number of funcional requirements than the conventional approach

(without the support of the REMO technique). This beneﬁt is reached without overcomplicating the task of

eliciting requirements.

1 INTRODUCTION

Considering a cycle of software development or mo-

dernization, the requirements elicitation and speci-

ﬁcation activities prove itself essential to fulﬁll the

user’s necessities (Wiegers and Beatty, 2013). For

this reason, different techniques were proposed in the

literature, going from notations representing require-

ments in different levels of abstraction— such as fe-

atures, goals, problem frames, and use cases (Kang

et al., 1990; Van Lamsweerde, 2001; Jackson, 2001;

Yu, 2011; Jacobson, 2004)- to practices that seek

to favor the extraction and understanding of require-

ments (Jackson, 2001; Van Lamsweerde, 2009; Ja-

cobson et al., 1999).

Besides that, for certain application domains,

there is a growing need to align the business pro-

cesses with the enterprise information systems (Re-

gev et al., 2005). As such, it is being recommend to

carry out activities for understanding and improving

business processes before the development of enter-

prise systems (Bleistein et al., 2006; Ramesh et al.,

2005; Dietz and Albani, 2005; Regev et al., 2005).

Some authors argue that software needs arise natu-

rally through the mapping of business processes; me-

anwhile, recent works present techniques to extract

requirements through business processes mapping,

usually described in notations such as BPMN (Busi-

ness Process Modeling Notation) or Petri Nets. This

is one of the objectives of the REMO (Requirements

Elicitation Oriented by Business Process Modeling)

technique, for instance. It presents a set of heuristics

for the elicitation of requirements through business

process models in the BPMN notation (Vieira et al.,

2012b).

Recent empirical studies have been performed to

verify to process of requirements elicitation through

the REMO technique, however not including indus-

trial case studies in their protocol (Vieira et al., 2012b;

Vieira et al., 2012a). The lack of industrial valida-

tion often hinders practitioners from understanding

and generalizing the beneﬁts with the adoption of the

technique in real situations. Considering such gap,

this paper presents an empirical study about the fe-

324

Mendonça, J., Moura, P., Evangelista, W., Martins, H., Reis, R., Canedo, E., Bonifácio, R., Silva, C. and Wanderley, F.

An Empirical Evaluation of Requirements Elicitation from Business Models through REMO Technique.

DOI: 10.5220/0006310803240332

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 324-332

ISBN: 978-989-758-248-6

asibility of adopting the REMO technique in indus-

trial situations. The REMO technique presents a set

of heuristics to identify requirements from processes

models described in BPMN—notation used in our re-

search context (Section 2). Accordingly, we decided

to experiment with this technique in order to reduce

the efforts related to requirements elicitation from bu-

siness processes. With this, the main contributions of

this article are:

• The report of an empirical investigation of the

REMO technique in a industrial and non-trivial

context (Section 3 describes how it was con-

ducted).

• The observation that the REMO technique is ef-

fective to identify around 80% of the requirements

related to business processes and that its heuris-

tics are easily absorbed by requirements analysts

(Section 4).

The previous studies, carried out by a different

group of researchers that design the REMO techni-

que, present some limitations. First, they analyzed

only one process with a well-deﬁned scope and small

complexity. Second, the previous studies were con-

ducted within an academic context, considering only

undergraduate students as participants. Differently,

here a set of software engineering practitioners use

the technique REMO for eliciting requirements from

15 different processes.

These results have a signiﬁcant implication: at le-

ast in the context in which this research was carried

out, using the REMO technique could reduce the costs

of training the requirements analysts for the task of

requirements elicitation through business processes.

We believe such results could be achieved in similar

domains. Besides the sections mentioned above, this

paper also describes the threats to the validity of our

empirical study (Section 5), relates our results to those

of other existing research studies (Section 4), and

presents some ﬁnal considerations and future works

(Section 6).

2 BACKGROUND

This research was conducted in the context of a

technical cooperation project between a university

and a Military Institute, with the objective of mapping

business processes and than extracting requirements

in the domain of material supplying management of

a large Brazilian Government Agency. The results of

the project subsidy the modernization of an enterprise

system for that domain.

2.1 Research Context

In the beginning of the project, and based on informa-

tion gathered from the agency’s own manuals, nine

modules were deﬁned, four of which are of problem

domain character for representing the entire life cy-

cle of the material supplying. These are: Planning,

Acquisition, Controlling, and Discarding. The ot-

her modules act as support to the value chain, such

as Maintenance, Finances, Transportation, Identiﬁca-

tion, and Allocation of material. From this initial gat-

hering, it was realized the need to specify more than

230 related processes, and then identify high level re-

quirements that would be used to guide an effort to

modernize a legacy system.

To reach such objectives, two teams were crea-

ted: one to model the business processes, genera-

ting BPMN diagrams and the descriptive documents

of the processes; and the other to identify functio-

nal requirements detailed as epics, features, and user

stories. That requirements elicitation effort, which

should start during the activities of business process

modelling, formulates a document entitled Require-

ments Document, which speciﬁes the business pro-

blem and the high-level requirements that present sig-

niﬁcant value to the context of the expected solution.

Using this approach, it is possible to identify oppor-

tunities for automating some of the business proces-

ses’ activities in the new version of the software un-

der development. The project has been going on for

18 months, already culminating on the mapping of

192 business processes and requirements documents.

Together, they encompass approximately more than

1000 functional requirements.

The two teams previously mentioned work in

close collaboration. That is, requirements analysts

participate in the business modelling activities effecti-

vely (by showing up in all meetings, for instance).

While the speciﬁcation of a business process is being

consolidated, members of the requirements team ma-

nually derive the functional requirements from the bu-

siness processes diagrams, which later give origin to

the requirements document that is validated by the

stakeholders (including the agency’s IT sector). This

time-consuming manual effort approach of require-

ments identiﬁcation (named hereafter as our conven-

tional approach) motivated us, more recently, to em-

pirically evaluate the efﬁcacy of the REMO technique

in our context.

2.2 The REMO Technique

The REMO technique (Vieira et al., 2012b) is a re-

quirements elicitation technique oriented by business

An Empirical Evaluation of Requirements Elicitation from Business Models through REMO Technique

325

process modelling, which was proposed by a different

team of researchers. It consists on using heuristics ba-

sed on the metamodel elements (activities, gateways,

messages, and artifacts) found in BPMN diagrams, to

help the systems analysts to extract software require-

ments.

As an example of the REMO technique, consider

the BPMN diagram from Figure 1. From the fol-

lowing REMO heuristics, it was possible to identify

three functional requirements (as detailed in Table 1).

(H1) Process Activities shall be supported by the

functional requirements the system will pro-

vide.

(H2) Process Gateways might be related to either

functional requirements or business rules the

system must support.

(H3) Data Objects might also reveal functional requi-

rement, particularly when the related concepts

must be managed by the system.

Five steps were deﬁned for the activity of require-

ments elicitation using the REMO technique (Vieira

et al., 2012b). This way, the analysts should obtain

the requirements according to a sequence of steps that

involve

(1) Comprehend the Business Processes Model nota-

tion.

(2) Identify functional requirements.

(3) Identify non-functional requirements.

(4) Identify the business rules.

(5) Review all identiﬁed requirements.

The original speciﬁcation of the REMO technique

details nine heuristics to support analysts to identify

requirements from business process models. For in-

stance, there is a heuristic that recommends an one-to-

one mapping of a business process activity into either

a functional or a non-functional requirement. Simi-

larly, the authors suggest that a time-event might be

translated into either a business rule or functional re-

quirement.

For our study (detailed in the next section), we ex-

cluded the ﬁrst step, as the team had already recei-

ved a training in Business Processes Modelling using

BPMN, and were already acquainted with the BPMN

elements. The REMO heuristics support the steps 2,

3, and 4 enumerated above.

3 STUDY SETTINGS

This section describes some details regarding how the

case study was conducted, deﬁning the protocol, go-

als, and processes to conduct our empirical evalua-

tion.

3.1 Objectives

The main goal of this study was to verify the efﬁcacy

of the REMO technique in a real context of require-

ments extraction from business processes and, in this

way, ﬁll a gap related to the lack of empirical studies

conducted in the industry and related to this domain.

The term efﬁcacy in this paper refers to the use of

the REMO technique to identify the software require-

ments with a coverage similar to what would be achie-

ved using a more conventional approach, which was

used during the conduction of the cooperation pro-

ject described in Section 2. If the REMO technique

can be applied in real situations, the costs with requi-

rements elicitation could be initially reduced, since

in a more extreme scenario, it would not be neces-

sary to have requirements analysts participating in the

activity of mapping business processes—actually, it

would be enough to apply the heuristics of the REMO

technique to obtain the requirements.

To reach the objective of this study, we established

the measurement objective presented in Table 2, fol-

lowing the principles of the GQM (Goal, Questions,

and Metrics) paradigm proposed in (Basili, 1988).

From the measurement objective established in

Table 2, we deﬁned the following research questions

to help the team to understand if the objective was re-

ached, and then we deﬁned metrics for each question.

(RQ1) How effective is REMO as a requirement eli-

citation technique?

(RQ2) What is the perception of the analysts regar-

ding the usage of the REMO technique?

As presented by (Vieira et al., 2012b), the efﬁ-

cacy of the REMO technique was evaluated in a pre-

vious work by comparing the percentage of require-

ments classiﬁed as correct with a baseline speciﬁca-

tion built by specialists. Differently, here we ana-

lyze our research questions under a different light:

although the REMO technique might ﬁnd additional

requirements (when compared to what would be the

conventional technique’s oracle), this does not neces-

sarily mean a negative aspect of the technique. Rat-

her, this might indicate that some requirements pos-

sibly escaped with the adoption of the conventional

technique.

In addition, a requirement identiﬁed in the con-

ventional technique, but not in the REMO one, is con-

sidered a transparent requirement in the business pro-

cesses model. Escaped requirements suggest a higher

efﬁcacy in the REMO technique, which allowed for

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

326

Figure 1: BPMN Diagram.

Table 1: Requirements of REMO.

Cod Name Description Heuristic

RF01 Request Equipment The system should ensure the De-

partment to Request the Equip-

mentto the Leadership.

H1 - Activits of Process

H3 - Data Object

RF02 Consult of Inventory The system should consult the wa-

rehouse inventory.

H1 - Activits of Process

H3 - Data Object

RF03 Evaluating Equipment Request The system should ensure that the

department requests the equipment

from the Leadership

H1 - Activits of Process

H2 - Gateway

the identiﬁcation of a non-elicited requirement with

the conventional technique. Differently, a transparent

requirement suggests that the adoption of the heuris-

tics of the REMO technique alone is not enough for

the software requirements elicitation through business

processes.

The analysis of escaped and transparent require-

ments provide quantitative indicators regarding the ef-

ﬁcacy of the REMO technique. Additionally, a quali-

tative analysis, supported by a questionnaire that fol-

lows the TAM (Technology Acceptance Model) ap-

proach and similar to the one adopted in (Vieira et al.,

2012b), was conducted with the requirements ana-

lysts. This qualitative analysis seeks to obtain the per-

ception of the analysts in the ﬁeld of requirements re-

garding the usage of the REMO technique, and can

be considered a replica of the previous study about

the REMO technique. The remaining of this section

presents more details about the protocol used during

the execution of the empirical study.

3.2 Participant Characterization

Six requirements analysts were conveniently selected

to participate in the case study, as they were invol-

ved in the cooperation project described in Section 2.

These analysts were reasonably acquainted with the

supplying management ﬁeld, having participated in

processes mapping meetings and requirements ex-

traction activities for at least six months (using the tra-

ditional approach). They were all involved in training

for the procedures used in the task of creating the Re-

quirements Document, which was done through the

business processes mapping activities. The partici-

pants received an initial orientation regarding the case

study to be accomplished, and were instructed to read

the articles and the dissertation that detail the REMO

technique (Vieira et al., 2012b; Vieira et al., 2012a).

An Empirical Evaluation of Requirements Elicitation from Business Models through REMO Technique

327

Table 2: Research Goals.

Analyze: the REMO technique.

With the purpose of: Investigate its effectiveness in a real context.

Regarding: the task of requirements elicitation and easy of use.

Considering the perspective of: Requirements analysts.

In the context of: A real software modernization efforts.

3.3 Protocol Deﬁnition

The case study took into account fourteen business

processes, randomly selected from a pool containing

approximately 190 processes that had been previously

mapped in the cooperation project. These proces-

ses, though pertaining to the ﬁeld of supplying ma-

nagement, describe the workﬂow of areas from diffe-

rent logistics roles (such as Planning, Controlling and

Maintenance).

The requirements documents related to the four-

teen business processes acted as speciﬁcation baseli-

nes (oracles) using the conventional approach for the

extraction of the metrics used to estimate the efﬁcacy

of the REMO technique. The processes were divided

between the participants of the current project team,

where each one executed the REMO technique in the

different selected processes. Each participant also re-

ceived a list with the heuristics deﬁned by the REMO

technique, the description and the diagram of the pro-

cess, as well as a document to register the require-

ments identiﬁed by the technique.

3.4 Data Analyses Method

The data extracted from the questionnaires with the

participants of the study were analyzed using two qua-

litative approaches. Firstly, the TAM model propo-

sed by (Davis, 1989) to instigate the acceptance of

the REMO technique by the requirements analysts.

TAM is an adaptation of a theory originated from psy-

chology, the TRA (Theory of Resonated Action), but

focused on the ﬁeld of information technology (Da-

vis, 1989) and with the intention of explaining what

makes a person accept or reject an information sy-

stem (Surendran, 2012). To achieve the objectives set

by the TAM, we utilize two perspectives: one regar-

ding the utility and another the easiness of use. The

ﬁrst corresponds to the degree to which a person be-

lieves the use of a certain technique can improve their

work performance. As for the second, it corresponds

to the degree to which a person believes that the usage

of a certain technique can be effort-free (Davis, 1989).

4 RESULTS

In this section, we present the results of the quanti-

tative and qualitative analyses of the study, with the

application of the data analyses method described in

Section 3.

4.1 Quantitative Analysis

As mentioned in Section 3, the quantitative analysis

considered the speciﬁcation of randomly selected pro-

cesses, which had been previously validated with re-

spect to criteria such as correctness, content and for-

matting. It is possible to verify the summary of the

quantitative results in Table 3. Besides that, Table ??

presents some descriptive statistics related to the ge-

nerated artifacts. The ﬁrst computed metrics were the

escaped and transparent requirements. The boxplot

in Figure 2 summarizes the results. It is possible to

see that the amount of requirements identiﬁed by the

REMO technique, and not identiﬁed explicitly in the

conventional approach, is more expressive than the

amount of transparent requirements, that is, identiﬁed

in the conventional approach but not in the REMO

technique.

Figure 2: Escaped Requirements x Transparent Require-

ments.

This result can be explained through two different

views. First, the conventional approach does not fol-

low a systematic approach and then team could not

have identiﬁed all the potential requirements related

to a business process. Another possible explanation is

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

328

Table 3: Summary of the Quantitative Results. (Proc) corresponds to the Processes, (RF) corresponds to the amount of functi-

onal requirements identiﬁed by the REMO technique, (RNF) corresponds to the non-functional requirements and business

rules identiﬁed by the REMO technique, (RED) corresponds to the requirements identiﬁed by the traditional approach, (RAd)

corresponds to the transparent requirements, (REsc) corresponds to the escaped requirements, (RFP) corresponds to the false-

positives identiﬁed in the REMO technique and (ISE) corresponds to the survival index of the escaped requirements. The

other columns give a general idea of the complexity of the processes considered in the investigation.

Proc. RF RNF RED Escaped RAd RFP ISE (%) Activ. Gateways Events

P1 8 7 5 3 2 2 33.33 25 7 4

P2 11 2 14 5 3 2 60.00 68 14 25

P3 17 4 21 9 0 6 33.33 87 27 28

P4 18 1 10 4 4 4 0.00 44 14 16

P5 20 1 15 6 2 2 66.67 58 10 6

P6 11 1 14 2 5 1 50.00 59 14 19

P7 5 1 8 0 2 0 - 31 9 17

P8 12 3 9 1 1 0 100.00 27 8 10

P9 8 1 9 0 2 0 - 52 13 16

P10 12 2 7 8 1 3 62.50 67 25 24

P11 27 4 10 8 1 3 62.50 72 17 24

P12 18 4 13 6 4 1 83.33 56 11 21

P13 31 5 11 8 1 4 50.00 76 18 24

P14 21 1 12 3 3 2 33.33 76 17 23

Table 4: Basic statistics regarding the number of require-

ments found in each process.

Identiﬁed requirements

Technique Mean Median SD

Conventional 11.29 10.50 4.0

REMO 18.29 17.00 8.14

that, for the context of the project, it was not ne-

cessary to specify the requirements in too much de-

tails. Considering another perspective (transparent

requirements), there is a central tendency (median

value) of the REMO technique not identifying two

transparent-requirements per business process. Con-

sidering the conventional approach, an average of

11.29 requirements were identiﬁed per process, rein-

forcing the effectiveness of the REMO technique—in

which the analysts were able to identify 82.28% of the

requirements identiﬁed in the conventional approach.

Observe that this result is positive for the REMO

technique, since in the conventional approach the re-

quirements analysts participated in the business pro-

cesses mapping activities, which allowed for a greater

understanding of the needs of the process managers.

Transparent requirements can emerge due to different

reasons. In particular, as the requirements team had

participated in the business processes mapping inte-

ractions, some requirements can be identiﬁed and not

directly related to an element of the business process.

On the other hand, for the selected processes, this

type of situation did not occur often, as the amount

of transparent requirements is rather low.

Unlike the previous works (Vieira et al., 2012b;

Vieira et al., 2012a), in this case study it was possi-

ble to differentiate between the escaped requirements

and false-positive requirements resulting from the ap-

plication of the REMO technique. It is important to

highlight that the escaped requirements, referenced in

Table 3, include the false-positive requirements; there

are requirements identiﬁed exclusively in the REMO

technique and which do not correspond to a require-

ment pertaining to the scope of the project. These

requirements occur because the process models com-

prehend all the activities done by the actors of the

process, even if a software outside the scope of the

materials management process automatizes some of

these activities. Table 3 shows the Survival Rate of

the Escaped Requirements (ISE), that is, the percen-

tage of escaped requirements that do not correspond

to false-positives. Such index is calculated following

Equation (1). On average, 48% of the escaped re-

quirements correspond to false-positives. The ana-

lysis of the quantitative results reinforce the efﬁcacy

of the REMO technique in identifying over 80% of

the requirements identiﬁed by the conventional appro-

ach. On the other hand, almost 50% of the require-

ments identiﬁed exclusively by the REMO technique

are false-positives.

ISE = (1 −

RFP

Escaped

) × 100 (1)

Considering how the results relate themselves

with the complexity of the processes, it was pos-

sible to identify a moderate correlation (0.54) bet-

ween the amount of functional requirements, non-

functional requirements, and business rules identiﬁed

by the REMO technique and the complexity of the bu-

siness processes, computed as the amount of BPMN

elements. That is to say, for the case study explored in

An Empirical Evaluation of Requirements Elicitation from Business Models through REMO Technique

329

this paper, there is no one-for-one mapping between

the activities of the process and the identiﬁed requi-

rements. We also observed a stronger correlation be-

tween the amount of requirements obtained through

the conventional approach and the complexity of the

business processes (0.65), but which does not suggest

one-for-one mappings between requirements and acti-

vities.

Altogether, we found some evidences about the

feasibility of using REMO to obtain relevant re-

quirements from business processes—we were

able to ﬁnd almost 80% of the requirements

found by the conventional approach using the

REMO technique.

This result might suggest that we could reduce the

effort for training the analysts in the process of ﬁnding

requirements from business models. Moreover, this

result also indicates that it is promising to use an auto-

mated approach for ﬁnding requirements from BPMN

models.

4.2 Qualitative Analysis of the Study

Results

The qualitative analysis attempted to investigate the

acceptance of the REMO technique according to the

view of the participants regarding its use. For such, a

strategy similar to the one presented by (Vieira et al.,

2012b) was used. It uses the Technology Acceptance

Model (TAM) to explain the attitude and behaviors of

the participants. The acceptance index was obtained

through an online questionnaire. We elaborated semi-

structured questions directed to the requirements ana-

lysts of the project, who answered the questions by

the end of the case study. The online questionnaire

was composed of 12 closed-ended questions related

to their view of the utility and easiness of use of the

heuristics of the REMO technique. The analyst could

answer these questions after the end of the require-

ments elicitation activity using the processes models.

To obtain a higher level of precision of the collected

answers in relation to the aspects involving the varia-

bles of the TAM, a ﬁve-point LIKERT scale was also

used: Totally Agree, Partially Agree, Neutral, Parti-

ally Disagree, and Totally Disagree. The following

questions sought to identify the view of the analysts

about the utility of the REMO technique.

4.2.1 Questions Regarding the Utility of the

REMO Technique

We deﬁned six questions that the analysts had to ans-

wer to capture their perception regarding the utility of

the REMO technique. Such questions are enumerated

ahead:

(QUT1) Considering the context of the project,

would you identify requirements more

quickly using the heuristics?

(QUT2) Considering the context of the project,

would you have better performance when

executing tasks by using the heuristics?

(QUT3) Would you have better work productivity by

using the heuristics?

(QUT4) Would you have better efﬁcacy in identi-

fying software requirements using the heu-

ristics?

(QUT5) Would it be easier to identify the require-

ments of a software when using the heuris-

tics?

(QUT6) Do you consider the heuristics useful to ap-

ply during the requirements elicitation?

4.2.2 Questions Regarding the Easiness of Use of

the REMO Technique

We deﬁned six questions that the analysts had to ans-

wer to capture their perception regarding the easiness

of use of the REMO technique. Such questions are

enumerated ahead:

(QE11) Do you think it was easy to learn the heuris-

tics of the REMO technique?

(QE22) Do you think your elicitation tasks would be

more easily accomplished using the heuris-

tics?

(QE33) Do you consider the heuristics to be clear and

comprehensible?

(QE44) Do you consider it easy to remember how

to use the heuristics during the requirements

elicitation?

(QE55) Do you consider to have gained new skills

with the usage of the heuristics?

(QE66) Do you consider the heuristics easy to use?

4.3 Analysis of the Answers of the

Qualitative Questions

Table 5 and Table 6 present, respectively, a summary

of the answers about the analysts’ perception regar-

ding the utility and easiness of use of the REMO

technique. The answers related to their perception

regarding the utility of the heuristics of the REMO

technique (Table 5), show, in their majority, a good

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

330

acceptance of the technique. The participants consi-

dered that the heuristics facilitate the identiﬁcation of

the requirements of a software and that they are use-

ful to be applied during the requirements elicitation.

They also claimed that the heuristics would allow fas-

ter identiﬁcation of requirements.

Table 5: Perception regarding the Utility of the REMO

Technique. (TD) means Totally Disagree, (D) means Dis-

agree, (N) means Neutral, (A) means Agree and (TA) means

Totally Agree.

Question TD D N A TA

Q1.1 0 0 0 5 1

Q1.2 0 1 1 2 2

Q1.3 0 0 2 1 3

Q1.4 0 0 1 2 3

Q1.5 0 0 1 5 0

Q1.6 0 0 0 3 3

Regarding the performance in the execution of

tasks, approximately 66% of the analysts claimed

that the REMO technique would improve their per-

formance in requirements elicitation. As for work

productivity, approximately 33% of the participants

were neutral regarding the statement that the usage of

the heuristics would improve their productivity, and

83.3% of the analysts answered that using the heuris-

tics proposed in the REMO technique improves the

efﬁcacy and facilitates the identiﬁcation of software

requirements. Only 16.6% were neutral in this per-

spective. All participants considered the heuristics

useful for requirements elicitation.

As for the perception of the analysts in relation to

the easiness of use of the REMO technique, we could

say that the majority of the participants felt no difﬁ-

culty in using the REMO technique. In all questions

proposed to the team, it can be seen that the result

was in favor of the technique and the application of

its heuristics (see Table 6).

Table 6: Perception regarding the Easiness of Use of the

REMO technique. (TD) means Totally Disagree, (D) means

Disagree, (N) means Neutral, (A) means Agree and (TA)

means Totally Agree.

Question TD D N A TA

Q2.1 0 0 1 3 2

Q2.2 0 0 1 3 2

Q2.3 0 0 1 2 3

Q2.4 0 0 2 1 3

Q2.5 0 1 0 3 2

Q2.6 0 1 0 1 4

The majority (83.3%) of the interviewed analysts

comprehended that the heuristics are easy to learn, fa-

cilitate in requirements elicitation and were described

in a clear and comprehensible manner. As for the ot-

her 16.6%, they neither agreed nor disagreed. Howe-

ver, 33.3% of the interviewees pointed out to a cer-

tain difﬁculty in memorizing the heuristics. As for

skills obtained with the heuristics and their easiness

of use, approximately 83% of the interviewees consi-

der the usage of the REMO technique positive under

this light.

The analysis of the qualitative results reinforce

how easy it is to introduce the REMO technique

in requirements elicitation teams. Besides, we

can see that the technique had good acceptance

and adds value to requirements elicitation.

5 THREATS TO VALIDITY

Some factors can be taken into account in the evalu-

ation of the validity of the study. Firstly, the partici-

pants possessed previous knowledge about the busi-

ness, since the analysts had been in the process map-

ping teams. These meetings always count with the

presence of the requirements analysts, who could di-

rect the mapping so as to facilitate the understanding

of the requirements involved in the creation of the Re-

quirements Document artifact, which could interfere

in the result obtained by the REMO technique.

To lower the bias related to business knowledge,

each participant received processes in which they had

not been involved or had little knowledge of. Besi-

des, during the extraction of requirements using the

REMO technique, the participants had no access to

the Requirements Document that had been elaborated

for that business process. Another possible threat is

related to the lack of training for the application of

the heuristics proposed in the REMO technique since

the analysts simply read the main reference about the

REMO technique (Vieira et al., 2012b). On the other

hand, a higher degree of understanding of the techni-

que would possibly reinforce the results found in this

study. The maturity of the participants involved in the

study varies according to their experience in require-

ments elicitation, which interferes in the level of ab-

straction of the requirements during the elaboration of

the Requirements Document and the gathering of re-

quirements using the REMO technique. To lower this

variance, the participants interacted between themsel-

ves, making it so the work experience of an analyst

could affect the work of others. This leads to results

more-or-less aligned.

Some processes contemplate information that was

not within the scope of the system under develop-

ment. In that situation, the REMO technique was li-

kely to identify a large quantity of requirements that

would not be useful to the scope of the project (lea-

An Empirical Evaluation of Requirements Elicitation from Business Models through REMO Technique

331

ding to false-positive requirements). To mitigate such

a threat, we did not considered processes detailing

elements outside the scope of the system. The dif-

ferent levels of details present in the Requirements

Document and covered by the REMO technique can

also threat the validity of the study. This mainly

occurs because the Requirements Document descri-

bes only high level requirements and business neces-

sities, while the REMO technique often leads to more

detailed requirements. To solve this divergence, two

participants documented a comparative analysis bet-

ween the requirements identiﬁed in the Requirements

Document and the ones used in the REMO technique.

We could have investigated other relevant factors

about the use of the REMO technique, such as the

time required to obtain the requirements (effort) and

the possible degree of REMO automation. We pos-

tpone this kind of research to a future work. Par-

ticularly because an effort analysis in this context

will probably require a higher degree of control—

typically supported by a controlled experiment, which

will increase the threats related to external validity. In

addition, as far as we know, there is only an incipient

tool support for the REMO technique.

6 FINAL REMARKS

This article presented the conduction of an empirical

study of the REMO technique, carried out in a context

of cooperation between an university and a military

agency.

Such empirical study involved the elicitation of

requirements from 14 business processes, randomly

selected from a pool of 190 processes whose soft-

ware requirements had already been elicited and ap-

proved by a board of domain specialists and stakehol-

ders interested in the system. The main objective of

the study was to answer to research questions: (RQ1)

How effective is REMO as a requirement elicitation

technique? and (RQ2) What is the perception of the

analysts regarding the usage of the REMO technique?

In regard to the ﬁrst research question, a quan-

titative analysis indicates that the REMO technique

was effective in requirements elicitation, compared to

the conventional technique (without using heuristics).

In relation to the second research question, we ob-

served that the usage of business processes diagrams,

coupled with the heuristics proposed by the REMO

technique, facilitates the identiﬁcation of the functio-

nal requirements.

REFERENCES

Basili, V. Rombach, H. (1988). The tame project: Towards

improvement-oriented software environments. IEEE

Transactions on Software Engineering, pages 758–

773.

Bleistein, S. J., Cox, K., Verner, J., and Phalp, K. T. (2006).

Requirements engineering for e-business advantage.

Requirements Engineering, 11(1):4–16.

Davis, F. D. (1989). Perceived usefulness, perceived ease of

use, and user acceptance of information technology.

MIS Quarterly, 13(3):319–340.

Dietz, J. L. and Albani, A. (2005). Basic notions regar-

ding business processes and supporting information

systems. Requirements Engineering, 10(3):175–183.

Jackson, M. (2001). Problem frames: analysing and

structuring software development problems. Addison-

Wesley.

Jacobson, I. (2004). Use cases–yesterday, today, and tomor-

row. Software and Systems Modeling, 3(3):210–220.

Jacobson, I., Booch, G., Rumbaugh, J., Rumbaugh, J., and

Booch, G. (1999). The uniﬁed software development

process, volume 1. Addison-wesley Reading.

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., and

Peterson, A. S. (1990). Feature-oriented domain ana-

lysis (foda) feasibility study. Technical report, DTIC

Document.

Ramesh, B., Jain, R., Nissen, M., and Xu, P. (2005). Ma-

naging context in business process management sys-

tems. Requirements Engineering, 10(3):223–237.

Regev, G., Soffer, P., and Bider, I. (2005). Coordinated de-

velopment of business processes and their support sy-

stems. Requirements Engineering, 10(3):173–174.

Surendran, P. (2012). Technology acceptance model: A sur-

vey of literature. International Journal of Business

and Social Research, 2(4):175–178.

Van Lamsweerde, A. (2001). Goal-oriented requirements

engineering: A guided tour. In Requirements Engi-

neering, 2001. Proceedings. Fifth IEEE International

Symposium on, pages 249–262. IEEE.

Van Lamsweerde, A. (2009). Requirements engineering:

from system goals to UML models to software speciﬁ-

cations. Wiley Publishing.

Vieira, S. R. C., Viana, D., do Nascimento, R., and Conte, T.

(2012a). Evaluating a technique for requirements ex-

traction from business process diagrams through em-

pirical studies. In Informatica (CLEI), 2012 XXXVIII

Conferencia Latinoamericana En, pages 1–10.

Vieira, S. R. C., Viana, D., do Nascimento, R., and

Conte, T. (2012b). Using empirical studies to eva-

luate the REMO requirement elicitation technique.

In Proceedings of the 24th International Conference

on Software Engineering & Knowledge Engineering

(SEKE’2012), pages 33–38.

Wiegers, K. and Beatty, J. (2013). Software requirements.

Pearson Education.

Yu, E. (2011). Modelling strategic relationships for process

reengineering. Social Modeling for Requirements En-

gineering, 11:2011.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

332