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

net/publication/261110089

Challenges and future trends in software requirements prioritization

Conference Paper · July 2011

DOI: 10.1109/ICCNIT.2011.6020888

CITATIONS READS
36 959

3 authors:

Muhammad Imran Babar Muhammad Ramzan

Army Public College of Management and Science Virtual University of Pakistan
31 PUBLICATIONS   114 CITATIONS    60 PUBLICATIONS   271 CITATIONS   

SEE PROFILE SEE PROFILE

Shahbaz Ahmed Khan Ghayyur

International Islamic University, Islamabad
21 PUBLICATIONS   71 CITATIONS   

SEE PROFILE

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

Risk Management In Agile Software Development View project

Software maintenance Prediction: An Architecture Perspective View project

All content following this page was uploaded by Muhammad Imran Babar on 27 May 2014.

The user has requested enhancement of the downloaded file.

 Challenges and Future Trends in Software
Requirements Prioritization
Muhammad Imran Babar', Muhammad Rarnzan2, Shahbaz A. K. Gha�
1Department of Software Engineering, International Islamic University, Islamabad Pakistan
2University Institute ofl1iformation Technology, University ofArid Agriculture, Rawalpindi Pakistan
Imimranbabar@yahoo.com,
Abstract-The right requirements are considered as a part
and parcel of software quality. Since the emergence of
software engineering the perfect requirements have a deeper
effect on the overaU quality of software systems. This
research paper is focusing on the shortcomings
limitations of existing software requirements prioritization
techniques and paves the way for researchers to explore new
horizons in software requirements prioritization. Most of
the techniques are solving the plight of smaU projects or toy
applications. There is not a single evidence of a successful
prioritization technique that would solve the problem of
large set of requirements. The innovative requirements
prioritization approaches are required for systems where
user requirements increase in hundreds
thousands. The existing techniques are
sufficient automation for such systems due to their certain
limitations.
Keywords- Software Requirements,
Prioritization Techniques, Challenges, Shortcomings.
I. INTRODUCTION
The software business community is fully involved in
innovative development due to the rapid increase in the
usage of software applications. The very existence of
innovation induces the factor of complexity in designing
such systems effectively. The complexity comprises in
terms of the lack of clear objectives or user requirements.
The clear objectives or requirements have a deeper effect
on the design of the system. It becomes hard to develop
such systems or products if the objectives are not clear.
Such complexities can be controlled by giving due
consideration to the user or stakeholders' requirements. A
set of user requirements is selected on the basis of
importance of the requirements with the help of a
requirements prioritization method. The requirements
prioritization plays a vital role in decision making [3] and
eliminates the complexities caused
requirements or objectives. Requirements prioritization is
a complex decision making process [7, 14, 23, 37], so in
order to implement a prioritization technique there is the
need of professional skills and sound domain knowledge
[20].
In requirements prioritization we have to find out the
important needs of the users for the system under
development [35, 36]. The very purpose of software
requirements prioritization is to find
requirements that can be implemented under constraints
of cost, quality, resources and time which ultimately
978-1-61284-941-6/11/$26.00 ©2011 IEEE
'shahbaz.ahmed@iiu.edu.pk, 2ramzan@uaar.edu.pk
result in customer satisfaction [1, 18, 4, 41, 42]. The
requirements prioritization is not only required to find out
least important requirements but also helps to resolve the
conflicts between requirements and helps in future
or
planning [41]. The selection of right requirements, from
a given set of requirements, is a sort of challenge. The
right selection of requirements will help in fulfilment of
all intersests and preferences of stakeholders under
defined technical constraints and this will enhance
business value [31]. So the overall quality of a system
depends upon the right selection of the customer's needs
or requirements. If the set of selected requirements would
and even in
not be right then the cost of the rectification would
not providing
increase at latter stages [6] and the quality of the product
will also suffer.
The requirements prioritization is also important for
Prioritization, gaining market leverage or for proper understanding of
the market gain and loss [3]. The overall quality of a
software system is taken into account when a system
satisfies its users and customers in terms of their
requirements [5, 12]. Due to certain constraints like
limited resources, time to market and limited budget
faced by the software industry it is not possible to
consider a complete set of user requirements in a single
release so only a small set of requirements is taken into
account for a single release [16, 17]. There are different
aspects of software requirements like importance [23,
24], cost, penalty, time [40] volatility [37], risk [3, 37, 40,
4] and dependencies with other requirements on the basis
of customers, cost, technical value and requirement
change [8, 34]. On the basis of these aspects the
requirements are prioritized and trivial requirements are
rejected initially and only value added requirements are
considered. The business value can only be created when
the right requirements will be selected and the right
by unclear selection of requirements will create the value in terms of
profit [35, 36]. In software industries different techniques
are in pracitce for the selection of right requirements due
to lack of a mature requirements prioritization process
[3]. So a mix up of the techniques is adopted in the
industry depending upon the aspects like time, cost,
importance, etc., and it results in the conflicts because
one aspect is directly affecting the other. For example
requirements prioritization on the basis of cost may
out the core change the priority of the requirements. If a requirement
is highly costly but more important then the customer can
change its view due to high cost so the requirement's
319
priority will change from high to low [5]. The role of
stakeholders also depends upon the aspects or attributes
of the requirements during requirements prioritization
process. This is the glaring problem
stakeholders define the phrase requirements prioritization
differently [11].
Rest of the paper is comprised of five sections. In
Section II there is a description of different proposed
Software Requirements Prioritization Techniques with
respect to their importance. Section III is comprised of
limitations and drawbacks of existing
Requirements Prioritization Techniques. Section N is
describing the future and current trends about Software
Requirements Prioritization Techniques with respect to
automation. Section V and VI are comprised of proposed
solution to solve the issues of performance and scalability
of requirements prioritization and
respectively.
II. PRIORITIZAITON TE CHNIQUES
Researchers have developed different
prioritization techniques for right selection
requirements. The techniques are Analytical Hierarchical
Process (AHP), Hierarchy AHP, Ranking, Cumulative
Voting or Hundred Dollar Test, Top Ten Requirements,
Binary Search Tree, Numerical Assignment, and many
other new techniques are presented recently. Different
methods or ways are used to prioritize the requirements
for example stakeholders have to prioritize requirements
on the basis of factors like which
mandatory, desirable or essential one
requirements are not in the specific domain [8]. While
some have adopted quantitative ranking
requirements prioritization. Kent Beck presented the
planning game method to prioritize the requirements in
extreme programming [5]. Wiegers presented a technique
in which quantitative ranking from 1-9 was used and for
ranking the factors like cost, risk and importance were
taken into account [40]. According to Laurent et al.
though the implementation of these techniques is simple
but they do not support, negotiations and higher level
goals, strongly. These techniques are also not providing a
scalable solution in order to manage the large scale
requirements in complex and large projects [23].
In the presence of all these approaches
requirements prioritization process is not mature. Most of
the companies are unaware about the
methods and their managers don't know that how to
assign priorities to requirements [27]. Karlsson is of the
view that there is a rapid development in requirement
engineering but still the industry leaders are in shortage
of effective requirements prioritization approaches [18].
III. CHALLENGES
Different researchers have evaluated the results of
different prioritization approaches and then on the basis
of these results they have presented new techniques.
Karlsson et al. have conducted a research in which they
have evaluated different techniques [21] and recorded the
results of different techniques.
Karlsson et al. applied the different prioritization
methods in order ''to prioritize 13 well-defined quality
requirements on a small telephony system" [21]. The
that different results provided by most of the techniques, except AHP
and Bubblesort, are unreliable and prone to errors while
on the other hand AHP and Bubblesort are more reliable
but time consuming due to the decisions which one must
have to consider during requirements prioritization
methods [21]. Though AHP is a reliable technique for
requirements prioritization but the technique is complex
Software to implement and more time consuming due to pair
comparisons. The Hierarchy AHP is complex to
implement and also prone to errors so the results given by
Hierarchy AHP are not reliable [21]. The Spanning Tree
technique is also prone to faults and is unreliable. The
prioritization techniques of Binary Search and Priority
conclusion Groups are also unreliable because of faulty results. The
role of consistency index is very important because it
helps to reduce the human error so the results provided by
Bubblesort may be faulty and unreliable [18]. All the
requirements techniques are applied to only few requirements so AHP
of user and Bubblesort though efficient but are considered as
problematic when the requirements are going to scale up
[21]. Laurent et al. have said "AHP does not scale well
because the number of comparisons grows exponentially
with the number of requirements" [22]. All these
tehcniques works well for small or medium size projects
but they are not suitable for projects with large scale of
requirements [22]. It is found that AHP is not suitable
requirement is when the requirements exceed the limit of 20 because
and which when the number of comparisons grows so it becomes
difficult to manage the requirements [24].
system for Laurent et al. have presented a technique called
"Requirements Triage" which is also prone to errors and
the results don't recall [22]. Peng Shoo also proposed an
algorithm for requirements prioritization and this
algorithm or ''technique allows customers to rank a
relatively small set of items then combines these rankings
over a large number of customers to determine an
ordering for a large requirement set" [31]. The proposed
algorithm is just simulated and not implemented in the
real environment. The simulation is performed on small
number (ten) of customers on ten items [31]. Most of the
researchers have tried to present the extensions of AHP
still the which are focusing the scalability issue but still there is
no evidence of any experiment that is performed on
prioritization projects consisting of hundreds and even thousands of
requirements [11]. Most of the experiments are performed
on only few requirements. The "Requirements
Prioritization Model" for market driven products [26] is
an extension of AHP and is proposed to solve the issue of
scalability. The model is implemented on companies A
and B but there is no data evidence or statistics for the
experimentation which is performed and most of the
results are just opinions. The technique or model is
actually focusing the issue of scalability (large scale
requirements) but the proposed model is not for each and
every organization [26] and also not telling the focused
domain. Further there is no evidence that to which extent
the proposed model is solving the issue of scalability. In a
320
value based Fuzzy Logic prioritization technique [27] the paper for requirements prioritization is AHP about which
authors have proposed an Intelligent Fuzzy Logic based we have found in the literature that the technique is suitable
technique for requirements prioritization based on the only for limited or small set of requirements and the
perceived value of each requirement. But the results after techinque is focusing on minimization of the overall
sufficient experimentation are documented as: "The transportation cost [28]. Presently people are busy to
process is prone to error due to its heavy reliance on evaluate AHP on small projects and are busy in removing
experts. The process is very time consuming. The element the limitations of AHP instead of proposing new
of bias was visible in some of the experiments techniques that may prove more fruitful for projects with
conducted" [27]. hundreds of requirements. In another research [2] a
However later on an improved version of the technique prioritization technique is presented which is for legal
called VIRP is presented comprising of three stages or requirements. It is stated that the "Laws and regulations
levels i.e. "Requirement Elicitation and Stakeholder can make requirements prioritization particularly
Level Prioritization", the "Expert Level Prioritization" challenging due to the high costs of noncompliance and the
and the last or third stage is "Fuzzy Logic Based substantial amount of domain knowledge needed to make
Requirement Prioritization"[45]. The first and the last prioritization decisions" [2]. The very technique proposed
steps of the technique are automated and the last step is by Aaron K. Massey et al. is focusing the legal
als made intelligent andfree of biasness using Fuzzy implications of requirements in the domain of healthcare.
Logic but the second step "Expert Level Prioritization" is The major focus of this technique is HIPPA (Health
not automated and intelligent one which consumes too Insurance Portability and Accountability Act) which
much time and reduces the efficiency of the technique so regulates the Electronic Health Records (EHRs). The
there is the need to propose improvements in the second technique is focusing the domain of Healthcare systems
step, in terms of automation and intelligence, which is and it's not suitable for all projects.
heavily based on experts. There is the need to remove the The literature shows that most of the techniques which
role of experts or software engineers in order to make the are proposed are only suitable for few requirements and
technique more efficient with respect to time. Different not suitable when the requirements scaled up in case of
experiments were performed about the performance of large number of requirements for large projects.
different prioritization techniques in order to evaluate the According to the literature evidences the problems with
total time consumed by all techniques including VIRP. the existing requirements prioritization techniques can be
The comparison of time consumption of different summarized as:
prioritization techniques during experimentation 1. The existing techniques don't provide a scalable
including VIRP is given in the Figure 1[45] as: solution when the requirements scaled up in case
of large number of requirements.
2. Most of the techniques are time consuming.
Average Time Consumed (Work
3. The results are faulty or error prone.
hours) 4. Results don't recall.
180 5. Mostly solve the issues of small scale
160
.... 140
requirements or toy projects but with errors.
! ��g
80

