Potential Effect of Creeping User Requirements on Project Management: A Simulation Approach

256
IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.11, November 2009

Potential Effect of Creeping User Requirements on Project
Management: A Simulation Approach
P. K. Suri1, Rachna Soni2, Ashish Jolly3

1Department of Computer Science & Applications, Kurukshetra University, Kurukshetra (Haryana), India.
2Department of Computer Science, DAV Girls College, Yamuna Nagar (Haryana), India.
3Department of Computer Science & Applications, Shri Atmanand Jain Institute of Management & Technology, Ambala
City (Haryana), India.


Abstract
during the elicitation activity. Disparate priorities, limited
Requirements management has been discussed for at least fifteen
resources, time-to-market demands, and risk intolerance
years. As a discipline and as a practice, it has become more and
are but a few of the reasons for this. Triage takes into
more complex. In software projects new requirements are
considerations all the painful realities of the marketplace
continuously issued and the objective of the requirement
and makes the decision of which features will we build
management is to elicit, manage and prioritize requirements. In
now, which will be built in the next release, and which
the present study, a specific requirement management process is
simulated. The stochastic parameters of the proposed system
will be deferred until even later.
with specific system boundaries under a given environment have

been estimated using event to event simulation. The present
Requirements Specification: The art of detailing the
study will yield realistic results which are very near to the
exact external behavior of a system that will address the
functioning of the live system. Based on results from simulation,
features selected during the triage process. The level of
conditions that result in an overload situation are identified.
detail of these requirements depends greatly on the
Simulation is also used to find process change proposals.
situation. For example, if specifying a handheld remote
Keywords:
mouse, it might be sufficient to state “The system shall
Requirement volatility, Requirement management, Project
contain three programmable buttons, corresponding to the
management, Risk factors
three buttons on a standard three-button mouse.” However,
if the device is to be mounted in a holster and controlled
1. Introduction
by robotic fingers instead of being hand-held, then the
statement of requirements for the buttons would need to
Requirements are those externally observable
be considerably more detailed. Seventy-one percent of all
characteristics of a system that a user, buyer, customer, or
software development projects result in complete failure
other stakeholder desires to have present in the system.
(i.e., premature cancellation or shelf ware upon
Requirements management is the set of activities
completion).
encompassing the collection, control, analysis, filtering,
Poor requirements management is generally considered
and documentation of a system’s requirements.
one of the major causes for product failure [2, 3]. After all,
Requirements management consists of three activities:
if we do a poor job of understanding our customers’ needs,
Requirements Elicitation: The art of understanding the
if we do a poor job of deciding the right features to build,
needs of Stakeholder and collecting them in a repository
and if we do a poor job of writing down what we think we
for future analysis.
want out of a system, how can we possibly expect a
The needs can be expressed quite abstractly and in terms
successful project? All the software development
of a problem, e.g., “I want to reduce my billing error rates
techniques and tools and whatever level of CMM maturity
by at least 35%.” The needs can be expressed quite
you have achieved will be of no use to you if you are not
specifically and in terms of a solution, e.g., “I want there
building the “right” product.
to be a large red button on the operator’s console.” In all
This paper is organized into three main sections, each
cases, these needs are called features.
addressing the techniques, tools, and common wisdom of

each of the three aspects of requirements management.
Requirements Triage: The art of deciding which features

are the appropriate features to include in the product.
The High Cost of Requirement Errors
Rarely is it possible to satisfy every requested feature
There is strong evidence that effective requirements
gathered from every stakeholder
management leads to overall project cost savings. The
three primary reasons for this are:
Manuscript received November 5, 2009

Manuscript revised November 20, 2009

---

IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.11, November 2009
257
1. Requirement errors typically cost well over ten times
Global Software Development (GSD)
more to repair than other errors.
As said by [9], software process is defined by a set of
2. Requirement errors typically comprise over 40% of all
activities, methods, practices and technologies that people
errors in a software project.
and companies use to develop and to keep related
3. Small reductions in the number of requirement errors
software and products. The interest in the software
pay big dividends in avoiding rework costs and schedule
process is based on the following premises: The software
delays.
quality is strongly dependent on the quality of the process
Studies performed at GTE, TRW, and IBM measured and
used in its preparation; ?The software process can be
assigned costs to errors occurring at various phases of the
defined, managed, measured and improved. However, it is
project life-cycle2. Although these studies were run
not a simple task to develop software using a well-defined
independently, they all reached roughly the same
development process. Such process has become
conclusion: If a unit cost of one is assigned to the effort
increasingly more complex, whereas the software
required to detect and repair an error during the coding
demands of companies increase according to the strategic
stage, then the cost to detect and repair an error during the
importance for its operations. As part of the globalization
requirements stage is between five to ten times less.
efforts currently pervading society, software project teams
Furthermore, the cost to detect and repair an error during
have also become geographically distributed on a
the maintenance stage is twenty times more.
worldwide scale. This characterizes Global Software

Development (GSD). Tools and technological
Requirements Management
environments have been developed over the last few years
Requirements engineering plays an important role in the
to help in the control and coordination of the development
software development. As said by [8], a requirement is the
teams working in distributed environments. Many of these
condition or capacity that a system that is being developed
tools are focused in supporting procedures of formal
must satisfy. Therefore, the compliance with requirements
communication such as automated document elaboration,
determines the success or the failure of a project. The
processes and other non-interactive communication
requirements are identified, registered, organized and
channels. Moreover, [3], [4], [5] and [10] point out that
verified during the project development and that is what it
GSD is one of the biggest business-oriented challenges
called requirements management, a process that
that the current environment presents under the software
establishes and keeps the agreements firmed between the
development process point of view. Many companies are
project team, users and customers related to the changes
distributing its software development process in countries
of requirements in a specific system. The literature states
such as India, Russia and Brazil. Frequently this process
that the problems related with requirements engineering
occurs in only one country, particularly in regions with tax
are one of the main reasons for software projects failures.
incentives or critical mass in some skill or resource areas.
This means that the final product does not have all the
Organizations search for competitive advantages in terms
requirements gathering from users and customers [12].
of cost, quality and flexibility in the area of software
Research identified that 70% of the requirements were
development [10], looking for productivity increases as
difficult to identify and 54% were not clear and well
well as risk dilution [7]. Many times the search for these
organized. Also, it can be identified that [8] requirements
competitive advantages forces organizations to search for
are not easy to be described in words. There are different
external solutions in other countries (offshore
types of requirements in different levels of details. It can
outsourcing). This epitomizes the traditional problems and
be impossible to manage the requirements if they cannot
the existing challenges in GSD.
be controlled. Most requirements change during the

project time.
Key Benefits of better Requirements Management
Therefore, it is not difficult to find errors in the
Even in light of the above information, some will still
requirement specifications, and they can have a large
argue, why waste time with this unnecessary step; why not
impact in the project costs. An estimative shows that 40%
proceed directly to implementation? Experience has
of the requirements generate rework during the project life
shown that the benefits of effective requirements
cycle [12]. It is evident that the earlier a problem is
management include:
detected and solved (especially during the requirements

phase), many other problems are minimized in the
Better control of complex projects Lack of
following project phases. But in contrast, what it is
knowledge of the intended behavior of the system, as well
observed is a short time for the requirements phase in a
as requirements creep, are common factors in out-of-
project, not considering the project type or environment
control projects. Requirements management provides the
where this phase occurs.
development team with a clear understanding of what is to

be delivered, when and why. Resources can be allocated

based on customer-driven priorities and relative

---

258
IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.11, November 2009
implementation effort. And the impact of changes are
(a) S servers (employees)
better understood and managed.
(b) Each server provides service at the same constant

average rate µ.
Improved software quality and customer satisfaction
(c) The average arrival rate is constant; for all n
The fundamental measure of software quality is “does this
(d) ? < ?
S
software do what it is supposed to do?” Higher quality can
where
result only when developers and test personnel have a
Lambda = arrival rate
concise understanding of what must be built and tested.
L = average number of requirements in the system

Lq = average number of requirements in the queue
Reduced project costs and delays Research
Lw = average number of requirements in
demonstrates that errors in requirements are the most
the nonempty queues
pervasive and most expensive errors to fix. Decreasing
W = average time a requirement spends in the system
these errors early in the development cycle lowers the
Wq = average time a requirement spends
total number of errors and cuts project costs and time-to-
in the queue
market.
Ww = average time a requirement

