Understanding the Use of Elicitation Approaches for Effective Requirements Gathering

8/9/2019 Understanding the Use of Elicitation Approaches for Effective Requirements Gathering

1/6

Understanding the use of Elicitation Approaches for Effective RequirementsGathering

Bee Bee Chua 1, Danilo Valeros Bernardo 1, June Verner 2 Faculty of Engineering and Information Technology 1 and School of Computer Science and Engineering 2

University of Technology, Sydney and University of New South Wales

Sydney, Australia [email protected];[email protected];[email protected]

Abstract -Requirements sometimes can turn out to be eitherincomplete or inconsistent. Factors contributing to this situationinclude the selection of the elicitation technique and otherapproaches used. Some approaches used for requirementsgathering such as single elicitation approach, and their effectsduring requirements elicitation, can cause deficiency in manyrequirements elicitation methods. Our experimental studyshowed that when an interview technique is used, choice-basedand integration-based approaches are far better than a singleelicitation approach, as they provide an effective process foreliciting complete and correct requirements.

Keywords-requirements elicitation; requirements gathering;interviews; choice-based; integration-based

I. INTRODUCTION

The aim of most requirements elicitation (RE)techniques or tools is to reduce requirements ambiguity andto improve requirements clarity. However only a few REtechniques, on their own, can support requirementscorrectness, consistency and completeness, and can addressambiguity. Face-to-face RE methods such as stakeholderinterviews focus on getting the right requirements and notso much on resolving requirement ambiguity. Consequently,

the formation of focus groups is designed to help elicit userrequirements much more clearly and to removeinconsistencies.

Other tools such as flowcharting, business processes,documentation, user manuals, organizational charts, processmodels and systems and process specifications are madeavailable to support and assist developers and designerswhen translating user logical requirements into visual aidsshowing steps and sequences. Similarly, while action-basedmethods and observational RE techniques (for example, on-site analysis, market research and competitor analysis)concentrate on requirements ambiguity reduction, they areless focused on eliciting appropriate requirements.

Ensuring requirements that are complete and correct isimportant for the software development team so that thecorrect system can be properly developed in accordancewith users’ wants and needs. Unfortunately, eliciting

business user requirements is a process which is very time-consuming for both business analysts and users.

Applying methods such as prototyping and use caseshelps to ascertain which requirements users want rather than

reducing the complexity of business and technologyrequirements. None of these methods is good for outliningrequirements completeness and ensuring their correctness.

Most industry business analysts or software developerswe interviewed say that they prefer to use interviews alone asa single RE technique because of ease of use and suitabilityfor users and themselves. They suggest that they only choosemultiple RE techniques if a single technique does not resultin clear requirements. In the context of RE literature, theadvantages and disadvantages of using a single techniquehave been widely discussed, yet few have investigated asingle RE technique during requirements collection.

The objective of this paper is to provide insight into asingle RE technique, the interview, and to investigateapproaches that are effective in collecting complete andconsistent business requirements. To attain this objective,this paper is structured as follows: section two discussesrelated works; in section three, we use an experiment to

provide an outline of how the RE approaches were used. Insection four, our exploratory results are discussed, and insection five, we suggest future research.

II. RELATED WORKSIt is not easy to discuss requirements problems unless we

are presented with real empirical work.

TABLE A PROBLEMS WITH REQUIREMENTS ADAPTED FROM [2]

Problems with Requirements adapted from [2]Incomplete requirements Incomplete understanding

of needsIncomplete domain knowledge Poor user collaborationOverlooking tacit assumptions Incorrect requirementsIll-defined system boundaries Misunderstanding of

system purposeAmbiguous requirements Synonymous and

homonymous termsUn-testable terms Unnecessary design

considerationsInconsistent requirements Non-solid intentions of

requestersDifferent views of different users Unfixed requirementsFluctuating requirements Continuous acceptance of

additional requirementsExcessive requirements Unorganized bulky

information sourcesToo many requesters Over-commitment by

sales staff

2010 Fifth International Conference on Software Engineering Advances

