REQUCRISP: An Efficient Requirements Elicitation Tool with Pattern Matching Mechanism

Sathiya Prabhu.K#1
School of Information Tech & Engg VIT University, Vellore, India School of Information Tech & Engg VIT University, Vellore, India

International Journal of Computer Information Systems, Vol. 4, No.1, 2012

Balamurugan. B#2

Dept of Computer Science & Engg JNTUACEP, Pullivendula, India

Naresh. A#3

Dept of Computer Science & Engg SSITS Rayachoty, India

Venkata Ramana.V#4

School of Information Tech & Engg VIT University, Vellore, India

Vijayan. E#5

Abstract-- Defining requirements is one of the difficult as well as important processes in the development of the software system. Requirement Negotiation is the process conducted after collecting the requirements to ensure that all the requirements are collected properly. One of the main problems faced during the requirement negotiation process is that defining the requirements conflictingly or vaguely defining them [12,16,17]. Hence defining the requirements clear and crisp is most important in the requirement elicitation process. Since much of the time is spent in eliminating the vague expression of the stakeholder itself. Hence a web-based tool with pattern matching technology has been developed so that stakeholders can participate from different geographical location to facilitate the requirement negotiation process easier and faster to define clear crisp requirements from the stakeholders. Keywords - REQUCRISP, Facilitator, Stakeholders, Requirement tree,Elicitation optimization,pattern matching .

requirement engineering process. The paper deals with how the clear crisp requirements can be negotiated among the stakeholders with the help of web-based tool, so that the participant can participate in the requirement negotiation process from different geographical location which reduces the time, cost and lot of paper works. The remainder of the paper is organized as follows; Section 1 deals with the Introduction of the Requirement Elicitation and common cited problems in the requirement elicitation process. Section 2 gives the process of typical Requirement Negotiation process. Section 3 describes the various functions of REQUCRISP (Proposed system). Section 4 describes the pattern matching mechanism of REQUCRISP. Finally Section 5 gives the conclusion and future enhancement of the system. II. TYPICAL REQUIREMENT NEGOTIATION PROCESS Earlier the process of requirement negotiation were conducted among the stakeholders at a same geographical location [2,6] where there will be facilitator who governs the requirement negotiation process and there will a recorder who will catch the requirements from the stakeholders and put them in the flip chart [2]. The outcome of the process leads to an assorted specification collection for the product. However, the approach includes huge consumption of time and cost and paper works [7, 10]. In this approach the understanding of the requirement stated by one stakeholder by the other stakeholder is quite difficult and the requirements engineering process plays much of its task in eliminating the vague expressions of the stakeholder itself. III. DESCRIPTION OF THE PROPOSED SYSTEM OVERVIEW: THE REQUCRISP Hence keeping in mind about the drawbacks of the typical requirement negotiation process a pattern matching concept is introduced in the requirement elicitation mechanism while the stakeholders defining the requirements. A. Project Preparation Module The REQUCRISP consists of Requirement preparation

I. INTRODUCTION The 2003 SQI report states that in small scale assessment of requirement engineering process at JPL, out of 967 stated requirements 223 requirements defined with weak words and phrases, 83 has multiple requirements 53 requirements are not stated precisely, 37 are incomplete [1]. The 2004 Standish Group report, also states that the most commonly cited factors for the challenged projects are all related to requirements. Requirements are the functions that the system should exhibit in order satisfy the stakeholders needs. Stakeholders are the person who directly or indirectly related to the system. Requirement Elicitation is the process of finding whether all the stakeholders needs are consolidated. The main problem faced in the requirement negotiation process is that the requirements defined by one stakeholder appears conflict to other stakeholder. The most common cause for those problems are due to the stakeholders has conflicting views [16,17]. As a result the project cant meet its deadline which is leads to cost overruns [9]. In the todays competitive world the uses of web methodologies is enormous. Hence incorporating the web methodologies in the requirement engineering process illustrate a huge impact on requirement engineering process, which normally includes time, cost, schedule and speed of

January

Page 33 of 63

ISSN 2229 5208

