## 3 Related Studies  
[PERSON] et al. [5] proposed an ambiguity detector tool for assessing requirements specifications by identifying lexical, syntactic, and semantic ambiguities in the requirements. The input of the ambiguity detector is requirements specifications and the corpus. Then, the requirements are processed with a Stanford POS tagger and an algorithm is implemented for detecting each ambiguous sentence. Four SRS documents with different numbers of lines were evaluated to determine the existence of ambiguities in each document. The percentages of the detected ambiguities are shown for each ambiguity. [PERSON] and [PERSON] [6] also implemented the same ambiguity detector for syntactic and syntax ambiguity in SRS documents. The researchers developed a prototype tool to evaluate the proposed approach. However, the study extracts a very limited dataset for the development of the tool, and only displays the detected ambiguity without saving the changes made on the detected ambiguity. [PERSON] and [PERSON] [7] improved this approach by adding referential ambiguity detection. Thus, the researchers tend to present lexical, syntactic, syntax, and pragmatic ambiguity detection in their work; however, only seven requirements were evaluated as a dataset. Nonetheless, all these studies do not perform any performance evaluation for the proposed approach to identify the accuracy of the performed algorithm in detecting ambiguities. In 2017, [PERSON] et al. [9] proposed a natural language processing (NLP) approach to detect domain-specific ambiguities in computer science terminology. The method involves crawling Wikipedia to extract both computer science (CS) and domain-specific documents and pre-process them. Next, the most frequently occurring nouns in CS documents are ranked, and a modified form of each noun is injected into domain-specific documents. The word2 vec method is used to train word embeddings on a corpus of CS and domain-specific documents. Finally, the similarity of embeddings for CS nouns and the modified variants in domain papers is compared, which estimates the variance in meaning of CS nouns when used in different domains. This approach focuses solely on nouns and shows promising results in preliminary studies on five domains. Further validation of this method is needed to avoid misunderstandings when modifying documents and engaging with specialists in relevant disciplines. [PERSON] and [PERSON] [17] described a method for constructing a software system that integrates existing expert tools and controls them using automated compensation algorithms to help end-users create unambiguous and complete requirements specifications. The complete text analysis pipeline is built ad hoc and, hence, is adapted to the specific conditions of a requirements description based on ambiguity indicators. The purpose of this method is to detect ambiguity and incompleteness in natural language software requirements and automatically correct them. This approach not only covers pragmatic ambiguity but also incompleteness, lexical, and syntactic ambiguities. The evaluation result of the indicator quality for incompleteness is 0.73 for accuracy, 0.70 for recall, 0.83 for precision, and 0.72 for F-Score. For referential ambiguity, it scored 0.82 for accuracy, 0.710 for recall, 0.93 for precision, and 0.75 for F-Score. For syntactic ambiguity, it scored 0.80 for accuracy, 0.71 for recall, 0.87 for precision, and 0.74 for F-Score. However, the pragmatic ambiguity covered in this approach is limited to referential ambiguity. [PERSON] and [PERSON] [18] proposed DARA, a method for detecting and resolving ambiguity in SRS. The lexical, referential, coordination, scope, and vague domains are the focus of the tool. DARA also used the provided approach by [PERSON] et al., 2012 [5] in the ambiguity detection design. As a result, the authors highlighted the indicators for detecting each ambiguity handled using a rule-based approach.