Prioritization of Software Functional Requirements from Developers Perspective

Prioritizing software requirements is important and difficult task during requirements management phase of requirements engineering. To ensure timely delivery of project, software developers have to prioritize functional requirements. The importance of prioritization increases when size of requirements is big. Software for large enterprises like the Enterprise Resource Planning (ERP) systems are more likely to be developed by a team of software developers where large size requirements are distributed in parallel team members. However, requirements are dependent on each other, therefore development of pre-requisite requirements must be carefully timed and should be implemented first. Therefore, assigning importance and priority to some requirements over others is necessary so that requirements can be available on time to developers. This paper proposes a prioritization approach for functional requirements on the basis of their importance during implementation. The design of research method consists of Analytical Hierarchical Process (AHP) technique based on spanning trees. Through spanning trees, dependent requirements were linked in hierarchical structure and then AHP were applied. As a result of prioritization, requirements were distributed in such a way that dependency among requirements of developers were kept minimum as much as possible so that waiting time of requirements for their pre-requisite were reduced. With reduced effect of dependency in requirements of parallel developers, timely delivery of software projects can be assured. Keywords—Requirements prioritization; Functional Requirements (FRs); directed graph; spanning tree (ST); Analytical Hierarchical Process (AHP)


I. INTRODUCTION
Requirements Engineering (RE) is a systematic way of collecting software requirements [1][2] [3]. There are different types of software requirements [4][5] [6]; Business Requirements (BRs) that deal with benefits of implementing requirements, Process Requirements (PRs) that deal with time and cost issues during development, Functional Requirements (FRs) that deal with the actual functionalities of the software, and finally Non-Functional Requirements (NFRs) that deal with requirements such as usability, security, and performance. The collected FRs need proper management in determining issues such as which requirements should be given higher priority, which team member will implement a particular requirement, when the requirements is expected to be delivered, how will the requirements be integrated and other concerns related to requirements management [7] [8].
Requirements Prioritization (RP) is a task in RE that focuses on giving priority or ordering a group of requirements [9] [10]. Techniques such as cost-value ranking, attribute goaloriented, and value-oriented approaches work well for BRs in combination with high level FRs [11] [12]. FRs are prioritized either from client's perspective or developer's perspective [13] [14]. FRs from client's perspective are normally high level requirements that are also known as user requirements (URs). Techniques like the Analytical Hierarchical Process (AHP), binary trees, Genetic Algorithm (GA) are more suitable to prioritize FRs from user perspective [15][16] [17]. Meanwhile, techniques like Quality Function Deployment (QFD) and contextual preference-based technique are suggested for prioritizing NFRs [18] [19]. Although most of the techniques like AHP work well for small size requirements, they are not scalable and suitable to apply on large requirements. While machine learning techniques and intelligent based techniques such as Artificial Neural Networks (ANN) and SNIPR are suitable for prioritizing large-sized FRs, but they are not suitable techniques to prioritize FRs from developer's perspective where requirements are distributed in parallel development team [20][21] [22].
As FRs are not isolated but inter-related so prioritization of FRs is necessary especially when parallel team members are assigned to implement the entire requirements. Giving importance and priority to some requirements over the others is necessary so that pre-requisite requirements can be available on time for other requirements. According to [23], successful projects are not only those that meet all their FRs and NFRs but timely delivery of these requirements is also necessary. Most of big size software's fail to deliver in time, thus proper management and prioritization of FRs from developer's perspective is necessary for successful implementation and delivery of any software project [24].
Although the current prioritization techniques are able to prioritize FRs from user perspective effectively in selecting particular modules or requirements, the same techniques are not either capable or applied to prioritize FRs from developer's perspective when it involves the internal structure and dependency of one requirement on others. Another problem is that most techniques are suitable for prioritizing small-sized requirements but not scalable for large set of requirements. Therefore, a new prioritization is needed for focusing on prioritizing FRs from developer perspective Technique like AHP can be applied with pre-defined prioritization rules to FRs but it is not scalable for big-sized requirements. However, we can use technique such as AHP that pairwise compare requirements to prioritize requirements from developer's perspective.
To address this gap, this research work proposes a new approach to prioritize FRs using AHP but based on spanning trees, called the SAHP. The proposed prioritization approach will then be evaluated on FRs of ODOO ERP as case study. Finally, this paper will also investigate the scalability of SAHP in ERP systems by comparing time complexity of the SAHP with existing AHP. The remaining of this paper proceeds as follows. Section 2 presents preliminary studies related to AHP. Section 3 presents the proposed AHP based on Spanning Trees called the SAHP. Section 4 reports evaluation of prioritization experiments using requirements of ERP system. Section 5 presents efficient distribution of requirements in parallel team members and finally Section 6 concludes with some indication for future work.

