Using Interdependencies for the Prioritization and Reprioritization of Requirements in Incremental Development

There is a growing trend to develop and deliver the software in an incremental manner; to achieve greater consistency in the developed software and better customer satisfaction during the requirement engineering process. Some of the developed increments in the incremental model will be delivered to consumers and run in their environments, so a set of these requirements are evaluated, introduced, and delivered as the first increment. Other requirements are delivered as the next step and so on for the next increment. The priority of requirements plays an important role in each increment, but it is precluded by the interdependences between the requirements and resources constraints. Therefore, this paper introduces a model for requirements prioritization and a reprioritization based on these important factors. The first one is the requirement interdependencies which are described as a hybrid approach of tractability list and directed acyclic graph, and the second factor is the constraints of the requirements resources that are used based on the queuing theory for requirements reprioritization. In order to achieve this, two algorithms namely; Priority Dependency Graph (PDG) and Resources Constraints Reprioritization (RCR), were proposed with a linear time complexity and implemented via a case study. Keywords—Requirement engineering; incremental model; requirement prioritization; requirement interdependencies; dependency graph; queuing theory


I. INTRODUCTION
In the incremental software model, small releases of the software are implemented in a series mode instead of providing the whole system after a long period of development. This model efficiently impacts the prioritization of requirements in such a way that the most relevant requirements can be introduced in the system's first releases. On the other hand, later phases are left with less important requirements. When requirements are elicited, a large number of them are often created, which is very difficult to implement them at the same time [1]. This is due to the market impact, the user persisting to have the software finished, and the limitations on cost and staff. Therefore, the requirements need to be prioritized in such a way that the earliest product releases meet the most critical ones, particularly when an incremental model is used, where the product is designed, implemented, and tested incrementally until the product is completed.
The requirements affect each other and are related to each other during software development in a way that prevents treating them separately. This is referred to as the interdependence between requirements. Consequently, requirement interdependency concerns about the relationships between requirements which during software development will influence decisions and activities. This play an important role in the prioritization of requirements, especially with incremental development which requires a careful selection of requirements that meet the growth of the various increments. Choosing one requirement may therefore activate the selection of several other requirements that rely on it.
On the other hand, the literature that discusses the interdependence requirements, limited work has been carried out. Interdependence of requirements is a special form of traceability of requirements that defines the relationships between different requirements. The traceability list, which is a table of relationships describing the dependencies between requirements [1], is one of the techniques for representing requirement interdependencies.
Carlshamre [2] used the directed graph (digraph) to represent the interdependencies between requirements, as well as classifying the interdependencies into five relationships; and, REQUIRES, TEMPORAL, CVALUE, ICOST, and OR, which visualized later by the directed graph. The concern in this approach wasn't to visualize types of interdependencies rather than representing them as dependency graph and apply an algorithm to prioritize the requirements. Another way to represent the interdependencies is to use ontology-based representation and a formal graphical representation to visualize the requirements interdependencies in a proper way [3].
It is possible to prioritize requirements, taking into account several different aspects, such as importance, cost, penalty, time, risk and dependencies [4]. The literature is full of several prioritization strategies for requirements. These include the process of analytical hierarchy (AHP) which is the most common priority-based technique that is designed to permit decision-makers to set priorities and decide the correct decision. Initially, AHP specifies the parameters and substitutes for each requirement and uses them to construct a hierarchy to activate pair-wise comparisons; then the users can determine their favorites for each pair of attributes by assigning a decision scale. However, this technique requires a quadratic time to prioritize the requirements and suffers from scalability issues particularly when the number of requirements increases [5]. The creation of binary search tree, in which each requirement is shown in a node. The tree needs to be prioritized; the low priority requirements are set on the left side of the tree and high priority needs are positioned on the right. Although this method is fast but it the comparison of BST is typical, only showing which requirement is more desirable [6]. Another technique is the bubble sort in which the principle is similar to AHP, where they both make use of the comparison operation pair-wise and they require a time complexity of n 2 . The distinction between them is that it is only possible for the decision-maker to consider which requirement is more significant between the compared requirements in bubble sort. [7]. Cumulative voting or the 100-dollar test is a straightforward process that gives the system's stakeholders 100 units to be divided between requirements. The higher unit requirement has a higher priority and the lower unit requirement has a lower priority. The stakeholder controls distribution process of these units based on the priority of the requirements. However, if there are quite several requirements, this approach has a downside, because this method will not work well and will calculate the prioritization in wrong way. Also, it can be difficult to be aware the quantity of units that must be allocated and those that must be left [8][9]. Spanning trees technique is similar to AHP, where they both make use of the comparison operation pair-wise, but uses the minimum spanning technique. This can be done by the use of spanning tree architecture in order to eliminate the redundant comparisons, consequently, reducing the total number of comparison. On the other hand, it is not efficient when the number of requirements is large [10]. Numerical assignment (grouping) which provides a scale to all requirements based on separating them into different groups. Each requirement will then be assigned to a 5-point scale to assess its significance, however this technique provides low rate of reliability as well as fault tolerance [11][12]. Wieger Method determines the priority of the requirement by dividing the value of the requirement by the amount of costs and the technological risks associated with its implementation, and by assessing its customer significance, by applying 1-9 scale, as well as its implications, if this requirement were not enforced. It has drawback in which the stakeholders can easily influence it to achieve their objective goals [13]. MoSCoW technique is focused on cooperation between analysts and stakeholders to group the requirements into four categories. The efficiency here is good, but human attempts are required with disagreements between analysts and the views of stakeholders, so this approach would therefore be rated as low scalability and other hybrid techniques [14]. Most of the algorithms mentioned previously require quadratic complexity, so for a large number of requirements, the efficacy of the method becomes poor. Several papers were proposed in the literature in order to compare these method [15-17, 22, 23]. The purpose of this paper is not to compare the different approaches, but to suggest a new algorithm for the prioritization of requirements. However, the proposed approach for prioritizing requirements in this paper differs from the previous methods in achieving linear time complexity as well as the ability to reprioritize the requirement based on the resources availability.
The need for reprioritization has emerged from the fact that despite the effort expended in order to prioritize the requirements, this would be influenced by the constraints of precedent and resources constraints [18]. Therefore, this paper aims to introduce a hybrid approach of Traceability list and Directed Acyclic Graph to represent the requirements interdependencies for the prioritization process. As well as introducing a new algorithm for reprioritizing the requirements based on the queuing theory.
As discussed earlier, there are many types of requirement interdependencies mentioned in the literature. So it is worth to mention that this paper, proposed the prioritization and reprioritization requirement algorithms irrespective of the types of interdependencies and the methods used to identify them between the requirements, which are beyond the scope of this paper. Instead of focusing on the types of interdependencies and how they are described in any software project, this paper focuses on prioritizing the requirements based on the proposed algorithms using the proposed dependency parameters.
The paper is structured as follows: section 1 is the introduction and related work, section 2 gives a description of requirements interdependencies, section 3 presents the proposed approach in requirement prioritization, section 4 illustrates the approach as a case study and section 5 is the paper conclusion.