spends in the queue if it must wait
Improved team communications
k +1
Requirements management facilitates early involvement
? ? ?
of customers to ensure the application meets their needs.
P(n > k ) = ?? ?? = probability of more than k
A central repository builds a common understanding
? ? ?
between the user community, management, analysts,
developers and test personnel of project needs and
requirements in the system.
commitments.
t
?
?
? ?

(pT >
? 1
t)
(
)
=
Easing compliance with standards and regulations
e
= probability the time in
Most major standards bodies and regulatory agencies
the system is greater than t
involved with software compliance and process

improvement have a keen understanding of the
With these assumptions (a),(b),(c) and (d),we have
requirements management problem. For example, the

Software Engineering Institute’s Capability Maturity
n

Model (CMM) addresses requirements management as
? ? ?
1
n =
,......,
1
,
0
s ?1
one of the first steps in improving software quality. DOD,
p =
? ?
n
p
FDA, and ISO 9000 standards and regulations also require
0

n!? ? ?
companies to demonstrate maturity and control of this

n
process. It is clear that doing a better job of the above will
? ? ?
save considerable time and money, not to mention
p
1
=

n?s
p
?
? ??
reducing the career challenges that result from
n
s s
0
!
? ? ?
unsuccessful or partially successful software
implementations.
n ? s

p(n ? s) = probability an arrival has to wait for service
2. Simulation Model

= probability of at least s requirements in the
system
The simulation accepts a set of input parameters which

specify the simulated situation. These input parameters

include the number of requirements entering the process

each day, the number of available servers (employees) for
= ?? pn
each phase and average time spent on requirement on each
n=s

phase.
s

(? ?) p
Model with Poisson Input Constant Service Time
=
0
s!(1 ? ? ?s)
The requirements are modeled to have an exponentially
distributed intensity of arrival, i.e. they arrive according to

Poisson process.
We assume

---

IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.11, November 2009
259

p =
1
Arrival rate chart
0
??
n?
s ?
??
?
?
s?1 1 ?
? ?
1
? ? ?
???
+
?
7
n
s
? ?s
t
s
n=
!?
? ?? !1
0
( ?
)
?
?
? ??
??
? ?
? ?
?
n 6
?
? ? ?
? ? ?
?
?
e
m 5
e

ir 4
L
s
? ? ? +1
qu 3
e
LQ
r
p
?
?
2
? ? ???
0
. of

1
o
L =
N 0
q
2
s s
. (
!
?
1 ? ?s)
5
10
15
?
arrival rate
L =
+
L

q
?

Fig 1: Arrival rate chart
L

W = ?
Waiting time of requirements in the
L
system
w
q
=

q
?
0.5

e 0.4
?
i
m
(
0.3
W
?
s
t s 1
e T
/ ?)
?
?
?
? ??
?
? ?
?
?
?
?
?
?
?
1
P
e
ag 0.2
WQ
(
0
t
P T >t)
?? ?
?
?
?
?
???
=e ? +
1

ver 0.1
A
s (
! ?
1 ? ? )
s (s ? ?
1 ? ?) ?
?
?
0
?
?
?
?
5
10
15
arrival rate
3. Results and Discussion

Results of the simulation model stated above, (where
Fig 2: Waiting time of requirements in the system
arrival rate is generated through Poisson distribution) are

as given below:

Probabilistic Modeling
Case 1: mu=6, S=3 and T=10 days
0.8

0.7
LAMBDA
5.00000 10.00000 15.00000
0.6
L
.85553 2.04137 6.01124
l
i
t
y
PT
0.5
PN
LQ
.02220 .37470 3.51124
bi 0.4
PZERO
W
.17111 .20414 .40075
r
oba 0.3
P
PS
0.2
WQ
.00444 .03747 .23408
0.1
PT
.14141 .19459 .46198
0
PN
.36011 .28777 .11236
5
10
15
PZERO
.43213 .17266 .04494
requirement arrival rate
PS
.05771 .29976 .70225

Table 1
Fig 3: Probability Graph


For higher values of Lambda, queueing system not valid
From the table it is observed that average no of
because Lambda < s*mu.
requirements waiting in the queue increases with increase
in the arrival rate of the requirements, so the average time
a requirement spends in the system(w) and queue (both)
increasing and the probability that no requirement is in the
queue is decreasing. The probability of at least s
requirements in the system is increasing. Case 2 of the
study deals with the problem of high waiting time in the
queue.