II. BACKGROUND STUDY
Analytical Hierarchical Process (AHP) is an organized decision-making method that is intended to compute complex multi-criteria decision problems. AHP is technique that is also applied efficiently in many other fields such as biology and social sciences for prioritization. In fact, AHP is the utmost frequently discussed prioritization technique within decision making in requirements engineering. AHP is led by comparing all possible pairs of hierarchically categorized entities such as requirements as well as stakeholders for obtaining comparative priorities for all objects [15].
Research in [25] revealed that AHP is capable of improving total time of calculations for pairwise comparisons of the requirements by using eigenvalues and matrix evaluation. The research also proposed Consistency Index (CI) to remove errors like inconsistency. Basically the requirements are arranged in groups called bins in the form of hierarchy. This form of prioritization although be helpful in those cases where requirements are not too much and we need to prioritize with the help of AHP. Number of comparisons will be less as compared to traditional AHP but still it fails large set of requirements.
According to [26], although we assign priorities to FRs, we can also assign priorities on the basis of PRs. The work discussed prioritization of PRs by considering both local priority and perspective priority and proposed the Correlation-Based Priority Assessment (CBPA) that prioritizes requirements from different stakeholder perspectives while to highlight the key issues among them. Two types of requirements were considered (1) from business point of view and (2) from management point of view. Increased profit, lead in competition, reduced cost of development, reduced time to development are business-oriented process requirements while maintaining a project within budget, on schedule, high customer satisfaction, increase productivity are managementoriented process requirements that are considered and prioritized in the research work by author. The relationship between different requirements, its prioritization and impact are discussed in the paper in the form of matrix. Apart from PRs, prioritization of requirements from multiple stakeholder's point of view is also discussed. High priority requirement needs more attention and leads to project success [26].
Apart from fully AHP-based solutions to prioritization of requirements, intelligent-based solution has also been proposed for prioritization of requirements collected from stakeholders by applying machine learning techniques to first group similar requirements, and then apply Artificial Neural Networks (ANN) for further prioritization. Finally, AHP was applied at the end for final comparisons. In first step, before clustering, stakeholders are requested to prepare requirements, then on the basis of profiles of stakeholders and through expert opinions using ANN, requirements can be prioritized [22].
Along with stakeholder preferences, it is also necessary to have prioritization which can handle dependencies in between requirements from user perspective. DRANK is an automated algorithm was presented to perform comparisons based on the importance of dependent requirements and compared the results with AHP and other techniques. Experiments proved that this technique is more efficient and scalable for large size URs [27].
Though many authors have used AHP and tried to reduce number of comparisons from different perspectives, AHP are still unable to cater prioritization of FRs during an active implementation software life cycle. Existing AHP implementation needs user input for pairwise comparison of requirements, while we need this process to be automatic i.e. to take input from its internal structure rather than user. The purpose of this study is to reduce this research gap to prioritize FRs from developer's perspective.

III. PROPOSED AHP BASED ON SPANNING TREE (SAHP)
This section proposes spanning trees based approach to represent FRs and then prioritized with AHP. Spanning tree represents hierarchal order and dependencies of all interrelated requirements. From spanning tree, one can easily pairwise compare requirements with AHP. FRs collected from any sources using appropriate elicitation technique and must be specified in the form of Software Requirement Specification (SRS). In this research, the FRs are represented as alphabets R1, R2, …, Rn and are enclosed in circles as nodes.

