0% found this document useful (0 votes)
49 views6 pages

Agriculture 1

The document discusses techniques for prioritizing software requirements including analytical hierarchy process, cost-value approach, planning game technique, 100-point method, ranking method, binary search tree technique, and borda count technique. It analyzes the strengths and limitations of each technique and proposes a framework to help software engineers perform prioritization by combining existing techniques and approaches.

Uploaded by

iamadnan
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
49 views6 pages

Agriculture 1

The document discusses techniques for prioritizing software requirements including analytical hierarchy process, cost-value approach, planning game technique, 100-point method, ranking method, binary search tree technique, and borda count technique. It analyzes the strengths and limitations of each technique and proposes a framework to help software engineers perform prioritization by combining existing techniques and approaches.

Uploaded by

iamadnan
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Analysis and optimization of software

requirements prioritization techniques


Muhammad Aasem1, Muhammad Ramzan1, Arfan Jaffar2
1
University Institute of Information Technology, Arid Agriculture University Rawalpindi, Pakistan
[email protected], [email protected]
2
National University of Computer and Emerging Sciences Islamabad, Pakistan
[email protected]

Abstract— Prioritizing requirements helps the project team would be possible to arrange them in ascending and
to understand which requirements are most important and descending orders.
most urgent. Based on this finding a software engineer can
decide what to develop/implement in the first release and A systematic approach of prioritization takes some
what on the coming releases. Prioritization is also a useful parameters which are also called key factors or aspects of
activity for decision making in other phases of software prioritization process. Some common aspects like
engineering like development, testing, and implementation. importance, penalty, cost, time, risk, volatility and other
There are a number of techniques available to prioritize the aspects have been discussed in [20] along with their
requirements with their associated strengths and limitations. combination. The detail discussion is out of the scope of
In this paper we will examine state of the art techniques and this paper. Similarly, a discussion on stakeholder can also
analyze their applicability on software requirements domain. be found in [5, 20] regarding prioritization process.
At the end we present a framework that will help the
software engineer of how to perform prioritization process Next section presents an overview of main
by combining existing techniques and approaches. prioritization techniques with their strengths and
limitation. In section III, we summarized these techniques
Keywords- Requirements Engineering, Prioritization and discussed our findings. Based on these findings, we
Framework propose a framework and explain its methodology. Finally,
we conclude our work and set future directions.
I. INTRODUCTION
The goal of prioritization is to support decision making II. LITRATURE REVIEW
process, which has always been a key topic of many There are a number of prioritization techniques that can
subject ranges from economics, military, politics, be applied to software requirements to calculate priority
administration to daily life’s simple activities. Regarding values of each candidate requirement. Each of these
software engineering, prioritization is used in almost every techniques uses a measurement scale to present the output.
phase its life cycle i.e., selecting a project, finalizing the
requirements, designing and developing of modules, Before taking an overview of these techniques lets first
testing, implementation, and even in post implementation examine level of measurements or scales, because each
activities. But unfortunately it becomes more difficult as technique is based on one of them. Table 1 presents a
the subject expands its base criteria. In its simplest form, summary of the scales [7]. It is claimed that all
there comes no need for prioritizing objects if there is only measurement in science can be classified in one of the four
one of it. But with just a couple alternatives, it becomes types i.e., "nominal", "ordinal", "interval" and "ratio”. The
difficult to make a decision based on more than one suggested level of measurement also implies a hierarchy.
criterion. In case of having tens, hundreds or even Assumptions are less restrictive and data analyses rend to
thousands of alternatives, decision-making becomes much be less sensitive. At each level up in the hierarchy, the
more difficult and complex. A number of prioritization current level includes all the qualities of the lowers and
techniques are available in order to deal with different adds something more. Therefore, it is desirable to have a
level of complexity. These techniques are in used in higher level of measurement (e.g., interval or ratio) rather
different domains for supporting decision making. than a lower one (nominal or ordinal).

In this paper, we will examine these techniques and


evaluate their applicability in requirement engineering with
the aim of classifying most important requirements. We
assume that requirements have been captured and finalized
properly such that one can see them as a list of objects.
These objects (requirements) can also hold their values
(with will be assigned to each of them using a
prioritization technique) of any type e.g., integers, floating
values or alpha-numeric values. Based on these values it

