Requirement Prioritization: A Study and Proposed Framework

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 3, Issue 6, June 2013)

595

Requirement Prioritization: A Study and Proposed Framework

Lipika Bose Goel

1

, Prof. Sanjeev Thakur

2

1,2_{Amity University, Sec 125 Noida}

Abstract— Requirements may be defined as a demand or need. In software engineering, a requirement is a description of what a system should do. Requirement prioritization process is used to determine which candidate requirement of a software project should be included in a certain release, for this purpose different techniques are used.

In this paper we have proposed a framework to prioritize the software requirements. The proposed framework will rank the requirements by the relative level of value, cost, efforts and threat associated with each requirement.

Keywords— Analytic Hierarchy Process, Prioritization of Software Requirement, Requirements Prioritization Techniques, Requirements Engineering.

I. INTRODUCTION

In commercial software systems development there is an increasing need for methods capable of prioritizing candidate requirements. Reasons for this include that not all requirements can usually be met with available time and resource constraints that the customers to a larger extent are demanding systems with the most bang for the buck, or that requirements must be allocated to different releases. Efficient and trustworthy methods for

prioritizing requirements are therefore strongly

demanded by practitioners. The role of requirements prioritization is of extreme importance during the software development lifecycle, when planning for the set of requirements to implement in the successive system releases, according to information concerning the available budget, time constraints as well as stakeholder expectations and technical constraints.

In requirements prioritization we have to find out the important needs of the users for the system under development. The very purpose of software requirements prioritization is to find out the core requirements that can be implemented under constraints of cost, quality, resources and time which ultimately result in customer satisfaction. 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 planning. 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 intersects and preferences of stakeholders under defined technical constraints and this will enhance business value.

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 not be right then the cost of the rectification would increase at latter stages and the quality of the product will also suffer. The requirements prioritization is also important for gaining market leverage or for proper understanding of the market gain and loss The overall quality of a software system is taken into account when a system satisfies its users and customers in terms of their requirements. 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 There are different aspects of software requirements like importance cost, penalty, time volatility ,risk and dependencies with other requirements on the basis of customers, cost, technical value and requirement change . On the basis of these aspects the requirements are prioritized and trivial requirements are rejected initially and only value added requirements are considered.

The first section gives a brief Introduction to Requirement Prioritization Process along with the Requirement Engineering Process. The second section describes the existing most common seven Requirement Prioritization Techniques namely AHP, Bubble Sort, Priority Groups, Minimal Spanning Tree, Binary Tree. The third section deals with evaluation of the Requirement prioritization Techniques along with the factors considered during prioritization. The fourth section mainly describes the Experimental work carried out in proposing the new framework for Requirement Prioritization. In this section we have proposed a framework that will rank the requirements by the relative level of value, cost, effort and threat associated with each requirement. The last section concludes the paper with its future scope.

II. REVIEW OF LITERATURE

(2)

International Journal of Emerging Technology and Advanced Engineering

596

A prioritizing session may consist of three consecutive stages:

(1)The preparation stage where a person structures the requirements according to the principle of the prioritizing methods to be used. A team and a team leader for the session is selected and provided all necessary information.

(2)The execution stage where the decision makers do the actual prioritizing of the requirements using the information they were provided with in the previous stage. The evaluation criteria must be agreed upon by the team before the execution stage is initiated. (3)The presentation stage where the results of the

execution are presented for those involved. Some prioritizing methods involve different kinds of calculations that must be carried out before the results can be presented.

The following sections will now discuss some of the Requirement Prioritization Techniques:

A. Analytical Hierarchical Process (AHP)