A. Spanning Trees
In graph theory, a spanning tree is a subset of graph. A graph G = (V; E) consists of finite set of vertices V and finite set of edges E. Edge is something that connects two vertices. Graphs are useful for the representation of any kind of data in particular sequence [28] [29]. This research uses directed acyclic graphs (DAG) rather than cyclic graphs. Requirements are represented as vertices and arrows in the graph indicates the dependency of a requirement on another requirement. The requirement generates arrow and points to another requirement indicating that it is necessary or required for www.ijacsa.thesai.org another requirement. For example, R1  R2 indicates that R1 is depended on R2 or R2 is required for the completion of R1. Given the requirements collected, Fig. 1 shows the graphical representation of requirements through DAG. Cycles in requirements are not possible because if one requirement is needed for the implementation of other requirement than opposite is not possible e.g. if R1 is required for R2 and R2 is required for R3 than it is not possible that R3 will be required for R2 and R1. Graph based approach is also used in one of our previous research study to related FRs [30].
Spanning trees are special graph that have several important properties. First, if T is a spanning tree of graph G, then T must span G, meaning T must contain every vertex in G. Second, T must be a sub graph of G. In other words, every edge that is in T must also appear in G. Third, if every edge in T also exists in G, then G is identical to T [31]. Spanning trees can be formed simply either by performing breadth-first search (BFS) or depth-first search (DFS) or it can be formed directly from adjacency matrix. Because spanning trees use graph-based search algorithms that are only dependent on the number of vertices in the graph, the algorithms are considerably fast [32] [33]. The general properties of spanning trees are as follows.
The resulting spanning trees from graph of Fig. 1 are shown in Fig. 2. From a spanning tree, one can easily see the need of particular requirement in relation to other requirements.

B. Analytical Hierarchical Process (AHP)
Spanning trees will show the relationship of requirement with other requirements. As shown in Fig. 2, a finite number of spanning trees will be produced from directed graph. Next, AHP will be applied to individual trees or combination of many trees that have common requirements. The main idea is that while applying AHP to spanning tree, only depended requirements will be compared, hence resulting in optimal prioritization in a reduced time. For example, consider the spanning tree with starting node R6 shown in Fig. 2, R6 will be compared with R3, R1 and R7 as it is required for all these requirements. However, R7 will be not compared with R1 or R3 as there is no direct relation with these requirements. In this case, when R6 is compared with R3 or any other requirement, then there is no need to compare between R3 with R6. Requirements that are not depended can be considered as equal during comparison and assigned with value 1. This means with the help of spanning tree, the number of comparisons can be greatly reduced. AHP can be applied to either every spanning tree individually or combination of two or more trees if they have some requirements in common. We have five spanning trees as given in Fig. 2. AHP will be applied to first four spanning trees combined as they are related by some common requirements. First, apply AHP to Tree 5 starting with root R8 and then apply AHP to combined four trees. Table I shows requirements of Tree 5 for comparison and calculation.
From Table I, we can see that we can put value either 1 or greater than 1 while comparing any two requirements. We can only put 1 or greater value where 1 represents equal priority requirements and value greater than 1 represents those requirements that have not equal priorities. For instance, we can use values such as 2, 3, 4, …, n for requirements that are not equal in priorities. If we increase the value, the difference in both requirements will be increased. The value 2 is taken for requirement that is needed for other requirement. For instance, if R1 is required for R2 and R2 is required for R3, then we will put 2 for R1 against R2 and will put 4 for R1 against R3. The value 1 is taken for requirements that have either equal priority or not related and 2 against those requirements that need this particular requirement as well and value ½ for the reverse case. In this case, as R8 is required for R9, therefore the value is 2 against R9 for R8. Priority value for each requirement against other requirements is shown in Table I e.g. priority of R9 against R8 is 0.5 which means priority of R8 is double as compare to R9. For independent requirements like R10 and R12, we put value 1 because these requirements have no relation.
Next, the task is to calculate normalized values for each requirement by dividing the values of each column value in Table I by column sum. Column sum for each column is shown in Table II. For example, the value 1 in the first row and the first column will be divided by 2.5, which comes to 0.4. Consequently, normalized values for each requirement are shown in Table II. The column sum2 represents the averaging over normalized values for each row. The same process is then repeated for the combined four trees together and the values obtained in shown in Table III.  The column sum2 also shows the priority value of every requirement of the spanning tree, in particular, or combination of spanning trees. The sum of these sum2 values will equal to number of requirements i.e. 7. These values can be divided on number of requirements to find priority of requirements out of 1. For considering whole set of requirements i.e. In 14 requirements, priority value will be divided on 2 (2 is sum value for all requirements priorities). Column value z for Table II and Table III shows priority out of 14 requirements. Priority out of 14 is calculated. Similarly, for calculating priority of requirement in 100, value 100 is multiplied.