978-1-4244-8003-6/10/$26.00 ©2010 IEEE


Table 1. The measurement scales for classification
Scale Permissible Statistics Admissible Scale Mathematical Offers Example
Type Transformation structure
nominal mode, chi square One to One standard set names or labels for certain rocks can be generally
(equality (=)) structure characteristics. categorized as igneous,
(unordered) sedimentary and metamorphic

ordinal median, percentile Monotonic totally ordered Ranking horse race ranking like 1st, 2nd,
increasing set 3rd etc
(order (<))
interval mean, standard deviation, Positive linear affine line interval scale measurement temperature with the Celsius
correlation, regression, (affine) scale
analysis of variance
ratio All statistics permitted for Positive field Estimation of the ratio between a Weight , Mass, length, time,
interval scales as well as similarities magnitude of a continuous quantity plane angle, energy and electric
geometric mean, harmonic (multiplication) and a unit magnitude of the same charge
mean, coefficient of kind .also possesses meaning for
variation, logarithms non-arbitrary zero.

sophistications, but regarding granularity it is a fine


approach.
A. Analytical Hierarchy Process
The Analytic Hierarchy Process (AHP) is a statistical B. Cost-Value Approach
technique proposed by Thomas Saaty [4] for multicriteria
This approach was created by Joachim Karlsson and
complex decision making problems. It can be used to
Kevin Ryan [3] to guides decision makers about how to
prioritize requirements on the basis of different aspects
prioritize the requirements based on their relationships of
[20], like importance, penalty, cost, time, and risk. In this
value to cost of implementation [9]. Users or customers are
approach, the candidate requirements are compared in
interested in 'value' parameter which is the benefit that is
pair-wise fashion to determine the extent of how one of the
supposed to be gained from the candidate requirements.
requirements is more important than the other requirement.
'Cost' on the other hand is the cost of implementation
The intensity of importance should be according to Table
regarding money and time. In order to investigate
2. In this approach, the candidate requirements are
candidate requirements, this approach uses AHP technique
compared in pair-wise fashion to determine the extent of
to calculate a value-cost ratio and presents the result in a
how one of the requirements is more important than the
graph as input to release decision [30]. In simple terms, it
other requirement [14]. For n number of requirements,
can base said that this approach is based on AHP and its
AHP makes n x (n-1) / 2 comparisons at each hierarchy
two dimensional values provide an easy mean to plot them
level. The computation of these comparisons become
on cost-value graph but takes no account of
extensive when the number of candidate requirements
interdependencies between requirement.
increases.
The areas where AHP has been successfully C. B-Tree Prioritize
implemented [6] include: selection of one alternative from In a performance comparison, D. A. Heger [12] has
many; resource allocation; forecasting; total quality shown that approaches based on B-Tree have the smallest
management; business process re-engineering; quality amount of performance fluctuations. Therefore, it can be
function deployment, and the balanced scorecard. concluded that a prioritization technique based on B-Tree
Table 2. Basic scale for pair-wise comparisons in AHP approach would be a systematic way in which the number
Importance Description of comparison required by can be kept low. The B-Tree
1 Equal importance prioritization technique proposed in [2] is capable of
3 Moderate difference in importance incorporating the dynamics of the requirements as these
5 Essential difference in importance never freeze, they keep-up coming and few of them are
7 Major difference in importance dropped too. Regarding prioritization, binary tree
9 Extreme difference in importance
algorithm has a function f that maps the requirements
according to its priority value from set of all candidate
2,4,6,8 Intermediate values between
requirements in the set already prioritized requirements. It
Reciprocals If requirement i has one of the above numbers
provides the run time capability i.e., if you have few
assigned to it when compared with
hundreds of requirements and you don't want to wait until
requirement j, then j has the reciprocal value
all are finalized, still, you can start to prioritize them and
when compared with i.
add or delete later if required. It also gives the control to
keep the number of comparison fixed for prioritizing a
AHP is fault-tolerant method and includes a requirement if the total number of requirements is known
consistency check [11] as well as the resulting priorities in advance. Moreover, the result of this technique is more
are relative and based on a ration scale, which allows presentable then other techniques, even if they are not
useful assessment of requirements. When both quantitative finalized yet. But the basic idea of this technique tends
and qualitative aspects of a decision (based on more toward presentation of result rather than
prioritization) are needed [5], AHP provides a powerful prioritization mechanics.
and flexible means in this regard. The comparison table
shows that AHP is very complex in terms of
method, requirements are ranked on an ordinal scale
[11]. The process starts with classification of all
requirements into different groups and given to each
stakeholder. Each stakeholder assign a number to
each requirement in each group on a scale of 1 to 5
based on his/her perception. The final priorities are
determined by calculating average of all the ranking
given to all requirements by the stakeholders.
It is easy for stakeholders to classify their
requirements in fewer groups. The number of groups
can be increased or decreased according to the
parameters. Despite its wide applicability, this
technique also poses several problems. Clear
definition of the groups is a major issue. From most of
the stakeholders view point, most of the requirements
B-Tree Prioritize 100-Dolars test Numerical Assessments are "critical" and so that they might put majority of
the requirements to be implemented [14], which may
lose the objective of prioritization. Once the result is
obtained from this method we could see all
requirements in three groups; labeled critical,
standard, optional. Each group may contain different
numbers of requirements which will be the
requirements in each group have the same priority
Ranking Top 10 Requirements Planning Game
that means that each requirement does not get a
unique priority [27].