978-0-7695-4144-0/10 $26.00 © 2010 IEEEDOI 10.1109/ICSEA.2010.89

325

2010 Fifth International Conference on Software Engineering Advances

978-0-7695-4144-0/10 $26.00 © 2010 IEEEDOI 10.1109/ICSEA.2010.89

325


2/6

Researchers Davey and Cope [1] provide some insightinto this area and present an interesting table which Tsumaki& Tamai [2] used as the basis for conducting a study intorequirements elicitation problems, suggesting 22 differentsources of requirements difficulties (see above table A).Additional problems incurred in RE include missingattributes [3], poorly defined user requirements [4], a poor

understanding of users’ needs [5], user requirements that areoverly difficult to understand by the software developmentteam, and incorrect user requirements leading to confusionfor developers. Of all the factors considered, the greatestimpact comes from ambiguous user requirements, whichincreases a project’s exposure to unpredicted project risk [6].

From a software maintenance perspective, Chua et al. [7]describe unclear initial user requirements that lead to thenecessity of requirements changes during testing andmaintenance. In other words, effort rework increases becauseof requirements changes, and as a result, the cost of softwaremaintenance increases.

To resolve requirements problems, formal RE methodsand techniques were developed. Davis et al. [8] mentioninterviews as the most popular RE technique for gatheringrequirements. However they also note that interviews are notthe only effective RE technique. Frey and Oishi [9] defineinterviews which are used to gain an understanding of a

particular topic as a means of communication andinformation exchange where one person asks preparedquestions (interviewer) and another answers them(respondent). Styles of interviews vary; each has its ownindividual effect, which can significantly impact onrequirements collection.

In the software requirements field [5], requirements-

gathering techniques such as brainstorming, prototyping,card sorting, interviews and agile methodologies [10, 11, 12,13, 14, 15, 16] are effective in supporting requirementselicitation. Such techniques are thought to be worthwhilewhen conducted in the academic environment and can help

promote learning by encouraging socialization andinteraction between learners; however, they do notnecessarily support requirements completeness. Althoughmany techniques have been introduced, business analystshave ended up choosing interviews rather than othertechniques because interviews are simple, they involve fewsteps, and are effective for collecting structuredrequirements. The other argument is that the interview has

been rated as one of the most effective requirements

elicitation techniques by practitioners [8].The use of either a single RE technique or combined RE

techniques for each requirements gathering outcome dependson the approach used and the particular situation. Sometechniques are suitable for extracting factors, variables ornames, while some requirements elicitation techniques needto deal with choices, decision support and prioritization; forexample, in order to organize what users’ requirements areChia and Okamoto [18] interviewed users by applying a

modeling-based approach to model users’ experience andtheir involvement in an activity or scenario in order toidentify factors in requirements that could be used to developa system. Firesmith [19] highlighted that although interviewscan help to reduce requirements conflicts betweenstakeholders, and in prioritizing requirements, they do notaddress requirements that are either incomplete or incorrect.

The way an interview is used is not designed to correctincomplete and inconsistent user requirements .

We have often heard from business analysts that theyhave gathered sufficient requirements from users, but wehave subsequently discovered that these requirements are notas accurate as they should be. The underlying question iswhich approach is the most effective in providing and

promoting elicitation support for interviewers, especially insituations where user requirements are implicitly known butnot explicitly clear.

III. EXPERIMENT

One of the authors of this paper is subject coordinatorfor an undergraduate course offered to informationtechnology students. In one of their assignments, students areasked to read a short scenario and then construct a diagramwith stakeholders’ concerns, views and hopes for using anew information system. Such a scenario is commonly in

practice where good requirements are important. In particular, a software development team needs explicitinformation on user or systems requirements to build asuitable system. Unfortunately, in reality, user requirementsare not constant and we can expect changes to continuouslyarise; hence prior to implementing requirements changesappropriately, we need to understand the impact and analyzethe change in order to ascertain the effect on the scope of the

project and the impact on other requirements.

To foster enthusiasm in students doing the experiment,every student was informed that each would play two roles.The main role player is a requirement analyst responsible forcollecting requirements from stakeholders; the other role isas a stakeholder whose responsibility it is to providerequirements to the requirement analyst.