C. Time Complexity of SAHP
Time complexity of AHP depends on total number of pairwise comparisons. With spanning tree, total number of comparisons are reduced because of limited number of relations. Either we consider combination of all spanning trees in one table or individual trees, the number of comparisons of dependent or related requirements will be always same (from adjacency matrix one can see how much relations exists). The number of comparisons in all cases will depend on how much relations of requirements in graph exist. In this example, as only 20 relations are possible, the total number of comparisons will equal to only 20. Therefore, in this way, number of necessary comparisons are reduced from n*(n-1) / 2, which was from 91 to only 20 in this example. This reduction in value shows the advantage of using spanning trees for related depended requirements only. Overall values and calculations during comparing requirements can be reduced by considering individual trees for prioritization as explained.
For given requirements set, maximum relations that can exists are equal to ((n-1) + (n-2) + (n-3) + . . . + (n-n)), where n are total number of requirements. This is possible when all requirements are connected point to point in chain like structure such that one requirement is dependent on other requirement. The value of n will be decremented and will be added until it reaches to 0. In such case, total number of comparisons will become n*(n-1) / 2 which is equal to number of comparisons of AHP. The minimum number of relations will be 0 in any requirements set. In such case, priority of all requirements will be consider to be equal i.e. 1. Fig. 3 shows number of comparisons of two techniques i.e. AHP without spanning trees by considering all requirements and AHP with spanning trees. Let's take 10 requirements. Minimum possible relations are 0 while maximum relations can be 45. Any number of relations can be possible between 0 and 45. The orange linear line of Fig. 3 shows that number of comparisons in this proposed approach is directly proportional to number of relations. It is equal to 45 i.e. case of AHP where maximum relations exist. In small set of requirements where requirements are few in amount, this is possible that maximum relations exist (number of relations reaches number of requirements) such that each requirement is point to point connected with other requirement but we rarely can see such number of relations in large set of requirements like ERP.
From this discussion, it can be concluded that by comparing only the depended requirements through spanning tree, the number of comparisons and calculations can be greatly reduced. Therefore, although total comparisons of dependent requirements are same in all cases, but as the entire project, the number of comparisons and calculated normalized values are not same due to independent requirements.

D. Requirements Priority
Priority is assigned to requirements on the basis of its position in spanning tree i.e. how much they are needed and dependent on other requirements. Requirements need can either increase breadth-wise or depth-wise. In either case, priority can increase but priority values in both cases can be different. Similarly, priority of requirement can decrease when requirements are dependent and wait for other requirements.
AHP can be applied for calculating priority of requirement on the basis of how much they are depended or required for other requirements. AHP is simple and accurate prioritizing technique that can find priority of requirements by comparing pairwise all requirements together. If requirement let say R1 is required for R2 and R2 is required for R3, then priority of R1 can be taken as double of R2 or it can be said that priority of R1 is two times as compared to R2 while R1 priority is 4 times as compare to R3. The following scenarios show different cases of requirements behavior as they change when applied with AHP.

