Figure 1 - uploaded by Muhammad Qasim Riaz
Content may be subject to copyright.
Types of ambiguities
Source publication
Abstract—Requirements Engineering is one of the most
important phases of the software development lifecycle. The
success of the whole software project depends upon the quality
of the requirements. But as we know that mostly the software
requirements are stated and documented in the natural
language. The requirements written in natural language can...
Contexts in source publication
Context 1
... in natural language are the confusions which are caused due to grammatical errors, use of invalid words or sentences with multiple meanings or due to lack of details [6]. The figure 1 shows the major types of ambiguities, which are also explained following: ...
Similar publications
Citations
... Papers like Riaz MQ's 2019 study [35] (Global Citation Score-7) and Osama M's, 2020 work [36] (Global Citation Score-1) demonstrate a keen focus on detecting and resolving ambiguities in software requireme112nts using NLP techniques. This theme resonates across several papers, emphasizing the importance of clarity in requirement engineering and the role of NLP in achieving it. ...
... Historiograph network map for the citation landscape[17,[30][31][32][33][34][35][36][37][38]. ...
This systematic literature review examines the integration of natural language processing (NLP) in software requirements engineering (SRE) from 1991 to 2023. Focusing on the enhancement of software requirement processes through technological innovation, this study spans an extensive array of scholarly articles, conference papers, and key journal and conference reports, including data from Scopus, IEEE Xplore, ACM Digital Library, and Clarivate. Our methodology employs both quantitative bibliometric tools, like keyword trend analysis and thematic mapping, and qualitative content analysis to provide a robust synthesis of current trends and future directions. Reported findings underscore the essential roles of advanced computational techniques like machine learning, deep learning, and large language models in refining and automating SRE tasks. This review highlights the progressive adoption of these technologies in response to the increasing complexity of software systems, emphasizing their significant potential to enhance the accuracy and efficiency of requirement engineering practices while also pointing to the challenges of integrating artificial intelligence (AI) and NLP into existing SRE workflows. The systematic exploration of both historical contributions and emerging trends offers new insights into the dynamic interplay between technological advances and their practical applications in SRE.
... There is semantic ambiguity when the meaning of a sentence can be interpreted in multiple ways based on its context [31]. While in pragmatic ambiguity, a sentence can have multiple contextual meanings [32], [33]. ...
Requirements specifications written in natural language enable us to understand a program’s intended functionality, which we can then translate into operational software. At varying stages of requirement specification, multiple ambiguities emerge. Ambiguities may appear at several levels including the syntactic, semantic, domain, lexical, and pragmatic levels. The primary objective of this study is to identify requirements’ pragmatic ambiguity. Pragmatic ambiguity occurs when the same set of circumstances can be interpreted in multiple ways. It requires consideration of the context statement of the requirements. Prior research has developed methods for obtaining concepts based on individual nodes, so there is room for improvement in the requirements interpretation procedure. This research aims to develop a more effective model for identifying pragmatic ambiguity in requirement definition. To better interpret requirements, we introduced the Concept Maximum Matching (CMM) technique, which extracts concepts based on edges. The CMM technique significantly improves precision because it permits a more accurate interpretation of requirements based on the relative weight of their edges. Obtaining an F-measure score of 0.754 as opposed to 0.563 in existing models, the evaluation results demonstrate that CMM is a substantial improvement over the previous method.
... Each type of ambiguity caters for different ambiguity problems. Lexical ambiguity occurs when a word contains multiple meanings [8] [9]. It is further divided into two sub-types: homonymy and polysemy. ...
... Referential, coordination [12], and scope ambiguity [13] are the sub-types of sematic ambiguity. Pragmatic ambiguity occurs when human contextual knowledge and common-sense knowledge are uncertain [8] [11]. Whereas Language Errors are caused due to poor grammatical structure [14]. ...
... It means, under this ambiguity there can be multiple expressions of a sentence if translated [43]. Semantic ambiguity has three ambiguity types i.e. referential, coordination, and scope ambiguity [8]. Coordination ambiguity has further two kinds: 1) when "and" or "or", more than one conjunction is used in a sentence. ...
Ambiguity in natural language requirements is an inherent challenge. Ambiguity arises when the user does not participate in the system development. Ambiguity once incorporated seeps into later stages of system development. In traditional software development approaches ambiguity is addressed at the inspection phase, which is manual, labour intensive and costly activity. Researchers have proposed several methods, techniques, approaches, tools etc. for avoidance, detection, and removal of ambiguity once requirements are specified. However, all the approaches utilize time and effort and require manual intervention. To the best of our knowledge, there are very few studies present in literature that focus on reducing ambiguity during requirements elicitation. Traditional techniques are reactive and address ambiguity once requirements are specified. We propose that a pro-active approach is needed for addressing ambiguity early i.e., during elicitation. Doing so will result in unambiguous requirements that can lead to successful development. The proposed approach uses gamification i.e., use of game elements to engage users and keep them interested while performing the task at hand i.e., elicitation of unambiguous requirement. The approach is supported via Gamified tool Gamify4Req, which uses the game concepts of avatar, leaderboard and points and badges. The validation of the tool is performed on two case studies selected from software market, and user involvement is measured with help of a questionnaire. The findings show that the gamified tool outperforms the existing methods used in the industry for reducing ambiguity in requirements both in terms of number of identified ambiguities and time spent on the task. Moreover, the tool ensures user involvement which is measured with help of user involvement survey. usage activity and survey of users.
... In contrast, informal documentation uses natural language to document the requirements that is less reliable and more vulnerable to ambiguities. Regardless, using informal documentation approaches is preferred over formal documentation [4]. ...
... These studies indicated that there are five different methods used by researchers to deal with pragmatic ambiguity. These approaches are knowledge base approaches [4], Controlled Language and Rule Based Approach [9], Machine Learning & Heuristics Based Approach [9], Word embeddings-based approaches [1] [10] [11], and shortest-path search algorithm approach [12] [13]. The literatures also indicate that there are three approaches to deal with resolving pragmatic ambiguity: linked data [8], Score-Based Automatic Resolution approach [14], and web data and semantic knowledge approach [15]. ...
The success of any software must meet the stakeholder's expectations and needs. Requirement specifications are collected from clients and documented in software requirements' specifications. Most software requirement documents are written in natural languages. Natural language requirements may be inconsistent and ambiguous. Such inconsistencies and ambiguities can result in misinterpretations and incorrect implementations in designing and developing of software. The purpose of this study is to detect and correct ambiguity in software requirements. Ambiguity is a statement that has more than one meaning. The most common types of ambiguities are semantic, syntactic, lexical, syntax, and pragmatic. Therefore, this study aims to estimate the degree of ambiguity of typical computer science words (e.g., system, application, database) when used in different domains. Word embedding is used for identifying and detecting ambiguous words in a requirement. Then the study uses linked data for resolving ambiguity words. To evaluate the proposed tool, open-source software specification documents was used to check its performance by comparing human detection and correction capacity and the outcome demonstrates that humans have difficulty detecting and correcting ambiguity in software requirement specifications (SRS) from one domain to other domains as compared to the proposed tool. The result shows that the developed tool was accurate in detecting and correcting pragmatic ambiguities, compare to human.
... is type of ambiguity occurs when a word has more than one meaning [13,14]. It is divided into two parts homonymy and polysemy. ...
... Homonymy arises as a word with distinct meanings along with etymologies (same spellings but different meanings) [15], e.g., bank: "world bank means a depository of financial institution" and "sloping land." Polysemy word consists of several meanings that are interrelated but etymology or having different contexts [14] i.e., word "green" may represent green or a fruit that is unripe [16]. Previously, some research has been done on lexical expressions to lead other types of requirements' ambiguity, but lexical ambiguity lacks research [17]. ...
... is is also known as structural ambiguity which arises due to parsing of a sentence in multiple ways, having different meanings [15,18], for example, a sentence "I saw a girl with the binoculars" can be parsed into two different meanings, the girl has binoculars, or I used binocular to see the girl. It is further divided into attachment ambiguity [14]. Attachment ambiguity refers to the doubt of attaching a clause or part of sentence to the other part of the sentence [19]. ...
Requirements elicitation is one of the most significant activities of requirements engineering (RE) process. Poorly specified requirements can lead to a failed project. Various elicitation techniques are used to elicit requirements from the users and other stakeholders, each having its own pros and cons. Lack of user engagement, less user involvement, textual nature of the requirements, time taking process are some of the major problems that make it difficult to perform elicitation via traditional techniques. Moreover, these problems further create other challenges such as ambiguity, inconsistency, and incompleteness in requirements. Currently, researchers have focused on reducing ambiguity in requirements with the help of different techniques such as natural language processing techniques, requirement templates, and formal methods; however, these techniques work on reducing ambiguity during specification or from specified requirements. One of the “young’ and exciting way of engaging users in requirements elicitation of a system is “Gamification’, which helps in user engagement into the system. We intend to discover how gamification helps in reducing ambiguity by engaging stakeholders in an interactive manner. In this review study, we have reviewed traditional techniques used to detect and reduce requirements ambiguity. On the contrary, we have also presented the significance of gamification in requirements elicitation and the popular but effective game elements used in similar systems. Furthermore, this study highlights the significance of using gamification in requirements elicitation, which is beneficial to software development team as well as the users involved in the system.
... Lexical ambiguity happens when one word has more than one meaning [9,10]. Its sub-types are homonymy and polysemy. ...
... Homonymy occurs in a word with distinct meanings with etymologies i.e., same spellings but different meanings [11], such as bank: world bank/riverbank. Whereas polysemy word has several interrelated meanings with different contexts [10], such as the word 'green' may represent the green color or an unripe fruit [12]. Lexical ambiguity is the most common form of ambiguity but lacks research [13]. ...
Software projects are susceptible to failure if requirements are ambiguous, inconsistent, and misunderstood. Previously, researchers have emphasized on reducing ambiguity either in specified requirements or after the elicitation phase. In this paper, we have designed a pro-active gamified tool ‘Gamify4Req’ for reducing requirements ambiguity during elicitation. Gamify4Req incorporated lexical and semantic ambiguity rules, game rules, and effective game elements to elicit unambiguous requirements from users. Furthermore, this study is a part of Ph.D. research on reducing ambiguity, whereas tool implementation, validation, and findings will be covered later.
... The conclusions were that all three tools are performing quite similarly and that the two newer tools, Requirement Scout and QVscribe, did not outperform QuARS which was developed almost 20 years ago. Different techniques, tools, and their technologies are reviewed and discussed in [14][15][16][17]. In these papers, researchers were reviewing the tools and technologies, and they were not experimenting on an actual set of requirements. ...
... In these papers, researchers were reviewing the tools and technologies, and they were not experimenting on an actual set of requirements. In [14] researchers performed a literature review focusing on the tools for automatic detection of ambiguities in the requirements. They extracted 25 tools developed between 2008 and 2018. ...
Requirements engineering is a time-consuming process, and it can benefit significantly from automated tool support. Ambiguity detection in natural language requirements is a challenging problem in the requirements engineering community. Several Natural Language Processing tools and techniques have been developed to improve and solve the problem of ambiguity detection in natural language requirements. However, there is a lack of empirical evaluation of these tools. We aim to contribute the understanding of the empirical performance of such solutions by evaluating four tools using the dataset of 180 system requirements from the electric train propulsion system provided to us by our industrial partner Alstom. The tools that were selected for this study are Automated Requirements Measurement (ARM), Quality Analyzer for Requirement Specifications (QuARS), REquirements Template Analyzer (RETA), and Requirements Complexity Measurement (RCM). Our analysis showed that selected tools could achieve high recall. Two of them had the recall of 0.85 and 0.98. But they struggled to achieve high precision. The RCM, an in-house developed tool by our industrial partner Alstom, achieved the highest precision in our study of 0.68.
... Moitra et al. [8] introduced a tool called ASSERT (Analysis of Semantic Specifications and Efficient generation of Requirements-based Tests) for capturing requirements, backed by a formal requirements analysis engine. Riaz et al. [9] surveyed on the currently available tools and techniques for the automatic detection of natural language ambiguities from software requirements. Demuth et al. [10] is using cloud-based approach in order to check inconsistency in the requirements. ...
Requirements engineering (RE) is one of the most important phases in software development process. Therefore, the handling of inconsistent/ conflicting requirements is considered as a major issue in the requirements phase. Due to the evolving practices of Global Software Development (GSD), where the development team is geographically spread, the phase of RE is more prone to inconsistencies. Many approaches have been suggested to overcome the problem, however, these solutions are very limited in their scope and does not fit the peculiarities of GSD configurations. On the other hand, Block Chain methodology has shown promising results in various domains and has very sophisticated features like transparency and decentralization to support the management of inconsistent requirements. Similarly, Model Driven Software Engineering (MDSE) is marked with abstraction and reducing complexity which may be benefited to handle inconsistent requirements. Consequently, this article introduces a Block chain Oriented Model Driven (BOMO) framework by integrating the concepts of RE and Block Chains in the context of MDSE. This allows the effective management of inconsistent requirements through block chain technique with simplicity as offered by MDSE. As part of the framework, a meta model is proposed which has been subsequently evolved into a Sirius graphical modelling tool. The applicability of the proposed framework has been demonstrated via a case study. Experimental results prove that the proposed framework may be used with sufficient reliability and can be further evolved to handle inconsistent requirements in a promising manner. CCS CONCEPTS • Software and its engineering • Software organization and properties • Software system structures • Software system models •Model-driven software engineering Additional
... One of the areas in which researchers examine methods to improve the quality of requirements is requirement specification. Studies on requirement specification are concerned with issues in requirements such as incompleteness (Dalpiaz, Van der Schalk, & Lucassen, 2018;Riaz, Butt, & Rehman, 2019), traceability (Ali, Cai, Hamou-Lhadj, & Hassine, 2019;Blasco, Cetina, & Pastor, 2020), and internal conflicts (Liu, 1998;Rossanez & Carvalho, 2016;Yen, Liu, & Teh, 1994). In addition to these studies, there are also other studies that advocate employing templates for a more appropriate presentation of the requirements (Petersen et al., 2015). ...
In large-scale projects, the client defines a set of product requirements, which the provider is then expected to deliver within the agreed time, cost and scope. If a client sets ambiguous requirements for the project, this may result in the receipt of an unsatisfactory product. Therefore, reducing ambiguity in product requirements by the client is a critical success factor. Despite its significance and regular occurrence, the requirement ambiguity problem has not yet received a methodological solution that can fit large-scale projects, which commonly include a great number of requirements. This paper proposes a semi-automated approach, which combines natural language processing (NLP) to identify ambiguous terms and statements and a soft computing technique to specify these terms using fuzzy set theory. This work contributes to the current literature on requirement specification by highlighting a line of research which paves the way to leverage the applications of advanced tools to allow the clarification of ambiguous requirements in large-scale projects.
... It is one of the intrinsic problems of natural language that occurs more frequently compared to other types of issues as indicated in the empirical study conducted in [19]. Ambiguities are commonly categorized into four types, namely lexical, syntactic, semantic and pragmatic ambiguities [18], [20], [21], [22]. ...
... According to the recent review in [20], each of the ambiguity types has main subdivisions. Figure 1 shows the types of ambiguities alongside the main subdivisions of each type in solid lines and our extended subdivision in dashed lines. ...
... These major types are explained as follows. Fig. 1: Types of Ambiguity [20] Lexical Ambiguity: refers to a situation where a single word has more than one meaning. This type can be further categorized into homonymic and polysemic types of ambiguities. ...