F. Ranking
Ranking is based on an ordinal scale but the
requirements are ranked without ties in rank [27].
Using this technique, the most important requirement
is ranked as 1 and the least important requirement is
Theory W: ranked as n (for n requirements). In order to obtain
the ranks of the requirements, different algorithms
like bubble sort, binary search tree, Quick sort and
Figure 2. Prioritization Techniques other sorting techniques may be used. [5]. However,
in ranking, multiple aspects can be combined by taking the
mean priority of each requirement. This might result in ties
in the requirements that this method wants to avoid [20].
D. Commulative Voting, The $100 test This technique is Medium in granularity and easy in terms
Hundred-Dollar Test is rather subjective method of sophistication [5] and more suitable candidate when the
proposed by Leffingwell and Widrig. Basically, this priorities of a single stakeholder have to be prioritized.
technique is used in brainstorming exercise. In this
approach [26], each of the stakeholders spends money out G. Top Ten Requirements
of $100 to “invest” in purchasing requirements. Once each In this approach, the stakeholders are asked to choose
participant has taken down their points, then next step is of their top-ten requirements from all specified (candidate)
totaling. The written values are connected and list that on requirements. Doing so, they are not bound to assign an
a chart. The requirement that has got the highest score is internal order between the chosen requirements. The
the most important requirement. reason to not prioritize further is that it might create
This is a simple technique that can be easily understood unnecessary conflict when some stakeholders get support
and applied by stakeholders but with greater numbers of for their top priority and others only for their third priority.
requirements it becomes difficult for them to deal with this [27]. It is very easy technique in terms of sophistication as
method. Moreover, this technique is useful when well as useful in the situation of multiple stakeholders with
requirements require human judgment because it is hard to same and equal importance, however, it is extremely
describe quantitatively. In this case, it is heavily based on coarse in terms of granularity [5]. This technique can be
experienced stakeholders whose availability is also an used in conjunction with other techniques to achieve better
issue. results.

E. Numerical Assisments (Grouping) H. Planning Game


This method is also suggested [20] in RFC 2119 and In Planning Game, requirements are prioritized in
IEEE Std. 830-1998. It is based on ordinal scale so that consultation with customers. Customers divide their
requirements are grouped together in different groups, requirements to be done into a set of stories, each of which
which the stakeholders can relate to for trustworthy can be written on some cards card in a few sentences.
classification. Mostly three groups are used namely
critical, standard and optional [5]. In numerical assessment
Table 3 Comparison of Techniques
Technique Scale Granularity Sophistication Aspect [20] Perspective[20] Type
AHP Ratio Fine Very Complex Strategic Importance, Product Manager Algorithmic
Penalty
B-Tree -- Fine Complex - - Algorithmic
100-Dollars Test Ratio Fine Complex Customer importance Customers Manual

