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

1, 2012

REQUIBOT: An Efficient Requirements Gathering Tool over underlying Web Technologies

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

Balamurugan. B#2
School of Information Tech & Engg VIT University, Vellore, India

Naresh. A#3
Dept of Computer Science & Engg JNTUACEP, Pullivendula, India

Venkata Ramana V#4

Dept of Computer Science & Engg SSITS Rayachoty, India

Vijayan. E#5
School of Information Tech & Engg VIT University, Vellore, India

Abstract-- Defining requirements are one of the difficult as well as important processes in the development of the software system. Requirements are negotiated after collecting the requirements to ensure all the requirements are collected properly. Knowing the importance of negotiation activity for the project success many negotiation support tools were evolved but most of them provide a platform or framework for the negotiation but lacks in effective negotiation support [4]. Moreover the earlier tools which were used are more complicated to work with in terms of collection, maintenance and reusability. Hence a tool has been developed to facilitate the requirement negotiation process in easier way. The tool is developed to operate in a web environment so that the stakeholders can participate in the requirement negotiation process from any place. Keywords-- Requibot, Facilitator, Stakeholders, Win-Win process model.

of integrating various modules starting from the maintaining stakeholders profile information, negotiation preparation to reveal options for issues in the elicited requirements. The remainder of the paper is organized as follows; Section 1 deals with Negotiation Support Systems, which describes the domain of typical negotiation systems. Section 2 gives the description about the REQUIBOT tool (The proposed system), Section 3 describes the Architecture of the REQUIBOT tool. Section 4 describes the tricks of the various modules. Finally Section 5 gives the conclusion and future enhancement of the system. II. TYPICAL REQUIREMENT NEGOTIATION SYSTEMS Earlier the software requirement negotiation activities were conducted between the experts and analysts [6] at a same geographical location and negotiation and prioritization of the selected requirements is done manually without the aid of a software tool. The process begins with a facilitator initiating a requirement elicitation and negotiation process and directs it to end in a successful way [2]. The outcome of the process leads to an assorted specification collection for the product. However, drawbacks in the approach in term of consumption of time and cost are noticeably high [7, 10]. To improve the complication of requirement elicitation, enormous tools have been developed and deployed in software industry with context to several software methodologies [10]. The lacking of the tools to provide a good communication platform and framework for negotiation to make negotiation support effective is measured [4] and the same has led to the development of REQUIBOT. Hence following the philosophy of win-win process model [8], a web based collaboration environment was created to carry out the requirement negotiation process for the distributed stakeholders situated in geographic location.

I. INTRODUCTION The 1994 Standish Group report says that about 31% of software projects are cancelled before they were completed. It also adds that 52.7% of projects will cost 189% of their original estimates [2]. Further in a recent 2004 Standish Group report, the percentage of failed projects drops to 18 percent, but the percentage of challenged projects is still as high as 53 percent [8]. According to Standish Group study the 3 most commonly cited factors for the challenged projects are all related to requirements (lack of user input, incomplete requirements & specifications, and Changing requirements & specifications) [5]. Defining requirements is one of the most critical activities in the development of software intensive systems, because requirements problems appear to transcend other issues in terms of the risks and problems they pose to application development. Requirements negotiation is an activity which is carried out in the initial stage of software development process to address important concerns of all stakeholders who are involved in the software project [2]. Over past decades many electronic support systems were developed but most of them are still in training and researches seldom practiced for live projects [4]. The paper deals with the methodologies

III. DESCRIPTION OF THE PROPOSED SYSTEM OVERVIEW: THE REQUIBOT This tool was made with intensive analysis keeping in stack the need and process of software

January

