Open AccessAn Automated Tool for Detection and Tutoring of Sources of Ambiguities in Requirements Documents
Author(s) -
Ayat Shaaban*,
Hanan Elazhary,
Ehab E. Hassanein
Publication year - 2019
Publication title -
international journal of recent technology and engineering
Language(s) - English
Resource type - Journals
ISSN - 2277-3878
DOI - 10.35940/ijrte.c4660.098319
Subject(s) - computer science , systems development life cycle , software engineering , requirements engineering , software requirements , software requirements specification , ambiguity , requirements analysis , requirements elicitation , requirement , non functional requirement , process (computing) , software development , software development process , functional requirement , natural language , software , software construction , programming language , artificial intelligence
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.