Multi-Aspects Based Requirements Prioritization Technique for Value ...

Multi-Aspects Based Requirements Priortization Technique for Value-Based Software Developments Falak Sher1, Dayang N. A. Jawawi2, Radziah Mohamad3, Muhammad Imran Babar4 1,2,3,4

Department of Software Engineering, UTM, Johor, 81310, Malaysia [email protected], [email protected], [email protected], [email protected]

1

(SRP) process is used to choose candidate requirements for different releases of software. Babar et al. state that “the right requirements are considered as a part and parcel of software quality” [5]. More than 49 techniques are reported in the literature to support the prioritization process for small, medium and large-scale requirements [6]. Different techniques for requirements prioritization are empirically validated for their support for ease of use, scalability, ease of learning, timeconsumption, judgmental errors and complexity. [7]. Some of the key validated prioritization techniques are Analytical Hierarchy Process (AHP), Hierarchy AHP, Minimal Spanning Tree (MST), Cumulative Voting (CV), Hierarchical Cumulative Voting (HCV), Priority Groups (PG), Binary Priority List (BPL), Bubble Sort (BS), Numerical Assignment (NA) [7, 8]. Most of these techniques are assessed based on technical factors only.

Abstract—In requirements engineering (RE), different activities are carried on to add up business values to the software products. In value-base software (VBS), financial impacts on business are measured, and this phenomenon makes VBS different than other traditional software applications. In VBS systems, determination of valuable requirements is a crucial task and depends on multiple aspects or factors. Requirement prioritization is a part of RE and is considered as a crucial decision-making activity. Requirements prioritization is a process where requirements are arranged in an order to create a stakeholder priority list. Different requirements prioritization techniques are used by the experts in the industry to partially support the prioritization process for VBS development. Business and technical aspects play a vital role to make prioritization process effective. In existing requirements prioritization techniques, technical aspects are not applied well, and their consideration is partial only. Moreover, the business aspects are ignored which are highly vital for VBS development. There is a need to introduce multi-aspects requirements prioritization technique to support the selection of candidate requirements for VBS development. Hence, this paper focuses on a new requirements prioritization technique for VBS.

There are 4 main sections of this research study. Section I is an introduction and section II is a background. Section III describes the proposed multi-aspects based software requirements prioritization technique in detail. Section IV shows the experimentations and the results of one experiment are given in detail. Section V concludes the whole study.

Keywords—Requirements engineering; requirements prioritization; technical aspects; scalability; complexity

I. INTRODUCTION

II. BACKGROUND

The Value-based software (VBS) was first introduced by Kauffman, later on many researchers added their contribution in the field with a major focus on economic considerations [1]. The term value refers to financial benefits associated with softwares. According to Boehm “The value-based approach to software development integrates value considerations into current and emerging software engineering principles and practices, while developing an overall framework in which these techniques compatibly reinforce each other” [2]. The VBS systems target matters related to finance, and this specialty makes these systems different from typical or traditional software systems. “The purpose of requirements engineering (RE) activities is to add business value that is accounted for in terms of return-on-investment of a software product” [3].

To support prioritization process, different techniques are reported and evaluated in the literature. AHP supports pairwise comparison to prioritize requirements [9]. The empirical evidences prove that mostly technical aspects are considered individually or in a group for requirements prioritization. Zultner presented prioritization technique using AHP to determine priorities of multiple stakeholders. Similarly, Karlson introduced cost-value approach to help out the process of prioritizing requirements considering cost and value as major aspects [10]. SERUM [11] facilitates prioritization by focusing on cost estimation, benefit and two types of risks. Value-oriented prioritization (VOP) is based on the framework targeting business values for making decisions to prioritize requirements for small-scale organizations [4]. This is the only effort reported in the literature where attention is paid to business aspects to be considered as a part of requirement prioritization process. Another contribution is made as “Value based Intelligent Requirement Prioritization (VIRP)”, the main focus of this technique is to assign values to the requirements at multi-level and prioritize requirements using fuzzy logic [12]. Although this technique claims a novel contribution, but