� :g We are focusing in our research the issues of

20
o scalability and time. There is the need to provide a
... � �
...$- Co � i;>� .....<>6':� <I. .;:. "'� -s-<{3 requirements' prioritization which would help in
.. �
....oQ c;
4�
prioritization of large scale requirements in an efficient
way.
Fig. 1 Average Time Consumed by Prioritiztion Techniques
IV. FUTURE TRENDS
Though the technique is very effective but with the Laurent et al. have described the problems related to
automation of "Expert Level Prioritization" the technique software requirements prioritization and according to
would become more efficient. them "Lack of an effective prioritization and triage
In the research [15] an approach is presented to elicit process can lead to problems such as missed deadlines,
software requirements and its prioritization using AHP. In disorganized development efforts, and late discovery of
this approach mini software is developed and not a large architecturally significant requirements. Existing
scale project is developed as quoted in this research paper prioritization techniques do not provide sufficient
"From this approach we can easily rank the requirements automation for large projects with hundreds of
and can implement it on the basis of the ranking. In this stakeholders and thousands of potentially conflicting
paper we have developed the Mini Software for Numerical requests and requirements" [23]. Most of the software
Integration (MSNI)" [15]. The technique presented by systems fail or end up because of irrelevant requirements
Muhammad Sadiq at el. is used to improve the and they don't fulfill the original requirements so it
effectiveness and efficiency of the freight transportation resulted in their rejection at early stages [11]. It's also
between source and destination using optimization essential to choose a best suit of requirements, when
algorithm. The basic technique which is adopted in the resources are limited, in order to get best outcome in

321
terms of customer satisfaction within the specified budget software engineers and the involvement of experts is the
[17]. cause of biasness in this stage. The second step "Expert
The above statements provide the motivation for future Level Prioritization" is the cause of too much time
research. As for projects where requirements scale up in consumption because of experts' opinions so there is the
hundreds or even in thousands there is a problem of "late need to remove the role of experts or software engineers
discovery of architecturally significant requirements" in order to make the technique more efficient with respect
[23]. So due to "infinite range of candidate requirements" to time. The involvement of experts can be eliminated by
[17] "many software systems end up being developed making "Expert Level Prioritization" or Level 2 more
without meeting their requirements and thus cannot be intelligent. The flow graph of the technique with
used as initially expected" [11]. To solve this problem proposed extension is shown in figure2:
there is the need to prioritize the requirements in a new
and innovative way. In literature survey we have found

}
that the "Existing prioritization techniques do not provide
sufficient automation for large projects with hundreds of
Lm))
stakeholders and thousands of potentially conflicting

