2 APPROACHES FOR
REQUIREMENT EVOLUTION
There are at least two different approaches to
managing requirement evolution. The requirement
engineering approach (Wiegers, 1999; Kotonya and
Sommerville, 1998; Jarke et. al, 1999) attempts to
manage requirement evolution using process-
oriented activities that try to eliminate the
phenomena. The other approach (Jarke et. al, 1999,
van Lamsweerde, 2000; Tomayko, 2002; Lehman,
1998; Lehman, Perry and Ramil, 1998) considers
requirement evolution as a natural and inevitable
feature of systems development instead of an issue
that has to be solved or eliminated. Software
lifecycle models and methodologies, such as
prototyping (Kotonya and Sommerville, 1998) and,
more recently, different kinds of agile methods
(Cockburn, 2001), are examples of the latter
approach to requirement evolution.
One way of understanding requirement evolution
is to measure it quantitatively, as in (IEEE Std
982.1, 1988; IEEE Std 982.2, 1988; Andersson and
Felici, 2002). These IEEE standards propose a
Requirement Maturity Index (RMI); the RMI metric
attempts to quantify the readiness of requirements.
In (Andersson and Felici, 2001), the metric is
extended by taking into account historical
information on change, as a result of which a
Historical Requirements Maturity Index (HRMI) is
proposed. The above-mentioned approaches measure
RMI or HRMI over all the software releases and
quantify the readiness of requirements over time.
These metrics are calculated on the basis of
requirement specification, which is performed as a
result of requirement elicitation and analysis.
A phenomenon called ‘requirements creep’
(Ryan et. al, 2001; Wiegers, 1999) takes into
account new emerging requirements which do not
necessarily exist in the requirement specification
document but have emerged during the course of the
development process. In (Wiegers, 1999),
requirements creep refers to the ”difference between
the requirements specification developed after the
requirements procedure and the requirements at the
time when the actual product is built”. In (Ryan et.
al, 2001), requirements creep is referred as
”significant additions or modifications to the
requirements of a software system throughout the
lifecycle, resulting in extensions to and alteration of
the software’s functionality and scope”.
3 CASE STUDY
3.1 Project Description
This study was carried out in the systems
development department of an international ICT
company. The project involved the development of
an E-commerce mobile service platform. The system
was intended to enable organizers or their sponsors
to promote their products in different kinds of
happenings, such as ice hockey and football games.
The system was composed of two subsystems, a
platform in which the services were running
(Subsystem A) and a toolbox, which permitted
addition, configuration and simulation services
(Subsystem B). This toolbox was intended to run on
a PC in the Windows environment and the platform
in the UNIX environment.
The project employed the object-oriented
approach for systems development and was
implemented in 2001.The project was divided into
the following phases on the basis of the company’s
process model: pre-study, feasibility study, project
execution and piloting and maintenance. The
requirements were collected and analyzed during the
pre-study and feasibility study phases. One of the
first activities in the project execution phase was to
design the software architecture, in which the system
was divided into the respective modules and their
interfaces. This was followed by the detailed design,
implementation and integration and system testing
phases. After the system testing showed the quality
of the software to be acceptable, the product went
onto the piloting and customer approval phases.
A process-oriented approach was taken to
managing requirement evolution in the project. A
requirement specification document was formulated,
and the requirements were ‘frozen’ in this document
upon completion of the requirement elicitation and
analysis phases. After requirement freezing,
requirements were managed through a strict
requirement changing procedure. This requirement
changing procedure was intended to be specified in
each development project, but the spirit of the
changing procedure was such that every single
change to the requirements had to be analyzed and
handled by the project steering group.
Unfortunately, in most of the projects this did not
work, as was the case in this E-commerce project.
This project, involved an entire subsystem,
Subsystem B, for which only four requirements were
specified in the requirement specification document.
Nevertheless, at the end of the development project,
Subsystem B was 60 % of the size of the whole
software application in terms of code size and the
required development effort. The new requirements
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
670