Value-based requirements engineering (VBRE) is considered and declared as very complex process irrespective of the size of the organization which is interested in software development. Suitable prioritization process creates a major difference in the success or failure of the software even in the small organizations [4]. Software requirements prioritization

978-1-4799-6089-7/14/$31.00 ©2014 IEEE

1

that more aspects should be considered and supported by prioritization techniques and the supported or respective tools as well.

still the business aspects are missing, which are very important for VBS systems. Existing techniques consider different factors for requirements prioritization. Selection of suitable prioritization methods depends on different constrains that need to be considered for the prioritization process [13]. It is essential to decide what is important before these requirements are incorporated into the development process. Different stakeholders have different perceptions regarding requirements significance. The requirements importance determination is a quite hard job being a subjective matter [14, 15]. The term ‘importance’ has different meanings agreed in the different proposals [9, 10, 15-17]. To satisfy the needs of different stakeholders, it is better to identify their preferences. Alongwith stakeholder’s technical concerns, it is also compulsory to focus on business related concerns to support prioritization process. These aspects focus on financial benefits of the organization, competition with the market competitors, following regulations and implementation cost [14]. In the VBS system, the value of the requirement becomes critical because of the associated financial risks of the system development without considering business aspects.

Fig. 1 Technical Aspects for requirements prioritization

Requirements prioritization process mainly depends on stakeholders and their involvement in order to complete the ranking process of requirements for different releases of software. Due to the diversified nature of the requirements, it is not possible to freeze the requirements. This volatility of requirements selection and prioritization process is crucial and very difficult to handle. Important factors that manage the volatility include market trends, changing needs of the users and better understanding of the requirements [22]. Similarly, growing nature of requirements and software coming from modern projects increase complexity of the requirements and software [10, 23]. This complexity is the cause of an inability to generate immediate ranks [8, 19].

III. REQUIREMENTS PRIORITIZATION ASPECTS It is necessary to prioritize requirements objectively; i.e., some parameters or aspects should support in the realization of value to the requirements. It is easy to consider single aspect as a part of decision-making for SRP by recognizing its importance for the system. Most of the aspects or attributes depend directly or indirectly on each other. For example, importance depends on the complexity of the requirement, capacity of reusing existing code and effort required on the testing process [18]. Moreover, many factors exist that decide about the inclusion and exclusion of different aspects as a part of RP e.g. explicit circumstances, specification of products, stakeholders perspective [19]. In SRP process, stakeholders take the responsibility of prioritization of requirements based on the aspects required for the success of the system. However, importance is highly subjective matter that varies considerably from one stakeholder to another [15].

In requirements prioritization process, the concerns and roles of stakeholders, situations for prioritization and many other technical aspects must be considered thoroughly [24]. Requirements prioritization based on a single aspect is quite easier job to decide and select requirements for realization as compared to multi-aspects based assessment. However, multiaspects based approach is more reliable. Requirements engineers’ core responsibility is to choose right approaches, tools and techniques to support the requirements prioritization process based on technical aspects. Although this decision is difficult due to the complex nature of projects and diversified nature of the RE [25]. Evaluation of the existing techniques is performed by different authors. Accordingly, different techniques have different capacities. Some techniques are good in term of one aspect and are difficult otherwise. Few techniques are similar in their functionality but are complex in their use. Requirements are also non-isolated segments and have dependencies on each other. It is claimed that requirements are 80% interdependent, and only few requirements may be treated in individual capacity. These dependencies are source of complexity in making and executing project plan [26].