The analytic hierarchy process (AHP) is a decision-making method. Using AHP to prioritize software requirements involves comparing all unique pairs of requirements to determine which of the two is of higher priority, and to what extent. In a software project comprising n requirements, n(n - 1)/2 pair-wise comparisons are consequently required by decision maker. On the one hand AHP is a demanding method due to the dramatically increasing number of required pair-wise comparisons when the number of requirements grows. On the other hand AHP is very trustworthy since the huge amount of redundancy n he pair-wise comparisons makes the process fairly insensitive to judgmental errors. Prioritizing software requirements using AHP involves all three stages of a prioritizing session:

(1)As preparation, outline all unique pairs of

requirements.

(2)As execution, compare all outlined pairs of

requirements using the Table 1.

(3)As presentation, use the ‗averaging over normalized columns‘ method (based on the pair-wise comparisons) to estimate the relative priority of each requirement. Calculate the consistency ratio of the pair-wise comparisons using methods provided by AHP. The consistency ratio is an indicator of the reliability of the resulting priorities, and thus also an estimate of the judgmental errors in the pair-wise comparisons.

Intensity of

Importance Description

1 Of equal importance

3 Moderate difference in importance

5 Essential difference in importance

7 Major difference in importance

9 Major difference in importance

Reciprocals‘

If requirement i has one of the above numbers assigned to it when compared with requirement j, then j has the reciprocal value when compared with i.

B. Bubble Sort

Bubble sort is one of the simplest and most basic methods for sorting elements with respect to a criterion. Interestingly, bubble sort is closely related to AHP. As with AHP, the required number of pair-wise comparisons in bubble sort is n (n - 1)/2. But, the decision maker only has to determine which of the two requirements is of higher priority, not to what extent. Using the bubble sort approach involves the following stages of a prioritizing session:

(1)As preparation, outline the requirements in a vector. (2)As execution, start to compare the requirements at the top with the requirement at the position below the top. If the requirement in the above position is considered of higher priority, swap their positions. Continue the comparison until unique combinations of positions have been compared.

(3)As presentation, outline the sorted vector. The result of the process is a vector where the original order of the requirements has changed. The least important requirement is at the top of the vector, and the most important requirement is at the bottom of the vector. The result of a bubble sort is requirements ranked according to their priority on an ordinal scale.

C. Priority groups

(3)

International Journal of Emerging Technology and Advanced Engineering

597

Subsequently, the groups can be internally ranked either by using a suitable approach for ordering the requirement. The primary gain is that we do not have to compare high priority requirements with low priority requirements, since they are placed in different groups. The actual choice of the number of groups depends on the situation and the knowledge of the people performing the prioritization. Using the priority groups approach involves all three stages of a prioritizing session. Assume three distinct groups are used:

(1)As preparation, outline the candidate requirements. (2)As execution, put each of the requirements into one

of the three groups. In groups with more than one requirement, create three new subgroups and put the requirements into these groups. Continue to apply this process recursively to all groups.

(3)As presentation, just read the requirements from left to right.

D. Minimal spanning tree

The pair-wise comparisons in AHP provide interesting relationships to each other. For example, if requirement A is determined to be of higher priority than requirement B, and requirement B is determined to be of higher priority than requirement C, then requirement B should be of higher priority when compared to requirement C. Despite this, AHP lets the decision maker perform the last comparison. Because of this redundancy AHP can indicate inconsistent judgments (such as claiming B to be of higher priority than C in this example).If decision makers were perfectly consistent, the redundancy of the comparisons would be unnecessary. In such a case only n -1 comparison would be enough to calculate the relative intensity of the remaining comparisons. This implies that the least effort required by a decision maker is to create a minimal spanning tree in a directed graph (i.e. the graph is at least minimally connected). In the directed graph which can be constructed by the comparison provided, there is at least one path between the requirements not pair-wise compared. Using the minimal spanning tree approach involves all three stages of a prioritizing session:

(1)As preparation, outline n-1 unique pairs of

requirements so that a minimal spanning tree can be constructed.

(2)As execution, compare all outlined pairs of

requirements using the scale in Table 1.