Ranking Ordinal Medium Easy Volatility Requirements Specialist Manual

Numerical Ordinal Coarse Very Easy Time, Project Manager, Manual


Assignment Risk Requirements Specialist
Top 10 --- Extremely Extremely Easy Customer importance Customers
Coarse

The experts then estimate how much effort is required to ranking in combined form i.e., first divide the requirements
build each story. The customer then chooses which stories into priority groups (numerical assignment) and then rank
should be built in the next cycle, based on the time them within each group [22]. Based on these observations,
available and the estimates from the experts [28]. we found that an easier or more efficient technique can be
developed if we combine some existing techniques.
It is a variation of numerical assignment technique and
very suitable to extreme programming. However it offers Based on these findings, in the next section we present
more flexibility than numerical assignment where users are our propose model that will be analyzed against its
asked to essentially divide the requirements into three established objectives.
groups
IV. THE PROPOSED FRAMEWORK
I. Theory W
We presented an overview of some most common
Theory W is also known as Win-Win model [29] is prioritization techniques and approaches in section II.
based on negotiation to resolve any differences of opinion These techniques are not especially for software
among various stakeholders. The principles of this engineering domain, but with some alteration they can be
technique are progress based on predefined plan, risk made so. The main issue in adoption of these techniques is
assessment and risk handling. Before starting the actual deciding; when to use which technique/approach and how.
negotiations, users are asked to rank their requirements Moreover, the number of requirements can vary from 10 to
carefully such that they point out the requirements they are hundreds and even more then hundreds based on the
willing to negotiate and which they are not. Theory W is a software nature. Therefore, a general purpose and unified
major constituent of Value Based Software Engineering software requirement prioritization framework is needed
(VBSE) agenda and principle as well. that could facilitate most of the software systems’
requirements to prioritized.
III. DISCUSSION AND FINDINGS
In order to develop a unified framework for
Requirements of a software system can be prioritized requirement prioritization; we reviewed the existing
using the techniques discussed in the previous sections. techniques and determine their scope in section II and
Each technique has some good quality attributes and identified the quality attributes that our ideal technique
limitations of scope. In Table 3, we present a summary of should have ( see section IV.A). In the light of these
existing techniques based on some parameters. Some are attributes we designed a new technique by combining the
closed to more reasonable result but expensive in time strategies of existing techniques in one (section IV.B).
and/or cost complexity when requirements increase. Some Finally we analyzed the strength of these techniques based
techniques are mainly based on human judgments that are on their desirable attributes (section IV.C).
sometimes not preferred due to two reasons i.e., biasness
parameter of human nature and expert people A. Quality Attributes
unavailability.
After the examining the literature we conclude that
We see that AHP and 100 dollars test are fine in terms there should be a uniform model that could be used as an
of granularity as well as they are based on ratio scale (with upper layer software requirement prioritization technique.
is a good measurement scale for statistical calculations). The desired model or framework should have maximum
Regarding its algorithmic nature, AHP takes lead from 100 benefits with minimum computational overhead flexible
dollars test technique. Complexity and time penalty are enough to meet the requirements of small, medium and
two main disadvantages of AHP as soon as number of even large projects. It should be made automated in its
candidate requirements increase. To overcome this maximum operation. At user perspective, it should be
problem, AHP input can be filter out with 100 dollars test, simple to understand easily i.e., take a list of requirements
or Numerical assessment, because they are very easy. and produces output in a series of releases based on their
Similarly, the output of AHP can be presented with the priorities.
help of B-Tree (which is also algorithmic). AHP can be
made more optimized by using range values instead of The purpose of specifying the above quality attributes
crisp values. One such example can be seen in eXtreme is to validate our proposed model against them. In other
Programming (XP) [31] that uses Planning Game (PG) in words, specified our requirements.
it. Moreover, In PG we can see numerical assignment and

978-1-4244-8003-6/10/$26.00 ©2010 IEEE