---

260
IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.11, November 2009
Case 2: Lambda=15, T=10 days and mu=6
No of employees Vs Average waiting

time of requirements
LAMB
15.00 15.00
15.0
15.00 15.00
DA
0
0.5
e
MU
6.00 6.00
6.00
6.000
6.00
i
m 0.4
00
t
g
0.3
N
1.00 1.00
1.00
1.000
1.00
i
t
i
n
W
a
WQ
00
w 0.2
e
S
3.00 5.00
7.00
9.000
11.00
ag 0.1
er
00
Av
0
T
.33330 .3333
.333
.3333
.33330
3
5
7
9
11
0
30
0
No. of employees
L
6.01 2.630
2.50 2.500
2.5000

37
46
2
Fig 5: No of employees Vs average waiting time of the
system
LQ
3.511 .1303
.008
.0004
.00002

7
58
6
W
.40075 .1753
.167
.1667
.16667
Critical probabilitis
6
24
0
WQ
.23408 .0086
.000
.0000
.00000
0.8
9
57
3
0.7
0.6
PT
.46198 .1465
.135
.1353
.13536
y
PT
it 0.5
4
96
9
il
b
PN
a 0.4
b
PN
.11236 .2002
.204
.2052
.20521
PZERO
o 0.3
Pr
PS
5
95
0
0.2
PZER
.04494 .0801
.081
.0820
.08208
0.1
O
0
98
8
0
3
5
7
9
11
PS
.70225 .1303
.015
.0011
.00006
No of employees
7
44
9

Table 2
Fig 6: Probability Chart



The above graph reveals that by adding two employees in

the system the requirement creep can be stabilized. It will
reduce the average time a requirement spends in the
No of employees Vs average no of
system and queue.
requirements in the system
8
f

4. Conclusion
s
o
nt
6
o
e
n
L
e
m
In the above work a simulation technique has been used to
4
r
e
ag
LQ
know the potential effect of creeping user requirements on
qui
2
aver
r
e
the project. The substantial progress has been achieved in
0
the areas of requirement elicitation, analysis and
3
5
7
9
11
specification. The present simulator will be an asset in IT
no of employees
industry in order to optimize the software development

process and to release the software product in an
Fig 4: No of employees Vs average no of requirements
estimated scheduled time. The future research lies in the
in the system
holistic view and system vide solutions to the entire
management process.

---

IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.11, November 2009
261
References
[22] Jäälinoja J. “Requirements implementation in embedded
[1] 1] The Merlin-project web site. (2005-07-12) URL:
software development”, University of Oulu, Department of
http://virtual.vtt.fi/merlin/
Information Processing Science, Master’s Thesis, pp. 85,
[2] Jones, C., “Patterns of Software Systems Failure and
2004.
Success”, International Thomson Press, 1996.
[23] Cleland-Huang J., Zemont G., and Lukasik W. “A
[3] Parviainen P., Vierimaa M., Tihinen M., Kääriäinen J.,
Heterogeneous Solution for Improving the Return on
Takalo J. “Industrial Inventory Summary (Merlin-project
Investment of Requirements Traceability” in 12th IEEE
deliverable D1.1.3.)”, pp. 37, 2004.
International Requirements Engineering Conference
[4] McConnell, S., Rapid Development, Microsoft Press, 1996,
(RE’04) pp. 230 – 239, 2004.
p. 86.