---' }
requests and requirements" [23]. There is the need to
automate the existing techniques in order to utilize them
fully for better results.
.--- -: _________ Len)l

V. PROPOSED SOLUTION
Most of the techniques are prone to errors so the results
�eural :'\etwork Based
Expel1 Prioritization
fol' RY Calculation
} Lm)3

are unreliable. There is not the evidence of a single using Ref

requirements prioritization technique that would help in

solving the plight of projects where requirements grow in
hundreds or even in thousands. There is not a single
evidence of an efficient and cost effective prioritization Fig. 2 Flow graph of the Fuzzy Based Intelligent Requirements
technique to prioritize requirements in an environment Prioritization Process with proposed extension work with respect to
Neural Networks.
where requirement dataset is medium / large and
volatility is high.
In this research we will apply Artificial Intelligence
There is the need to prioritize the significant functional
(Neural Networks) in order to make the system more
requirements inline with business compliance. Most of
intelligent and it would help in the elimination of the role
the techniques which are proposed are not providing
of experts at second level of VIRP i.e. the "Expert Level
sufficient automation and are not intelligent due to which
Prioritization" [45]. The elimination of the role of experts
the element of biasness is evident in most of the
or software engineers, using Neural Network, will help in
techniques. Here we are going to propose an extension in
elimination of bias also which may affect the
"Value based Intelligent Requirement Prioritization
performance introduced because of the heavy reliance of
(VIRP): Expert Driven Fuzzy Logic based Prioritization
technique on experts. In our porposed solution we are
Technique" [45]. The proposed extension will make the
going to automate the technique along with addition of
technique more efficient. The said technique is comprised
heuristics using Neural Network. In the first step of our
of three steps i.e. "Requirement Elicitation and
research we are desinging a Neural Network which will
Stakeholder Level Prioritization", "Expert Level
calculate the RV using values of pRCF and rRCF
Prioritization" and "Fuzzy Logic Based Requirement
obtained during first stage of VIRP. Then we will
Prioritization" [45]. The first and last steps of the
simulate the Neural Network using Matlab or some other
technique are automated and the last step of the technique
tool. In the last step after automation we will calculate the
is also made intelligent and free of biasness using Fuzzy
cost of the VIRP technique in terms of effort or time
Logic but the second step "Expert Level Prioritization" is
consumed and the comparison will be made using the
not automated and intelligent one which consumes too
evaluation data available in [45] as shown in
much time and is a manual process for calculation of
Figl(Average Time Consumed by Prioritization
Requirement Value or RV. Following formula is used to
Techniques). After making a comparison of VIRP with
calculate RV manually:
5 5 the previous data the new cost, efficiency and reliability
RV = 0.35 + 0.02{L pRCE; + L,:RCE;} of VIRP will be calculated.
;=1 ;=1