B. The Framework
In this section we present our proposed framework that
has been developed on the predefined criteria (section α β
IV.A). There are three main sub-processes in the
framework; termed as α, β, and γ. The objective of
process-α is to prioritize requirements subjectively to
reduce the number of alternatives to n requirements
(alternatives), where n is the maximum limit of output- α.
In this process, we recommend to use 100-dolors (section
II.D) test prioritization method so that each requirement is
assigned a quantitative value. This value will help the
stakeholders to select n most valued requirements.
The objective of process-β is to rank the aspects of
prioritization for the given project and underlying software
product. Process-β should be executed once by key
stakeholders of the project & product while process- α is
an iterative process. A group of experts should decide the
ranking of aspects using win-win model which tends more
towards resolving conflicts. Once they both produce their
outputs in the form of batches of n size each (produced by γ
process-α) and Ranked Criteria (produced by process-β),
then process-γ is activated to automatically perform pair
wise comparisons using AHP technique (section II.A). The
output of AHP is presented in hierarchical structure using
B-Tree prioritize (section II.C). For the remaining
unprioritized requirements, process-α is executed again
and results are transformed to B-Tree through AHP until
there found no more unprioritized requirements. Once all
requirements have been mapped into B-Tree then release
scheduler sub-process of process- γ which is based on
Numerical Assessments (section II.E) is executed. Thus, at
the end, we get prioritized requirements divided into a
series of releases.

C. Analysis
In this section we analyze our system and determine;
how much we satisfied our desired quality attributes
(section IV.A).
It is still a useful approach for a one with fewer
requirements, as well as for a large amount of
requirements; therefore, it can be referred as unified
model. Figure 3. Proposed Framework

It utilizes both types of decision making approaches;


