الفهرس 
Structure of the thesis
Detecting and Resolving Ambiguity DARA DesignOnly 14 pages are availabe for public view
 |  | from | 78 |  |  |
| | | from | 78 | | |
Abstract
Requirements analysis phase is the first step of software building process. This phase made a Software Requirements Specification document (SRS). SRS document will be the base for development team to build a software application. Requirement Specification is a document that acts as a medium between system developer and users. The document contains sentences and statement that state the functional and nonfunctional requirements. The success of the software is mostly dependent on how well the users’ requirements have been understood and converted into suitable functionalities in the software [1]. Using UML models, information can be effectively represented. These models are useful for realizing the problems, interacting with stockholders and making documentation. Also, in all phases of software development process these models can be used effortlessly. Converting natural language to UML models automatically save time, effort and cost. But, Ambiguity is a critical issue in the software requirement specifications. Ambiguity is best defined by ‘having more than one meaning’, and is inherent to natural language. When we communicate, ambiguity may lead to noise in the communication channel [2]. Through the noise, the message of the sender may not be received as intended by the receiver. Humans recognize and resolve ambiguous words and descriptions by accessing all possible meanings that are stored in the brain. Ambiguity occurs when different readers can interpret a sentence differently. Usually, the users express their requirements in natural language statements that initially appear easy to represent. However, being represented in natural language, the statement of requirements often tends to suffer from ambiguities. Stakeholders are frequently not even conscious that there is an ambiguity in a requirement. Each stakeholder understands from reading the requirements an explanation that diverges from that of others, without knowing this divergence. So, the software developers design and develop a system that does not work as proposed by the users, but the developers justly think they have done the requirements. Because of the inherent ambiguity of NL, it is often difficult to prove properties on NL requirements and it causes high error rate in converting to UML [3]. Therefore, it is necessary for a tool that can detect and remove ambiguity of SRS document. The explanation of the system functions should to be unambiguous, implying that it is free of dissimilar interpretations. If the explanation has more than one possible interpretation, the software programmer may understand an ambiguous word in a manner the customer did not mean. This can lead to a system that does not meet the requirements of the customer. Dissimilar interpretations frequently remain undiscovered till later phases of the software life cycle, when design and implementation selections shape the specific understandings. It costs 50-200 times as much to rectify an error late in a system project compared to when it was presented [4]. Most previous work on ambiguity in requirements engineering tried to address the problem from providing users with a restricted natural language, tool, or handbook to assist with writing less ambiguously. Therefore, it is necessary for an approach that can detect and resolve the ambiguity of SRS document. It can help system analyst in determining and removing the ambiguity of a requirement statement. In this thesis, we illustrate an automated approach for detecting and resolving ambiguities that cause a high risk of misunderstanding by several readers and lead to confusion, waste of both effort and time and rework. Sentences in a natural language requirements specification document that have ambiguity are initial detected automatically from the SRS document and ambiguity type is determined. Sentences that include ambiguity are then resolved automatically also by
III
resolving algorithm based on a set of rules that we collected from training data. We implemented a tool for Detecting and Resolving Ambiguity (DARA), in order to clarify and estimate our approach. The tool focuses on Lexical, Referential, Coordination, Scope and Vague ambiguity, it can classify between them and it can calculate the percentage of each ambiguity type. DARA does not oblige the requirement engineers to write using a particular standard or style. Due to the training data, it turned out that we are currently able to develop a system which can recognize and resolve ambiguity in requirements specifications. We determine on the results of a collection of requirement specification documents to evaluate the performance and utility of the approach. It transpired that increasing the size of our training data, would improve the accuracy