For software requirements prioritization, different key aspects are taken into account. These aspects are divided into two major categories, technical aspects and business aspects. A. Technical Aspects There are some alternative terms which are used to represent the concept of aspects like criteria, factor, element and parameter [20] [21]. Aspect is also defined as a "property" or "attribute" [19]. Figure 1 shows the different technical aspects which are considered for the prioritization process in different requirements prioritization techniques. To define the requirements priority based on one or more aspects is a highly complex decision-making activity. These aspects include risk, value, cost, speed, effort, granularity, time, sophistication, dependencies, sensitivity, contradictory, volatility, penalty, resources and complexity. Some of these aspects are taken into account by existing requirements prioritization techniques, which make the requirements prioritization process more effective. However, there should be a provision

RE is a very complex domain in its nature and is represented as a combination of different processes required to meet different needs at different levels [27]. Requirement specification process is considered as very complex process. Diversified research in this field highlights the issues, concerns, prospects and different difficulties. Moreover, still

2

requirements specification domain needs to t be explored by different researchers and organizationns in terms of technological advancement [28].

The different business vaalues support the process of requirements prioritization [9, 32]. 3 VOP is one of the existing prioritization approaches which is based on business aspects as a part of the prioritization proceess and is considered as one of the best approaches. This approach also supports the identification and weighing of business risks and cost of implementing each requirementt. This aspect of the approach helps in reducing the impact off the different risks induced due to expert judgments.

m it necessary to Limited resources in software projects make prioritize requirements, which eases the planning of subsequent software releases [29]. Moreoover, requirements prioritization supports the conflict reesolution between stakeholder preferences. Multiple stakeholdders’ contribution is required in the prioritization process to addrress the complexity issue. Currently, most of the software projects are completed with a large number of requirements. The requirements prioritization techniques facilitate the expeerts in order to list and sort the requirements for successful softtware development. Software experts in the software industry facce major challenges like time and complexity due to the inccreased number of requirements and comparisons. [30]. Sooftware companies practice different techniques, and few off them are useful. However, the others are not affordable in terms of cost, complexity, time and scalability. [31].

TABLE E. I VOP MATRIX

In VOP, the requirements prioritization matrix is used which contains different businesss and technical aspects. Output of this matrix is a prioritizedd list based on more logical decision for selection of valuablle requirements. Although VOP covers many of the aspects and is proved much better prioritization technique but a series of aspects are uncovered and unexplored. Similarly, a coomparison is performed on six different techniques, and VOP is declared best technique in terms of ease of use, time taaken to perform prioritization, scalability and other technical annd business aspects [8].

B. Business Aspects Two classifications of the aspects arre reported in the literature. One is the technical, and the othher one is business [4]. Figure 2 represents the business aspectts for requirements prioritization. With the growing naturee of business and industry it is becoming obligatory to covver most important aspects as a part of requirements prioritizattion process. These aspects include sales, marketing, comppetitive, strategic, customer retention, simplicity, innovative, resourceful, client focused and availability. These core businesss values or aspects are defined by the team of technical and business experts. Due to limited space it is difficult to list thee detail of team’s structure in this paper. The detail of differennt aspects related to business is collected from two teams com mprised of business and technical experts. Final list of 18 aspects is finalized by the b on consensus teams of experts (business and technical) based from list of aspects. As per experts’ opinionn, these aspects are closest to the business values requiredd for growth and promotion of common businesses. Moreoveer, teams of experts assigned relative weight to each aspect identified as core business aspect. This ranking is subjectiive ranking where weights are assigned from 1 to 10 and 10 is considered most critical for the company and 1 as least criticaal value.

An extension is proposed to t the existing VOP matrix to support proposed hybrid approoach for requirements. Eleven additional aspects are included in the existing matrix to make the prioritization process moore effective [33]. Table II represents the matrix used by the hybrid requirements prioritization technique. TABLE E. II HYBRID PRIORITIZATIO ON TECHNIQUE MATRIX

TABLE E. IIII MULTI-ASPECTS REQUIREMEN NTS PRIORITIZATION MATRIX

The proposed matrix for priooritization technique is given in Table III which is comprised of two categories of technical and

Fig. 2 Business Aspects for requirements prioritization p