subject (based on human judgment) and algorithmic. If the sounds effectiveness at some desirable level because of its
numbers of requirements are large enough that can make structure that combines best features of other techniques.
the performance of computational resources decreased
then the input is refined through human expert. In this way V. CONCLUSION AND FUTURE WORK
it guarantees maximum benefit with less overhead.
In this paper, we presented an overview of existing
This framework is flexible enough to be modified so prioritization techniques and then analyzed them in the
that any sub-process of α, β, or γ can be replaced with any light of software requirement prioritization. We observed
other improved techniques. For example in process- α one that these techniques can be categorized as Manual
can replace 100-dolor test with Ranking, Numerical (subjective) vs. algorithmic processes, easy to complex
Assessment, or with any new one if experts finds 100- regarding complexity, Fine to Coarse in terms of
dolors is not appropriate for the subject project. granularity. We realized the need of a uniform upper layer
of prioritization techniques that could be used to prioritize
The process-γ, is capable to be made fully automated
requirements that are small, medium, and even large in
because of its algorithmic nature of sub processes.
numbers. In order to meet this objective, we proposed a
Similarly, the subjective process i.e., α, β can also be made
framework that has α, β, and γ processes; in which first
automated apart from decision making capability (e.g.,
two are subjective and require human involvement while
form filling using web technologies). the last one can be made fully automated because of its
The above analysis of proposed work is presented algorithmic nature. Our αβγ-framework can be used in
theoretically, that should not be considered sufficient to most of the projects by changing is components e.g., for
verify and validate its adoptability. But still its main idea small number of requirements, one can ignore any sub-
component of process-α and can add a one when
requirements are very large in quantity. We initially, [13] W. Lewis, Uncertainties in the Analytic Hierarchy Process.
discussed its effectiveness, but it requires more efforts to DSTO-TN-0597
be tested on real scenarios. [14] A. Ahl, "An Experimental Comparison of Five Prioritization
Techniques - Investigating Ease of Use,Accuracy, and Scalability",
The proposed framework should be testing on at least Master Thesis No. MSE-2005-11, BTH, 2005
three kind of case-studies i.e., requirements in small, [15] K.S. Chin, S.Chin and V.M. Rao Tummala. An evaluation of
medium, and large quantity. Based on the result of these success factors using the AHP to implement ISO 14001-based
EMS
case studies variants of the framework can be proposed.
[16] S. Jenny, Early Requirements Prioritization Technique (best
Regarding automation, the feasibility of processes α and β practice white paper).Version 1, December 2008
for semi or full automation should be checked and if
[17] L. Lehtola and K. Marjo. “Suitability of requirements prioritization
possible they should also be made automated to some methods for market-driven software product development,” John
extent. In order to make this framework more usable and Wiley & Sons, Ltd.2006
effective, it can be made available to everyone using web [18] K. Kar A, Using Fuzzy Neural Networks and Analytic Hierarchy
technologies. Process for Supplier Classification in e-Procurement software
product development.John Wiley & Sons, Ltd.2006, 2009.
[19] S. Ponaraseri, A.Sus2 and P. Tonella, Using the Planning Game
REFERENCES for Test Case Prioritization
[20] A. Aurm, Engineering and maangeing software requirements.
[1] J. Karlsson, "Software Requirements Prioritizing", Proceedings of Springer
the 2nd International Conference on Requirements Engineering [21] E. Hull, K.Jackson and J.Dick, Requirements engineering (2nd
(ICRE'96), 1996, pp. 110-116. Edition). Springer
[2] B, MD. R, Q. Abbas and R.P. Verma. “An Approach for [22] Y. Ralph R, The.Requirements Engineering Handbook
Requirement Prioritization using B-Tree, “ IEEE Computer
[23] D.Firesmith, Prioritizing Requirements.Journal of Object
sociery. 2008
Technology, vol. 3, no. 8, Sep-Oct 2004, pp.35-47
[3] J. Karlsson, and K. Ryan, "A Cost-Value Approach for Prioritizing
[24] Avesani, Bazzanella1, Perini, Susi. Supporting the Requirements
Requirements", IEEE Software 14(5), 1997, pp. 67-74.
Prioritization Process-A Machine Learning approach
[4] L. Satty T, The Analytic Hierarchy Process, McGraw-Hill, New
[25] L. Saaty, T, “Multicriteria Decision Making The Analytic
York, 1980.
Hierarchy Process, “ RWS Publications, Pittsburgh, PA. (1990)
[5] K. Kashif A, “A Systematic Review of Software Requirements
[26] D. Leffingwell, D. Widrig, ”Managing Software Requirements- A
Prioritization,” Thesis no MSE-2006-18.BTH, 2006.
Use Case Approach”, Addison-Wesley, USA, May 2003, 2nd
[6] E. Forman and S.I. Gass. The Analytic Hierarchy Process - An edition, pp 124-125
Exposition. Operations Research, 49(4)469-486, 2001
[27] Patrik Berander. "Prioritization of Stakeholder Needs in Software
[7] S. Stevens S, "On the Theory of Scales of Measurement". Science Engineering - Understanding and Evaluation". ISBN 91-7295-052-
103 (2684): 677–680. PMID 17750512, 1946. 8. Chap (3). P 42-43
[8] T. William M.K, The Research Methods Knowledge Base, Third [28] B. Joseph, Learning the Planning Game- An Extreme
Edition. SBN-10: 1592602916 Exercise.www.csis.pace.edu/~bergin/xp/planninggame.html
(http://www.socialresearchmethods.net/kb/measlevl.php)
[29] B. Boehm & R. Ross, "Theory-W Software Project Management:
[9] K. Lena, Requirements Prioritisation and Retrospective Analysis Principles and Examples." IEEE Transactions on Software
for Release Planning Process Improvement. PhD Thesis. Engineering 15, 4 (July 1989): 902-916
[10] A. Jim, S. Randy K. and C. David, “Value-Oriented requirements [30] Patrik Berander. Evolving Prioritization for Software Product
Prioritization”, Jan-Feb 2007 IEEE software Management. Patrik Berander ,2007.
[11] J. Karlsson, “An evaluation of methods for prioritizing software [31] K. Beck, Extreme programming explained. Addison-Wesley,
requirements,” 1997. Upper Saddle River, 1999.
[12] Heger, Dominique A. (2004), A Disquisition on The Performance
Behavior of Binary Search Tree Data Structures, European Journal
for the Informatics Professional 5 (5)

You might also like