Automated dialogue systems for requirements elication practice
Loading...
Links to Files
Permanent Link
Author/Creator
Author/Creator ORCID
Date
2014-02-05
Type of Work
Department
Towson University. Department of Computer and Information Sciences
Program
Citation of Original Publication
Rights
Copyright protected, all rights reserved.
There are no restrictions on access to this document. An internet release form signed by the author to display this document online is on file with Towson University Special Collections and Archives.
There are no restrictions on access to this document. An internet release form signed by the author to display this document online is on file with Towson University Special Collections and Archives.
Subjects
Abstract
Background: Requirements gathering is a vital part of the software development lifecycle. The act of requirements elicitation revolves around prompting prospective clients with questions that will result in an efficient set of requirements. The questions an analyst, software engineer, developer, or project manager asks and the way that they follow up on those questions to probe clients for requirements provide information to aid in the requirements elicitation process and a system's development as a whole. Problem Definition: The act of requirements elicitation is difficult and requires an immense amount of skill and attention to detail to not only draw all requirements from the clients, but to also provide a solid basis for system development. Choosing a questioning methodology is vital to comprehensive coverage of all categories of requirements. Approaches: The intention of this project was to develop an automated dialogue system that would allow users to interact with and discover appropriate questions for requirements elicitation. The notion of a question answer (QA) system would give users the ability to engage in a natural language, human-like conversation, to simulate an environment in which an analyst could ask questions to elicit system requirements. For this project, two types of dialogue systems were implemented. The first interaction was an AIML closed-domain chatbot allowing for open-ended set of inputs, whereas the second closed-domain iteration implemented a closed set of acceptable inputs. Each iteration accounted for all requirement categories and possibility of questions based on a prompting technique that was researched and deemed to be a best fit for the system descriptions that were included in the dialogue system's domain. Results: In conducting a pilot study on the first iteration chatbot, a number of limitations regarding AIML's handling of an extremely open-ended variety of questions specific to a requirements elicitation domain were discovered. The nature of the second iteration's restricted set of inputs guaranteed 100% accuracy in the system's responses, but removed the user's ability to devise their own questions. Conclusions: This project was an introduction to developing a much larger system aiding in the training of students pursuing and understanding of requirements engineering and the requirements elicitation phase of the software development lifecycle. The dialogue system implementations, results and findings of this thesis will be used in a doctoral study expected to continue.