3

Currently, due to the changiing and challenging dimensions of the business scenarios there is a need to focus on different perspectives and aspects. Moreoover, technical aspects are also very important and must bee taken into account while prioritizing requirements. Coree business values’ weights are assigned by the teams of tecchnical and business experts. Similarly, weights for technical aspects are assigned by d to define boundaries technical experts. It is very difficult between technical and businesss aspects in some cases. These aspects overlap and are the partt of both business and technical categories. Most of the existing techniques ignore details of the business aspects that help in thhe decision-making process in order to prioritize the requiremeents. Risk is assigned a negative value in the proposed multi-aspects requirements prioritization matrix. Risk weights are assignned and assessed, by technical experts, for each requirement against risk tolerance criteria of the organization.

business aspects. Some aspects are part of both b categories and are considered as shared aspects i.e. benefit,, value and cost etc. In the proposed matrix the requirement scorre Sr is calculate by taking the sum of multiplication of each bussiness value Vi with its respective weight Wr,i and is representedd in equation (1). Sr is the Total Score or value of a requirement. X

,

…

1

ROOM (OCSR) IV. EXPERIMENT - ONLINE CAR SHOW-R Multi-aspects technique is applied on OCSR. O Maximizing profit, business growth, customer’s attraction and satisfaction is the prime objective of this organizationn. Based on listed business objectives, developed software shoould be value-based software. Initially, a dataset of 10 requireements is taken in order to apply the proposed matrix. The limited number of requirements is selected in order to evalluate the proposed technique. Later on, more experiments withh a large number of requirements will be performed in orderr to highlight the importance of the technique. Online car shhow-room supports login facility, data manipulation of differentt models of old and new cars. Moreover, the system must be able to handle the data related to car rentals as well. The list of reqquirements is given below.

Score for Prioritized P Require ements WEIGHTS

1500 1000 500 0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10

The user shall be able to 1. Requirement 1. 2. Requirement 2. 3. Requirement 3. 4. Requirement 4. 5. Requirement 5. 6. Requirement 6. 7. Requirement 7.

REEQUIREMENTS

Login to system. Update car detaills (rental). Delete car inform mation. Delete car inform mation (rental). Logout from systtem. Change passwordd. Track new/used car c model information. 8. Requirement 8. update details of new/used car model. 9. Requirement 9. View rent a car innformation. 10. Requirement 10. Rent a car.

Fig 3. Graph showing rankeed prioritized requirements

Figure 3 describes the prioritization of the 10 requirements. p in the list. Requirement Requirement 7 has the highest priority 9 is the second in order in the liist, requirement 8 positions as 3 and so on. These three requirements r should go for implementation in the first release of the software. There is a slight difference in the priorityy of requirement 3, 4 and 5. These requirements will be a parrt of successive releases.

TABLE. IV MULTI-ASPECTS PRIORITIZATION MATRIX A

Fig 4. Graph showing rankeed prioritized requirements

4

Figure 4 reflects detailed picture of each aspect and the total weight achieved by different aspects. It helps to determine the priority list of different aspects included for VBS requirements prioritization process. Total score Sr value is calculated by multiplying the weight assigned against each aspect with the weight assigned to each requirement, and finally sum of all weights is taken. The basic purpose of this calculation is to evaluate the prioritization process from both angles, one is from individual requirement and the other is from each aspect to make the decision-making process more refined.

business experts being a part of the process. Consideration of technical and business aspects in the requirements prioritization process makes it more useful, for VBS development. V. CONCLUSION In order to make VBS more valuable, there is a need to focus the key business aspects. The VBS systems have a distinct nature as compared to the other traditional software applications. The VBS systems deal with financial matters hence, there is a need to focus every business aspects which may add some financial leverage. Requirements prioritization for VBS development is difficult and complex process. Different approaches are proposed by the researchers to facilitate prioritization of requirements, but they focus on limited technical and business aspects. The existing techniques do not focus the business aspects hence, in the proposed technique the due consideration is given to business aspects along-with the technical aspects. The initial results are appealing and are effective for VBS requirements prioritization process. The application of the business and technical aspects for requirements prioritization process improves the decision-making quality to support the development of VBS. However, this research has presented a pilot study of the technique and still there is a need to apply the proposed technique on more projects in order to generalize the results.