[5] Guidelines for Requirements Management United States
Dr. P.K. Suri received his Ph.D degree
Department of Energy, Software Quality Assurance
from Faculty of Engineering, Kurukshetra
Subcommittee, pp. 31, 2000.
University, Kurukshetra, India and
[6] Bosworth M., “Solution Selling”, New York, McGraw Hill,
master’s degree from Indian Institute of
1995.
Technology, Roorkee (formerly known as
[7] Lormans M., vanDijk H., van Deursen A., Nöcker E.,
Roorkee University), India. He is working
deZeeuw A. “Managing Evolving Requirements in an
as Professor in the Department of
Outsourcing Context: An Industrial Experience Report” in
Computer Science & Applications,
Principles of Software Evolution, 7th International
Kurukshetra University, Kurukshetra - 136119 (Haryana), India
Workshop on (IWPSE’04), pp. 149-158, 2004
since Oct. 1993. He has earlier worked as Reader, Computer Sc.
[8] Gause, D., and G. Weinberg, “Exploring Requirements”,
& Applications, at Bhopal University, Bhopal from 1985-90. He
New York, NY, Dorset House, 1989.
has supervised eleven Ph.D.’s in Computer Science and thirteen
[9] Kotonya G., & Sommerville I. “Requirements Engineering:
students are working under his supervision. He has more than
Process and Techniques”, John Wiley & Sons, pp. 282,
125 publications in International / National Journals and
1998.
Conferences. He is recipient of 'THE GEORGE OOMAN
[10] Goguen, J., and M. Jirotka, “Requirements Engineering”,
MEMORIAL PRIZE' for the year 1991-92 and a RESEARCH
Boston, MA, Academic Press, 1994.
AWARD –“The Certificate of Merit – 2000” for the paper
[11] Parviainen P., Hulkko H., Kääriäinen J., Takalo J., Tihinen
entitled ESMD – An Expert System for Medical Diagnosis from
M. “Requirements engineering, Inventory of technologies”,
INSTITUTION OF ENGINEERS, INDIA. His teaching and
VTT Publications 508, pp. 106, 2003.
research activities include Simulation and Modeling, SQA,
[12] Leffingwell, D., and D. Widrig, “Managing Software
Software Reliability, Software testing & Software Engineering
Requirements”, New York, Addison Wesley, 2000.
processes, Temporal Databases, Ad hoc Networks, Grid
[13] Spurr K., et al., “Computer Support for Cooperative Work”,
Computing and Biomechanics.
New York, John Wiley, 1994.

[14] Bosworth, M., “Solution Selling”, New York, McGraw Hill,
Dr Rachna Soni is Associate Professor
1995.
and Head, Deptt of Computer Science &
[15] Rinne J., Kohti hajautettua ohjelmistokehitystä. Pro gradu –
Applications, did her M.Phil from IIT,
tutkielma. Tampereen yliopisto, Tietojenkäsittelytieteiden
Roorkee and Ph.D from Kururukshetra
laitos, Tampere, pp. 54, 2001.
University, Kurukshetra. She has more
[16] Paasivaara M. & Lassenius C., “Collaboration Practices in
than eighteen years teaching experience in
Global Interorganizational Software Develop-ment
the institution of repute. She has published
Projects”, in Software Process Improvement and Practice, 8,
eight papers in International/national journal /conferences. Her
pp. 183-199, 2004.
area of interest includes Software Risk Management, Project
[17] Ohrwall Rönnbäck A, “Interorganizational IT Support for
Management, Requirement Engineering, Component based
Collaborative Product Development”, Dissertation from the
Software Engineering, Simulation etc.
International Graduate School of Management and

Industrial Engineering, IMIE. No. 59, Doctoral Dissertation,
Ashish Jolly received his MCA degree
pp. 83, 2002.
from University of Madras, Chennai in the
[18] Teppola S., Takalo J., Kääriäinen J. Tool chain. (Merlin-
year 1999. Currently he is pursuing Ph.D
project deliverable D1.3.3.), pp. 18, 2005.
in Computer Science from Department of
[19] Davis, A., “Software Requirements”, Englewood Cliffs, NJ:
Computer Science & Applications,
Prentice Hall, 1993.
Kurukshetra University, Kurukshetra,
[20] Hoffmann M., Kühn N., Weber M., Bittner M.
India. He is working as a Asstt Professor
“Requirements for Requirements Management Tools”, in
and Head in the Department of Computer
12th IEEE International Requirements Engineering
Science & Applications, Shri Atmanand
Conference (RE´04) pp. 301-308, 2004.
Jain Institute of Management & Technology (affiliated to
[21] Davis, A., et al., “Identifying and Measuring Quality in
Kurukshetra University, Kurukshetra), Ambala City, Haryana,
Software Requirements Specification,” IEEE International
India. He has more than nine years of teaching experience. He
Software Metrics Symposium, Los Alamitos, CA, IEEE
has published four research papers in referred International
Computer Society Press, pp. 164-175, 1997.
journals of repute. His research area includes Simulation,

Software Engineering and Software Project Management.

---