Page 57 of 63

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 4, No. 1, 2012 companies, Business administrators, and Software clients to elicit requirements from their stakeholders. The tool consists of series of modules tailored to facilitate the entire needs of the elicitation process from the initial eliciting requirements, identify issues and to reveal options for the issues in a conflict scenario of the elicited requirements. The process of the requirement negotiation is as follows The administrator (read facilitator) will first give the project details and objectives of the negotiation activities to the stakeholders before contributing their work in the negotiation process. The facilitator will also act as stakeholder in addition to maintaining and coordinating the requirement negotiation process. With the facilitator information the stakeholders will elicit the requirements and identify the objective criteria for the elicited requirements so that the elicited requirements can be grouped together under specific criteria and the requirements will be prioritized according to its impact rate. The specific criterion is algorithm based and can be designed by the facilitator himself. Finally the stakeholders will work together to identify the issues in the elicited requirements and explore available options for the identified issues. The finalization of the options ends the process of elicitation and negotiation. (Figure 1 shows the flow of information from the Requirement Preparation module to the Reveal option module) IV. REQUIBOT ARCHITECTURE As the tool is a web-based application, it is designed based on object-oriented methodology and made as 3-tier architecture. The client tier consists of administrator and n number of stakeholders. The application tier is deployed with Apache web server and REQUIBOT and the data tier will lead with MYSQL database. A. Client Tier In the client tier there will be a facilitator and n number of stakeholders will initiate and interact with the system with the help of an online GUI terminal. As the stakeholders will be in different geographical locations, they need to connect to the internet in order to interact with the system. B. Application Tier In the application tier there will be apache web server and REQUIBOT. Apache web server act as the bridge between the clients and the database. It takes care of clients request for storing the data into the database and retrieving the data from the database. It is also responsible for consistent storage of data into the database. On the other side the REQUIBOT is responsible for the execution of the system that provides each and every module for the clients. C. Data Tier The Data tier will be MYSQL database completely responsible for storing large amount of data. Data is not limited to user profiles, Project related information, Time line of the modules and requirement negotiation artifacts such as domain details, requirements, objective criteria, conflicts and issues. V.
Converge Requirements

Requirement Preparation

Brainstorm Requirement

REQUIBOT SECURITY

Identify Objective Criteria

As the system is in web based environment, it is very important to prevent the confidential data of the project from intruders. Hence the REQUIBOT maintains different levels of security as follow. The first level of security is for the facilitator to select the negotiation team members. Only the selected members can get into the project and view the project details. Hence the project details is secured. The second level is only the facilitator can edit the project details. In the negotiation process only the facilitator has the full control over the negotiation artifacts. For editing the negotiation artifacts the tool will ask for the project key (an authentication key which will be known only by the facilitator). Hence the negotiation artifacts also secured. The third level of security to prevent the all type of attacks that might exists in the networks such as sniffing, eavesdropping, man-in-the-middle etc. the REQUIBOT stores the complete details of the acting users such as the I.P

Requirement Classification

Conflict Resolution

Requirement Prioritization

Reveal Option

FIGURE 1. REQUIBOT PROCESS ACTIVITIES

January

Page 58 of 63

ISSN 2229 5208

address username and password and the date, time and duration of the users. So, that all the possible network attacks can be tackled. Finally to all extent since the facilitator has the full control over the negotiation process any type of mall functions can be tackled. VI. REQUIBOT MODULES A. Project Management Module The project management module is exclusively for the facilitator to create a new project or to update an existing project. In this module the facilitator can set/edit the number stakeholders, set the time line of each and every module and give the domain knowledge about the project. B. Brainstorm Requirement Module In the Brainstorm requirement module all the stakeholders will mutually elicit all the requirements for the project. If any vague expression is found, the other stakeholder or facilitator can write a comment about that requirement. Based on that comment the stakeholder in charge of the requirement can edit their requirement or can justify their views in writing the comments. Considering stakeholder Sx, the requirement elicited by the stakeholder is given by Sx.ER. Hence the overall elicited requirements will be given by ER(Sx,n)=1- n Sx.ER where n belongs to total number of stakeholders involved in the requirement negotiation process. Brainstorming requirement module is inbuilt with some pattern matching mechanism. Before the stakeholders submit the requirements the Requibot will check whether the entered requirement compliance with the predefined pattern. If it is not a compliant the Requibot asks 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 doesnt specify exactly 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 Requibot just give alert message before submitting the requirement if the stakeholder is sure about his view he can continue submitting it. (For example the Screen shot 1 show the brainstorm requirement module of REQUIBOT for a live project where the elicited requirements will be cached in the Flip Chart below and by clicking on the respective requirements the

International Journal of Computer Information Systems, Vol. 4, No. 1, 2012 stakeholders can comments on the requirement (if necessary) )

SCREEN SHOT 1. BRAINSTORM REQUIREMENT