II. REQUIREMENTS INTERDEPENDENCIES
The requirements influence each other and are linked to each other in a way that prevents handling them separately. This can be referred to as the dependencies between requirements. Basically, these requirements can also affect the decisions and activities during the development of the software. Requirements can, for example, affect each other through implementation constraints, the cost of implementing other requirements, or the customer satisfaction [19]. This means that in order to make accurate decisions during the development process, it is important to study the interdependencies.
Simply stated, requirement interdependencies mean that a dependent relationship exists between the requirements. For instance, it is safer to start developing Ri before Rj if the Rj requirement requires Ri to work.

III. METHODOLOGY
A model for the prioritization and reprioritization of requirements based on a hybrid approach of representations of requirements is introduced. Fig. 1. demonstrates this model, which consists of two phases: the phase of prioritization and the phase of reprioritization. The first step can be achieved by prioritizing the requirements using dependency graph, while the next step is used to reprioritize the requirements using the queuing theory. The requirements are presented as a traceability list and then as a dependency graph, as shown in Fig. 1. The dependency graph is subsequently regarded as an input to the Priority Dependency Graph (PDG) algorithm in 225 | P a g e www.ijacsa.thesai.org order to create a priority list of requirements. This list is then processed on the basis of the resources constraints in the system by the Resources Constraints Reprioritization (RCR) algorithm.

