International Journal Of Computer Science And Applications Vol. 1, No. 1, June 2008 ISSN 0974-1003 Published by Research Publications, Chikhli, India 11 An Approach to Deal with Ambiguity in Requirement Elicitation Md. Rizwan Beg Dept. of Computer Sc. & Engg. Integral University, Lucknow, India +91-0522-2890812 rizwanbeg@gmail.com Dr. Qamar Abbas Dept. of Computer Sc. & Engg. Integral University, Lucknow, India +91-0522-2890812 qrat_abbas@yahoo.com Alok Joshi Dept. of Computer Sc. & Engg. Integral University, Lucknow, India +91-0522-2890812 joshialok@rediffmail.com ABSTRACT Requirements elicitation has received little attention in past and it has been ignored by most of the software engineering research community, the requirements are often ambiguous, incomplete, inconsistent & informal. Out of which the problem of ambiguity at time of requirement elicitation is difficult to deal with. So in order to solve the problem of ambiguity between the stakeholder and client at the time of interview, this paper proposes a method which is to be used, as soon as a new requirements is expressed by the client in natural language the system converts it to the set of production rules, where each rule is corresponding to the particular context. Then the variables of the each production are converted into bipolar representation, which is used as single vector denoting the sentence of the interview session. The stakeholder brain is considered as associative networks of the bipolar vectors. Upon applying the sentence to the network if we get the same output vector as the input vector then there is no ambiguity in the requirement just expressed. Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Elicitation method. General Terms Algorithms, Theory Keywords Ambiguity, requirement elicitation, stakeholder, client, interview, natural language, grammar, production rules, associative nets. 1 INTRODUCTION According to Standish research around 31% of projects are canceled before they can be completed and around 52 % of projects costs around 189% of the actual cost just around 16% of projects get completed within time and in budget, it was found that incomplete and changing requirements are the big concern so requirement engineering if not tackled seriously can create a big problem [15]. The success and failure of the software product depends on whether it meets the requirement for which it has been built or not. According to [5], “Requirement engineering is the process that identifies whether software is a success or a failure by identifying the stake holders and their needs and then documenting it in form of agreement for the further implementations”. Following activities are involved in the requirement engineering phase [9]- (1) Requirements elicitation, (2) Requirements analysis, (3) Requirements specification and (4) Requirements validation. The goal of requirements engineering is to produce good quality requirements specification as that can only minimize the project cost and can assure the on time delivery of the product. According to [IEEE 84] good software requirements specification must be: unambiguous, complete, verifiable, consistent, modifiable, traceable, and usable during operations and maintenance. As all the above mentioned characteristics are important and may affect the production of quality requirements, according to [6], “ambiguity can occur at three levels namely requirements elicitation, requirements documentation, and requirements validation”. We are here concentrating ambiguity removal on the requirement elicitation part of the requirement engineering phase. As “Requirements elicitation is the process of discovering the requirements of a software project” [2].Some researchers says, Requirements elicitation is related to the gathering of requirements [12]. As there are various ways to gather the requirement and various persons are involved in it, some are using the system , some have financial interest, some maintains it and some pays for the system they all are named as Stakeholders [7] so generally they can be any of the following customers/sponsors, users, developers, quality assurance teams, and requirements analysts [5]. Here we are considering the Stakeholder as a developer or a requirement analyst. There are various ways for gathering the requirements, for the purpose, various elicitation techniques are used, these techniques are the methods used by requirement engineers to determine the needs of the stakeholders [3] [4], the criteria for the selection of the particular technique is not fix, it can be the favorite technique for requirement analyst or it can be a favorable in particular domain or application [1]. The elicitation techniques can be classified into the four categories- Traditional Techniques, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. © Copyright 2008 Research Publications, Chikhli, India