module for the facilitator to distribute the project information and the goals and objectives of the stakeholders in the requirement engineering process. This module is exclusively for the facilitator, entering into this module will check for the authentication details. B. Requirement Elicitation Module The next module of the REQUCRISP is requirement elicitation module where it provides a framework for the stakeholders to state the requirements of the system that is going to be developed. The impressive function of this module is it is inbuilt with some pattern matching mechanism. Before the stakeholders submit the requirements the REQUCRISP will check whether the entered requirement compliance with the predefined pattern. If it is not compliant the REQUCRISP will ask the stakeholder to rephrase the requirement. The Pattern includes whether it has spelling mistakes, grammatical mistakes and whether it matches with some of the common pattern which may give vague expression (the pattern is also configurable by the facilitator). For example if stakeholder writes the requirement as the security should be the requirement didnt specify precisely which security. Hence the right pattern for this should be like the security of However in some cases the stakeholder view may also correct hence the REQUCRISP just give an alert message before submitting the requirement. If the stakeholder is still sure about his view he can continue submitting it. If other stakeholder doesnt understand about the requirement he/she can write comment about the requirement so that the stated stakeholder will make the requirement more precise. C. Requirement Tree The Requirement tree is also an integral part of the requirement elicitation module, which will display all the elicited requirements in the tree structure based on the keywords of the stated requirements. Tree structure will help to easy analysis of the important requirements of the system before going to the later phases of requirement engineering process. C. Review Requirement Module The final module of the REQUCRISP is the review requirement module. This module will let the facilitator to review all the elicited requirements to check for the redundancy or any ambiguous requirement and the facilitator have the rights to edit or delete those requirements before move on to the later modules. This module is accessible only by the facilitator, entering into this module will check for the authentication details. IV. PATTERN MATCHING MECHANISM The pattern matching mechanism in the REQUCRISP is done with Perl compatible standard (with the functions like preg_match, preg_match_all) with the grouping of characters

International Journal of Computer Information Systems, Vol. 4, No.1, 2012 inside a pattern like as follows Start and End indicator as ^ and $ Count Indicators like +,*,? Logical operator like |. Grouping with {},(),[] For example the pattern matching mechanism will be of the form If (preg_match_all ($pattern [$i], $stated_req)) alert (The stated requirement.); The REQUCRISP will search for some imprecise words for example if a stakeholder state that the system should be water resistant there will exist an issue like which system component should not be exposed to water and which should be water resistant in addition there are Some of the general words and phrases to be avoided while defining the requirements are as follows [1].

TABLE 1. WORDS AND PHRASES TO BE AVOIDED

etc. And/or Adequate Minimum of Able to Capable to Can Sufficient Support This These as applicable

as appropriate maximize minimize may if practical capability of capability to easy effective robust normal not limited to

The REQUCRISP will match for these words represented in the above table and alert the stakeholders before defining the requirements. Normally the words that ends with ly (timely, immediately, optionally etc.) are generally imprecise and poorly stated requirements [12] In addition to that the spell check mechanism is also enabled in the REQUCRISP with the help of php spell check components, which will underline the word which is not in the dictionary and give suggestion for the correct words also. V. CONCLUSION AND FUTURE ENHANCEMENT The REQUCRISP was tested for collecting the requirements for some live projects and it works fine in eliciting the clear crisp requirements from the stakeholders and

January

Page 34 of 63

ISSN 2229 5208