A. Dependency Constraints
Any software can be defined as a set of R requirements where R={R1, R2, .... ,Rn}. When an incremental model is followed, then the first increment is analyzed, implemented and delivered as a set of these requirements. Other requirements are delivered as the next step and so on for the next level. In each increment the priority of requirements is playing an important role, but it is often precluded by requirements interdependencies. The approach to prioritizing the requirements in this paper is therefore focused on the representation of dependencies between requirements using the dependency graph. First of all, a simple description of the dependency factors used is discussed below: 2) Dependency volume: The dependency volume determines the number of requirements that are internal dependent on the current requirement.
3) Dependency intensity: The dependency intensity determines the degree of dependency for each requirement, two types are available: a) "Loose Dependencies is defined as: it would be ok to continue task without awareness of dependencies but would be better with awareness" [20]. b) "Tight Dependencies is defined as: the successor task has to wait until all its precursor tasks finish, the failure of the precursor will block the successor" [20].
The first parameter indicates the two main types of interdependencies in our method. External dependency determines whether the requirement in the future increment is dependent on another requirement, and internal dependency determines whether the requirement in the same increment is dependent on another requirement, as shown in Fig. 2.
The precedence constraint defined in the first parameter illustrates the relationship between the requirements in terms of precedence where in any software; the requirements must be implemented before other requirements. Therefore, for all iterations of increments there must be an order in which the requirements are executed. Loose dependencies can be used when there is no strict use of dependency between requirements, such as some requirements in mobile applications that doesn't require awareness of the context of the mobile user, but if provided the software will behave in an efficient manner. On the other hand, tight dependency is for those requirements that must be executed before other requirements as is the case in most software applications.
As depicted in Fig. 2. , the requirements are represented as a dependency graph where a directed acyclic graph (DAG) is used to define the R requirements as vertices V and the precedence constraints as edges E. In order to calculate the priority for each requirement in each increment based on the dependency types mentioned earlier, a topological sorting [21] with slight modifications is then performed.
An example of a dependency graph is represented in Fig. 3. R1 and R9 do not have dependencies in this DAG, while vertices R2 to R10 are dependent on other vertices; R4, for instance, depends on R1. Note that R4 has a volume of dependency greater than R3 that influences its prioritization process.   • InDegree array that contains the number of InDegree edges for each vertex.
• OutDegree array that contains the number of OutDegree edges for each vertex and represent the dependency volume.
• Dependency Scope array that determine the dependency scope for each vertex in the graph whether it is external or internal based on equation 1.
• Dependency Intensity that determine the intensity of the dependency for each vertex in the graph whether it is tight or loose based on equation 2.
The algorithm starts by initializing queue with all vertices that has zero InDegree, then while this queue has vertices in it.
Higher priority will be granted to the vertices with internal dependency than those with external one; if two requirements are equal in the scope of dependency, then the decision can be made based on the volume of dependency. Such that, the requirements with tight dependency intensity will have higher priority for internal dependency than the requirements with loose dependency intensity; the algorithm will calculate the priority for those vertices until it is empty.

