Predicting NFRs in the early stages of agile software engineering

Abstract

Non-Functional requirements (NFRs) are overlooked whereas Functional Requirements (FRs) take the center stage in developing agile software. Research has shown that ignoring NFRs can have negative impacts on the software and could potentially cost more to fix at later stages. This research extends the Capture Elicit Prioritize (CEP) methodology to predict NFRs in the early stages agile software development. Research in other fields such as the medical field have shown that historical data can be beneficial in the long run. In the medical field it was found that historical data can be beneficial in determining patient treatments. The Capture Elicit Prioritize (CEP) methodology extended the NERV and NORMAP methodologies in previous research. The CEP methodology identified 56 out of 57 requirement sentences and was successful in eliciting 98.24% of the baseline an improvement of 10.53% of the NORMAP methodology and 1.75% improvement over the NERV methodology. The NFRs count for the CEP methodology was 86 out of 88 NFRs which was an improvement of 12.49% over the NORMAP methodology and 4.55% over the NERV methodology. The CEP was used and utilized the EU eProcument requirements document. The CEP methodology utilized the capture methodology by gathering potential NFRs using OCR from requirements images. The elicit part took the NFR Locator plus and takes sentences from documents and places them in distinct categories. The NFR categories are defined from the Chung's NFR framework utilizing a set of keywords utilized for training to locate NFRs. The e αβγ-framework was utilized to prioritize the NFRs. Utilizing the data from previous research of the CEP methodology and extending the CEP methodology to include a decision tree to predict future NFRs. A simple decision tree was utilized to make a prediction utilizing the past NFRs data. If a certain NFR appears three times or higher in the requirements document. It is most likely that NFRs will appear in the next iteration of the software requirements specification. If the NFRs is equivalent to three times it is likely it will appear in the next iteration. If the NFRs is between one and two it is not likely to appear in future iteration. The path can be traced from the root of the tree to a decision tree's leaf (yes or no) that determines whether the NFRs will appear in future iterations. This research showed that using the data available can be beneficial for the next iteration of software development. This research showed that historical metadata can help in predicting NFRs utilizing a decision tree to make a prediction where NFRs appear multiple times in a set of the EU procurement documents can predict the next iteration of software development. The NFRs Availability, Compliance, Confidentiality, Documentation, Performance, Security, and Usability were found and these NFRs are most likely to appear in the next iteration of the EU procurement software.