See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228716711

Elicitation and Prioritization of Software Requirements

Article · December 2009

CITATIONS READS

19 282

2 authors:

Mohd Sadiq Mohd Shahid

Jamia Millia Islamia Mewat Engineering College (WAQF)
69 PUBLICATIONS   628 CITATIONS    6 PUBLICATIONS   87 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Requirements elicitation View project

Numerical Algorithm View project

All content following this page was uploaded by Mohd Sadiq on 08 January 2016.

The user has requested enhancement of the downloaded file.

 SHORT PAPER
International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009
Elicitation and Prioritization of Software
Requirements
Mohd. Sadiq
Computer Engineering Section, University
Polytechnic, Faculty of Engineering and
Technology Jamia Millia Islamia (A Central
University), New Delhi-110025 (India)
E-mail: sadiq.jmi@gmail.com
Abstract: A requirements may be defined as a demand
or need. In software engineering, a requirement is a
description of what a system should do. System may
have dozen to thousands of requirements. Software
requirements stipulate what must be accomplished,
transformed, produced or provided. In this paper we
have proposed a framework for elicitation and
prioritization of software requirements using AHP and
QFD techniques. This framework mathematically
prioritize the software requirements after eliciting the
software requirements from existing method such as
misuse case, JAD, ontology and so on, but in this paper
we have used the JAD approach in order to elicit the
software requirements.
Keywords: Software Requirements, Elicitation
Techniques, Analytic Hierarchy Process, and Quality
Function Deployment.
I. INTRODUCTION:
Elicitation is all about determining the needs of
stakeholders and learning, uncovering extracting and
/or discovering needs of the users and other potential
stakeholders [5]. Requirement elicitation is
recognized as one of the most critical knowledge
intensive activities of the development of software.
Studies by [13] indicate that 70% of the system errors
are due to the inadequate system specification and
30% of the system errors are due to design issue. The
analysis of secure software system based on the
system requirements elicited in the form of use case
and misuse case. Use cases have proven helpful for
elicitation of communication about, and
documentation of the function requirements. The
integral development of use and misuse cases
[8,10,12] provides a systematic way for the elicitation
of both the functional and non functional
requirements [9]. Using an elicitation method can
help in producing a consistent and complete set of
security requirements. However, brainstorming and
elicitation methods used for ordinary functional (end-
user) requirements usually are not oriented toward
security requirements and do not result in a consistent
138
© 2009 ACADEMY PUBLISHER
Mohd. Shahid
M. Tech. Scholar, Department of Computer
Science and Engineering, Al-Falah School of
Engineering and Technology, Dhauj, Faridabad
Maharshi Dayanand University, Rohtak,
Haryana (India)
E-mail: shahid27.jmi@gmail.com
and complete set of security requirements. The
resulting system is likely to have fewer security
exposures when security requirements are elicited in
a systematic way. QFD was developed in the Kobe
shipyards as a way to expand and implement the view
of quality as taught by W. Edwards Deming and
others [16, 17]. It has been widely applied in many
industries worldwide, such as automobile,
electronics, food processing, computer hardware, and
software. Software Quality function Deployment
(SQFD) focuses on improving the quality of both the
software development process and the product [16,
18]. A number of requirements elicitations techniques
have been developed to extract requirements from a
user. The following list is a sample of methods that
could be considered for eliciting security
requirements. The goal of JAD (Joint Application
Development) is to involve all stakeholders in the
design phase of the product via highly structured and
focused meetings. Typical participants in the session
include a facilitator, end users of the product, main
developers, and observers. In the preliminary phases
of JAD, the requirements-engineering team is tasked
with fact finding and information gathering.
Typically, the outputs of this phase, as applied to
security requirements elicitation, are security goals
and artifacts. The actual JAD session is then used to
validate this information by establishing an agreed-on
set of security requirements for the product. If JAD
has some advantages so it has also some
disadvantages. The important disadvantage of JAD is
that if there are too many JAD sessions while the
project is progressing then user may develop a
feeling that the developer are shifting their work and
responsibility onto the users. To get the detailed
description about the remaining techniques please
refer to [5] [6] [4]. The paper is organized as follows:
In section 2 we present the background and related
work. In section 3 we have proposed the framework
for elicitation and prioritization of software
SHORT PAPER
International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009
requirements (FEPSR) using AHP and QFD
techniques, in this section we have also applied
FEPSR on a Mini Software for Numerical Integration
(MSNI) and finally we conclude the paper in section
4.
II. BACKGROUND AND RELATED WORK:
D.Firesmith [1], have worked for prioritization
dimensions, prioritization approach, prioritization
techniques and processes. This paper does not
explain how the software requirements will be
prioritize mathematically? It has only a list of
prioritization techniques. In [19] C. Kuloor and A.
Eberlrin have explained the requirements engineering
for software product lines. It has limited number of
elicitation techniques. This paper does not include
ontology framework, misuse cases, rapid application
development etc. In [21] J.Karlsson, C Wohlin, and
B.Regnell have evaluated six different methods for
prioritization software requirements. In this paper,
authors have found that Analytic Hierarchy Process
to be the most promising method. But in literature we
have found the some weaknesses of the AHP. The
limitation of the AHP is that it only works because
the matrices are all of the same mathematical form-
known as positive reciprocal matrix. To create such a
matrix requires that, if we use the number 9 to
represent A is absolutely more important than B then
we have to use 1/9 to define the relative importance
of B with respect to A. Some people regard that as
reasonable: others are less happy about it. This paper
does not include any elicitation technique. We know
that without eliciting any requirements we can not
prioritize it. So in order to prioritize the requirements,
there should be a list of elicitation techniques.
Researchers, scientist and academician in the field of
software engineering have proposed several
techniques to elicit the software requirements. In [3]
authors have proposed an approach for the software
requirements elicitation. They have used the several
steps like training sessions to eliminate “lack of user
input” and “poor understanding”, recording
keywords, pictorial representation of needs and wants
to reduce language barriers etc. but this approach
does not have the information that how we will
prioritize the requirements. In [7] the authors have
provided the different elicitation technique and
criteria for its selection. In the continuation of the
above work we have proposed a FEPSR using AHP
and QFD.
III. PROPOSED FRAMEWORK:
In this section we have proposed FEPSR using AHP
and QFD with the help of [14, 15]. This framework
overcomes the problems that we had discussed in the
last section.
1. Evaluation of Elicitation Criteria.
2. Choose the appropriate Elicitation method.
139
© 2009 ACADEMY PUBLISHER
3. Elicit the software requirements with the
help of the following
(a) Collect information about user
expectations.
(b) Train the Clients, Users and Managers.
(c) Write the description of the user need for
the proposed system.
(d) Now you can apply Misuse cases, JAD,
RAD, and Ontology framework.
4. In this framework we are using two different
prioritizing techniques i.e. Analytic
Hierarchy Process (AHP) and Quality
Function Deployment (QFD).
5. If we are using AHP
{
Create the overall performance
matrix
}
Then calculate the Eigen vector
Else
{
Develop the QFD matrix
on the basis of the software
requirements
}
6. Draw the Pareto- like graph
3.1 Evaluation of Elicitation Criteria:
The elicitation evaluation criteria may be useful in
selecting an elicitation method. We evaluate the
elicitation criteria on the basis of [13, 14].
3.2 Choose the appropriate Elicitation Technique: In
[4] Nancy. R. Mead, have discussed the techniques to
evaluate the elicitation criteria .So in this paper we
have used that technique to evaluate the best
elicitation technique and we found that JAD is
appropriate for MSNI. Above parameters are used to
choose the best elicitation techniques. In this paper
we have applied Joint Application Development to
elicit the software requirements. We know that we
have elicited the software requirements for
Numerical Integration Based Software i.e. MSNI
which were used to solve the given set of integrals
using Simpson’s 1/3, Simpson’s 3/8 and Trapezoidal
rules.
3.3 Elicit the Software Requirements with the help of
the following:
3.3.1 Collect information about user expectations:
Software Requirement Specification is the first step
in the software development which is used to capture
the requirement of the client. Before the designing
phase SRS team write the user manual i.e. SRS and
from this SRS we collect the information about the
user need and expectations. This careful compilation
of information will be used in the next phase to train
SHORT PAPER
International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009
the clients/ user and make them aware of what they
can and can not expect from the software developers.
In this stage stakeholder also learn about the
limitations of the computer resources and
functionalities, and availability of other resources.
3.3.2 Train the Clients, Users, and Managers: Once
we have collected the information about the user
need and expectation; the next step is to train the
clients, users and managers. At this stage, missing
user input can be supplemented.
3.3.3 Write the description of the user need for the
proposed system: After the successful completion of
the above steps, each stakeholder will write the
description of his/ her needs of the system that the
clients want to develop. Since the clients and
customers are already educated about the computer
limitations and availability of resources through the
training sessions. In this stage expectations of the
development process become clearer. With the help
of the above steps i.e. 3.3.1, 3.3.2, and 3.3.3, we have
elicited the software requirements for MSNI and the
important list of software requirements are given
below.
(a) Total numbers of existing algorithm like
Simpson’s 1/3 rule, Simpson’s 3/8 and Trapezoidal
rule. (EA); (b) Total numbers of algorithms proposed
by the researchers (PA); (c) Accuracy (AC); (d)
Graphical User Interface (GI); (e) Functionality of
the algorithm (FA); (f) Passwords (PW) (g) Risk (RI)
(h) Cost (CO).
3.4 In this paper we have used two different
approaches for prioritizing the software requirements
i.e. Analytic Hierarchy Process and Quality Function
Deployment (QFD). The Analytic Hierarchy Process
(AHP) is a structured technique for dealing with
complex decisions. Rather than prescribing a
"correct" decision, the AHP helps the decision
makers find the one that best suits their needs and
their understanding of the problem. Based on
mathematics and psychology, it was developed by
Thomas L. Saaty [11] in the 1970s and has been
extensively studied and refined since then. The AHP
provides a comprehensive and rational framework for
structuring a decision problem, for representing and
quantifying its elements, for relating those elements
to overall goals, and for evaluating alternative
solutions. It is used around the world in a wide
variety of decision situations, in fields such as
government, business, industry, healthcare, and
education. In this section we have first explain how
the AHP would be used to prioritize the software
requirements. Suppose a university wishes to buy a
piece of software of certain type and has four aspects
in mind which will govern its purchasing choice. (i)
Expense, E (ii) Operability, O (iii) Reliability, R (iv)
Adaptability for other uses or Flexibility , F.
140
© 2009 ACADEMY PUBLISHER
Competing manufactures of that equipment have
offered three options, X, Y, and Z . The software
engineers have looked at these options and decided
that X is cheap and easy to operate but is very
reliable and could not easily be adapted to other
users. Y is somewhat more expensive, is reasonable
and easy to operate, and is very reliable and not very
adaptable. Finally, Z is very expensive, not easy to
operate, is a little less reliable than Y but is claimed
by the manufacturer to have a wide range of
alternatives uses. Each of X, Y, and Z will satisfy the
firm’s requirements to differing extents so which,
overall, best meets this firm’s needs? This is clearly
an important and common class of problem and AHP
have numerous applications. We first provide an
initial matrix for the firm’s pair wise comparisons in
which the principal diagonal contains entries of 1, as
each factor is as important as itself [15].
E O R F
E 1
O 1
R 1
F 1
There is no standard way to make the pair wise
comparison but let us suppose that the firm decide
that O is slightly more important than cost. In the
next matrix that is rated as 3 in the cell O, E and I/3
in E, O. They also decide that reliability is far more
important than cost, giving 9 in R, E and 1/9 in E, R.
Similarly we enter the information into the given
matrix on the basis of the Saaty Rating scale. This
forms the completed matrix, which we will term the
Overall Preference matrix (OPM) is
E O R F
E 1 1/3 1/9 1/5
O 3 1 1 1
R 9 1 1 3
F 5 1 1/3 1
The eigenvector (importance weight) of the relative
importance or value of E, O, R, and F is (0.058,
0.2620, 0. 454, and 0.226). Thus R is most valuable,
O and F are behind, but roughly equal and E is very
much less significant. So in this way we can easily
collect the customer’s requirements. After the
detailed description of the AHP we have provided the
QFD approach in order to prioritize the software
requirements and the steps for the QFD are given
below:
1. Generate the importance weight for CNS
using Analytic Hierarchy Process (AHP)
2. Place the customer needs, their weight and
specification in a QFD matrix.
3. Find out the absolute weight and relative
weight.
4. Create the Pareto-like chart of the weights.
 SHORT PAPER
