Research Articles Open Access

Evaluation and Selection of Non-Functional Requirement based on Integrated AHP, TOPSIS and Fuzzy TOPSIS

Insha Rafique
Available online January 1, 2025
PDF

Abstract

The process of evaluating and choosing non-functional requirements (NFRs) is difficult and demanding. Software malfunctions and up-marks can result from improper NFRs. Several evaluation factors must be taken into account in order to get good performance. It is necessary to ascertain how their methods change in accordance with the review and benchmarking process of NFRs in order to identify the limits of how the criteria are set. The evaluation and benchmarking of non-functional requirements using Multi Criteria Decision Making (MCDM) methods is the main topic of this paper. MCDM uses a variety of methods to identify the best option among several criteria and alternative situations. Weights are assigned to criterion using the Analytic Hierarchy Process (AHP), a multi-criteria decision making method. Distance metrics are used in the Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) to rank and choose various options. On the other hand, criterion weighting and alternative rating are done using FUZZY TOPSIS. NFRs are used for MCDM calculations, and all of these methods are attempted to be discussed. MCDM evaluates and chooses the best NFRs using performance, overhead, and configuration criteria, which helps in identifying solutions for future directions. The results indicate that, in comparison to other NFRs, functionality requirement received better ranking score records.

Keywords

Non-Functional Requirements Multi Criteria Decision Making NFRs evaluation and benchmarks

Introduction

Non-functional requirements (NFRs) describe quality attributes and constraints that influence whether a software system satisfies its expected quality goals [1]-[3]. Requirements prioritization and quality-requirements engineering have therefore received sustained attention in requirements engineering [4]-[6]. Inadequate treatment of quality requirements can create conflicts and management problems during software development [7]-[9]. NFRs are also commonly treated as quality-related properties that need to be identified, analyzed, and evaluated during requirements engineering [1]-[3], [5], [10]. This paper evaluates and ranks NFRs using Analytic Hierarchy Process (AHP), Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS), and Fuzzy TOPSIS. AHP is used to derive criteria weights, TOPSIS ranks alternatives according to their distance from ideal solutions, and Fuzzy TOPSIS extends this decision process to fuzzy values [11]-[15]. The evaluation uses Cost, Security, Conformance, Suitability, and Operability as performance criteria. Their relationship is summarized in Figure 1. The criteria are described as follows:

  • Cost: Cost is the value of money that has been used up to produce deliver a service, and hence is not available for use any longer. In all software cost is money spend to avoid failure.

  • Security: Security is the main issue, software should be safe and ensure the security. Functionality and usability are preferable in terms of Security.

  • Conformance: Software must consist of Supplier should offer a product that can meet standards or grades Buyer provides sample, it should be easy and efficient. So, it is a preferable requirements as compared to other NFRs.

  • Suitability: Suitability check the quality of the software is suitable or not. Functionality and Usability have minimum values. So, both of these are preferable NFRs in terms of suitability.

  • Operability: The qualities of a system which work well over its lifetime, and software operability applies these core engineering principles to software systems. So, Functionality is preferable in terms of operability.

The remainder of this paper is organized as follows. Section 2 presents the methodology used for the evaluation and selection of NFRs. Section 3 describes the MCDM-based evaluation and ranking using AHP, TOPSIS, and Fuzzy TOPSIS. Section 4 reports and discusses the results, including the comparative analysis of the evaluated NFRs. Section 5 concludes the paper.

Complete Article

The complete article, including all figures, tables, equations and algorithms, is available in the official publication PDF.

Conclusion

This paper evaluated and ranked Non-Functional Requirements (NFRs) using three Multi-Criteria Decision Making (MCDM) techniques: AHP, TOPSIS, and Fuzzy TOPSIS. AHP was used to determine the weights of the evaluation criteria, while TOPSIS and Fuzzy TOPSIS were applied to rank the considered NFR alternatives. The analysis considered Functionality, Usability, Efficiency, and Portability using Cost, Security, Conformance, Suitability, and Operability as evaluation criteria. The TOPSIS results ranked Functionality first, followed by Usability, Efficiency, and Portability. The Fuzzy TOPSIS results also gave Functionality a higher reported closeness coefficient than Usability. Therefore, within the criteria and alternatives considered in this study, Functionality emerged as the highest-ranked NFR. The results show how AHP, TOPSIS, and Fuzzy TOPSIS can be integrated to support the evaluation and selection of NFRs. AHP provides criteria weightage, whereas TOPSIS and Fuzzy TOPSIS use relative closeness measures to support the ranking process. The use of fuzzy values further provides a mechanism for representing uncertainty during the evaluation process.