B. Complexity Analysis
Consider the complexity analysis of the proposed algorithm. Hence, a queue is used to store the vertices of zero InDegree. So, each time a node's InDegree is modified, we check if the value of it is 0 we add it to the queue, this will take O (|V|). Now to find a node of zero InDegree it takes O (1). The Dequeue operation will take O (|V|) while reducing the InDegree of all adjacent vertices to a vertex will take O (|E|). Therefore, the algorithm can be implemented to run in O (|V| + |E|) which is a linear running time. Note that most of the prioritization methods in the literatures have a quadratic complexity where our algorithm requires a linear one.

C. Resources Constraints Reprioritization Algorithm
As illustrated earlier, requirement prioritization is precluded by the available resources that are needed to develop the requirement or task, therefore the concept of the queuing theory is used to reprioritize and schedule the requirements to the available teams in the system. The method here is based on the outcome from the previous stage where the requirements are prioritized and added along with their priorities to a list or queue. The service facility may have of one or more teams. So, a requirement at the head of the queue can go to any team that is free. If there is more than one team, then a concurrent development will take place.
Each requirement in the queue must have the following characteristics: 1) Arrival Time λ to the queue for each requirement.
2) Waiting Time wt for each requirement, which indicates the waiting time for each requirement.
3) Status S: either FREEZE or INPROCESS. This parameter used to freeze the requirement and their dependent requirements.
4) Old Priority P old , this parameter is used to indicate the old priority for the requirenment. 5) New Priority P new , this parameter is used to indicate the new priority for the requirenment.
6) Available Resources Flag (ARF), this parameter will be used to indicate whether the resources are available to perform the requirement.
The RCR Algorithm involves the following steps: 1) Select the requirement with the minimum λ.
2) Check ARF whether it is set or not.
3) If ARF is equal to zero, then change the state S of this requirement to FREEZE and increment wt by 1.

4)
If ARF is equal to 1 then change the state to IN_PROCESS and change Pold to Pnew and schedule it to the available team. 5) Each time check the ARF for the freeze requirement before reprioritize the new requirement since it has higher priority than it due to the dependency factor. Fig. 4. demonstrates the prioritizer and scheduler that carries out the previous steps for reprioritizing the requirements based on the resources available and schedules them to the available team.

IV. CASE STUDY
To demonstrate our approach in a practical way, a sample software project for a library management system is considered, with three increments and twenty requirements, R = {R1,…, R20}. The first increment contains 9 requirements with the following dependencies:  Table I represents the traceability list for the twenty requirements. This list is converted into a directed acyclic graph which represents the requirements and interdependencies between them; Table II describes the number of InDegree and OutDegree edges for each vertex in the graph, Table III is the findings of the proposed algorithm which represents all the requirements and its associated priorities, notice that the requirement R1 has the highest priority with 2.0. While the requirement R19 has the lowest priority with 0.1, the scale is based on the total number of requirements in the software. Table IV showed the reprioritization process based on the resources constraints. Owing to the unavailability of the tools needed to develop these requirements, those requirements and their dependent requirements are frozen.

V. CONCLUSION
In incremental software model small releases of the software are implemented in a sequence fashion instead of delivering the whole system after a long time of development. Therefore, this model can influence the prioritization of requirements in efficient manner so that the most important requirements can be implemented in the first releases of the system. A model were proposed to achieve requirement prioritization and reprioritization based on requirement interdependencies which represented as a hybrid approach of tractability list and directed acyclic graph, and on the resources constraints of the requirements. The proposed algorithms were introduced, analyzed and implemented using a case study. PDG and RCR algorithms require time complexity of O (|V| + |E|) which is a linear running time compared to the quadratic time complexity provided by the available algorithms that handle requirement prioritization. Also, the proposed approach has the ability to reprioritize the requirement based on the resources availability. Future work may add an improvement to the proposed algorithms or may combine them with other priority algorithms, in order to provide a hybrid solution that enhances the overall process.