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

While analyzing the existing modeling techniques, we also found that all model-
ing methods make tacit assumptions that might not be realistic in all situations. For
example, RE authors seem to still assume that modeling is manifestly more useful
than well written textual requirement documents. In our view, reality may question
the extent to which this assumption is realistic. RE publications say very little about
those contexts in which modeling would yield marginal benefits or be a financial
burden and a project “over-kill”.
Furthermore, ES requirements modeling approaches have the tacit expectation
that the resulting models are sufficiently understandable for those who are to review
them and make decisions based on them. Our survey found that understandabil-
ity of both enterprise and systems requirements models was addressed in very few
papers and whenever it was addressed, it was from the perspective of the require-
ments engineer (also called requirements analyst). This finding agrees with a finding
from a recent mapping study [ 10] that we did on empirical evaluation of the quality
attributes of requirement specifications. Therein, we found that understandability
was the most frequently researched quality aspect of requirements specifications,
yet we found no paper that evaluated understandability of ES specifications. This
finding is a surprise as it indicates a paradox: on one side, the authors of model-
ing techniques do acknowledge the importance of the social aspects in ES projects
and the purpose of the models as communication vehicles to help establish a
common understanding among stakeholders; on the other side, the RE research
community published very little on the extent to which the models, produced by
using the proposed modeling techniques, are understandable for the relevant project
stakeholders.
Next, the papers which are focused on modeling for the purpose of gap anal-
ysis rest on the tacit assumption that the better the fit (that is, the closer the
match achieved between business processes and ES solution), the more the value
achieved. In reality however, the “aligned” ES solution becomes available for clients
at earliest six months after the gap analysis took place and the value that clients
receive at that time is far below the expectations. Indeed, the practice shows that
only one out of five companies achieves more than half of anticipated benefits
[ 59] . This alone questions the fundamental assumptions behind most gap analy-
sis techniques and makes us think that we should re-evaluate our understanding
of “business/ES fit” from the perspective of ES project goals and business value.
Most of the ES projects have measurable goals and a gap analysis is rarely per-
formed without considering the business case for the ES project. Therefore, it
is worthwhile uncovering the relationship among the concepts of business/ES fit,
project goals, and business case. This forms a direction for future research. We
think that only when we understand sufficiently well this relationship, could we
better leverage the RE community's collective knowledge of business/ES fit and
of gap analysis techniques so that it adds more value to RE practitioners and
ES-adopters.
Next, most of the papers on modeling techniques do not address the costs
involved in using these techniques. Those paper which do so, implicitly assume that