Arab J Sci Eng (2014) 39:4667–4681 DOI 10.1007/s13369-014-1150-3
RESEARCH ARTICLE - COMPUTER ENGINEERING AND COMPUTER SCIENCE
A Requirements Negotiation Process Model that Integrates EasyWinWin with Quality Assurance and Multi-Criteria Preference Techniques Hazrina Binti Sofian · Siti Salwah Binti Salim · Seyed Reza Shahamiri
Received: 6 September 2012 / Accepted: 15 June 2013 / Published online: 28 May 2014 © King Fahd University of Petroleum and Minerals 2014
Abstract Requirements negotiation is performed to address conflicts over business requirements to achieve a shared vision of software to be developed. Examples of difficulties that can arise during requirements negotiation are: lack of clarity about requirements and expectations among stakeholders, hassle of detecting and removing requirements negotiation defects, and balancing of give-and-take in reaching an agreement. Although there are some models available to address some of the issues, an integrated approach is required to solve them in a single process. This paper proposes an all-in-one requirements negotiation process model called groupware requirements negotiation system (GRNS), which is capable of solving requirements negotiation difficulties by integrating EasyWinWin, quality assurance techniques, and multi-criteria preference techniques with Bayes theorem. Moreover, a system is developed to support the proposed GRNS process model; it was evaluated by two industrial companies using experimental evaluation, questionnaires and expert analysis. The results of the evaluation show that the proposed model is effective in eliciting clear requirements, providing structured communication among stakeholders, reducing defects and decreasing their severity level as well as assisting stakeholders to understand other stakeholders’ perspectives to achieve an agreement. Consequently, the proposed model overcomes the difficulties of the previous process models, provides controllability over negotiation sessions, and assists stakeholders to achieve negotiation goals.
H. B. Sofian · S. S. Binti Salim (B) · S. R. Shahamiri Department of Software Engineering, Faculty of Computer Science and Information Technology, University of Malaya, 50603 Kuala Lumpur, Malaysia e-mail:
[email protected]
Keywords Requirements negotiation · EasyWinWin · Quality assurance · Multi-criteria preference
1 Introduction Requirements negotiation is a process used to reach agreement among stakeholders regarding business requirements of software to be developed. The process is an abstract representation of activities involved in performing requirements negotiation in which outcomes are agreed business requirements that define software’s functionalities and quality attributes. Misunderstanding or misidentification of software attributes may result in decreased quality of software application [1,2]. In addition, the negotiation process may identify unresolved issues that must be considered, because they may influence
123
4668
Arab J Sci Eng (2014) 39:4667–4681
software’s functional and non-functional attributes dramatically [3]. In particular, while agreements are used as a basis for system analysis, design and implementation, unresolved issues should be managed as potential project risks. Previous studies have affirmed the importance of analysing and negotiating requirements conflicts to develop a software system that is consistent with business requirements [4–7]. Generally, requirements conflicts occur when stakeholders have different needs and expectations of software. Identification of requirements entails involvement of numerous heterogeneous stakeholders with different roles, responsibilities and priorities; hence, conflicts are likely exist among some requirements [8]. Thus, an effective requirements negotiation process is vital for stakeholders to discuss and resolve inconsistencies and conflicts [9] to reach the same view on software to be developed. Realising the importance of requirements negotiation and the need for processes and systems to support requirements negotiation, researchers of previous studies tried to improve the existing requirements negotiation process model and requirements negotiation systems [10]. One of the earliest process models is the WinWin negotiation model [11], which emphasises stakeholders’ collaboration in defining requirements. It provides solutions to ease the difficulties of extracting clear business requirements by eliminating ambiguities and vague expressions when stakeholders express their business requirements during requirements negotiation. It is pertinent to note the significance of conducting effective communication during requirements negotiation [12] to derive clear business requirements; this is because these requirements are used to define the software development contract. However, eliminating ambiguities and vague expressions of stakeholders’ requirements is not the only challenge in requirements negotiation. According to Gruenbacher [13], the WinWin negotiation model is unable to provide structured communication among stakeholders, which leads to difficulties in resolving conflicts among business requirements. To mitigate the foregoing predicaments, the EasyWinWin process model (EWW) was proposed [14]. Although EWW may provide structured communication for stakeholders while requirements negotiation is being performed, EWW is unable to resolve this problem: reducing the number of defects in elicited business requirements to produce highquality negotiation results. In particular, fixing defects in software engineering activities in later stages of the process can be more expensive than fixing them in the early stages [15,16]. To detect business requirements defects in the early stages, the EWW with quality assurance (QA) process model was suggested [13]. QA techniques provide approaches to detect and remove defects that appear in business requirements provided by stakeholders. The characteristics of defects can be unclear statements, incomplete and obsolete requirements [17] as well as incorrect statements.
123
MPARN WinWin Negotiation
EWW
EWW-QA
Fig. 1 Evolution of requirements negotiation process models
Another requirements negotiation issue is stakeholders’ inability to understand other stakeholders’ perspectives to arrive at an agreement [18]. Stakeholders may have different expectations of how software should behave, and such disagreements can influence the main functionalities of software. Multi-criteria preference analysis requirements negotiation (MPARN) [19] is an ad-hoc model that provides structured activities that can assist stakeholders to understand other stakeholders’ perspectives to achieve an agreement. Figure 1 describes the evolution of requirements negotiation process models. As can be seen, the WinWin negotiation model is the requirements negotiation process model which has become the basis of EWW [20]. The EWW process model is an improved version of the WinWin negotiation model by providing structured communication activities to enhance negotiation process while supporting facilitation techniques [14]. To identify and remove requirements defects, QA techniques were integrated with (into) EWW; hence, EWW-QA was proposed. On the other hand, MPARN adopts the WinWin negotiation model; thus, it consists of negotiation activities from the WinWin negotiation model as well as activities that can perform quantitative assessment. Nevertheless, MPARN is unable to assess option score and criteria objectively. Another issue related to requirements negotiation process is inadequate provision of graphical support in visualising results of requirements elicitation [21]. On the whole, software requirement negotiation difficulties can be summarised as follows: 1. The need to eliminate vague expressions of stakeholders’ requirements. 2. The necessity to have structured communication among stakeholders throughout requirements negotiation. 3. Inability to reduce the number of defects to derive highquality negotiation results. 4. Unclear understanding of different perspectives among stakeholders to achieve an agreement. 5. Ad-hoc process from options to agreements. 6. Inability to assess option score and criteria objectively. 7. Lack of graphical support in visualising results of quantitative assessment. As explained, none of the existing process models addresses all of these issues. Consequently, it is necessary to develop an integrated requirement process model that can
Arab J Sci Eng (2014) 39:4667–4681
utilise the above process models and resolve these difficulties simultaneously. This paper attempted to formulate a requirements negotiation process model, called groupware requirements negotiation system (GRNS), which integrated EWWQA with MPARN using Bayes theorem to propose an allin-one integrated solution. Furthermore, a system was developed based on the GRNS process model to address all the afore-mentioned difficulties of requirements negotiation; experimental evaluation, questionnaires and expert analysis were performed to evaluate the proposed process model and system. In particular, two companies from the industry were requested to apply the GRNS process model and system. Then, a set of questionnaires was distributed among participants to obtain their feedback. Finally, an expert from industry was engaged to analyse the results provided by both companies and feedback received from participants.
4669
Fig. 2 WinWin negotiation process model and activities
2 Related Work This section describes the four requirements negotiation process models briefly explained earlier. A discussion covers the following: handling of the afore-mentioned requirements negotiation difficulties by the respective process models, and requirements negotiation difficulties which remain unresolved. At the end of the discussion, a comparative study of the existing process models is done and the proposed model is provided. 2.1 WinWin Negotiation Process Model The WinWin negotiation process model was proposed to ensure all stakeholders achieve their goals [4]. Its main contributions are [22]: 1. 2. 3. 4. 5.
eliciting business requirements from stakeholders; increasing cooperativeness; highlighting key issues; reducing disagreements; facilitating distributed collaboration with a stepwise approach to reconcile individual conditions.
This process model produces four deliverables or artefacts, namely win conditions (business requirements), issues, options, and agreement [23]; it provides stakeholders the capability to categorise artefacts systematically. Figure 2 illustrates the WinWin negotiation process model and its activities. Stakeholders begin the requirements negotiation process by brainstorming their win conditions. Based on the identified requirements, they determine the potential issue(s) of business requirements and reveal available options to resolve them. Stakeholders achieve agreement as soon as options are chosen to address the issues. Taxonomy organises all the deliverables and will be updated throughout the
requirements negotiation process. The main drawback of the WinWin model is that it only provides solutions for the first requirement negotiation difficulty; stakeholders must use other approaches to handle the remaining issues. 2.2 Multi-Criteria Preference Analysis Requirements Negotiation Multi-criteria preference analysis requirements negotiation adopts the WinWin negotiation model and integrates it with multi-criteria preference techniques. It is empirically effective to promote involvement and trust among stakeholders as well as to identify categories to reveal objective criteria and requirements classification. In addition, it prevents occurrence of misunderstandings among stakeholders about the functionalities of software. Nevertheless, as shown by In et al. [19], the use of ad-hoc process models to handle obstacles of reaching an agreement during the negotiation may not be beneficial when there are conflicts among identified win conditions. Thus, when stakeholders encounter any win-condition conflict, MPARN supports quantitative assessment, which resolves ad-hoc process between ‘reveal options’ and ‘negotiate agreements’ in the WinWin negotiation model. Subsequently, it may facilitate stakeholders in reaching agreements. The MPARN process model is illustrated in Fig. 3. Steps 1, 2, 3 and 8 are activities of the WinWin negotiation model adopted by MPARN. The remaining MPARN activities are: • Explore objective criteria facilitator and stakeholders perform this activity to obtain objective criteria, (i.e. taxonomy) based on elicited requirements. In particular, this activity enables stakeholders to identify priorities of requirements and to determine the criteria of importance.
123
4670
Arab J Sci Eng (2014) 39:4667–4681
Multi-Criteria Preference Analysis Requirements Negotiation Activities WinWin Negotiation Process Model Activities
1. Elicit Win Condition
Multi-Criteria Preference Techniques
4. Explore Objective Criteria
EasyWinWin Requirements Negotiation Model Activities 1. Review Negotiation Topic 2. Brainstorm Stakeholder Interest 3. Converge Win Condition
2. Identify Issues
3. Reveal Option
8. Negotiate Agreement
5. Assess options based on the criteria
6. Assess relative weight for criteria 7. Rank options
9. Update Taxonomy
Fig. 3 MPARN activities
4. Capture Glossary of Terms
9. Map Artefact to Taxonomy
5. Prioritise Win Condition
6. Identify Issues and Constraints
7. Reveal Option
8. Negotiate Agreement
Fig. 4 EWW process model
• Assess option score of criteria this activity is performed by stakeholders to assess performance of each option for each criterion. This activity serves the purpose of finding the best option for each conflict according to the criteria elicited in the previous step. • Assess objective-criteria weight this activity obtains relative weights of criteria and assesses the importance of elicited criteria in developing the system. The objective criterion that has the highest weight is considered the most important one. • Rank options this activity ranks performance of each option for each objective criterion by calculating option performance of each criterion using Bayes Theorem. • Bayes theorem Bayes Theorem is employed to score options and weight criteria. It is a mathematical formula used by MPARN to calculate the probability of achieving an objective criterion obtained in step 4 while considering the option taken to resolve the conflict [24,25]: Bayes Theorem = P(A|R) = P(A ∩ R)/P(R) in which: P(A ∩ R) = Objective criteria weight × option score and P(R) = Rank option value • Negotiate agreement post-analysis of agreement that quantifies stakeholders’ views of option performance of the criteria considered important.
123
Although MPARN handles the first, fourth and fifth negotiation difficulties, the rest of the problems remain unresolved. Likewise, stakeholders are unable to make a decision on objective criteria before the options are assessed. 2.3 EasyWinWin Requirements Negotiation Model The EWW model is based on the WinWin negotiation model and provides structured communication among stakeholders throughout the requirements negotiation process; it supports the use of facilitation techniques that allow stakeholders to have a better understanding of the related problems [3]. Damian et al. [26] stated that facilitation techniques are important for stakeholders to ease the requirements negotiation process. Figure 4 depicts the EWW process model. The activities are: 1. Review negotiation topic refines and customises negotiation topics to reflect stakeholders’ interests and culture. Stakeholders develop (add or delete) taxonomy that organises all deliverables that emerge from the entire requirements negotiation process. 2. Brainstorm stakeholder interests gathers win conditions using the provided taxonomy. 3. Converge win condition this activity merges the related win conditions into a single category. 4. Capture glossary of terms defines glossary of terms found in identified requirements. 5. Prioritise requirements prioritising requirements is necessary because it may not be possible for all software
Arab J Sci Eng (2014) 39:4667–4681
4671
requirements to be met due to limited time and resources. Practitioners may use techniques of requirements prioritisation as discussed by Karlsson et al. [27]. Identify issues based on the identified requirements, this activity helps stakeholders to determine the potential issue(s) of business requirements. Reveal options provides solutions for the identified issues. Negotiate agreements after options are discussed, stakeholders may achieve an agreement. Map artefacts to taxonomy identifies specific deliverable belonging to designated taxonomy.
EWW-QA requirements negotiation in detecting and removing defects were empirically evaluated. The process model is composed of three main phases, namely preparation, value-creation and finalisation; the three phases are integrated with QA techniques, which are preprocess, in-process and post-process, respectively. To put it differently, the process model contributes towards reduction of unnecessary complexities and risks caused by defects; the model carries out the procedure by applying quality assessments before the negotiation process is started, during the process, and after it is finished. Nonetheless, there are disadvantages in EWW-QA model, which are:
EWW only addresses the first and second requirements negotiation difficulties.
1. Detecting defects may be time-consuming and complicated. 2. Experienced stakeholders are needed to determine the severity level of defects. 3. The EWW-QA process model may only overcome the first three difficulties of requirements negotiation.
6.
7. 8. 9.
2.4 EasyWinWin with Quality Assurance Techniques (EWW-QA) This process model combines EWW with QA techniques to address quality issues in negotiation results by identifying and removing defects from business requirements [28]. As a result, project risks in the later stages of software development life cycle may be reduced. Grunbacher and Halling stated that a process model that incorporates QA techniques may allow all stakeholders to verify the quality of requirements by removing defects during the requirements negotiation phase [13]. Similarly, the effectiveness and efficiency of Table 1 Comparative study in terms of supporting requirements negotiation activities
Requirements negotiation activities
2.5 Comparative Study Table 1 presents a list of all activities of requirements negotiation and shows which of them are supported by the process models discussed here. Five activities are supported by all existing requirements negotiation process models. These activities were derived from the WinWin negotiation model and adopted by MPARN, EWW and EWW-QA.
WinWin negotiation
MPARN
EWW
EWW-QA
Negotiation preparation Review negotiation topic/update taxonomy/map artefacts to taxonomy Brainstorm requirements Converge requirements
GRNS process model
Review requirements
Capture glossary of terms
Review glossary of terms
Prioritise requirements
Identify issues
Reveal options
Produce WinWin tree
Classification/map artefacts to taxonomy Assess options based on criteria
Assess relative criteria weight by each stakeholder Rank options Negotiate agreements Inspection
123
4672
Arab J Sci Eng (2014) 39:4667–4681
Table 2 Comparative study in terms of addressing challenges of requirements negotiation
Requirements negotiation difficulties
WinWin negotiation
MPARN
EWW
EWW-QA
GRNS process model
1. Difficulties in eliminating vague expressions of stakeholders’ requirements 2. Difficulties in having structured communication among stakeholders throughout requirements negotiation 3. Difficulties in reducing the number of defects to derive high quality negotiation results 4. Difficulties in understanding other stakeholders’ perspectives to achieve an agreement 5. Ad-hoc process from options to agreements 6. Difficulties caused by inability to assess option score and criteria objectively 7. Lack of graphical support in visualising results of quantitative assessment
EWW adopts the WinWin negotiation model and integrates it with EWW activities to provide structural communication for stakeholders throughout the process. The model is then adopted by the EWW-QA process model, where QA techniques are applied to provide deliverables fault detection and isolation activities. Thus, EWW-QA model may be considered as the most comprehensive process model as it contributes more by supporting most of the requirements negotiation activities. EWW-QA model goes through a three-step evaluation procedure that may provide higher quality. Nonetheless, it neither supports the multi-criteria preference techniques for quantitative assessment nor addresses all of the negotiation challenges. Table 2 compares the proposed model with the requirements negotiation models discussed above in terms of addressing difficulties of software requirements negotiation, as explained in Sect. 1. As is shown, each requirement negotiation process model only addresses some of the aforementioned challenges; this is because each process model is an improved version of another model, taking the WinWin model as its basis. The proposed GRNS process model supports all activities of requirements negotiation and provides solutions to all the difficulties. The next section describes the process model in detail. 3 GRNS Process Model Formulation The formulation of the GRNS process model is explained in Fig. 5, which shows how EWW, QA and MPARN are
123
adopted. Multi-criteria preference techniques are derived from the MPARN process model which adopted the WinWin negotiation model. The multi-criteria preference techniques are placed between the activity of ‘reveal options’ and that of ‘negotiation agreement’ in the WinWin negotiation model, as presented in Fig. 2. QA techniques split the ‘requirements negotiation’ stage into three phases, namely preparation, value-creation and finalisation, which are explained later. The EWW requirements negotiation process is integrated with the in-process QA techniques under the value-creation phase. Figure 6 shows the process model and its activities. The MPARN ‘Explore Objective Criteria’ activity and EWW ‘Brainstorm Negotiation Topic’ activity provide similar services; in particular, both serve the same purpose of requiring stakeholders to produce requirements categories based on elicited requirements. Thus, to avoid redundancy, the ‘Brainstorm Negotiation Topic’ is removed from the proposed process model. The ‘Explore Objective Criteria’ and ‘Map artefacts to Objective Criteria’ activities can be iterated if stakeholders want to organise artefacts throughout the requirements negotiation process. As can be seen in Fig. 6, the GRNS process model is divided into three phases, each of which requires commencing inputs and produces outputs at the end of the phase. The initial input is ‘mission statement’ of the system to be developed; it benefits the facilitator in preparing four information items: negotiation purpose, context information, major objectives and selected stakeholder list. These items serve as inputs to the value-creation phase. Stakeholders use the provided information items to produce negotiation results. Finally, the results are given in the finalisation phase, where
Arab J Sci Eng (2014) 39:4667–4681 Fig. 5 Formulation of GRNS process model
4673
Mission statement EWW + QA + MPARN
Preparation Phase Process
Value -Creation Phase
Pre -process QA techniques
Process Process
Finalis ation Phase
Process
In-process QA techniques
Post -Process QA techniques
Finalised Requirements Negotiation results EWW + MPARN Review negotiation topic
Negotiate agreement
Brainstorm stakeholders’ interests
MPARN
Converge on win conditions
Capture glossary of terms
Reveal options
Prioritise win conditions
Identify issues
MPARN Explore objective criteria
they are evaluated based on defects provided by inspectors; thereafter the negotiation results are considered as final. In the following section, each phase is explained further. 3.1 Preparation Phase Preparation activities help the facilitator to prepare negotiation objectives and related information before stakeholders begin requirements negotiation. In particular, pre-process QA techniques are integrated with preparation activities to support the facilitator in reviewing the checklist of necessary steps and typical defects. After the review, this phase allows the facilitator to conduct specific tailoring activities. 3.2 Value-Creation Phase The value-creation phase helps stakeholders to collaboratively engage in requirements negotiation. The information prepared in the previous phase is revealed to stakeholders in the initial part of this phase. Stakeholders then identify issues from the list of brainstormed interests; they then determine
Assess relative weights for criteria
Assess options based on criteria
Rank options using Bayes Theorem
the options that may resolve the identified issues using EWW activities. In-process QA techniques are used to conduct a rapid joint review that includes all stakeholders and authors of requirements to spot and rectify defects throughout the valuecreation phase. Multi-criteria preference techniques (activities 13–16 in Fig. 6) support quantitative assessment. They begin with exploring and evaluating objective criteria, (i.e. condition probability) and proceed to assess options based on the criteria, (i.e. joint probability). Finally, the GRNS process model applies Bayes Theorem for posterior probability calculations to rank the identified options. Stakeholders apply the probability values for negotiating agreements and producing negotiation results. Although prior probability is only an approximation and may not be one hundred percent accurate, its applications are extensive and acceptable, especially in complex pattern recognition tasks such as automatic speech recognition. Elimination of prior probability will render GRNS incapable of addressing the fifth challenge of requirements negotiation: “Ad-hoc process from options to agreements”, which is men-
123
4674
Arab J Sci Eng (2014) 39:4667–4681
GRNS Process Model Preparation (P0)
Pre-Process QA Techniques (QA0)
Value Creation (P1)
In-Process QA Techniques (QA1)
Post-Process QA Techniques
Finalisation (P2)
Checked Plan
Mission Statement
4. Review checklist containing necessary steps and typical defects
Negotiation purpose, context information, major objective of the developing system, selected stakeholder list
1. Summarize purposes, context information, and major objectives
5. Brainstorm Stakeholder Interest
2. Select stakeholders
7. Capture Glossary of Terms
6. Converge Win Condition
Plan to check
3. Conduct specific tailoring activities
9. Prioritise Win Condition
8. Produce initial set of requirements and glossary of terms
20. Planning for inspection by inspector leader Final Deliverable to check
21. Preparation for inspection by inspector leader
Negotiation Results
10. Identify Issues and Constraints 22. Inspection preparation
11. Reveal Option
23. Individual reading
12. Explore objective criteria Checked Deliverables
13. Assess relative weights for criteria 14. Assess options based on criteria
25. Report and/or rework
15. Rank options using Bayes 16. Visualize quantitative result Deliverable to check
17. Negotiate Agreement
24.Meeting of inspectors
19. Review WinWin tree
Finalised Requirements Negotiation Result
18. Map Artefact to Objective Criteria
Fig. 6 Proposed GRNS process model and activities
tioned in Table 2. Dealing with this challenge is important because priorities of selection should be based on the type of stakeholders: stakeholders from management or shareholders may have different priorities from those of operational stakeholders such as end-users. Even priorities of various operational stakeholders may be different as they each perform different tasks using the software. Thus, it is important to assign weights to the relative criteria using Bayes Theorem to determine the criterion with the highest weight (vote). GRNS also supports activities of selecting stakeholders and ensures that all stakeholders contribute their opinions in the entire process of requirements negotiation. 3.3 Finalisation Phase Stakeholders conduct inspections in the finalisation phase to detect and remove defects from negotiation results. They inspect negotiation results using reading techniques and document the identified defects. Finally, stakeholders vote on the issue pertaining to defects to decide whether improvements are required. 4 Evaluation This section explains the evaluation procedure of the GRNS process model. The evaluation was carried out by two indus-
123
trial companies using experimental evaluation, questionnaires and expert analysis. The hypothesis of evaluation is that the GRNS process model is capable of providing an allin-one solution to ease difficulties of requirements negotiation; it is user-friendly and suitable for users in the software industry.
4.1 Participants The evaluation of the proposed process model was conducted by two software development companies, namely Century Software Bhd and iMocha Sdn Bhd. The first company is involved in government projects for financial management and business solutions. The second company is in the business of providing financial systems for banks and insurance companies. Individuals with different skills from the two companies were chosen as participants of the evaluation; they include programmers, systems analysts, project managers and technical leader specialists. These people were selected because they have experience in the process of requirements negotiation. An expert was also asked to join the evaluation panel. He is an IT consultant who has 20 years of consulting experience in software development for governmental and private projects.
Arab J Sci Eng (2014) 39:4667–4681 Table 3 Experimental evaluation description
4675
Participants
Project managers User managers Systems analysts Technical lead specialist
Independent variable Dependent variable
Negotiation session with QA techniques and negotiation session without QA techniques Defect count in negotiation results Defect severity
Experimental control
Provide same experimental material for both groups
Table 4 Experimental results Participant
Independent variable
Defect count
Defect severity
Century Software House Sdn Bhd
Negotiation session without QA techniques
9
Average
iMocha Consulting Sdn Bhd
Negotiation session with QA techniques
3
Minor
4.2 Instruments A web-based system was developed to accommodate the proposed GRNS process model using PHP and MySQL DBMS. Participants were asked to apply GRNS to a case study to evaluate the proposed model. The case study was a receipting system project that was designed for front-end payment collection; the system was to be interfaced with the existing back-end financial systems. Both companies had the same set of negotiation objectives, context information requirements and glossary of terms, but the negotiation process was carried out separately by the respective companies. 4.3 Procedure Table 3 describes the experimental evaluation. For verification purposes, Century Software Bhd conducted requirements negotiation using a version of the GRNS process model which was not integrated with QA. On the other hand, iMocha Sdn Bhd performed requirements negotiation using the complete GRNS process model that was integrated with QA techniques. Both groups used the same experimental material as the experiment control. The defect counts in both sets of negotiation results were considered in verifying the effectiveness of the GRNS process model with QA techniques in detecting and removing defects. As soon as participants had completed the experiment, a set of questionnaires was distributed to all of them. The final negotiation results derived from the experimental evaluation were given to the expert reviewer to analyse the results. The expert reviewer was given the requirements negotiation results produced by iMocha Sdn Bhd; the results were derived from the experiment which applied the comprehensive GRNS process model, (i.e. including QA techniques).
The purpose of this evaluation was to find out whether multicriteria preference techniques provided structured activity between ‘revealed option’ and ‘negotiated agreement’. Similarly, assessing the degree of assistance to reach agreement, as provided by the posterior value for stakeholders, was also considered. The results are described in the following section.
5 Results and Discussion This section is divided into three parts. The first part shows the experimental evaluation results. The second part explains the results of the questionnaires, and the final part describes the analysis performed by the expert reviewer. 5.1 Experimental Evaluation Results Table 4 shows the results of the experimental evaluation. As can be seen, the proposed GRNS process model that incorporated QA techniques produced fewer defects and with lower severity in comparison with the model that did not apply the techniques. The levels of defect severity we have considered in this study are: 1. Critical the defect causes an unfixable software system, subsystem or module failure. 2. Major the defect causes a failure in software system, subsystem or module with acceptable processing alternatives to achieve the desired result. 3. Average the defect causes the system to produce incorrect, incomplete or inconsistent results. 4. Minor the defect causes the system to produce undesired processing results but can be easily fixed.
123
4676
Arab J Sci Eng (2014) 39:4667–4681
Table 5 Effects of proposed GRNS process model on the experimental case study
The applied QA technique
Effects
Review preparation information
Detected 2 defects from requirements preparation module
Review requirements
Detected 5 incomplete requirements from the list of requirements
Review glossary of terms
Detected 2 out of 3 misleading definitions from the list of glossary of terms
Inspection activity
Detected 1 defect in an issue that was not described completely, and 1 option defect that was not related to the issue. Similarly, there were 2 undetected, vague issues
5. Exception the defect may be considered as an enhancement. Defects at this level may be deferred or even ignored.
were caused by vague statements, the severity level of which is minor as they may only cause undesired results that can be easily fixed.
In the following section, the above results are elaborated further. Negotiation session without QA techniques a total of nine defects were detected by participants of the first company in this experiment. The requirements’ defects were caused by:
5.2 The Questionnaires’ Results
(a) Incomplete requirement descriptions, which were commonly caused by including the word ‘etc.’, in the requirements. (b) Vague statements which did not clearly explain the requirements, such as ‘Design a proper data centre’. (c) Misleading definitions in glossary of terms. (d) Incomplete and vague information in requirements preparation. Most defects found in the requirements were due to vague and incomplete business requirements. This type of defects may cause developers to interpret requirements differently and implement the corresponding functionalities incorrectly. According to [29], a minor defect in negotiation results can become more serious, which may cause the final software system to diverge from the expected requirements and lead to costly reworking. The levels of severity of these defects are average, and they may cause the system to produce incomplete results. However, there were no conflicting statements and ideas about the objectives, assumptions and expectations during the business requirements brainstorming activity. This means stakeholders fully understood the information provided by the facilitator during the requirements preparation activity. Negotiation session with QA techniques results from the same case study show that the defect count was reduced by 66 % by applying the GRNS incorporated with QA techniques. Table 5 explains how stakeholders detected and removed the defects. In particular, there were 14 defects in total; using the GRNS with QA helped to find 11 of them, (i.e. 78.5 % of the defects were detected), but 21.5 % or 3 defects remained. Nevertheless, the three remaining defects
123
The questionnaires were used to: 1. Assess the ease of use of GRNS. 2. Assess the effectiveness of GRNS functionalities in supporting requirements negotiation. 3. Assess the effectiveness of GRNS in easing the difficulties of requirements negotiation. 4. Assess the overall opinion of GRNS. Ease of use of GRNS participants agreed that the proposed model gave them full control in expressing their interests and concerns regarding the project. The proposed model achieved 95 % effectiveness in capturing positive emotional responses. Similarly, participants believed that the proposed process model was 90 % efficient and 80 % helpful throughout the requirements negotiation session. The effectiveness of GRNS functionalities in supporting requirements negotiation Table 6 explains the effectiveness of GRNS functionalities. The mode values of the functionality effectiveness show that all functionalities are effective in supporting requirements negotiation, except the function to reveal option. In more precise words, 22.22 % of the participants do not feel that this function is effective. This is because GRNS does not allow stakeholders to reveal available options for each issue separately. Instead, GRNS only permits options to be revealed when all related issues are banded together under one objective criterion. This is mainly due to characteristics of system design. When options are revealed based on one issue, more issues may be created because options for other issues have not been revealed and considered. Thus, in early-stage activities of GRNS, objective criteria (such as functionality, cost and schedule) are defined by stakeholders before issues are grouped into respective objective criteria by stakeholders. At the stage for function to reveal options, stakeholders need to select one
Arab J Sci Eng (2014) 39:4667–4681
4677
Table 6 Ratings of effectiveness of GRNS functionalities GRNS functionalities
Rating (%)
Mean
Mode
1
2
3
4
Do not know
1. Requirements preparation
–
–
77.78
22.22
–
3.30
3
2. Review preparation information
–
–
66.67
33.33
–
3.40
3
3. Brainstorm requirements
–
–
88.89
11.11
–
3.20
3
4. Converge win conditions
–
–
88.89
11.11
–
3.20
3
–
88.89
11.11
–
3.20
3
6. Capture glossary of terms
–
–
88.89
11.11
–
3.20
3
7. Review glossary of terms
–
–
77.78
11.11
11.11
3.22
3
8. Explore objective criteria
–
–
88.89
11.11
–
3.20
3
9. Requirements classification
–
–
77.78
11.11
11.11
3.22
3
66.67
22.22
11.11
3.33
3 3
5. Review requirements
10. Identify issues and constraints 11. Prioritise requirements
–
–
88.89
11.11
–
3.20
12. Reveal options
11.11
11.11
44.44
11.11
22.22
2.50
3
13. WinWin tree
–
–
50.00
50.00
–
3.56
3
14. Assess objective criteria
–
–
62.50
37.50
–
3.44
3
15. Assess option based on objective criteria
–
–
–
16. Negotiate agreements 17. Inspection
–
–
62.50
37.50
75.00
25.00
88.89
11.11
–
3.44
3
3.33
3
3.20
3
Mean
Mode
Table 7 Effectiveness ratings of GRNS process model in easing requirements negotiation difficulties GRNS process model activities and techniques
Rating (%) 1
2
3
4
Do not know
1. WinWin spiral model: enable users to express interest and concerns 2. EasyWinWin activities: provide structured communication among stakeholders 3. Repeatable quality assurance techniques: ability to detect defects throughout requirements negotiation 4. Multi-criteria preference analysis: facilitate users to achieve shared vision on how the proposed system should behave 5. Multi-criteria preference analysis: encourage involvement and trust among users 6. Multi-criteria preference analysis: provide structured and standardised process from reveal option to negotiate agreement
–
–
66.67
33.33
–
3.40
3
–
–
66.67
33.33
–
3.40
3
–
11.11
66.67
22.22
–
3.20
3
–
–
88.89
11.11
–
3.20
3
–
11.11
66.67
22.22
–
3.20
3
–
–
77.78
22.22
–
3.10
3
objective criterion at a time before GRNS displays all of the related grouped issues. By choosing this solution, GRNS allows users to reveal options after considering all of the related issues. The effectiveness of the GRNS process model in easing difficulties of requirements negotiation the Effectiveness ratings of the GRNS process model in easing requirements negotiation difficulties are described in Table 7. The mode values show that all requirements negotiation activities and tech-
Fig. 7 GRNS overall opinion
123
4678
Arab J Sci Eng (2014) 39:4667–4681
Table 8 Expert review analysis
123
Arab J Sci Eng (2014) 39:4667–4681
4679
Table 8 Continued
niques used in the GRNS process model are effective in easing requirements negotiation difficulties, indicating that the GRNS process model has fulfilled the expected objectives. However, a closer look shows that 11.11 % of participants feel that GRNS is not effective in detecting defects throughout the requirements negotiation; this is because defects in identified issues and revealed options can only be detected after completion of the entire requirements negotiation process. There is no specific function that supports this activity of defect detection immediately after activity of identifying issues or revealing options. In addition, 11.11 % of participants agree that the GRNS process model is not effective in encouraging stakeholders’ involvement and trust, because the GRNS process model
allows negotiation process to proceed without the involvement of all participants. The overall opinion on GRNS all participants agree that GRNS is capable of allowing distributed stakeholders to negotiate requirements as GRNS is presented as a web-based tool. Furthermore, according to 87.5 % of participants, GRNS meets industry demand, since the GRNS process model is effective in supporting requirements negotiation process. Figure 7 illustrates participants’ overall opinion. 5.3 Expert Analysis This section presents the effectiveness of understanding other stakeholders’ perspective by viewing the posterior values.
123
4680
Arab J Sci Eng (2014) 39:4667–4681
When stakeholders understand one another, it is easier to agree on selection of options needed. Furthermore, all stakeholders are able to rank options; this makes voting more comprehensive. In particular, the expert was asked to analyse the posterior values and the agreements reached by participants from iMocha Sdn Bhd. The purpose was to provide feedback regarding the helpfulness of GRNS for stakeholders to reach an agreement. Table 8 presents the expert review analysis.
6 Conclusion This paper presents a requirements negotiation process model that integrates EWW with QA and MPARN techniques. The proposed model assists stakeholders to perform the following tasks: elicit clear requirements, provide structured communication among stakeholders, reduce defects and decrease their severity levels as well as understand other stakeholders’ perspectives to achieve an agreement. Moreover, a webbased system was developed, which implemented the proposed process model; the system provides a synchronous mode of interaction for distributed stakeholders to negotiate requirements. The proposed process model was evaluated in practice using experimental evaluation, questionnaires, and expert analysis from software industry environment. With reference to experimental evaluation, GRNS reduced defects by 78.5 % in our experiments. Likewise, the questionnaire evaluation results show that the majority of participants stated that the proposed process model overcame the requirements negotiation difficulties discussed in earlier sections of this paper. Furthermore, analysis conducted by the expert reviewer explains that stakeholders may understand one another’s perspectives better by viewing posterior values during negotiation agreement activity. The integration of EWW with QA and MPARN allows the GRNS process model to capture all the strengths and useful outputs of the adopted process models; consequently, the proposed GRNS process model is an all-in-one requirement negotiation system, capable of handling all types of problems arisen. The advantages of the proposed process model are: 1. Clear expression of stakeholders’ requirements. 2. Provision of structured activities throughout requirements negotiation process. 3. Deriving quality negotiation results. 4. Providing structured activities between stages of ‘reveal options’ and ‘negotiate agreements’. 5. Assisting stakeholders in achieving agreement on intended behaviour of the proposed system. 6. Assessing option score and criteria objectively. 7. Providing graphical support by displaying posterior values in tabulated form.
123
The GRNS process model cannot reveal options based on a single issue, because each requirement may have multiple issues, and each of the issues can have multiple options. If the GRNS process model could carry out this task, users would have to assess numerous options, which were timeconsuming, unnecessary; moreover, more issues might be created, because other issues had not been considered while assessing an option. It would be helpful for future studies to find a solution to provide stakeholders with an alternative approach to reveal options for issues under the same category, or to reveal options based on a single issue. References 1. Elish, K.; Alshayeb, M.: A classification of refactoring methods based on software quality attributes. Arab. J. Sci. Eng. 36(7), 1253– 1267 (2011). doi:10.1007/s13369-011-0117-x 2. Alshayeb, M.: The impact of refactoring to patterns on software quality attributes. Arab. J. Sci. Eng. 36(7), 1241–1251 (2011). doi:10.1007/s13369-011-0111-3 3. Grunbacher, P.; Halling, M.; Biffl, S.; Kitapci, H.; Boehm, B.W.: Repeatable quality assurance techniques for requirements negotiations. In: 36th Hawaii International Conference on Systems Sciences, Los Alamitos, CA, USA 2003. 36th Hawaii International Conference on Systems Sciences, p. 9. IEEE Computer Society 4. Boehm, B.; In, H.: Identifying quality-requirement conflicts. IEEE Softw. (Copyright 1996, IEE) 13, 25–35 (1996) 5. Curtis, B.; Krasner, H.; Iscoe, N.: Field study of the software design process for large systems. Commun. ACM 31, 1268–1287 (1988) 6. Nissen, H.W.; Jeusfeld, M.A.; Jarke, M.; Zemanek, G.V.; Huber, H.: Managing multiple requirements perspectives with metamodels. IEEE Softw. 13(2), 37–48 (1996). doi:10.1109/52.506461 7. Nuseibeh, B.: Conflicting requirements: when the customer is not always right. Requir. Eng. 1(1), 70–71 (1996). doi:10.1007/ bf01235767 8. Easterbrook, S.: Resolving requirements conflicts with computersupported negotiation. In: Requirements Engineering: Social and Technical Issues, pp. 41–65. Academic Press Professional, Inc., San Diego, CA, USA (1994). ISBN: 0-12-385335-4. http://dl.acm. org/citation.cfm?id=189996 9. Ali, R.; Dalpiaz, F.; Giorgini, P.: Reasoning with contextual requirements: detecting inconsistency and conflicts. Inf. Softw. Technol. 55(1), 35–57 (2013). doi:10.1016/j.infsof.2012.06.013 10. Saberi, S.; Shahandeh Nookabadi, A.; Reza Hejazi, S.: Applying agent-based system and negotiation mechanism in improvement of inventory management and customer order fulfilment in multi echelon supply chain. Arab. J. Sci. Eng. 37(3), 851–861 (2012). doi:10.1007/s13369-012-0197-2 11. Boehm, B.; Bose, P.; Horowitz, E.; Lee, M.J.: Software requirements negotiation and renegotiation aids: a theory-W based spiral approach. In: Proceedings of the 1995 IEEE 17th International Conference on Software Engineering, Seattle, WA, USA 1995. Proceedings—International Conference on Software Engineering, pp. 243–253 12. Calefato, F.; Damian, D.; Lanubile, F.: Computer-mediated communication to support distributed requirements elicitations and negotiations tasks. Empir. Softw. Eng. 17(6), 640–674 (2012). doi:10.1007/s10664-011-9179-3 13. Grunbacher, P.; Halling, M.; Biffl, S.; Boehm, B.W.: Integrating collaborative processes and quality assurance techniques: experiences from requirements negotiation. J. Manag. Inf. Syst. 20(4), 10–30 (2004)
Arab J Sci Eng (2014) 39:4667–4681 14. Gruenbacher, P.; Briggs, R.: Surfacing tacit knowledge in requirements negotiation: experiences using easy win win. In: 34th Annual Hawaii International Conference on System Sciences, Maui, HI, United states 2001. Proceedings of the Hawaii International Conference on System Sciences, IEEE Computer Society, p. 35 15. Shahamiri, S.R.; Kadir, W.; Ibrahim, S.; Hashim, S.Z.M.: An automated framework for software test oracle. Inf. Softw. Technol. 53(7), 774–788 (2011). doi:10.1016/j.infsof.2011.02.006 16. Shahamiri, S.R.; Wan-Kadir, W.N.; Ibrahim, S.; Hashim, S.: Artificial neural networks as multi-networks automated test oracle. Autom. Softw. Eng. 19(3), 303–334 (2012). doi:10.1007/ s10515-011-0094-z 17. Wnuk, K.; Gorschek, T.; Zahda, S.: Obsolete software requirements. Inf. Softw. Technol. 55(6), 921–940 (2013). doi:10.1016/j. infsof.2012.12.001 18. Keil, M.; Carmel, E.: Customer-developer links in software development. Commun. ACM 38, 33–44 (1995) 19. In, H.P.; Olson, D.: Requirements negotiation using multi-criteria preference analysis. J. Univ. Comput. Sci. 10(4), 306–325 (2004) 20. Boehm, B.; Ross, R.: Theory-W software project management principles and examples. IEEE Trans. Softw. Eng. 15, 902–916 (1989) (Copyright 1989, IEE) 21. Acuña, S.T.; Castro, J.W.; Juristo, N.: A HCI technique for improving requirements elicitation. Inf. Softw. Technol. 54(12), 1357– 1375 (2012). doi:10.1016/j.infsof.2012.07.011 22. Boehm, B.; Egyed, A.: Software requirements negotiation: some lessons learned. In: Proceedings of the 1998 International Conference on Software Engineering, Kyoto, Japan 1998. Proceedings— International Conference on Software Engineering, IEEE Comp Soc, pp. 503–506
4681 23. Kazman, R.; In, H.P.; Chen, H.-M.: From requirements negotiation to software architecture decisions. Inf. Softw. Technol. 47(8), 511– 520 (2005). doi:10.1016/j.infsof.2004.10.001 24. Tosun, A.; Bener, A.; Turhan, B.; Menzies, T.: Practical considerations in deploying statistical methods for defect prediction: a case study within the Turkish telecommunications industry. Inf. Softw. Technol. 52(11), 1242–1257 (2010). doi:10.1016/j.infsof.2010.06. 006 25. Coolen, F.P.A.; Goldstein, M.; Munro, M.: Generalized partition testing via Bayes linear methods. Inf. Softw. Technol. 43(13), 783– 793 (2001). doi:10.1016/s0950-5849(01)00185-9 26. Damian, D.E.H.; Eberlein, A.; Woodward, B.; Shaw, M.L.G.; Gaines, B.R.: An empirical study of facilitation of computermediated distributed requirements negotiations. In: 5th IEEE International Symposium on Requirements Engineering, Toronto, Canada 2001. Proceedings of the IEEE International Conference on Requirements Engineering, IEEE Computer Society, pp. 128–135 27. Karlsson, J.; Wohlin, C.; Regnell, B.: An evaluation of methods for prioritizing software requirements. Inf. Softw. Technol. 39(14–15), 939–947 (1998). doi:10.1016/s0950-5849(97)00053-0 28. Mahmood, S.; Lai, R.; Soo Kim, Y.; Hong Kim, J.; Cheon Park, S.; Suk Oh, H.: A survey of component based system quality assurance and assessment. Inf. Softw. Technol. 47(10), 693–707 (2005). doi:10.1016/j.infsof.2005.03.007 29. Linhares, G.B.R.; Borges, M.R.S.; Antunes, P.: Collaboration and conflict in software review meetings. Int. J. Inf. Technol. Decis. Mak. 11(6), 1065–1085 (2012). doi:10.1142/s0219622012400159
123