The purpose of this experiment is to investigate theeffects of the requirements elicitation techniques used bystudents. Group sizes of five to six students were formed tocarry out discussions and participate in the RE activity.Students were told that they could use any requirements

gathering techniques of which they were aware. On this basis, students were not given any detailed instruction onhow to go about eliciting and collecting requirements.

At the end of the activity, students were asked to presenttheir findings through the construction of a diagram. A weeklater, survey forms were distributed for completion; one ofthe questions in the survey asked how the students had goneabout collecting requirements from different groups.

326326


3/6

87 out of 90 students completed the sur it for analysis. The investigation includeeffects of a particular RE technique as itgiven context, and what kinds of effects rea single and combined RE. Unsurprisinglchose the interview as the only requiretechnique they used. From time perspecti

reason why students prefer interviewstechniques because of restricted time in thewere given very short time to collect requimust complete the exercise on that day.why they like interviews because it is facecan have a good interaction with other studconcurred with [8] that interviews are theused elicitation technique in practice.

Table B relates to students who utechnique and a single approach. 63%discussed the problem as a group and develinterview questions before they approachedan interview (we called this approachstudents claimed that they discussed the pr and developed closed-ended interview quesapproached the other group for interviewapproach 2).

TABLE B STUDENT RESPONSES USING SINGLE

Approach

Numbof

studeWe discussed as a group anddeveloped open ended interviewquestions before we walked toanother group for interviews 55

We discussed as a group anddeveloped closed-ended interviewquestions before we walked toanother group for interviews 13We discussed as a group anddeveloped closed-ended interviewquestions. However we did notinterview as a group but assignedindividual members in the group tointerview each role player in eachgroup 12We discussed as a group and didnot develop any interviewquestions. We walked to the groupand asked each role player in the

group for feedback 7

Fourteen per cent (14%) of studiscussed the problem as a group and dended interview questions. However, theythe interview as a group but assigned indivithe group to interview with a different rolgroup (we named this approach 3). The r students said they discussed the problem as

vey and returnedd exploring the

as applied in aulted from using, many studentsents elicitation

ve, one possible

than any othersubject. Studentsements and theyhe other reason

-to-face and theynts. This findingmost commonly

sed a single REof the students

oped open-endedother groups for

1). 15% of the blem as a grouptions before they

(we called this

TECHNIQUE

er

ts Percentage

63%

15%

14%

8%

dents said theyveloped closed-did not conductdual members ine player in eachemaining 8% ofa group and did

not develop interview questions. Tand asked each role player in thenamed this approach 4) .

Approaches 1 and 2 were fa because firstly the questions are earequire much time to think througquestions students asked focusedrather than the content itself. Ouwhere Davis et al. claim that strumore information than unstructuunstructured interviews gathersorting and ranking techniquunstructured interviews appear tothan thinking aloud techniques.

DIAGRAM 1 SHOWS STUDENTS R COMBINED APPROACHES IN A SINGL

In noting that the intervietechnique, it is interesting to learnmore than one approach. The t

chosen least frequently by students2 plus 3 plus 4. This is illustrateAlthough very few groups chapproaches, the result did not seeinvestigation. Our key concern is tois most effective in elicitinrequirements that are explicitly unanalysts and useful for gatheringrequirements for a proposed system.

IV. RESULTS

The students were much ofgraduated from high school and we

IT course at university. The majoritindustry experience, with a minoritor experience on the topic. Althouindustry exposure on gathering redevelopment project, at least more tother subjects require them to condexposure in industry from time tocomplete requirements. Interviewcommonly used in anywhere and aof students submitted their diagram