A. Experts Teams Judgement The expert judgments of the two teams, comprised of technical and business experts, are shown in Table V and Table VI. 1) Team A TABLE.

V

Requirements Requirement 1 Requirement 2 Requirement 3 Requirement 4 Requirement 5 Requirement 6 Requirement 7 Requirement 8 Requirement 91 Requirement 10 2)

Priority 5 6 7 8 10 9 1 3 2 4

ACKNOWLEDGMENT This research work is conducted at the University Teknologi Malaysia by the Software Engineering Research Group (SERG) and is funded by Ministry of Science, Technology and innovation Malaysia (MOSTI) under vote no. 4S064.

Team B TABLE.

VI

Requirements Requirement 1 Requirement 2 Requirement 3 Requirement 4 Requirement 5 Requirement 6 Requirement 7 Requirement 8 Requirement 9 Requirement 10

Priority 6 5 9 8 10 7 1 3 2 4

REFERENCES [1] S. Kauffman, At home in the universe: The search for the laws of self-organization and complexity: Oxford University Press, 1995. [2] B. Boehm and L. G. Huang, "Value-based software engineering: a case study," Computer, vol. 36, pp. 33-41, 2003. [3] A. Aurum and C. Wohlin, "A value-based approach in requirements engineering: Explaining some of the fundamental concepts," in Requirements Engineering: Foundation for Software Quality, ed: Springer, 2007, pp. 109-115. [4] J. Azar, R. K. Smith, and D. Cordes, "Value-oriented requirements prioritization in a small development organization," Software, IEEE, vol. 24, pp. 32-37, 2007. [5] M. I. Babar, M. Ramzan, and S. Ghayyur, "Challenges and future trends in software requirements prioritization," in Computer Networks and Information Technology (ICCNIT), 2011 International Conference on, 2011, pp. 319-324.

Table V and VI contain list of all those requirements which are prioritized by team A and team B respectively. Each team consists of 5 members. Two members are technical experts; two members are business experts and a team lead is an expert of both aspects. This prioritized list is compared with the prioritization matrix to determine the difference of opinion between two methods. According to the results given by the teams, there is a slight difference in the priority order of the requirements 1, 2, 3, 4 and 6. It shows that the priority list produced in table V and VI is almost same. This similarity is an evidence for the contribution made by technical and

5