the requirement tree makes the easy analysis of the important requirements before going to the later phases of the requirement engineering. The future enhancement needs to find some more algorithms for the later phases of requirement engineering also such as classification, prioritization, and conflict resolution and integrate all those functionality in a single tool so that the stakeholders can see the evolution of the requirements from the earlier stage. The present tool is dealing with the requirement engineering part only where ease the huge cost for the development of the softwares lies in testing and maintaining the system. Hence the future enhancement of the system will provide a solution to reduce the amount of cost spent on the development of softwares by integrating all the phases of software development in a single tool. ACKNOWLEDGMENT Here by I Sathiya Prabhu-k sincerely thank Mr. Balamurugan Balusamy who encouraged me and helped me to do lot of research about Requirement Engineering principles. It made me immense pleasure to publish the paper to the user. REFERENCES
[1] Ronald Kirk Kandt. Software Requirement Engineering: Practices and Techniques, JPL Document-D 24994, 2003. [2] Dean leffingwell. (2010) Don widrig, Managing Software Requirements, 2010. [3] B. Boehm, P. Grnbacher, and R. Briggs, (2001)."Developing Groupware for Requirements Ne-gotiation: Lessons Learned," IEEE Software, vol. 18, pp. 46-55, 2001. [4] Ying Lei, Yu-qiang Feng. (). A FRAMEWORK FOR INTEGRATED NEGOTIATION SUPPORT SYSTEM. [5] P. Gruenbacher , R. Briggs. (2001). Surfacing Tacit Knowledge in Requirements Negotiation: Experiences Using Easy Win Win, Proceedings of the 34th Annual Hawaii International Conference on System Sciences ( HICSS-34)-Volume 1, p.1062, January 03-06, 2001.

[6] Gregory E. Kersten. (2003). The science and engineering of e-negotiation: an introduction, Published in the Proceedings of the Hawaii International Conference on System Sciences, January 6-9, 2003, Big Island,Hawaii. [7] Lohmann, Philipp Heim, Kim Lauenroth. (2008). 16th IEEE international requirement engineering conference. Web-based Stakeholder Participation in Distributed Requirements Elicitation Steffen University of Duisburg-Essen, Germany. [8] Da Yang1,3, Di Wu2, Supannika Koolmanojwong2, A. Winsor Brown2, Barry W. Boehm2. WikiWinWin: A Wiki Based System for Collaborative Requirements Negotiation. [9] Vosburgh, J. B. (1984) et al., Productivity Factors and Programming Environments, Proceedings of the International Conference on Software Engineering, 1984, pp. 143-152. [10] Friedrich stallinger paul grunbacher, (2001), System dynamics modelling and simulation of collaborative requirements engineering. The journal of system and software 311-321. [11] N. Karacapilidis and D. Papadias. (2001). "Computer Supported Argumentation and Collaborative Decision Making: The Hermes System," Information Systems, vol. 26, pp. 259-277, 2001. [12] Hooks, I. F, and Farry, K. A. (2001), Customer-Centered Products: Creating Successful Products through Smart Requirements Management, AMACOM, 2001. [13] Pitts, M. G., & Browne, G. J. (2007). Improving requirements elicitation: An empirical investigation of procedural prompts. Information Systems Journal, 17, 89-110. [14] Tsumaki, T., & Tamai, T. (2006). Framework for matching requirements elicitation techniques to project characteristics. Software Process Improvement and Practice, 11, 505-519. [15] Davis, C. J., Fuller, R. M., Tremblay, M. C., & Berndt, D. J. (2006). Communication challenges in requirements elicitation and the use of the repertory grid technique. Journal of Computer Information Systems, 78. [16] Kotonya, G., and I. Sommerville, Requirements Engineering, Wiley, 1998. [17] Lauesen, S. and Vitner, O., (2001), Preventing Requirement Defects: An Experiment in Process Improvement, Requirements Engineering, vol. 6, 2001, pp. 37-50. [18] www.wikipedia.org. [19] Hans van Vliet. John Wiley & Sons, 2008, Software Engineering: Principles and Practice (3rd Edition) : xxvi+713pp. [20] Hans van Vliet and Sjaak Brinkkemper. Bedrijfskunde, (2002), Requirements Engineering: , Vol. 74, no. 1, pp 19-29 [21] Remco C. de Boer and Hans van Vliet, (2009), On the Similarity between Requirements and Architecture : . Journal of Systems and Software 82(3), pp 544-550.

International Journal of Computer Information Systems, Vol. 4, No.1, 2012

AUTHORS PROFILE Dr.Sathiya Prabhu Kumar is pursuing M.S (S.E) final year at V.I.T University, Vellore, India.His area of interest is not limited to Software Engineering, Software Requirement Engineering. He has done this work as a project in the University of Malaya, Malaysia.

January

Page 35 of 63

ISSN 2229 5208