International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009

From the above steps we have got the idea that how specification attributes and SA-2 means second
we will collect the customer needs and how we will specification attributes and so on.
prioritize that need using AHP? In this paper we have
used the concept of the QFD [16, 17] for the Table-04
prioritization of the software requirements. Consider Category I. Weight
4.1 0.0948
the following overall performance matrix (OPM) that 4.2 0.121
is derived from customer needs statement for MSNI: 4.3 0.069
Table-1 (OPM) 4.4 0.112
C PA AC EA FA GI RI PW CO 4.5 0.080
1 PA 1 1/5 1/3 1/7 3 3 1/5 1/3 4.6 0.121
2 AC 5 1 1/5 1/9 3 3 1/3 1/5 4.7 0.129
3 EA 3 5 1 1/7 3 3 3 5 4.8 0.084
4 FA 7 9 7 1 9 1/5 1/3 5 4.9 0.109
5 GI 1/3 1/3 1/3 1/9 1 5 3 1/5 4.10 0.0793
6 RI 1/3 1/3 1/3 5 1/5 1 3 5
7 PW 5 3 1/3 3 1/3 1/3 1 5 QFD Matrix
8 CO 3 5 1/5 1/5 5 1/5 1/5 1 CN GW Quality Characteristics
After applying the AHP we have got the importance SA-1 SA-2 SA-3 SA-4 SA-5
weights and it is summarized in table- 02. 4.1 .0253 1 1 3 10
Table-02 4,.2 .0323 3
Category I. Weight 4.3 .0184
1 0.0569 4.4 .0299
2 0.0674 4.5 .0213 9
3 0.221 4.6 .0323 10
4 0.2667 4.7 .0344 10
5 0.0627 4.8 .0224 1
6 0.100 4.9 .0291 1
7 0.141 4.10 .0211
8 0.083 Once the body of the matrix is filled in, multiply the
In the above table functionality of the algorithm has values in each column of the body of the matrix by
the highest priority because its importance weight is the corresponding values in the global weight column
0.2667 i. e. category 4. Under this category there are and sum the column. All raw column weights thus
again 10 requirements and these requirements are R1, calculated and then normalized as shown in the
R2, ----- R10. The overall performance matrix for following table:
this situation is as below: Table-5
Table-03 (OPM) S. Attributes Absolute Weight Normalized weight
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 SA-1 0.0253 0.00281
R1 1 1/5 3 7 1/3 5 7 9 1/9 1/3 SA-2 0.0323 0.00358
R2 5 1 3 1/3 5 3 1/5 1/5 9 1/7 SA-3 0.4199 0.046
R3 1/3 1/3 1 3 7 3 1/7 1/5 1/3 1/5 SA-4 0.4738 0.053
R4 1/7 3 1/3 1 3 3 3 1/5 1/3 7 SA-5 0.4423 0.0491
R5 3 1/5 1/7 1/3 1 3 5 9 1/9 1/7 From the given chart we conclude that which
R6 1/5 1/3 1/3 1/3 1/3 1 5 5 7 9 specification attribute will get the priority. In this
R7 1/7 5 7 1/3 1/5 1/5 1 3 5 7 approach SA-4 has got first priority, then SA-5 and
R8 1/9 5 5 5 1/9 1/5 1/3 1 5 1/5
R9 9 1/9 3 3 9 1/7 1/5 1/5 1 3 so on.
R10 3 1/7 5 1/7 7 1/9 1/7 5 1/3 1
Pareto-Like Chart of the weights
After applying the AHP [11, 18] we have got the ranked from largest to smallest
importance weights and it is summarized in table- 04. 0.06
To compare the global importance of all items in all
Relative Weights