C. Converge Requirement Module The Converge requirement module is exclusively for the facilitator to review all the elicited requirements and check for the redundancy or any improper requirement and the facilitator have the rights to edit or delete those requirements before move on further modules.

SCREEN SHOT 2. CONVERGE REQUIREMENT

Let ER(Sx,n)=1-n Sx.ER be the elicited requirements, the converge requirements (CR) will be represented by CR(Sx,n)= 1 - n Sx.ER - 1 - m Sx.AR where AR be the m number of redundant or ambiguous requirements identified by the facilitator. (The Screen shot 2 shows the converge requirement module where the facilitator can review all the elicited requirements and can delete any requirement using delete button (if necessary) or can also edit any requirements by clicking the respective requirements (if necessary). D. Explore Objective Criteria Module In explore objective criteria module the stakeholders can identify the objective criteria of the system to be built with all the requirements displayed at the top of the web page. (The Screen shot 3 shows the objective criteria module where all the elicited requirements are displayed at the top of the page with explored objective criteria at the bottom and screen shot 4 shows the add new objective criteria)

January

Page 59 of 63

ISSN 2229 5208

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

SCREEN SHOT 3. EXPLORE OBJ CRITERIA SCREEN SHOT 5. CLASSIFICATION OF REQUIREMENTS

SCREEN SHOT 4. NEW OBJ CRITERIA.

SCREEN SHOT 6. VOTING RESULT.

E. Classification Module Since manual classification of the whole requirements is tedious the Requibot provide a tree structure for all the elicited requirements based on the entered keyword. The Classification module also provide a live discussion session where stakeholders can discuss about the classification ideas with the other stakeholders and stakeholders can vote for the classification ideas. The system will display the idea which is voted by highest number of stakeholders. Finally facilitator will classify the requirement based on the voting result. (The Screen shot 5 shows the live discussion module and after discussing various issues the stakeholders can vote for their views. The screen shot 6 shows the voting result where for each requirement the criteria voted by maximum number of stakeholders will be indicated in the red colour)

F. Prioritization Module In the prioritization module the facilitator will let the stakeholders to prioritize the requirements based on the impact rate of the requirement. The System will display list of requirements under their respective objective criteria the stakeholder have to vote for the impact rate of the requirement in the development project. The requirement is voted on the number from 1 to 5. The system will take an average of the voted result and suggest the impact rate of the system. The Requibot also provide an automatic suggestion of impact rate and feasibility rate of the entire requirement based on the predefined prioritization rate and also on the history of prioritized data Considering Ri be the requirement and Wi be the impact score voted by a stakeholder Sx for that requirement. Impact score = 1-n Ri.Wi / n n- total number of stakeholders voted. Suggestion= I.C * n / 100 If S > 75 the requirement has high impact S>50 and S<75 S>25 and S<50 S>0 and S<25

January

Page 60 of 63

ISSN 2229 5208

(The Screen shot 7 shows the Prioritization module where the list of requirements will be displayed under their respective objective criteria and the stakeholders will prioritize the requirements based on the impact and feasibility rate. The Screen shot 8 shows the suggestion of impact rate and feasibility rate for the entire elicited requirements)

International Journal of Computer Information Systems, Vol. 4, No. 1, 2012 shows the list of requirements with total number of identified issues)

SCREEN SHOT 9. CONFLICT RESOLUTION

H. Reveal Option Module The Option module is to explore the available options for the identified issues in the previous module. In this module the options for the identified issue will be revealed based on each criterion not on each issue since each requirement can have n number of issues and each issue can have n number of options hence it is time consuming and not worthy process to identify option for each identified issue. As the options are revealed based on each criteria it will be easy for the stakeholders as they explore options for the set of interrelated requirements. The list of criteria will be displayed at the option module first screen selecting on the appropriate criteria will display all the identified issues of the requirements under those criteria. With list of identified issues displayed at the top of the screen the stakeholders can explore available options for the identified issue. The options explored by other stakeholders (if any) will also be displayed along with appropriate issues. The facilitator will keep in track of each and every activity and edit /delete the redundancy or improper specification of options. In the both conflict resolution and reveal option module the Requibot provide the pattern matching mechanism to eliminate vague expression as mentioned in the Brainstorm Requirement module and in addition provide a win-win tree which puts all the identified issues and options for the identified issue in a tree structure. (The Screen shot 10 shows the Reveal option module of REQUIBOT which shows the identified issues at the top and list of available options at the bottom)