Scenario 1:
In this scenario priority of requirement is determined when its need for other requirements increases breadthwise. Breadthwise contain all requirements on same level with same priority. Two cases can be considered here, one with seven requirements and other with five requirements and calculate priorities.

Case 1:
In this case, R1 is required for six other requirements with all requirements on same level with same priority as shown in Fig. 4. www.ijacsa.thesai.org Through AHP, we have calculated priority of R1 by comparing all seven requirements together which is equal to 1.75. R1 is considered to be double in priority as compare to individual requirements during pairwise comparison. The priority of all other requirements is shown in Table IV.  Table IV summarizes priority values for all requirements.

Case 2:
In this case, R1 is required for four other requirements with all requirements on same level or priority in Fig. 4. Now priority of R1 is reduced to 1.32 as shown in Table IV.

Scenario 2:
In this scenario, requirements size increases depth wise. In case 01 of scenario 1, R1 is required for six other requirements in depth wise structure such that one requirement is depended on other requirement as shown in Fig. 5. In case 02, number of requirements that need R1 are reduced from six to four. Priority of R1 in first case comes out 3.5 while in second case it is 2.21. The priority of R1 in 2 nd case of scenario 2 (required for four requirements) is still greater than case 01 of scenario 1 (required for six requirements). This shows priority increases with greater ratio depth wise and this has advantage because in scenario 1, R1 is available to all requirements after implementation but in scenario 2, it is not available to all requirements e.g. R7 in scenario 2 can't be implemented when R6 is not available but in scenario 1, all requirements are dependent on R1.    Fig. 6 shows the priority of R1 against R6 and R7 will be equal to ½. The sum of reciprocal values will reduce the priority of requirement. Priority of R1 is now 1, which is minimum as compared to all cases. Priority of other requirements are shown in Table IV.
From values given in above Table IV, it can be concluded that requirement priority is associated with its increasing size but the ratio in which it increases depth wise is greater than breadth wise and it should be increase with high ratio in depth wise as compare to breadthwise because in breadthwise, the pre-requisite requirement is available for all requirements and the delay is not too much as compare to the case of depth wise where pre-requisite requirement is not available for all requirements and by delaying this requirement can delay the implementation of its requirements more in case of parallel developing project.
Similarly, if number of pre-requisite requirements and number of requirements for which particular requirement is needed are equal then priority of requirement will be equal. For example, in Fig. 7, the number of backward and forward requirements for R1 are equal, in all cases priority of requirement will be equal. With AHP, we have calculated priority of R1 that is 0.84 for all cases of Fig. 7.

A. Results and Discussion
Results of prioritization of ODOO ERP requirements after applying suggested framework using AHP and spanning tree combination have been calculated. Requirements are prioritized by applying the same criteria discussed.  Table VI.

B. Time Estimation
Time estimation is time taken by particular requirement to complete its implementation. Every requirement consume certain amount of efforts on the basis of which time can be calculated. Many models are suggested by authors for calculating efforts and time estimation of requirements and projects. We applied USE CASE point (UCP) estimation technique which was simple in use and more appropriate for our requirements. The UCP estimation method was presented initially in 1993 by Karner estimates efforts in person-hours based on use cases that primarily specify FRs of a system [11] [12]. Use cases are assumed to be developed from scratch, be sufficiently detailed and typically have less than 10-12 transactions. The method has previous been used in numerous industrial software development projects. There have been promising outcomes and the method was highly accurate than expert estimates in industrial trials.
UCP defines the functional scope of the system to be developed. Attributes of a use case model may therefore serve as measures of the size and complexity of the functionality of a system. After following all steps of USE case estimation technique, effort in hours for each requirement is calculated. After approximation, we have divided requirements into three categories as follows.
 First category contains requirements that take approximately 20 hours to complete its implementation. This is time just needed to implement requirement with functionalities. This time contain unit and integration testing time.
 Second category contain requirements that contain requirements that take approximately 30 hours to complete its implementation.
 Third category contain requirements contain requirements that take approximately 60 hours to complete its implementation.