[6] P. Achimugu, A. Selamat, R. Ibrahim, and M. N. r. Mahrin, "A systematic literature review of software requirements prioritization research," Information and Software Technology, vol. 56, pp. 568-585, 2014. [7] M. Vestola, "A Comparison of Nine Basic Techniques for Requirements Prioritization," 2010. [8] M. Khari and N. Kumar, "Comparison of Six Prioritization Techniques for Software Requirements," Journal of Global Research in Computer Science, vol. 4, pp. 38-43, 2013. [9] K. E. Wiegers, "First things first: prioritizing requirements," Software Development, vol. 7, pp. 11-19, 1999. [10] J. Karlsson and K. Ryan, "A cost-value approach for prioritizing requirements," Software, IEEE, vol. 14, pp. 67-74, 1997. [11] D. Greer, D. Bustard, and T. Sunazuka, "Prioritisation of system changes using cost-benefit and risk assessments," in Requirements Engineering, 1999. Proceedings. IEEE International Symposium on, 1999, pp. 180-187. [12] M. Ramzan, M. A. Jaffar, and A. A. Shahid, "Value based Intelligent Requirement Prioritization (VIRP): Expert Driven Fuzzy Logic based Prioritization Technique," International Journal of Innovative Computing, Information and Control (IJICIC) Vol, vol. 6, 2011. [13] A. Iqbal, F. Khan, and S. Khan, "A critical analysis of techniques for requirement prioritization and open research issues," International Journal of Reviews in Computing, vol. 1, pp. 1-11, 2009. [14] L. Lehtola and M. Kauppinen, "Empirical evaluation of two requirements prioritization methods in product development projects," Software Process Improvement, pp. 161-170, 2004. [15] L. Lehtola, M. Kauppinen, and S. Kujala, "Requirements prioritization challenges in practice," Product focused software process improvement, pp. 497-508, 2004. [16] H. Erdogmus, J. Favaro, and M. Halling, "Valuation of software initiatives under uncertainty: concepts, issues, and techniques," Value-Based Software Engineering, pp. 39-99, 2006. [17] M. Daneva and A. Herrmann, "Requirements prioritization based on benefit and cost prediction: A method classification framework," in Software Engineering and Advanced Applications, 2008. SEAA'08. 34th Euromicro Conference, 2008, pp. 240-247. [18] P. Berander, "Prioritization of Stakeholder Needs in Software Engineering," Understanding and Evaluation. Licenciate Thesis, Blekinge Institute of Technology, Sweden, Licentiate Series, p. 12, 2004. [19] P. Berander, "Using students as subjects in requirements prioritization," in Empirical Software Engineering, 2004.

[20]

[21]

[22] [23]

[24]

[25]

[26]

[27] [28]

[29]

[30]

[31] [32]

[33]

6

ISESE'04. Proceedings. 2004 International Symposium on, 2004, pp. 167-176. A. Egyed, "A scenario-driven approach to trace dependency analysis," Software Engineering, IEEE Transactions on, vol. 29, pp. 116-132, 2003. J. Henry and S. Henry, "Quantitative assessment of the software maintenance process and requirements volatility," in Proceedings of the 1993 ACM conference on Computer science, 1993, pp. 346-351. M. G. Christel and K. C. Kang, "Issues in requirements elicitation," DTIC Document1992. R. B. Svensson, T. Olsson, and B. Regnell, "An Investigation of How Quality Requirements are Specified in Industrial Practice," Information and Software Technology, 2013. K. A. Khan, "A systematic review of software requirements prioritization," Unpublished master’s thesis, Blekinge Institute of Technology, Ronneby, Sweden, 2006. L. Jiang, A. Eberlein, B. H. Far, and M. Mousavi, "A methodology for the selection of requirements engineering techniques," Software & Systems Modeling, vol. 7, pp. 303-328, 2008. C. Li, M. van den Akker, S. Brinkkemper, and G. Diepen, "An integrated approach for requirement selection and scheduling in software release planning," Requirements Engineering, vol. 15, pp. 375-396, 2010. A. Aurum and C. Wohlin, Engineering and managing software requirements: Springer, 2005. F. Belfo, "People, Organizational and Technological Dimensions of Software Requirements Specification," Procedia Technology, vol. 5, pp. 310-318, 2012. H. F. Hofmann and F. Lehner, "Requirements engineering as a success factor in software projects," IEEE Software, vol. 18, pp. 58-66, 2001. A. Perini, A. Susi, F. Ricca, and C. Bazzanella, "An empirical study to compare the accuracy of AHP and CBRanking techniques for requirements prioritization," in Comparative Evaluation in Requirements Engineering, 2007. CERE'07. Fifth International Workshop on, 2007, pp. 23-35. M. Ramzan, "Intelligent Requirement Prioritization using Fuzzy Logic," National University, 2010. J. Karlsson, C. Wohlin, and B. Regnell, "An evaluation of methods for prioritizing software requirements," Information and Software Technology, vol. 39, pp. 939947, 1998. I. Aaqib, "A Hybrid Technique for Requirements Prioritization," International Islamic University Islamabad, Pakistan 2012.