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

authors, who proposed requirements representation techniques, also investigated the
fitness relationship. Their research efforts yielded quantitative models [ 16, 25, 46,
54] that help understand the fitness relationship and plan actions to preserve it when
requirements change. The RE community is especially indebted to Colette Rolland
and her team for the number of fitness analysis studies (e.g. [ 16, 25, 46] ) which they
carried out in this area.
Fifth, the RE community is united on that it is a good practice to represent both
the domain models and the system models by using the same modeling language,
because both types of models relate to business issues and in ES projects it is unnat-
ural to segregate them. This position is shared by both researchers [ 42, 44, 53, 54]
and practitioners [ 5, 12, 13, 36, 48] . Indeed, two of the market-leading packages,
SAP and BAAN, provide modeling processes, tools and repositories of (solution-
specific) models which describe the package functionality in business terms [ 12,
36] . SAP-adopting organizations may use the ARIS modeling languages [48] , which
were used to document the SAP application suite, while BAAN-adopters may use
the Dynamic Enterprise Modelling approach [ 36] which is implied in the BAAN
package. Presently, new variants of these modeling techniques have been proposed,
e.g. the configurable reference-model approach [ 38, 44] to smooth even more the
gap analysis process and the identification of the best possible configuration options
within stated enterprise requirements.
However, the RE community also recognized that not all ERP packages have
ready-to-use solution models and, in turn, spent significant efforts to solve the
challenges related to this case. In the last decade, Colette Rolland [ 40] was the
first (1999) to develop and evaluate a map representation that is to be applied in
both domain requirements modeling and COTS systems modeling. Drawing on
her experience, Rolland and Prakash [ 41, 42] redefined the map representation to
cover the special case of ES as a major class of COTS-based projects. In 2000,
Illa et al. [ 19] built the SHERPA method for documenting ES requirements and
propose a formal language for modeling the application domain, translating user
needs into requirements over the ES products, and for reflecting how concrete ES
products adjust to these requirements. In 2002, the UML was customized to the
ES project context [26] . In 2003, Arinze et al. [ 1] proposed an object-oriented
framework to ease the gap analysis of enterprise and ES models, and Soffer et al.
[ 53] developed and empirically evaluated the Object Process ERP representation
that also is able to capture the so-called “ERP optionality” levels, that is, both the
full scope of ES-embedded process and data control options, and the interdepen-
dencies among them. Building on it, Soffer et al. developed in 2005 a bottom-up
reverse-engineering based modeling approach [54] to solve the problem of aligning
a selected package to enterprise requirements. In 2004-2007, Carvallo et al. [ 8, 17]
gave a new dimension to the discussion of requirements modeling approaches in
ES by contributing to engineering the COTS (or ES) non-functional requirements.
Based on case study research, these authors propose the RECSS method [ 8] , a
goal-oriented approach which helps describing enterprise requirements as well as
functional and non-functional requirements of the system. By applying this method,