Completion time of particular module will be sum of time taken by all its requirements. This time reduces when the project is to be developed by parallel team members. But total actual time can exceed calculated time in parallel development projects because requirements are interrelated to each other's and waiting time for particular requirements can cause delay in projects. The purpose of prioritization is to minimize the delay or waiting time.

V. DISTRIBUTION OF REQUIREMENTS IN PARALLEL DEVELOPERS
From results of prioritization we can conclude that not only priority value and order of requirements is necessary for reducing delays and assuring timely delivery of project but www.ijacsa.thesai.org distribution of requirements in team members is also necessary. Total delivery time of project is equal to maximum time taken by any team member to implement all requirements. Distribution of requirements as shown in Table VIII are not uniform e.g. actual time estimation of requirements of A = 410 hours, B = 610 hours, C = 880 hours and D = 670 hours. Total delivery time of the project can exceed from 880 hours due to waiting time which is the maximum time of team member C but total time can't be less than 880 hours. This is because C is given those requirements which take more time in hours. Efficient distribution will be in that case where everyone is given requirements with same efforts. The generalized formula we can make for equal distribution is as follows.
Where total efforts (man hours) = Total efforts (for all requirements starts from R1 to Rn).
From this formula, we will get average time for every team member which becomes 660 hours. If every team member gets no more than 660 hours than in ideal case total estimation time of delivery of project can be 660 hours which is reduced from 880 hours. This means further adjustment will be needed to reduce time estimation more and for this purpose some requirements of C can be assigned to A.
Along with equal distribution of requirements, we should reduce dependency among requirements of different team members as much as possible. Requirements of A that are required for C can be adjusted and can be assigned to C. Similarly, some requirements of C can be adjusted and implemented by A. From the spanning tree, one can easily identify which requirements are dependent on each other, so dependent requirements can be assigned to same team members. In ideal case, distribution of requirements will be uniform and dependency between different team member requirements will be zero.
The best way to distribute requirements is thus assigning requirements of whole spanning tree to same team member. Requirements of spanning trees should be adjusted in such a way that every team member get requirements with equal weight of man hours. Team members can either implement big spanning tree requirements or requirements of many small spanning trees. If some trees requirements are distributed in more than one member than requirements should be prioritized in order to reduce the waiting time.

A. Combining and Splitting the Spanning Trees
If two or more than two trees have some common requirements than we can combine two trees and consider as one group. The reason is that common requirements are depended on requirements of more than one trees requirements and hence this dependency can increase waiting time and cause delays in parallel developing projects. Splitting process is taken when tree size is either big or difficult to assign all its requirements to single developer or sometimes small size trees are split to assure equal distribution of requirements. Table VIII shows how different trees are combined. Six groups were made as result of combining trees with common requirements. Total efforts in man hours for each group are also shown below. It is better to split tree at edge where two trees are combined for assigning requirements to different developers. For example, T9 and T10 are combined with R54, so the tree can be break here. Common requirements can be assigned to any tree. Common requirements normally get low priority as they are dependent on other requirements. Similarly, T4 and T6 are combined with R42. In this case, we can break here (edge of R42) in order to equally distribute requirements. Common requirements can be adjusted with any tree requirements. But for equal distribution in terms of time efforts, especially in case where a single tree is quite large and needs to split, then we will split it. In such case, try to split an edge and assign those requirements that have significantly high priority difference from their parent requirements. It is better to split at edge where there exists quite big difference in priorities between two requirements. E.g. if tree T4 is to be split, there can many options, either to split edge at R60, R66, R35, R70, R71 or R90.
The difference in priorities between R34 and R35 is less as compare to other requirements because R35 is high priority requirement, so splitting at R35 can increase waiting time if R35 is assigned to different team member. Splitting at edge of low priority requirement and assigning it to other team member will decrease the effect of dependency and waiting time. For maintaining balance and equal distribution, more than one trees can be split e.g. T3 can be split along with T4 but at point where there exists quite difference in priority.
Thus from values of SAHP, distributed priority can be determined requirements can be easily assigned to team members such that effect of dependency in requirements become low as much as possible.