ey approached the groupgroup for feedback (we

ored by most studentsily developed and do notcritically. Secondly, theon the subject contextresults agree with [8],

ctured interviews gathered interviews, whereas

ore information thanes and, interestingly,gather more information

SPONDED USINGTECHNIQUE, INTERVIEW

is the most-selectedrom the groups that usedo combined approaches

were 1 plus 3 and 1 plusd in the diagram above.ose to use combined

to affect our researchidentify which approach

implicit stakeholderderstandable by businesscomplete and consistent

an age, had recentlyre in their first year of an

of students had no priorhaving little knowledgeh they do not have prioruirements in a softwarehan one assessment fromct field trips and have an

time to collect good andtechnique is one thatanytime. Fifteen groupsfor review. In two of the

327327


4/6

fifteen diagrams, the information gathered was a close matchto the sample solution. Content analysis was used to groupand categorize the sample answers; this helped us understandwhy some elicited requirements were either incomplete orinaccurate.

There are four approaches which business analysts

commonly use as a basis for eliciting requirements wheninterviewing and which it is believed have some effect onrequirements completeness and correctness . These fourapproaches are: 1) factor-based, 2) priority-based, 3) choice-

based and 4) integration-based. The term ‘factor-based’ isdefined as attributes, properties and values that are used fordescribing requirements. The term ‘priority-based’ refers tonumbering and sequencing requirements based on theirimportance. The term ‘choice-based’ defines requirementswhich incorporate with factors and prioritization, and theterm ‘integration-based’ refers to a combination of factor-

based, priority-based and choice-based approaches. Table Bclearly shows that groups developed open-ended interviewquestions before they interviewed other groups (approach 1).

We reviewed a couple of students designed interviewquestions, and referred to diagrams they submitted to us.Based on their diagrams and information provided in thetable, many requirements from their diagrams they gatheredfrom the role players are gathering factors. Their interviewquestions, which are unstructured, lead us to present theirdiagrams to us consists of heterogeneous factors (differentkinds), attributes and variables of stakeholders concerns andviews (see Table C).

TABLE C SHOWS EXAMPLES OF HETEROGENEOUS FACTORS INVIEW OF STAKEHOLDER CONCERNS AND VIEWS

Heterogeneous data or factors Stakeholder Type

Stakeholders who fear using aninformation system

Government

CountryGovernment

StateGovernment

o factorshown

Buyer Local International

HeterogeneousBill notshownaccurately?(2)

Currencyconversionaccuracy?(4)

Seller orSupplier

Local International

Correct paymentmade? (3)

Contractagreement?(3)

Data EntryStaff

Individual Group

Accuracy?(2)

Volume oftransactionto beentered? (4)

Note in bracket refers to number of groups

Similarly for approach 2, we reviewed structuredquestions and their answers in their diagrams, we identifiedtheir collected requirements and classify them as factor-

based as well. The difference between approach 1 and 2 isfactors are of a same kind. In more specific, homogenousfactors (same kinds) attributes and variables based on ouranalysis (see Table D). It is believed that in this approach,

groups developed closed-ended interview questions beforethey walked to the other group for interviews; Table Dshows examples of homogenous factors in view ofstakeholder concerns and views.

TABLE D SHOWS EXAMPLES OF HOMOGENOUS FACTORS INVIEW OF STAKEHOLDER CONCERNS AND VIEWS

Homogenous data or factorsStakeholderType

Stakeholders with concerns about aninformation system

Government Taxation (4) compliance (3), regulations(4)Safety requirements (4)

Buyer Easy/timely (4), Fast processing of sales(2)Automated retrieval of product (3)Quality of products (8), Cheap products(4)Accurate stock inventory (8)

Seller orSupplier

High speed information, Pay correctamount (8), Placing an order (8), Accurateinformation (8), Sale information up-to-date (8)

Data EntryStaff

Ease of use (8), Reliable product (1), Dataaccuracy (3), User friendliness (5), Quickresult (2)

Managers Increase revenue (5), expand businessmarket (4)

Note in bracket refers to number of groups for information

Neither approach applied in the interviews provedeffective in providing comprehensive information about therequired information system. The material they presented intheir diagram did not match our sample solution.

USING APPROACHES 1 AND 2, BUSINESS ANALYSTS ANALYZEDREQUIREMENTS ON A FACTOR-BASED METHOD.

