Proceedings,
International Workshop on Time-Constrained Requirements Engineering
Essen, Germany, (September 2002)
Abstract
Getting development done rapidly usually means doing little or no
requirements engineering (RE). This workshop intends to provide a forum
for researchers and practitioners to discuss in depth possible answers
to the question on how RE can be seen as a boon rather than as an
obstacle to getting development done on time.
In general, requirements engineering literature has been working with
the assumption that a system should be clearly specified before its
design and implementation can start. Failing to follow a well-defined
requirements process has in the past caused tremendous cost overruns,
delays and many project failures. One of the reasons often cited is that
the cost and time required for fixing an error increases as development
goes on. These experiences combined with the fact that the most critical
decisions are usually made during the early development phases support
the assumption that the investment of upfront effort will pay off during
the later phases of development. This is also the conclusion of the
comprehensive CHAOS report of the Standish Group, first published in
1995. A survey described in this report shows that almost half of
cancelled projects failed due to a lack of requirements engineering
effort and that a similar percentage ascribes good requirements
engineering as the main reason for project success.
Nevertheless, there are many companies that still do not practice good
requirements engineering. One of the main reasons given for skipping the
requirements engineering phase is lack of time. Too often, there is high
pressure to deliver something to the customer as soon as possible to
keep him/her happy. For this reason, a lot of companies have recently
shown great interest in the newly emerged agile methods, such as Extreme
Programming. However, it appears that agile approaches overlook
requirements engineering as a development phase and solve any problems
caused by this lack of upfront effort in the next increment or
iteration.
So far, these two camps do not seem to be connected nor do their
proponents collaborate closely. For this reason, this workshop wants to
be a forum to bring these two groups together. Some of the questions
that still remain unanswered include: When should which approach be
used? How can both approaches be combined? Although good answers to
these questions are likely to be several years away, this forum is
intended to get a step closer to an answer.
Topics of interest include, but are not limited to:
. RE for large-scale projects
. RE for small-scale projects
. Iterative and incremental RE
. RE for projects in which time-to-market has priority over cost and
number of features
. RE in rapid application development
. Use of agile methods for requirements engineering
. Combining traditional RE with agile methods
. Agile/flexible requirements management throughout the software
lifecycle
. Case studies, experience reports, lessons learned
. Suitability assessment of RE methods for various projects