References

  1. Capilla, R., Babar, M. A., & Pastor, O. (2012). Quality requirements engineering for systems and software architecting: methods, approaches, and tools. Requirements Engineering, 17(4), 255-258.
  2. Chung, L, Nixon, B., Yu, E., & Mylopoulos, J. (2000). Non-functional requirements in software engineering-kluwer academic publishers. Massachusetts, USA.
  3. Firesmith, D. (2003). Using quality models to engineer quality requirements. Journal of Object Technology, 2(5), 67-75.
  4. Berander, P., & Andrews, A. (2005). Requirements prioritization. In Engineering and managing software requirements (pp. 69-94). Springer.
  5. Cleland-Huang, J., Settimi, R., Zou, X., & Solc, P. (2007). Automated classification of non-functional requirements. Requirements Engineering, 12(2), 103-120.
  6. Dabbagh, M., Lee, S. P., & Parizi, R. M. (2016). Functional and non-functional requirementsprioritization: empirical evaluation of IPA, AHP-based, and HAM-based approaches. Soft Computing, 20(11), 4497-4520.
  7. Boehm, B., & In, H. (1996). Aids for identifying conflicts among quality requirements. IEEE Software, 13(2), 25-35.
  8. Ebert, C. (1998). Putting requirement management into praxis: dealing with nonfunctional requirements. Information and Software Technology, 40(3), 175-185.
  9. Egyed, A., & Grunbacher, P. (2004). Identifying requirements conflicts and cooperation: How quality attributes and automated traceability can help. IEEE Software, 21(6), 50-58.
  10. Casamayor, A., Godoy, D., & Campo, M. (2010). Identification of non-functional requirements in textual specifications: A semi-supervised learning approach. Information and Software Technology, 52(4), 436-445.
  11. Figueira, J., Greco, S., & Ehrgott, M. (2005). Multiple criteria decision analysis: state of the art surveys (Vol. 78) [BOOK]. Springer Science & Business Media.
  12. Saaty, T. L. (1980). The Analytic Hierarchy Process: Planning, Priority Setting, Resource Allocation. McGraw-Hill International Book Company.
  13. Hwang, C.-L., & Yoon, K. (1981). Multiple Attribute Decision Making: Methods and Applications: A State-of-the-Art Survey. Springer-Verlag. https://doi.org/doi: 10.1007/978-3-642-48318-9
  14. Zadeh, L. A. (1965). Fuzzy sets. Information and Control, 8(3), 338-353. https://doi.org/doi: 10.1016/S0019-9958(65)90241-X
  15. Chen, C.-T. (2000). Extensions of the TOPSIS for group decision-making under fuzzy environment. Fuzzy Sets and Systems, 114(1), 1-9. https://doi.org/doi: 10.1016/S0165-0114(97)00377-1
  16. Abad, Z. S. H., Karras, O., Ghazi, P., Glinz, M., Ruhe, G., & Schneider, K. (2017). What works better? a study of classifying requirements. 2017 IEEE 25th International Requirements Engineering Conference (RE), 496-501. IEEE.
  17. Auriol, G., Baron, C., & Fourniols, J.-Y. (2008). Teaching requirements skills within the context of a physical engineering project. 2008 Requirements Engineering Education and Training, 6-11. IEEE.
  18. Boehm, B., & Egyed, A. (1998). WinWin requirements negotiation processes: A multi-project analysis. 5th International Conference on Software Processes, 125-136.
  19. Breiman, L. (2001). Random Forests, Vol. 45. Mach Learn, 1.
  20. Breitman, K. K., Leite, J. C. S., & Finkelstein, A. (1999). The world sa stage: a survey on requirements engineering using a real-life case study. Journal of the Brazilian Computer Society, 6(1), 13-37.
  21. Callele, D., & Makaroff, D. (2006). Teaching requirements engineering to an unsuspecting audience. ACM SIGCSE Bulletin, 38(1), 433-437. ACM.
  22. Caruana, R. (2000). Learning from imbalanced data: Rank metrics and extra tasks. Proc. Am. Assoc. for Artificial Intelligence (AAAI) Conf, 51-57.
  23. Casamayor, A., Godoy, D., & Campo, M. (2012). Functional grouping of natural language requirements for assistance in architectural software design. Knowledge-Based Systems, 30, 78-86.
  24. Chen, Z. Y., Yao, S., Lin, J. Q., Zeng, Y., & Eberlein, A. (2007). Formalisation of product requirements: from natural language descriptions to formal specifications. International Journal of Manufacturing Research, 2(3), 362-387.
  25. Chung, Lawrence, Nixon, B. A., & Yu, E. (1996). Dealing with change: An approach using non-functional requirements. Requirements Engineering, 1(4), 238-260.
  26. Cleland-Huang, J., & Schmelzer, D. (2003). Dynamically tracing non-functional requirements through design pattern invariants. Workshop on Traceability in Emerging Forms of Software Engineering, in Conjunction with IEEE International Conference on Automated Software Engineering, 10, 1.
  27. Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268-1287.
  28. Dance, C. R., & Seeger, M. (2004, May 25). Method and apparatus for formatting OCR text. Google Patents.
  29. Davis, M. A. (1993). Software requirements. OBJECTS FUNCTIONS & STATUS.
  30. De Weck, O. L., Ross, A. M., & Rhodes, D. H. (2012). Investigating relationships and semantic sets amongst system lifecycle properties (ilities).
  31. Egyed, A., & Boehm, B. (1998). A comparison study in software requirements negotiation. Proceedings, INCOSE'98.
  32. Estabrooks, A., Jo, T., & Japkowicz, N. (2004). A multiple resampling method for learning from imbalanced data sets. Computational Intelligence, 20(1), 18-36.
  33. Farid, W. M., & Mitropoulos, F. J. (2012). NORMATIC: A visual tool for modeling non-functional requirements in agile processes. 2012 Proceedings of IEEE Southeastcon, 1-8. IEEE.
19 10

Similar Articles

You may also start an advanced similarity search for this article.