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

4. The projects deliver a system which is far from complete once the ES project is
over, because a cross-organizational ES solution must mirror rapidly-changing
business requirements, and so be adjusted regularly to accommodate current
business needs.
5. The resulting solution does not have an identified owner at cross-organizational
system level, as the system is shared.
6. These projects may well have a low level of organizational awareness of what
RE activities (e.g. eliciting coordination requirements, identifying and analyzing
coordination capability gaps, investigation and mapping of coordination mecha-
nisms [ 14] ) are to be used to elicit and model the requirements as completely as
possible.
7. The solutions are not “built” in the sense that a master architect envisions
the parts and their relationships; rather they evolve into existence and change
through their life cycles as new shared pieces of functionality are built, existing
intra-organizational systems connect to become shared, and shared parts of
the system are disintegrated as soon as needs of sharing processes and data
disappear.
We think that these characteristics pose elicitation and modeling challenges
which are well beyond those presently addressed in the RE-for-ES literature. For
example, these characteristics might make it overall difficult to use predefined
business-sector-specific solution-independent reference models, as such models
merely can not exist for all various collaborative arrangements that business part-
ners may creatively come up with. In contrast, these characteristics may rather
favor the use of constructionist elicitation methods in an extended enterprise set-
tings as they explicitly account for the organizational transformation inherent to
cross-organizational ES projects. The point we would like to make here is not that
cross-organizational ES are different; it is that the assumptions which we usually
make when we elicit and model the requirements in ES projects do not apply. We
think that a RE analyst needs to know both (i) the elicitation and modeling vehicles
at his disposal and (ii) whether or not the implicit and explicit assumptions about
the use of these vehicles match the project settings. We saw in Sects. 3.1 and 3.2
that most of the assumptions we typically make in elicitation and modeling do not
apply to a shared ES solution. Therefore, more research effort needs to be put into
evaluating our existing techniques and understanding their strengths and possible
weaknesses when deployed in a cross-organizational project context.
4.2 Directions from Examining Failures
One observation which we made consistently across the papers in our review is
that almost all projects that the papers' authors described were reportedly kinds of
successes. This clearly indicates the researchers' practice to learn from success; nev-
ertheless we should not underestimate the benefits of learning from failed projects