The groups which used approach 3 had discussions as agroup and developed closed-ended interview questions.However, they did not interview as a group but assignedindividual members in the group to interview a different role

player in each group; i.e., they first discussed questions as agroup and then assigned individuals to interview a role

What

Factors

Issues

Factor-based

328328


5/6

player in other groups. This means that each member in theteam interviewed that particular role player in each group.For example, one business analyst interviews 6 other role

players whose role is a buyer. After they collected 6 buyersinformation, the requirement analyst will group them and

prioritize which one is important. The diagrams they submitted revealed the information presented they focused

on a priority-based approach.

This approach seems to show that business analysts werewell in control of the situation and they decided the ‘best fit’of keywords to describe stakeholders, their concerns andviews. The approach shows inconsistent effects with respectto validation of requirements completeness by stakeholdersin the same role.

We reviewed their diagrams and they provided numbers beside each requirement. As we understand it, they tried toimply that there was more than one suitable requirement;however when ranking the importance of each requirement,they numbered them according to each level of importance.

USING APPROACH 3, BUSINESS ANALYSTS DETERMINEDREQUIREMENTS OUTCOME THROUGH A PRIORITY-BASEDAPPROACH.

Approach 4 was the one without any real preparatory

work. Two groups chose this technique and the information presented for the stakeholders demonstrates a lack of focus.

The diagrams from the groups that used combinedapproaches, 1 and 3 presented stakeholders’ concerns andviews based on a choice-based method . Interestingly, at agroup level, they gathered information based on factors, andat the individual level, they collected similar keywords andthen prioritized them. Based on the choices they gathered, itwas decided which fitted in best. Their answers turned out to

be closely matched to the course sample answer.

USING COMBINED APPROACHES 1 AND 3, BUSINESS ANALYSTSDETERMINED REQUIREMENT OUTCOME AS CHOICE-BASED

Below is an example of how the group went aboutcollecting their requirements.

Priority 1 Priority 2 Priority 3 Priority 4Stakeholders Understanding

of ProcessesWhat

proceduresare they?

What kindof

benefits?

The other combined approach used by a group was 1, 2,3 and 4. Their diagram showing stakeholders’ concerns andviews were interesting but somewhat complicated. We calledthis ‘integration-based’ . In our understanding, somemembers in the group were assigned different approaches.To our surprise, this technique also matched our samplesolution.

USING APPROACHES 1, 2, 3, AND 4 BUSINESS ANALYSTSDETERMINED REQUIREMENT OUTCOME AS INTEGRATION-BASED

StakeholderType

Stakeholders with concerns and fearsof using an information system

Government By addressing their needs and theirconcerns appropriately

In summary, factor-based and priority-basedapproaches when applied to requirements elicitation aim towiden and sharpen the dimensions of a problem at a surfacelevel in the context of a particular situation so that businessanalysts are likely to evaluate them less for requirementscompleteness. The application of a combination of choice-

based and integration-based interview techniques results in anarrower focus, which in turn results in more consistent andcomplete requirements being gathered by business analysts.

V. CONCLUSION AND FUTURE WORK

The aim of this experiment consists of two folds: Thefirst fold is to encourage business analysts or students whoneed to elicit requirements must not restrict themselves to astandard type of approach. For example, approaches thatthey used by factorizing or give priority to the importantrequirements. Integration and choice-based approachesseldom discussed or discovered provides effectiverequirements gathering into completeness, which can be

beyond than, one highly expected. The second fold ofconducting this experiment is to provide some thoughts forless experience or equally experience business analysts thatthe problem in interviews is not because of the technique,

What

Factors

Issues

Factors -based

Integration - based

Which is Which ?

Process

RegulationsProcedures

Policies

Multi -subjects based

What

Factors

Issues

Factor-based

Whi ch?

Keywords Priority ofimportance

Priority-based

Choice-based

W hich ?

Keywords Priority of

importance

Priority-based

329329


6/6

rather the need to focus on approaches which are beingused.

