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

cross-organizational poses new challenges, for example, how to elicit the require-
ments in the face of different partner companies using different ways to organize
domain knowledge and to create their domain dictionary. Would it be possible at
all for the partners in an extended enterprise to come up with one common way
of approaching the requirements elicitation tasks? What kind of coordination mod-
els make sense to use so that partner companies coordinate their elicitation efforts?
Future research in these areas is needed.
3.2 Modelling Techniques
In our literature review, we made a number of common observations referring to
all the surveyed approaches to requirements modeling and documentation in ES
projects. First, we found that all approaches are multi-perspective in nature (that is,
they use multiple viewpoints to document the ES requirements). This is unsurpris-
ing, given the highly complex context where requirements are to be documented,
which calls for using viewpoints as a tactics to cope with complexity.
Second, the RE publications agree on that in ES projects, requirements model-
ing addresses: (i) the selection of a package (and hence, the need to document the
domain), and (ii) the alignment of a selected package to the ERP adopter's business
(and hence, the need to model the functionality embedded in the package).
Third, the RE researchers give evidence confirming the viability of both top-
down and bottom-up approaches to analyzing the gap between enterprise require-
ments models and system models. These two types of approaches differ regarding
the starting point of the requirements documentation process. While bottom-up
approaches imply to start from the review of the package specification and pro-
ceed with documentation of the domain requirements, the top-down approaches
mean to starts from the (solution-independent) domain requirements that are to
be further refined by using information about the concrete package functional-
ity. The top-down approaches are preferred in contexts in which (i) modeling
is a prerequisite for a package selection exercise, or (ii) it supports a business
reengineering effort in an organization. In both cases, the outcomes of the mod-
eling process are solution-independent requirements. The bottom-up approaches
suit best those contexts, when the decision on a package has been made and
modeling is a part of a business process/ES alignment effort. RE researchers
[ 53] argue that unlike the bottom-up approaches, which target the alignment of
a package, the top-down modeling approaches are capable of addressing both the
selection of a package and the alignment of a selected package. In our view, regard-
less the focus of the modeling approaches, they both aid in jointly carrying out
problem analysis and solution design activity (that is, joint RE and architecture
design).
Fourth, our review indicates one common theme which is inherent to the
research on requirements modeling, namely the exploration of the fitness relation-
ship between domain models and system functionality. It is worth noting that those