Read without ads and support Scribd by becoming a Scribd Premium Reader.
See Premium Plans
 
International Journal of Computer Information Systems,Vol. 4, No. 1, 2012
REQUIBOT: An Efficient Requirements GatheringTool over underlying Web Technologies
Sathiya Prabhu.K
#1
Balamurugan. B
#2
Naresh. A
#3
Venkata Ramana V
#4
Vijayan. E
#5
School of Information School of Information Dept of Computer Dept of Computer School of InformationTech & Engg Tech & Engg Science & Engg Science & Engg Tech & EnggVIT University, VIT University, JNTUACEP, SSITS VIT University,Vellore, India Vellore, India Pullivendula, India Rayachoty, India Vellore, India
 Abstract--
Defining requirements are one of the difficult as wellas important processes in the development of the softwaresystem. Requirements are negotiated after collecting therequirements to ensure all the requirements are collectedproperly. Knowing the importance of negotiation activity forthe project success many negotiation support tools wereevolved but most of them provide a platform or framework forthe negotiation but lacks in effective negotiation support [4].Moreover the earlier tools which were used are morecomplicated to work with in terms of collection, maintenanceand reusability. Hence a tool has been developed to facilitatethe requirement negotiation process in easier way. The tool isdeveloped to operate in a web environment so that thestakeholders can participate in the requirement negotiationprocess from any place.
 Keywords--
Requibot, Facilitator, Stakeholders, Win-Winprocess model
.I.
 
I
NTRODUCTION
The 1994 Standish Group report says that about31% of software projects are cancelled before they werecompleted. It also adds that 52.7% of projects will cost189% of their original estimates [2]. Further in a recent2004 Standish Group report, the percentage of failedprojects 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 commonlycited factors for the challenged projects are all related torequirements (lack of user input, incomplete requirements &specifications, andChanging requirements & specifications) [5]. Definingrequirements is one of the most critical activities in thedevelopment of software intensive systems, becauserequirements problems appear to transcend other issues interms of the risks and problems they pose to applicationdevelopment.Requirements negotiation is an activity which is carried outin the initial stage of software development process toaddress important concerns of all stakeholders who areinvolved in the software project [2]. Over past decadesmany electronic support systems were developed but mostof them are still in training and researches seldom practicedfor live projects [4]. The paper deals with the methodologiesof integrating various modules starting from the maintainingstakeholders profile information, negotiation preparation toreveal options for issues in the elicited requirements.The remainder of the paper is organized as follows; Section1 deals with Negotiation Support Systems, which describesthe domain of typical negotiation systems. Section 2 givesthe description about theREQUIBOT tool (The proposed system), Section 3describes the Architecture of the REQUIBOT tool. Section4 describes the tricks of the various modules. FinallySection 5 gives the conclusion and future enhancement of the system.II.
 
T
YPICAL
R
EQUIREMENT
N
EGOTIATION
S
YSTEMS
 Earlier the software requirement negotiationactivities were conducted between the experts and analysts[6] at a same geographical location and negotiation andprioritization of the selected requirements is done manuallywithout the aid of a software tool. The process begins with afacilitator initiating a requirement elicitation and negotiationprocess and directs it to end in a successful way [2]. Theoutcome of the process leads to an assorted specificationcollection for the product. However, drawbacks in theapproach in term of consumption of time and cost arenoticeably high [7, 10]. To improve the complication of requirement elicitation, enormous tools have beendeveloped and deployed in software industry with context toseveral software methodologies [10]. The lacking of thetools to provide a good communication platform andframework for negotiation to make negotiation supporteffective is measured [4] and the same has led to thedevelopment of REQUIBOT. Hence following thephilosophy of win-win process model [8], a web basedcollaboration environment was created to carry out therequirement negotiation process for the distributedstakeholders situated in geographic location.III.
 
D
ESCRIPTION OF THE
P
ROPOSED
S
YSTEM
 O
VERVIEW
:
 
T
HE
REQUIBOTThis tool was made with intensive analysiskeeping in stack the need and process of software
JanuaryPage 57 of 63ISSN 2229 5208
 
International Journal of Computer Information Systems,Vol. 4, No. 1, 2012
companies, Business administrators, and Software clients toelicit requirements from their stakeholders. The tool consistsof 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 aconflict scenario of the elicited requirements. The process of the requirement negotiation is as followsThe administrator (read facilitator) will first give the projectdetails and objectives of the negotiation activities to thestakeholders before contributing their work in thenegotiation process. The facilitator will also act asstakeholder in addition to maintaining and coordinating therequirement negotiation process. With the facilitatorinformation the stakeholders will elicit the requirements andidentify the objective criteria for the elicited requirements sothat the elicited requirements can be grouped together underspecific criteria and the requirements will be prioritizedaccording to its impact rate.The specific criterion is algorithm based and can bedesigned by the facilitator himself. Finally the stakeholderswill work together to identify the issues in the elicitedrequirements and explore available options for the identifiedissues. The finalization of the options ends the process of elicitation and negotiation. (Figure 1 shows the flow of information from the Requirement Preparation module tothe Reveal option module)
FIGURE 1. REQUIBOT PROCESS ACTIVITIES
IV.
 
REQUIBOT
 