(3)As presentation, compute the missing intensities of importance by taking the geometric mean of the existing intensities of all possible ways in which they are connected.

E.Binary search tree

A binary tree is a tree in which each node has at most two children. A special case of a binary tree is a binary search tree where the nodes are labelled with elements of a set. Consider the elements of the set as the candidate requirements. Prioritizing n software requirements using the binary search tree approach involves constructing a binary search tree consisting of n nodes. The first thing to be done is to create a single node holding one requirement. Then the next requirement is compared to the top node in the binary search tree. If it is of lower priority than the node, it is compared to the node‘s left child, and so forth. If it is of higher priority than the node, it is compared to the node‘s right child, and so forth. Finally the requirements are inserted into the proper place and the process continues until all requirements have been inserted into the binary search tree. Using the binary search tree approach involves all three stages of a prioritizing session:

(1)As preparation, outline the candidate requirements. (2)As execution, select the requirements one at a time

and create a binary search tree.

(3)As presentation, traverse the binary search tree in order and add them to a list. The requirements having the lowest priority then come first in the list. Print the list. Since the average path length from the root to a leaf in a binary search tree is O (log n), inserting a requirement into a binary search tree takes on the average O(log n) time. Consequently, inserting all n requirements into a binary search tree takes on the average O(n log n) time. In this case, too, the requirements are ranked on an ordinal scale.

III. RESEARCH METHODOLOGY AND PROCEDURES

A. Proposed Framework

In this section we have proposed a framework that will rank the requirements by the relative level of value, cost, effort and threat associated with each requirement. 1. Elicit the software requirements with the help of the following

1.1 Collect information about user expectations. 1.2 Train the Clients, Users and Managers. 1.3 Write the description of the user need for the proposed system.

1.4 Now you can apply Misuse cases or JAD or RAD or Ontology framework.

(4)

International Journal of Emerging Technology and Advanced Engineering

598

For using AHP

{

Create the overall performance matrix }

Then calculate the Eigen vector (Importance Weight)

3. Find out the cost associated with each requirement. 4. Find out the risk associated with each requirement. 5. Find out the effort required for each requirement. 6. Compare the values of the importance weight of software requirements with step 3 and then rank or prioritize the requirements (List 1 of Requirements Prioritized).

7. Compare the values of efforts of software requirements with the List 1 prepared above and then rank the requirements (List 2 of Requirements Prioritized). 8. Again compare the risks of software requirements with the List 2 of Requirements prepare a final list of Requirements as prioritized. (Proposed Framework)

B.Experimental Work

In this paper we have elicited the software requirements for a Symantec project providing B2B service. Symantec wants to add some new features in its existing Estore and CSR Tool. Estore is the site where it sells its own products (e.g. Antivirus, Antispam, and Cloud based products) and CSR is the tool for the Customer Service Agents which they use for Customer Support.

The set of new Requirements are as follows:

(R1): Customer should be able to purchase trial ware orders which would expire in 30 days.

(R2): Customer should receive an Order Confirmation mail once his order is successfully placed.

(R3): Customer can check the status of the Order Placed. (R4): There should be a link in the site which on clicking will redirect the customer to the page which will display the list of all the products sold by the site. On clicking any of the product customers should directly land on the cart page. (R5): Customer should have an option to do manual renewal of the products purchased.

(R6): Customer should have an option of OPT OUT of the product purchased.

[image:4.595.307.554.144.260.2]

Consider the following overall performance matrix (OPM) that is derived from customer needs statement for Estore and CSR.

Table 1

Overall performance matrix (OPM)

R1 R2 R3 R4 R5 R6

R1 1 3 ½ 1/5 5 3

R2 1/3 1 1/3 1/7 1/3 2

R3 2 3 1 ½ 5 7

R4 5 7 2 1 7 9

R5 1/5 3 1/5 1/7 1 2

R6 1/3 ½ 1/7 1/9 ½ 1