0.05
0.04
categories each item needs to be adjusted by the 0.03 Series1
0.02
importance weighting of its corresponding category. 0.01

Thus all the weight category 4 would be adjusted by 0IV. CONCLUSION:

SA-4 SA-5 SA-3 SA-2 SA-1
multiplying the weight of each element by the Specification Attributes

importance weighting of category 4 i.e. 0.267. Thus

the global weight of element 4.1 would be
0.267*0.094= 0.0253. After obtaining all the global
weights we proceed to the next step in our CTQ
(critical- to- quality) process. Now we will Place
customer needs, there weight and specification in
QFD matrix. In the following table SA-1 means first
IV CONCLUSION:
The poor performance could be (i) unrelated to
elicitation techniques, (ii) caused by lack of effective
elicitation techniques, (iii) by availability but poor
use of effective elicitation techniques. In this paper
we have proposed an approach to elicit the software

141

© 2009 ACADEMY PUBLISHER

 SHORT PAPER
International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009
requirements and its prioritization using AHP. From
this approach we can easily rank the requirements
and can implement it on the basis of the ranking. In 6.
this paper we have developed the mini software for
numerical integration (MSNI). This software
basically integrates the value of a given function after
applying existing techniques like Simpson’s 1/3 rule, 7.
Simpson’s 3/8 rule, trapezoidal rule etc. Any product
development involves projecting its potentials
success in achieving its functional and commercial
goals. Better quality designs that match customer 8.
needs and preferences and integrate other life cycle
issues early in the software development process.
9.
Thus there is significant concern in industry about
quality product design, which is addressed by Quality
function Deployment (QFD). From the proposed
framework it would be easy to prioritize the
requirements. We know that 70% of the system errors 10.
are due to the in adequate system specification and
30% of the system errors are due to design issue. If
we can elicit the system requirements properly and 11.
can prioritize it according to proposed framework
12.
then we can definitely reduce this 70% factor.
V. ACKNOWLEDGEMENTS: 13.
The authors would like to thank Mr. Iqbal Azam,
Principal, University Polytechnic, Faculty of
Engineering and Technology, Jamia Millia Islamia
(A Central University), New Delhi-25, India ; and 14.
Mr. Jawad Ahmad Siddiqui, Chairman, Al-Falah
School of Engineering and Technology, Dhauj,
Faridabad, Haryana, India, for his valuable support ,
guidance and encouragement
REFERENCES:
1. D. Firesmith, “ Prioritizing Requirements”, 15.
Journal of Object Technology, Volume 3, No.8,
September 2004
2. LI Zong-yong, WANG Zhi-xue, YANG-ying,
WU Yue, LIU Ying, “ Towards multiple
ontology Framework for Requirements
Elicitation and Reuse”, 31st IEEE Annual 16.
International Computer Software and Application
Conference, 2007. 17.
3. P.Rajagopal, R.Lee, Thomas Ahlswede, Chia-
Chu Chiang, D. Karolak, “ A New Approach for
Software Requirements Elicitation”, Proceedings 18.
of the 6th IEEE International Conference on
Software Engineering, Artificial Intelligence, 19.
Networking and Parallel/ Distributed Computing,
2005.
4. Nancy R. Mead, “Requirements Elicitation 20.
Introduction”, Software Engineering Institute
Carnegie Mellon University, 2008-2009.
5. Ann M. Hickey, Alan M. Davis, “Requirements
Elicitation and Elicitation technique selection: A
Model for Two knowledge-Intensive Software
development Process”, Proceedings of the 36th
142
© 2009 ACADEMY PUBLISHER
View publication stats
IEEE International Conference on System
Sciences, 2002.
W.R. Friedrich, J. A. Van der Poll, “Towards a
Methodology to Elicit Tacit Domain knowledge
from Users”, Interdisciplinary Journal of
Information, Knowledge, and Management,
Volume2, 2007.
A.M. Hickey, A.M. Davis, “Elicitation
Technique Selection: How Do Experts Do It?”
Proceedings of the 11th IEEE International
Requirements Engineering Conference, 2003.
Gunnar Peterson, John Steven, “Defining Misuse
within the Development Process”, IEEE Security
and Privacy, 2006.
J.J.Pauli, D.Xu, “Misuse Case-Based design and
Analysis of secure Software Architecture”,
Proceedings of the IEEE International
Conference on Information Technology: Coding
and Computing (ITCC05), 2005.
Ian Alexander, “Misuse Cases Help to Elicit
Non-functional Requirements”, Computing and
Control Engineering 2003.
T. L. Saaty, “The Analytic Hierarchy process”,
New York, McGraw-Hill, 1980.
J. Karlsson, “Software Requirements
Prioritizing”, Proceedings of the International
Conference on Requirement Engineering, 1996.
Beichter F. et al, “ SLAN-4-A Software
Specification and Design Language”, IEEE
Transaction on Software Engineering, SE- 10,2,
1994, pp 155-162.
Mohd. Sadiq, Shabina Ghafir, Mohd. Shahid,
“An Approach for Eliciting Software
Requirements and its Prioritization using
Analytic Hierarchy Process”, IEEE International
Conference on Advances in Recent Technologies
in Communication and Computing, 2009,
ACEEE annual world congress on Engineering
and Technology , Kerala, India.
Mohd. Sadiq, Shabina Ghafir, Mohd. Shahid,” A
Framework to Prioritize the software
Requirements using Quality Function
Deployment”, National Conference on Recent
Development in Computing and its Application,
2009, organized by Jamia Hamdard, Delhi, India.
Xiaoqing frank Liu, “Software Quality
Development”, IEEE Potentials, 2008.
Bruce White, “QFD for small business”,
Transaction from the 18 Symposium on QFD,
2006.
http://en.wikipedia.org/wiki/Analytic_Hierarchy_
Process
C.Kuloor, Armin Eberlein, “Requirements
Engineering for Software Product Lines”, The
University of Calgary, Canada.
J. Karlsson, C. Wohlin, B. Regnell, “An
Evaluation of Methods for Prioritizing Software
Requirements”, Elsvier Journal of Information
and Software Technology, 1998, pp. 939-947.