ORIGINAL ARTICLE
Eliciting gaps in requirements change
Published online: 18 June 2003

Springer-Verlag London Limited 2003
Abstract We consider requirements change due to sys-
tem evolution which results from contextual forces such
as the decision to standardise practices across subsidi-
aries of a company. Our experience with the financial
branch of the French Renault group is that eliciting
change requirements poses its own specific problems. We
propose to model change as a set of gaps between the
requirements specification of the current and the future
system. Our approach is to define a generic typology of
gaps to facilitate a precise definition of change require-
ments. It adopts a goal oriented requirements specifi-
cation and shows how to customise the generic gap
typology to this specific requirements representation
formalism. The paper presents the approach to elicit
gaps and illustrates it with the Renault case study.
Keywords System evolution Æ System change Æ Change
gap Æ Change primitive Æ Gap meta-model
1 Introduction
System evolution is a fact of industrial life. In order to
survive in a more and more competitive environment,
organisations undergo frequent changes that imply
changes of their software-based systems. As a conse-
quence of the fast speed of organisational change, sys-
tem evolution costs are far higher than initial
development costs. Lientz and Swanson [1] and Nosek
and Palvia [2] show for example that more than 50% of
total life cycle cost is incurred after initial development
has been done. Handling system evolution has therefore
been an important issue, sufficiently recognised world-
wide to be the subject of the series of IPSE international
workshops [3]. Whereas a large number of approaches
deal with the evolution of the software model and its
impact on running instances, we are concentrating in
this paper on the system requirements level. The former
focus on the identification of primitive modifications,
evolution patterns and change propagation for different
types of software models such as (a) database schemas
[4, 5, 6], (b) workflow models [7, 8, 9] and (c) software
process models [10, 11, 12]. Instead, in the latter, fol-
lowing Lehman’s view that ’software evolution is driven
by the need to maintain user satisfaction’ [13], we con-
centrate on requirements change.
Our position is that a prerequisite to performing
software change is to understand the way organisational
changes impact system requirements. Just as for systems
developed from scratch where requirements elicitation
provides a basis for subsequent software design and
implementation, changes in design and implementation
are rooted in changed requirements. Eliciting these
change requirements is the concern of this paper.
Requirements engineering is intrinsically concerned
with change to such an extent that it has been defined in
[14] as the process of establishing the vision for change
in the organisational context. The focus has been natu-
rally placed on modelling the vision and the constraints
imposed by the context, on what Jackson calls the
optative properties [15]. In his survey of researches
conducted in the field of requirements engineering,
Lamsweerde [16] demonstrates the key role played by
goals to concretise the vision [14] and to refine high-level
strategic vision into low-level system constraints [17].
Despite our conformity with the goal-oriented view of
requirements modelling, our concern is on change
requirements for a specific type of evolution that we refer
to as system adaptation.
The nature of change requirements varies with the
nature of system evolution. There are many kinds of
system evolution and we focus on those that are caused
by changes in the organisational context in which a leg-
acy software system is now to operate. We will refer to
this type of system evolution as system adaptation. Our
experience with European companies shows that such
Requirements Eng (2004) 9: 1–15
DOI 10.1007/s00766-003-0168-y
Colette Rolland Æ Camille Salinesi Æ Anne Etien
C. Rolland (&) Æ C. Salinesi Æ A. Etien
CRI, Universite´ Paris 1, Sorbonne,
90 rue de Tolbiac, 75013 Paris, France
E-mail: rolland@univ-paris1.fr

changes of organisational context are currently frequent.
They typically occur when mergers/take-overs, globali-
sation, standardisation of practices across branches of a
company etc. occur. Several legacy software systems are
already running when such events take place. In such a
context, it is out of the question to develop a new system
from scratch but it is possible to integrate these legacy
systems or to select one of these for adaptation and
uniform deployment across the organisation.
Typically, system adaptation is bounded by the fol-
lowing constraints:
– No large-scale deviations in the selected software
system.
– Compliance with some of the functionality not found
in the selected system but provided by others.
– Provision of functionality for handling new business
opportunities that are now recognised to be impor-
tant.
From the foregoing it seems to us that the adaptation
process should have two characteristics:
1. It has to be put into the larger context of organisa-
tional change and, therefore, must concentrate first
on the requirements for system change. Thereafter,
traceability links can be used to propagate the change
requirements into actual software changes.
2. It should be driven by gaps which identify what has to
be changed/adapted to the new situation. In this
change context, it is not so much the representation
of the future situation that is important (as it is fixed
to a large extent) as the difference from the current
situation. If gaps remain implicit, it is difficult to
identify what has to be changed. Explicit gap repre-
sentation seems to us, therefore, crucial to expressing
change requirements.
We adopt the change-handling view in which change
creates a movement from an existing situation captured
in the As-Is model to a new one captured in the To-Be
model [18]. According to Jackson [15], the As-Is models
describe indicative properties whereas the To-Be models
describe optative properties. In the approach presented
in this paper the As-Is and To-Be models are require-
ments models expressed asmaps (Fig. 1). Amap [19, 20] is
a goal-oriented requirements representation formalism
that allows the representation of a set of requirements as
a non-deterministic ordering of intentions and of strate-
gies to achieve them. By avoiding unnecessary details,
maps help in focusing attention on what is to be achieved
(the intentions) and the ways required to achieve them
(the strategies). The As-Is map abstracts from the tech-
nical details of the implemented system to focus on the
business goals and associated strategies to attain them
that are supported by the system. The To-Be map ex-
presses the intentions and their associated strategies that
the organisation wants to achieve in the future.
The approach departs from Jarke’s view by modelling
the changes to be made as a collection of gaps between
the As-Is and the To-Be maps. A gap expresses a dif-
ference between the initial situation, the As-Is map and
the future situation, the To-Be map. Intuitively gaps
might be related to operators that cause transformations
of the As-Is map into the To-Be map. This is the view
developed in this paper. Map gaps express the require-
ments for change implied by the organisational business
expectations and the needs for the future. An expression
of gaps constitutes the requirements specification for
change, the change requirements.
In the adaptation process it is essential to describe the
gaps precisely since they are the basis of the actual
change of the software system. As suggested in Fig. 1,
map gaps might be propagated into schema gaps
describing the modifications in system functionality im-
plied by the change requirements. The actual adaptation
of the system is based on the schema gaps whereas map
gaps provide the business rationale for these schema
gaps. However, in this paper, our interest is with the
requirements level only.
In the proposed approach to elicit change require-
ments, gaps are precisely defined by associating each gap
to a predefined type of change. The paper proposes a
generic gap typology and its customisation to expressing
gaps between maps. The map gap typology is a set of
operators associated to the map representation system.
The approach for software system adaptation pre-
sented in this paper was developed to handle the stan-
dardisation of practices in the Financial branch, DIAC,
of the Renault motor company. The current software
system, besides providing other financial services, deals
with granting credit to Renault customers. A number of
such systems are running in DIAC subsidiaries located
in different countries, and it was required to standardise
these across Europe. The Spanish software system was
selected for adaptation and deployment in France,
Spain, Portugal and Germany.
The adapted software system, called FUSE, must
comply with the functionalities available in the French
software system and meet all the financial regulations in
the different countries. There are new business needs as
well as (a) diversification of the sales channels to include,
for example, sales by the internet in addition to regular
vendors, (b) inclusion of additional financial services, for
Fig. 1 The gap-driven approach
2