After applying the AHP we have got the importance weights and it is summarized in table 2- .

Table 2

Importance Weight of Requirements

Requirement Importance Weight

1 0.2909

2 0.0953

3 0.4436

4 0.8247

5 0.1581

6 0.0661

[image:4.595.319.543.315.429.2]

According to figure 1, three most valuable requirements are R4, R3 and R1. The three least valuable requirements are R5, R2 and R6. Figure 1 and Figure 2 shows the value distribution and Cost distribution of the requirements respectively.

[image:4.595.321.542.488.666.2]

(5)

International Journal of Emerging Technology and Advanced Engineering

[image:5.595.316.544.133.326.2]

599

Figure-2 shows that requirements R1, R6 and R5 are three most expensive and the three least expensive requirements are R2, R4 and R3.

Figure 2: Cost distribution of requirements

From Figure-1 and Figure-2 we conclude, in terms of Cost- Value ratio distribution that R4, R3, R5 are identified as high priority and R2, R1 and R6 are

identified as low priority. Therefore arranging

requirements in decreasing order of their priority: (List1): R4>R3>R5>R2>R1>R6

[image:5.595.53.279.176.373.2]

Now Table 2 depicts the Effort required for each Requirement:

Table 2

Efforts Required for each Requirement

Requirement Efforts Required(Hours)

R1 80

R2 50

R3 30

R4 40

R5 60

R6 65

Therefore as per the Efforts required the priority of Requirements will be:

List 2: R3>R4>R2>R5>R6>R1

Figure 3: Effort distribution of requirements

Comparing the List 1 with List 2 the requirements

are reprioritizing we obtain a new List of

Requirements

Prioritized as: List 3: R3>R4>R5>R2>R6>R1

C.Software Risk

There are three dimension of software risk. (i) Technical risk (ii) Organizational risk (iii) Environmental risk. The technical dimension results from uncertainty in the task and procedure. The organizational dimension results from poor communication and organizational structure. The environmental dimension results from rapidly changing environment and problems with external relationship with software developers and/or users.

The rank of risk is estimated using risk exposure and the value of the highest risk exposure indicate the most serious risk. Table-4 contains the calculated values of risk exposure and the ranking of risk.

Table 3

Calculated values of risk exposure and the ranking of risk

Require ment

Probability of Occurring of Risk(P)

Total loss if it occurs

(T)

Risk exposure(

RE)= (P*T)

Risk prior

ity

R1 3.0 % 7K 210 1

R2 0.5 % 2K 10 3

R3 0.1 % 1K 1 6

R4 0.3 % 1K 3 5

R5 2.0 % 4K 8 4

[image:5.595.50.278.495.594.2]

(6)

International Journal of Emerging Technology and Advanced Engineering

[image:6.595.54.278.133.340.2]

600

Figure 4: Risk distribution of requirements

Therefore as per the Risk involved the priority of Requirements will be:

Comparing the List 3 with List 4 the requirements are reprioritising we obtain a new List of Requirements Prioritized as:

Thus we have shown that AHP is used only to evaluate the importance weight of the requirements not to prioritize the requirements, after this we apply the existing prioritizing techniques. We consider the various other factors like Cost, Effort, and Risk Involved in prioritizing the requirements.

D. Flowchart Of The Proposed Approach For Requirement Prioritization

Step1: It is to check dependency constraints between requirements.

Step 2: It is to prioritize the requirements based on its Value using Analytic Hierarchy Process.

Step3: Calculates the cost for implementation required for each requirement of the requirement set. Then compare the Value and Cost Distribution of the Requirement and produce a List of Prioritized Requirement.

Step 4: Calculate the implementation effort required for each requirement of the requirement set. If required effort is greater than available effort than exclude some requirements. Now again revisit and prioritize the Requirement considering the Value Cost as well as Effort Distribution of the Requirement.