A
RCHITECTURE
 As the tool is a web-based application, it isdesigned based on object-oriented methodology and madeas 3-tier architecture. The client tier consists of administrator and n number of stakeholders. The applicationtier is deployed with Apache web server and REQUIBOTand 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 withthe help of an online GUI terminal. As the stakeholders willbe in different geographical locations, they need to connectto the internet in order to interact with the system.
 B. Application Tier 
In the application tier there will be apache web server andREQUIBOT. Apache web server act as the bridge betweenthe clients and the database. It takes care of clients requestfor storing the data into the database and retrieving the datafrom the database. It is also responsible for consistentstorage of data into the database. On the other side theREQUIBOT is responsible for the execution of the systemthat provides each and every module for the clients.
C. Data Tier 
The Data tier will be MYSQL database completelyresponsible for storing large amount of data. Data is notlimited to user profiles, Project related information, Timeline of the modules and requirement negotiation artifactssuch as domain details, requirements, objective criteria,conflicts and issues.V.
 
R
EQUIBOT SECURITY
 As the system is in web based environment, it is veryimportant to prevent the confidential data of the projectfrom intruders. Hence the REQUIBOT maintains differentlevels of security as follow.The first level of security is for the facilitator to select thenegotiation team members. Only the selected members canget into the project and view the project details. Hence theproject details is secured.The second level is only the facilitator can edit the projectdetails. In the negotiation process only the facilitator has thefull control over the negotiation artifacts. For editing thenegotiation artifacts the tool will ask for the
 
project key (anauthentication key which will be known only by thefacilitator). Hence the negotiation artifacts also secured.The third level of security to prevent the all type of attacksthat might exists in the networks such as sniffing,eavesdropping, man-in-the-middle etc. the REQUIBOTstores the complete details of the acting users such as the I.P
Requirement PreparationBrainstorm RequirementConverge RequirementsIdentify Objective CriteriaRequirement ClassificationConflict ResolutionRequirement PrioritizationReveal Option
JanuaryPage 58 of 63ISSN 2229 5208
 
International Journal of Computer Information Systems,Vol. 4, No. 1, 2012
address username and password and the date, time andduration of the users. So, that all the possible network attacks can be tackled.Finally to all extent since the facilitator has the full controlover the negotiation process any type of mall functions canbe tackled.VI.
 
REQUIBOT
 
M
ODULES
 
 A. Project Management Module
The project management moduleis exclusively for the facilitator to create a new project or toupdate an existing project. In this module the facilitator canset/edit the number stakeholders, set the time line of eachand every module and give the domain knowledge about theproject.
 B. Brainstorm Requirement Module
In the Brainstorm requirementmodule all the stakeholders will mutually elicit all therequirements for the project. If any vague expression isfound, the other stakeholder or facilitator can write acomment about that requirement. Based on that commentthe stakeholder in charge of the requirement can edit theirrequirement or can justify their views in writing thecomments.Considering stakeholder Sx, the requirement elicited by thestakeholder is given by Sx.ER. Hence the overall elicitedrequirements will be given by
ER(Sx,n)=∑
1- n
Sx.ERwhere n belongs to total number of stakeholders involved inthe requirement negotiation process.Brainstorming requirement module is inbuilt with somepattern matching mechanism. Before the stakeholderssubmit the requirements the Requibot will check whetherthe entered requirement compliance with the predefinedpattern. If it is not a compliant the Requibot asks thestakeholder to rephrase the requirement. The Patternincludes whether it has spelling mistakes grammaticalmistakes and whether it matches with some of the commonpattern which may give vague expression (the pattern is alsoconfigurable by the facilitator). For example if stakeholder
writes the requirement as „the security should be…‟ therequirement doesn‟t specify exactly
which security. Hence
the right pattern for this should be like „the security of…‟
However in some cases the stakeholder view may alsocorrect hence the Requibot just give alert message beforesubmitting the requirement if the stakeholder is sure abouthis view he can continue submitting it.(For example the Screen shot 1 show the brainstormrequirement module of REQUIBOT for a live project wherethe elicited requirements will be cached in the Flip Chartbelow and by clicking on the respective requirements thestakeholders can comments on the requirement (if necessary) )
SCREEN SHOT 1. BRAINSTORM REQUIREMENT
C. Converge Requirement Module
The Converge requirement moduleis exclusively for the facilitator to review all the elicitedrequirements and check for the redundancy or any improperrequirement and the facilitator have the rights to edit ordelete those requirements before move on further modules.
SCREEN SHOT 2. CONVERGE REQUIREMENT
Let
ER(Sx,n)=∑
1-n
Sx.ER be the elicited requirements, theconverge requirements (CR) will be represented by
CR(Sx,n)= ∑
1 - n
Sx.ER -
∑
1 - m
Sx.AR where AR be the mnumber of redundant or ambiguous requirements identifiedby the facilitator. (The Screen shot 2 shows the convergerequirement module where the facilitator can review all theelicited requirements and can delete any requirement usingdelete button (if necessary) or can also edit anyrequirements by clicking the respective requirements (if necessary).
 D. Explore Objective Criteria Module
In explore objective criteriamodule the stakeholders can identify the objective criteria of the system to be built with all the requirements displayed atthe top of the web page. (The Screen shot 3 shows theobjective criteria module where all the elicited requirementsare displayed at the top of the page with explored objectivecriteria at the bottom and screen shot 4 shows the add newobjective criteria)
JanuaryPage 59 of 63ISSN 2229 5208
Search
Search History:
Searching...
Result 00 of 00
00 results for result for
  • p.
    • Notes
    Load more