B. Distribution of Requirements
Requirements will be distributed in such a way that there does not exist either relation between requirements of different team members or if relation exist, then requirements should be prioritized so that waiting time can be reduced and timely implementation of requirements can be assured. Few cases are considered for distribution of requirements as shown below.

1) Distribution of requirements in 2 team members:
In distributing requirements based on efforts in man hours per team member, the value will be equal to 1325 hours i.e. half of total 2650 hours. There is no need to split any tree or group of trees because different groups can be managed to produce total efforts of 1325 hours. We can assign requirements of groups B, C, D to one developer for implementation and groups A, E, F along with 470 individual requirements to second developer. In this way two different developers will get independent requirements with no relationship between any two requirements.
2) Distribution of requirements on 3 team members: In this case efforts per team member will be equal to 880 hours. While distributing requirements on three developers, it is must to split large tree or group of trees to assure equal distribution of requirements on developers. Requirements with total efforts of 350 hours were separated from group B. The separated requirements from any tree of group based on values of SAHP. Group B requirements after splitting will remain with efforts of 880 hours. In this way two sub groups are made. Sub-group with 350 hours can be adjusted with groups C, D, E, F and 300 hours of individual requirements to comprise total of 880 hours. Similarly, requirements of group A can be implemented along with remaining individual requirements i.e. 170 hours. In such way equal distribution of requirements can be assured. After distributing requirements, it is necessary to prioritize it to reduce waiting time and delays in project.

3) Distribution of requirements in 4 team members:
To assure equal distribution of requirements, every team member will get requirements of 660 hours. For equal distribution, we can split group B into two subgroups with 640 and 590 hours. Similarly group A can be split into two subgroups with 660 and 60 hours. Splitting Group A were necessary as requirements of A were exceeded from 660 hours. Efficient distribution and prioritization of requirements reduces the effect of dependency between requirements and waiting time in parallel developing projects which results in timely delivery of projects. Separated requirements are shown in Table IX. This paper proposed an approach for prioritizing FRs using AHP based on spanning trees. The proposed approach of SAHP has been presented in detail with evaluation on ODOO ERP system. The proposed framework is capable of prioritizing large-sized FRs while in active development cycle. As FRs are inter-related, so prioritization will help in easy arrangement of requirements. Similarly, apart from its implementation priority, in which the requirement is prerequisite for other requirements, if we compare two requirements that are totally independent of each other, then deciding about which requirement is more important is a very important task. Importance of requirement was measured from how much it can reduce delay or waiting time.
Prioritizing and implementing important requirements decrease not only total estimation time but also decrease noncritical delay. Although non-critical delay does not increase estimation time of the project, it affects the waiting time of requirements. Another big problem that needs to be solved is that how much the proposed technique is scalable of handling and prioritizing large requirements size. Prioritizing large size requirements on the basis of its importance was solved using AHP and spanning tree in combination. AHP is used because it can solve dependency issues of requirements as it statistically compares pairwise for each and every requirement against other requirements. Requirements were represented with directed graph and spanning tree. From spanning tree, it became easy to decide about not only which requirement was necessary for other requirement but it became easy to compare all neighbor requirements that belong to same tree. AHP was applied to each tree separately and only depended requirements were scored value greater than 1. Priority of all other requirements during comparison were considered equal.
The results were obtained and were evaluated on parallel developing requirements of ODOO ERP. From different cases for prioritized and un-prioritized requirements, we showed that the proposed framework not only deal with big size requirements but reduce all possible delays in projects. We have shown that how spanning tree can help in equal and efficient distribution of requirements in parallel developing team members so that the effect of dependency and waiting time of requirements can be reduced. In future, we aim to do more industrial based experiments in order to validate framework on big projects and get feedbacks from industry.