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

[ 35] . Maybe, because of the prevailing culture to encourage researchers to publish
more about the lessons they learn from success than about their learning from fail-
ures, in the RE literature we found no study that gives failed examples of using
RE techniques in real projects. We must remind that in other disciplines, learn-
ing from failures has motivated innovation and we see no particular reason of why
learning-from-failed-projects can not be useful for the RE community as well. In the
experience of the first author, RE professionals do experience failure but the field
does not profit from these failure experiences. The prevailing “we-can-fix-it-later-
on” attitude, which is also compatible with the project management practice of com-
pressing deadlines, brings many ES projects teams in a working mode that under-
mines the role of requirements. If a system fails at the go-life stage, then teams rarely
get back to the RE process and look into RE malpractices, discern patterns of fail-
ure, and think of what they could do differently the next time. This situation is partly
attributable to the prevailing business practice that consultants are contracted for six-
month cycles and that, by the time RE mistakes are revealed in a project, they rush to
their next project, which may be in another business sector and they may not see an
immediate value of the reflection on what they could have done differently should
they go through the same project again. Moreover, most of the consulting companies
who employ the consultants are focused on securing their next contract engagement
in another organization and, therefore, may have little time to spend on accumulat-
ing RE knowledge through systematic post-mortems of past projects. We support the
position that to start learning from failures, we first need a few published examples
of RE malpractice in ES projects. However, these examples are not readily available
at the present time and it is a challenge to build up archives of bad examples and
failures. By this, we do not just mean a set of poorly specified requirements, e.g. dia-
grams, or suboptimal gap analyses, but sufficiently documented explanations of why
a RE method did not work as originally thought. We think that learning about the
mechanisms that are at place and that possibly condition the success and failure of
a RE practice will extend our repertoire of knowledge that can assist us in deciding
which practice to use in which context. For example, it is well known that business
owners in ES projects do not like reading technical descriptions (e.g. data mod-
els). However, there are RE teams in (assumingly) mature organizations who apply
alternative (more creative) techniques for getting the business data (and conversion)
requirements in a way that minimizes that chance of RE failure or even a project fail-
ure. What approaches do consultants deploy in getting the data requirements right?
We think, these skills could and should be explicated and shared with others.
4.3 Directions from Existing Market Trends
In the last decade, there are a number of changes in the market demands that have
implications for RE research for ES. For RE-for-ES to remain an industry-relevant
research field, it must be able to keep up with these changes. This section lists some
trends, which in our view restate and redefine the known RE-for-ES challenges, or