Step 5: Calculate the risk associated with each of the requirement. We evaluate the Risk Exposure factor and then formulate the Risk Priority. Again comparing the previous list of prioritised requirement with the Risk priority and revisit the Requirements to form a new list of Prioritized Requirement.

(7)

International Journal of Emerging Technology and Advanced Engineering

601

IV. CONCLUSION AND FUTURE SCOPE

It is almost impossible to implement all the requirements in one release. That is why some sort of prioritization process is needed to implement the most important requirements in the first release and leave the less important ones for the future releases.

In this paper we have proposed a framework to elicit and prioritize the software requirements. In this we have shown that AHP is used only to evaluate the importance weight of the requirements not to prioritize the requirements, after this we apply the existing prioritizing techniques. We have added the cost, effort and threat level analysis during the requirements prioritization. After adding threat with the requirements we conclude that prioritizations through AHP results are not only suitable for decision makers, they must think about the prioritization of the requirements using threat level analysis. This analysis will give the clear picture that how many requirements should be neglected and how many should be included, and it will also give the picture that how many requirements would be re-prioritize.

During requirement prioritization process lots of factors has to be considered. E.g. cost, benefit, risk, effort, etc. there are lots of methods for prioritization but there isn‘t a single method that addresses all the factors necessary for prioritization process.

Furthermore the prioritization process should not only considers the crucial factors but also the process must be easy to learn, easy to use, invisible to stakeholders to gain their interest and confidence, understandable to non-experts, reliable, efficient, scalable and flexible. Lots of factors can be added to this list. And most of the methods and techniques that are available nowadays are for small development organization. If the scale increases, these techniques get very difficult to implement and are less accurate. Hence lot of work has to be done in this field. Such techniques can be developed that uses all major factors listed above for prioritization, regardless of organization size, i.e. supports all size of development organizations.

REFERENCES

[1] D. Firesmith, ― Prioritizing Requirements‖, Journal of Object Technology, Volume 3, No.8, September 2004.

[2] J. Karlsson, ―Software Requirements Prioritizing‖, Proceedings of

the International Conference on Requ irement Engineering, 1996 , pp. 110–116.

[3] 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. [4] Mohd. Sadiq, Mohd. Shahid, ― Elicitation and Prioritization of

Software requirements‖, International Journal of Recent Trends in Engineering, Finland, 2009.

[5] 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.

[6] A.M. Hickey, A.M. Davis, ―Elicitation Technique Selection: How Do Experts Do It?‖ Proceedings of the 11th IEEE International Requirements Engineering Conference, 2003.

[7] Charette, R., ―Why Software Fails‖, [website] http://spectrum.ieee.org/sep05/1685

[8] J.Azar, R.K. Smith, & D. Cordes, "Value-Oriented requirements Prioritization in a Small Development Organization", IEEE Software, Jan/Feb 2007, pp. 32-73.

[9] Karlsson, J., K. Ryan, ―A Cost-Value Approach for Prioritizing Requirements‖, IEEE Software, Sept. 1997, pp. 67-74.

[10] Greer, D., Bustard, D., & Sunazuka, T. (1999b). Prioritization of system changes using cost-benefit and risk assessments, Proceedings of the Fourth IEEE International Symposium on Requirements Engineering, 180-187.

[11] Boehm, B.W., Software Risk Management: Principles and Practices, IEEE Software, January, pp 32-41, 1991.

[12] Monga, I. S. (2000) Aggregating individual scores in-group analytic hierarchy process: A comparison of competing approaches, M. Tech. Thesis, Department of Management Studies, Indian Institute of Technology, Delhi.

[13] 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.

(8)

International Journal of Emerging Technology and Advanced Engineering

602

[15] 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.

[16] 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

[17] Greer, D. and Bustard, D.W., Towards an Evolutionary Delivery Strategy based on Risk Analysis, Proceedings of Engineering of Computer Based Systems, IEEE Computer Society Press, March, 1996.