This paper makes two contributions. The first is acontribution to Requirements Elicitation knowledge that,although interview technique is no doubt a popular, andwell-known requirements elicitation technique, unlessappropriate approaches are used with the technique, theeffect on requirements gathering will be incomplete. Thesecond insight is that it should not be assumed thatidentifying requirements through factor-based and priority-

based approaches is an appropriate choice for identifyingcomplete and consistent requirements; our results prove thatthis is not so. Choice-based and integration-basedapproaches show encouraging signs of being moreappropriate in a requirement elicitation context. Futureresearch will include investigating the approaches in a real-world case study relating to marketing research companiesthat want to elicit feedback and complaints from new andexperienced customers in order to enable them to clarifytheir focus.

VI. REFERENCES

[1] B. Davey and C. Cope. Requirements Elicitation – what’smissing? Issues in Informing Science and InformationTechnology, 2008 Vol. 5, No.1, pp. 543-551

[2] T. Tsumaki and T. Tamai. Framework for matchingrequirements elicitation techniques to project characteristicsSoftware Process Improvement and Practice, 2006, Vol. 11,

No.5, pp. 505-519[3] A.M. Hickey and A.M. Davis, Requirements elicitation and

elicitation technique selection, In Proceedings of the 36thAnnual Hawaii International Conference on System Sciences(HICSS’03), 2003

[4] G. Kotonya and I. Sommerville. Requirements Engineering

Processes and Techniques. New York: John Wiley and Sons,1998 [5] K.Beck. Extreme Programming Explained: Embrace Change,

Reading, MA: Addison-Wesley, 2000[6] The Standish Group, ‘The CHAOS Report’

http://www.standishgroup.com/sample_research/chaos_19941.php. viewed at March 2010

[7] B. B. Chua, D.V. Bernardo, and J. M. Verner. Criteria forestimating effort for requirements changes, In Proceedings ofSoftware Process Improvement, 15th European Conference,EuroSPI, 2008, pp. 36-46.

[8] A. Davis, O. Dieste, A. Hickey, N. Jurist, and A.M.Moreno.Effectiveness of requirements elicitationtechniques: Empirical results derived from a systematicreview. In Proceedings of the 14th IEEE InternationalRequirements Engineering Conference, 2006, pp. 176 - 185

[9] H. Frey and S.M. Oishi. How to Conduct Interviews byTelephone and in Person, London: Sage Publications, 1995

[10] S.W. Ambler. Agile Modelling. New York: John Wiley andSons, 2002

[11] J. Coughlan, and R.D. Macredie . Effective communication inrequirements elicitation: A comparison of methodologies.Requirements Engineering, 2002, pp. 47-60

[12] A. V. D.Merwe and P. Kotze. Criteria used in selectingeffective requirements elicitation procedures , In ACMProceedings of the Annual Research Conference of the SouthAfrican Institute of Computer Scientists and Information

Technologists on IT Research in Developing Countries, 2007, pp. 162 - 171

[13] S.W. Ambler. Agile Modelling. New York: John Wiley andSons, 2002

[14] A. Cockburn and J. Highsmith. Agile software development:The people factor, Journal of The Business of Innovation,IEEE,2001, Vol. 34. No 11, pp. 131-133

[15] G. Kotonya and I. Sommerville. Requirements Engineeringwith Viewpoints, BCS/IEE Software EngineeringJournal,1996, Vol.11. No.1, pp. 5-18

[16] R. Vonk. Prototyping: The Effective Use of CASETechnology, New York: Prentice Hall, 2002

[17] R. R. Young. Effective Requirements Practices. Boston, MA:Addison-Wesley Longman, 2001

[18] Y. L. Chia and M. Okamoto. The Method of User’sRequirement Analysis by Participation of the User:Constructing an Information System for Travelers, HumanCentred Design, HCD, Springer-Verlag, 2009, pp. 862-868

[19] D . G. Firesmith. Prioritzing requirements Journal of ObjectTechnology, 2004, Vol 3. No. 8, pp. 35-47

330330

Understanding the Use of Elicitation Approaches for Effective Requirements Gathering

Documents

Transcript of Understanding the Use of Elicitation Approaches for Effective Requirements Gathering