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

requirements analysts can create a goal model of the system environment and also
include those external elements that interact with the system. Complementarily to
this, the RECSS method also uses a decomposition process through which one can
build quality models for the system modules based on the ISO/IEC software quality
standard.
Other RE researchers suggested the use of process modelling tiers to manage
the complexity of enterprise and ES process modeling [ 18] , the technique of the
Requirement Integration Model [ 32] to account for interdependencies in business
workflows, and the Data Activity Model for Configuration approach [ 34] meant to
help align a package to the organization by the joint engineering of data and pro-
cess requirements. The authors of [3, 52] , also proposed ontology-based approaches
to the representation and gap analysis of enterprise requirements and package-
embedded functionality. For example, Babkin et al. [ 3] developed a requirements
modeling approach that defines four sub-ontologies: ontology of requirements, of
main data objects, of business processes and of configuration objects. The first ontol-
ogy helps the elicitation process, while the other three ontologies are to support
business process modeling activities and the activities of data requirements configu-
ration requirements documentation, respectively. It is worth noting that the authors
of these approaches [54] posed the question of how their proposals compare with
the vendor-imposed modeling approaches (e.g. ARIS [12] and DEM [36] ). They
found that when using a modeling technique that is not part of the package, there
are some extra costs involved in creating the models of the system functionality.
Because the modeling approaches are not common standards in the ES field, for RE
professionals to use them in a broader practical context, they first have to create a
system model of their selected package.
We also make the note that all the proposed modeling techniques have been eval-
uated as a minimum by their authors by means of empirical research methods. Some
techniques, e.g. the event-driven-process chain modeling method of ARIS [ 56, 58]
have been validated by researchers that worked independently from the authors who
originally proposed the technique.
Similarly to our survey in the sub-area of requirements elicitation, we also
checked whether there are publications that compare the surveyed modeling tech-
niques for their effectiveness. We found three studies [ 27, 37, 55] that compared
business process modeling approaches. In [ 55] the authors compared them against a
set of criteria which are reportedly critical to ES adopters. In [37] , the authors com-
pared two variants of the event-driven-process chain modeling technique (which is
part of ARIS [ 12] ) regarding perceived usefulness and easy of use from the per-
spective of modelers, by carrying out an experiment with postgraduate students.
In [ 27] , the authors compared business process modeling languages against a five-
perspective-meta-model that helps judge the ability of a modeling language to
capture the essential elements of the business context and the subject domain. While
the authors in [ 55] indicate when to use which technique, the authors of the other two
studies [ 27, 37] attempted to answer the question which of the compared techniques
is better for a specific purpose/RE task.