SCREEN SHOT 7. PRIORITIZE REQUIREMENT

SCREEN SHOT 8. IMPACT AND FEASIBILITY RATE

G. Conflict Resolution Module In the conflict resolution module the stakeholders will identify the issues in the elicited requirements. The system will display the list of elicited requirements clicking on the respective requirements the system will allow the stakeholder to enter the issues and also display the issues which is identified by the other stakeholders earlier. The stakeholders can identify all type of issues as possible and at the end of the module the facilitator will go through all the identified issues and edit/ delete the redundancy and improper specification of issues. Each identified requirements can have n number of issues where n is a whole number (0,1,2.), that is each requirement can have zero or more issues. A requirement may dont have any issue also. In this module we will discuss about the requirements which has issues. (The screen shot 9 shows the conflict resolution module which

January

Page 61 of 63

ISSN 2229 5208

SCREEN SHOT 10. REVEAL OPTION.

I. Bulletin Board As the name specifies the bulletin screen will show the common announcement of the facilitator and stakeholders. The Bulletin screen will be always in the running mode in side of all the modules and even in every web page, so that it will be easy for the facilitator and stakeholders to post an announcement at any point of the negotiation activities. In addition to announcements the bulletin message also shows the server time i.e actual company time zone (since the stakeholders will be at different time zone) and it also shows the link to view all the project information and objectives of the negotiation activities which is posted by the facilitator for the benefits of stakeholders to get domain knowledge of the project before they contribute in the negotiation activities.

International Journal of Computer Information Systems, Vol. 4, No. 1, 2012 of misunderstanding and eliminated with help of mistakes live discussion session and tree structure. Prioritization of Prioritization of requirements is requirements is quite easy complicated since since overall decisions of number of choices needs all the stakeholders are to be considered and combined together. human decision is subjective in nature. Finding options for each Finding options for the identified issues is time identified issue is easy consuming and since Requibot allows sometimes not needed find issue for each also, since each category and not for each requirement can have n issue. number of issues and each issue can again have n number of options. Identified issue again can Existence of vague have vague expression expression is minimal with the help of pattern matching mechanism.

VIII. CONCLUSION AND FUTURE ENHANCEMENT

The tool was tested for some live projects for congregating requirements and it works fine in eliciting the requirements from the stakeholders and it is very easy to use or work with it even for the novice and it is easy to identify the issues in the elicited requirements and to explore the available options for the identified issues. Moreover it is easy to maintain the requirements in term of editing and updating.

VII. DIFFERENCE BETWEEN MANUAL METHOD AND REQUIBOT. The advantages of Requibot over the manual method of requirement engineering are as follows.
TABLE 1. ADVANTAGES OF REQUIBOT

The future enhancement needs to find some algorithm for automatic suggestion of classification and prioritization ideas for some of the common requirements.

Manual method Distribution of project details and objectives of the project involves lot of paper work and time consuming Elimination of vague expression from the elicited requirements involves huge process Classification of requirements involves lot

Requibot Distribution of project details and objectives is quite easy and instant.

The present tool can be used only to elicit the requirements whereas another big challenge in the development of the software system is that testing and maintaining the system. Hence the future enhancement of the system will include the open source of software development within the same company and simultaneous testing of the system along with the software development. REFERENCES

Existence of vague expression is minimal with the help of pattern matching mechanism. Misunderstanding and mistakes can be

[1] Hazrina Sofian. (2010). Easy win win with Quality Assurance and Multi-Criteria preference Technique: A Groupware System for Negotiating Requirements, 2010. [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.

January

Page 62 of 63

ISSN 2229 5208

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

[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 enegotiation: 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] Boehm, B., Bose, P., Horowitz, E., Lee, M.J. (1994). Software Requirements as Negotiated Win Conditions. Proceedings Intl. Conference on Requirements Engineering, IEEE April 1994. [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] B. Boehm and R. Ross. (1989) . "Theory-W Software Project Management Principles and Exam-ples," IEEE Transactions on Software Engineering, vol. 15, pp. 902-916, 1989. [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] Software Requirements Negotiation: Some Lessons LearnedPublished in the Proceedings of the 20th International Conference on Software Engineering, 1998. [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. 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 63 of 63

ISSN 2229 5208