An Automated Tool for Detection and Tutoring of Sources of Ambiguities in Requirements Documents
Ayat Shaaban1, Hanan Elazhary2, Ehab Hassanein3
1Ayat Shaaban*, Information Systems Department, Cairo University, Cairo, Egypt.
2Hanan Elazhary, College of Computer Science and Engineering, University of Jeddah, Jeddah, Saudi Arabia; Computers and Systems Department, Electronics Research Institute, Cairo, Egypt.
3Ehab Hassanein, Information Systems Department, Cairo University, Cairo, Egypt.
Manuscript received on 6 August 2019. | Revised Manuscript received on 14 August 2019. | Manuscript published on 30 September 2019. | PP: 2371-2375 | Volume-8 Issue-3 September 2019 | Retrieval Number: C4660098139/2019©BEIESP | DOI: 10.35940/ijrte.C4660.098319
Open Access | Ethics and Policies | Cite | Mendeley | Indexing and Abstracting
© The Authors. Blue Eyes Intelligence Engineering and Sciences Publication (BEIESP). This is an open access article under the CC-BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
Abstract: Software Engineering (SE) is the application of essentials to deal with the analysis, design, development, testing, deployment and management – Software Development Life Cycle (SDLC) – of software systems. Requirements Engineering (RE) is responsible for the most critical task in the SDLC; which is transforming the requirements and wishes of the software users into complete, accurate and formal specifications. One of the main responsibilities of RE is the creation of a software requirements document that exactly, reliably, and totally defines the functional and non-functional properties of the system to be developed. At some point through the RE process, the requirements are written using a Natural Language (NL). On one hand, NLs are flexible, common, and popular. On the other hand, NLs are recognized widely as inherently ambiguous. Ambiguity is noticed in a requirement document when a piece of text is interpreted in distinct ways. This may lead to erroneous software that is too expensive to correct in later phases of the SDLC. Many tools have been developed in the literature to detect ambiguities in requirements documents. Best practices for writing requirements have also been proposed to help avoid ambiguities in the first place. The goal of this paper is to combine features from both approaches by developing the Ambiguity Checker Tutor (ACTutor), which not only detects ambiguities, but also aids in tutoring requirements engineers to apply best practices while writing requirements (rather than merely listing them). The paper is mainly concerned with proving the tutoring effectiveness of ACTutor through empirical evaluation.
Keywords: Ambiguities, Ambiguity Resolution, Requirements Documents, Software Engineering, Tutoring Systems.
Scope of the Article: Automated Software Specification