Requirements Engineering for Enterprise Systems: What We Know and What We Don’t Know? - Intentional Perspectives on Information Systems Engineering - page 119

users. As Ramos and Berry explain, the transformation redefines the job of
the elicitation analysts in that he/she must be aware of how and when par-
ticular pieces of knowledge are created in the RE process in order “to know
when to be observing and what to be looking during the observation” [39] . The
constructionist approaches generally propose to complement the elicitation tech-
niques that focus on enterprise and system requirements with observation-based
techniques (e.g. ethnographic methods) to elicit stakeholders' tacit knowledge
and emotional requirements (e.g. values, beliefs). Emotional requirements are
deemed [ 39] as important for the project as enterprise, functional and non-
functional requirements are. Based on extensive case study research [ 39] , Ramos
and Berry convincingly justify why projects that include emotional requirements
are more effective than projects that merely use the elicitation techniques men-
tioned earlier in the other four classes in this section. Examples of constructionist
approaches are proposed in [ 2, 39] . In [ 39] , the approach provides a list of symp-
toms and emotional responses which the elicitation analyst should watch for.
In [2] , the authors provide characterizations of five “roles that an ES can play”
for its users. The job of the elicitation analyst is to first map the ES system in
the concrete ERP-adopting organization against these roles, and then to structure
his/her elicitation efforts based on the characteristics related to the particular role
at hand.
It is important to note that most of the authors of the surveyed papers on
elicitation techniques (discussed earlier in this section) carried out empirical eval-
uation research to demonstrate that their proposed techniques meet the goals that
have been set for them in the first place. This commitment of RE researchers
to the use of empirical research methods as well as the remarkable variety of
elicitation techniques motivated us to search for publications that compare the
techniques regarding, e.g. their effectiveness, the assumptions about the context
that the techniques need to satisfy so that they are useful, or the business goals
that can be best achieved by using these techniques. Our search yielded no pub-
lication that dealt explicitly with these questions. Instead, we found fragmentary
evaluative information in those papers only, which discussed how vendor-provided
ES-reference-model-based elicitation compares to process-mining-based elicitation.
In all these cases, researchers used the comparison to stress the key limitation
of vendor-provided approaches, namely that they are package-specific (and there-
fore they rarely could be used in projects that implement other packages). We
think, therefore, that the search for insights on and improved understanding of
when to use which technique, is the next big step in ES requirements elicitation
research.
The elicitation techniques also seem to assume that the ES-based solution
includes one vendor's product and is implemented in one company. No technique
explicitly addresses today's case of cross-organizational ES implementations, in
which the solution to be implemented includes more than one package, which
may not all be provided by the same vendor and which may not all be used by
all partner companies in an extended enterprise. The matter that the setting is