## 5 Case Study: Detecting Fault-Prone Software Requirements Specification for Edge/Cloud Application
### Analysis of Fault-Prone Edge/Cloud Application Software Requirements Specification

Table 11: _Cont._In this study, we utilized two models to evaluate the quality of the software requirements specifications (SRS) for edge/cloud applications: the ambiguity classification model (ACM) and the fault-prone software requirements specification detection model (FPDM). The ACM model was used to classify any potential ambiguities in the software requirements for each SRS, which leads to errors or misinterpretations during the development process. The ACM model flags any ambiguous requirements in the SRS, such as lexical, syntactic, semantic, syntax and pragmatic ambiguities. After applying the ACM model to the SRS dataset, the fault-prone software requirements specification detection model (FPDM) was then used to evaluate the fault-proneness of the SRS documents. The FPDM evaluates the SRS documents based on the title, descriptions, and presence of intended users of the SRS. Additionally, the result based on the ACM for detected ambiguous software requirements was included. This approach allows us to ensure that the SRS documents are of high quality and free of potential faults or ambiguities, ultimately leading to a more successful and efficient development process. Based on the results of our analysis using the fault-prone software requirements specification model, we determined that out of the 30 SRS documents collected for this study, 20 were classified as fault-prone due to the presence of ambiguities, which could potentially result in errors or misinterpretations during the development process. Conversely, our analysis using the FPDM found that 10 of the 30 SRS documents had a low number of detected ambiguities. These documents had clear titles and descriptions, included information on intended users, and had well-defined functional and non-functional requirements. Based on this, we consider these 10 documents to be relatively free from any major ambiguities or faults. This assessment of the quality of the SRS documents revealed a significant degree of variation, with some documents being clearly and concisely written, while others contained inconsistencies that could impede the development process. A panel of subject matter experts was assembled for the evaluation of the SRS documents. The panel consisted of six respondents who are experienced in leading and managing software projects, or system analysts with a computer science background and expertise in requirement engineering. Two of the experts had over 10 years of experience, while the remaining four had two to three years of experience in requirement engineering. The experts were presented with a questionnaire that included 30 SRS documents with edge/cloud applications and were tasked with assessing the clarity of the title, adequacy of the system description, suitability of the intended users, and identifying fault-prone SRS based on knowledge and expertise. A brief description of fault-prone and clean SRS criteria was also provided to aid the experts in evaluation. We created a \"Labeling tracker\" to help the experts to keep track of their progress on labeling the SRS. Additionally, the experts were given 14 days to provide feedback, allowing them to review it at their convenience. Based on the FPDM and expert evaluation, the classification of the 30 SRS documents was determined (Table 12). However, only two SRS documents did not match. Specifically, while the FPDM detected one SRS document as \"fault-prone\", the same document was labeled as \"clean\" by the human experts. Hence, for another document, the FPDM detected one SRS document as \"clean\", the same document was labeled as \"fault-prone\" by the human experts. This discrepancy suggests that the FPDM may have a higher sensitivity to identifying potential ambiguities in the requirements compared to human experts. Considering multiple approaches is essential to assess SRS quality to ensure a more accurate and reliable evaluation. Hence, Figure 10 illustrates the comparison of fault-prone and clean SRS based on the year they were established.