Prioritizing Non-Functional Requirements in Agile Process Using Multi Criteria Decision Making Analysis

Abstract

Agile software development does not include elicitation and management of non-functional requirements (NFRs). Several techniques have been proposed by researchers to elicit, manage and prioritize NFRs. The major issue with such techniques is that they involve customer or users to elicit and prioritize NFRs, which becomes problematic because they do not have exposure of NFRs. They may only be familiar with very few common NFRs such as performance, efficiency and security etc. There could be several other NFRs such as confidentiality, scalability, usability, maintainability, portability, reliability and many others which may not be known to the stakeholders. Consequently, some relevant NFRs may be missed and some wrong NFRS may be implemented in the final product which can degrade its overall quality. Secondly, it is very time consuming to elicit and prioritize NFRs from the stakeholders who have very low exposure. It is especially critical in the case of agile software development where product is developed and delivered at a very rapid pace. To overcome the challenge, this study proposed a model to prioritize NFRs for agile software development to produce quality software products. Thus, firstly, an extensive literature review was conducted to identify the NFRs which were further ranked through a survey carried out in agile software companies. Moreover, the NFRs were analyzed and prioritized using multi criteria decision making analysis technique called analytical hierarchical technique (AHP). The evaluation results showed that the NFRs prioritization model reduce the overhead of meetings and discussion required to gather and identify the NFRs common to agile products.

Multi-Criteria Decision Analysis of Project Management Competencies—A Case Study of Pakistani Non-Governmental Organizations (NGOs)

“…The RI is the random index, various authors have calculated and acquired different RIs dependent on the simulation method and the number of generated matrices involved in the process, Saaty at Wharton simulated with 500 and 100 run2) as shown in Table 9. The acceptable consistency ratio as per [77], [78] is < 0.1 or 10%, so the CR of .069 described in Table 10 is reasonably well within the threshold. Hence the same procedure was applied on dimension and sub-criteria for all the experts.…”

“…E. F. Lane and W. A. Verdini (1989) emphasized that the most important step in AHP is to examine the Consistency ratio (CR) elaborating this step to check the data is consistent or not [75], [76]. Moreover, Saaty recommended that CR below 10 percent is considered acceptable; otherwise, it needs to be revised [77]. For each row of the pairwise comparison matrix, the weighted sum is determined a by summing the product of the entries and the priorities of their corresponding (column) alternatives.…”

Agile Software Requirements Engineering Challenges-Solutions—A Conceptual Framework from Systematic Literature Review

“…Challenge 1 (C1)-Quality Requirements (QR) are neglected. The focus remains mainly on FRs [25]. QRs are ignored during the early sprints [26].…”

“…Literature sources for each challenge. C1 QRs are neglected[6,10,12,17,20,21,[23][24][25][26][27][28][29]37,38,40,46,53,54,63,64,74-82] 30 C2 Minimal documentation [6,10,17,21,23,24,27,28,31-34,37,41,46,47,51,53-56,64,65,77,82] 25 C3 Inappropriate prioritisation method [10,20,21,23,25,27,30,34-37,39,40,46,47,54,59,60,62,74,77,83,84] 23 C4 Managing change [20,21,23,24,28,34,35,38-43,47,53,65,82-86] 21 C5 Poorly written requirements [20,21,27,28,34,37,38,40,44-47,54,55,59,61,71,74,78,87,88] 21 C6 Inaccurate effort estimation [10,20,21,23,24,27,31,40,43,46,48-54,62,89] 19 C7 Customer unavailable or low availability [10,20,21,23,24,27,28,34,38,40,47,53-55,59,65,74,77] 18 C8 Customer knowledge[21,23,24,31,38,46,47,[54][55][56]76,77,90] …”