The manual calculation of RV results in intorduction of VI. CONCLUSTION

biasness and errors expecially when the requirements are From literature it is evident that to prioritize software
in hundreds or even in thousands. It's also a very time requirements specifications is not an easy task rather it's
consuming process to calculate and manage the RV of a more complex and brainstorming job. It's not easy to
thousands of requirements manually espeically in large find out the value of a requirement in its true spirit
and complex projects. So there is the need to propose because of the readily changeable nature of the
improvements in the second step, in terms of automation requirements. At this stage we have proposed an
and intelligence, which is heavily based on experts or extension in VIRP model for requirements prioritization

322
in order to overcome the shortcomings of existing
software requirements prioritization techniques. Currently
we are working on the proposed extension which will
result in better understanding and translation of
significant requirements and there would be less chances
of error. The VIRP technique will become more time
efficient, scalable and its overall performance will also
increase as compared to the other techniques.
ACKNOWLEDGEMENT
I am thankful to International Islamic University
Islamabad Pakistan and Higher Education Commission of
Pakistan (HEC) for providing resourcees in order to
conduct this research. I am also thankful to my teachers
Mr. Shahbaz A.K. Ghayyur and Mr. Muhammad Ramzan
who proved as a helping hand in this research.
REFERENCES
[1] Abran, A, Moore, J., Dupuis, R 2001. SWEBOK Guide to the
Software Engineering Body of Knowledge, IEEE.Ding, W. and
Marchionini, G. 1997. A Study on Video Browsing Strategies.
Technical Report. University of Maryland at College Park
[2] Aaron, K. , Massey, Paul N. , Otto, Annie I. A 2010. "Prioritizing
Legal Requirements". 2009 Second International Workshop on
Requirements Engineering and Law (relaw'09). IEEE
[3] Aurum, A, Wohlin, C. 2003. "The Fundamental Nature of
Requirements Engineering Activities as a Decision-Making
Process", Information and Software Technology, 45(14), pp. 945-
954.
[4] Barney, S. , Aurum, A, Wohlin, C. 200S. "A product management
challenge: Creating software product value through requirements
selection". Journal of Systems Architecture 54, pp. 576-593
[5] Beck, K. 2000. Extreme programming explained. Reading, MA:
Addison-Wesley.
[6] Bergman, B., KlefsjO, B. 2003. Quality from Customer Needs to
Customer Satisfaction, Student literature AB, Lund, Sweden
[7] Boehm, B, W. 19S1. "Software Engineering Economics", Prentice
Hall, Englewood Cliffs, NJ.
[S] Brackett, J. W. (1990). Software requirements. Technical Report
SEI-CM-19-1.2, Software Engineering Institute, Carnegie Mellon
Uni versi ty, USA
[9] Carlshamre, P. 2002. "Release Plmming in Market-driven Software
Product Development - Provoking an Understanding". Requirements
Engineering Jowna17 (31 pp. 139-151
[10] Dahlstedt, A, Persson, A 2003. "Requirements Interdependencies
- Moulding the State of Research into a Research Agenda",
Proceedings of the Ninth International Workshop on Requirements
Engineering: Foundation for Software Quality (REFSQ '03), pp.
71-S0.
[11] Davis, A M. 1993. "Software Requirements, Objects, Functions
and States. " Prentice-Hall International, Inc., Englewood Cliffs,
New Jersey.
[12] Ecklund, E. F. , Delcambre, L. M. L. , Freiling, M. J. 1996.
"Change Cases: Use Cases that IdentifY Future Requirements".
Proceedings of the 11 th ACM SIGPLAN Conference on Object­
Oriented Programming, Systems, Languages, and Applications
(OOPSLA '96), pp. 342-35S.
[13] Firesmith, D. 2004. "Prioritizing Requirements", Journal of Object
Technology, Vol. 3, No. S, September-October 2004
[14] Hatton, S. 2007. "Early prioritization of goals". In Advances in
conceptual modeling - Foundations and applications (pp. 235-
244).
[15] Iqbal, M. A, Zaidi, A M., Dr. Murtaza, S. 2010. "A New
Requirements Prioritization Model for Market Driven Products
Using AHP". International Conference on Data Storage and Data
Engineering. IEEE.
[16] Karlsson, J. 1996, "Software Requirements Prioritizing". In:
Proceedings of the 2nd IEEE International Conference on
Requirements Engineering (ICREI996), Colorado, USA, pp. 110-116
[17] Karlsson, J. , Ryan, K. 1996. "Supporting the Selection of Software
Requirements". In: Proceedings of IWSSI).S. IEEE.
323
[IS] Karlsson, J. , Ryan, K. 1997. "A Cost-Value Approach for
Prioritizing Requirements", IEEE Software, 14(5), pp. 67-74.
[19] Karlsson, J. , Olsson, S. , Ryan, K. 1997. "Improved Practical
Support for Large-Scale Requirements Prioritizing", Requirements
Engineering, 2(1), pp. 51-60.
[20] Karl !OOll, J. 1995. "A Systematic Approach for Prioritizing Software
Requirements", Linkoping Studies in Science and Technology, Doctoral
Dissertation No. 526, Department of Computer and Infonmtion Science,
Linkoping Institlte of Technology, Linkoping, Sweden
[21] Karlsson, L. , Regnell, B., Wohlin, C. 1995. "An Evaluation of
Methods for Prioritizing Software Requirements. " Information and
Software Technology 39, pp 939-947.
[22] Karlsson, L. , Berander, P. , Regnell, B. , Wohlin, C. 2004.
"Requirements Prioritization: An Experiment on Exhaustive Pair­
Wise Comparisons versus Planning Game Partitioning". In:
Proceedings of Empirical Assessment in Software Engineering
(EASE2004), Edinburgh, Scotland.
[23] Laurent, P. , Cleland-Huang, J. , Duan, C. 2007. "Towards
Automated Requirements Triage". 15th IEEE International
Requirements Engineering Conference
[24] Lausen, S. 2002. Software Requirements - Styles and Techniques,
Pearson Education, London, UK.
[25] Lehtola, L., Kauppinen, M. , Kujala, S. 2004. "Requirements
Prioritization Challenges in Practice". Proceedings of 5th International
Conference on Product Focused Software Process Improvement,
Kansai Science City, Japan, pp. 497-50S
[26] Lehtola L, Kauppinen M. 2004. "Empirical evaluation of two
requirements prioritization methods in product development
projects". In: Proceedings of the European Software Process
Improvement Conference (EuroSPI 2004), Springer-Verlag, Berlin
Heidelberg, pp.161-170
[27] Lubars, M. , Potts, C. , Richter, C. 1993. "A review of the state of
the practice in requirements modeling". Proceedings of IEEE
Symposium on Requirements Engineering (RE'93), IEEE
Computer Society Press.
[2S] Maciaszek, L, A 2001. "Requirements Analysis and System
Design-Developing Information Systems with VML", Addison
Wesley, London, UK.'
[29] Moisiadis, F. 2002. "The Fundamentals of Prioritizing
Requirements". Proceedings of Systems EngineeringlTest and
Evaluation Conference (SETE2002).
[30] Patrik, B., Per, J. "Hierarchical Cumulative Voting (HCV)­
Prioritization of Requirements in Hierarchies," International
Journal of Software Engineering and Knowledge Engineering.
[31] Peng, S. 200S. "Sample Selection: An Algorithm for
Requirements Prioritization". ACM.
[32] Qiao, M. 2009. "The Effectiveness of Requirements Prioritization
Techniques for a Medium to Large Number of Requirements: A
Systematic Literature Review". A Dissertation Submitted to
Auckland University of Technology
[33] Ramzan, M. , Arfan, J. M. , AlIliad, I. M. , Anwar, S, Arshad, A
Shahid. 2009. "Value Based Fuzzy Requirement Prioritization and
its Evaluation Framework". 2009 Fourth International Conference
on Innovative Computing, Information and Control. IEEE.
[34] Ruhe, G. , Eberlein, A, Pfahl, D. 2002. 'Quantitative WinWin - A
New Method for Decision Support in Requirements Negotiation',
Proceedings of the 14th International Conference on Software
Engineering and Knowledge Engineering (SEKE'02), pp. 159-166.
[35] Ruhe, G. 2003. "Software Engineering Decision Support - A New
Paradigm for Learning Software Organizations", Advances in
Learning Software Organization, Lecture Notes In Computer
Science Vol. 2640, Springer-Verlag, pp. 104-115.
[36] Ruhe, G. , Eberlein, A, Pfahl, D. 2003. "Trade-off Analysis for
Requirements Selection", International Journal of Software
Engineering and Knowledge Engineering, 13(4), pp. 345-366.
[37] Sadiq, M. , Shahid, M. 2009. "Elicitation and Prioritization of
Software Requirements". International Journal of Recent Trends in
Engineering, Vol 2, No. 3, November 2009.
[3S] Sadiq, M. , Ahmed, J. , Asim, M. , Qureshi, A, Suman, R 2010.
"More on Elicitation of Software Requirements and Prioritization
using AHP". 2010 International Conference on Data Storage and
Data Engineering. IEEE.
[39] Schulmeyer, G. G.. , McManus, J. I. 1999. "Handbook of Software
Quality Assurance", 3rd Edition, (Prentice Hall, Upper Saddle River,
NJ).
 [40] Sommerville, I. 1996. "Software Engineering". 5th ed. Addison­
Wesley, Wokingham, England.
[41] Sommerville, I., Sawyer, P. 1997. "Requirements Engineering
- A Good Practice Guide", John Wiley and Sons, Chichester,
UK.
[42] Wiegers, K. 1999. Software Requirements, Microsoft Press,
Redmond, WA
[43] Wiegers, K. 1999. First Things First: Prioritizing Requirements,
Software Development.
324
View publication stats
[44] Yeh, A, C. 1992. REQUirements Engineering Support Technique
(REQUEST) - A Market Driven Requirements Management
Process, Proceedings of Second Symposium of Quality Software
Development Tools, 211-223.
[45] M. Ramzan, M. Arfan JaiTar, Arshad A Shahid. (2011): "Value
based Intelligent Requirement Prioritization (VlRP): Expert
Driven Fuzzy Logic based Prioritization Technique", International
Journal of Innovative Computing, Information and Control
(IJICIC).