Guidlines for Selecting Elicitation Tech

8/9/2019 Guidlines for Selecting Elicitation Tech

1/5

Guidelines for the Selection of Elicitation

Techniques

Sumaira Kausar 1

, Saima Tariq2

, Saba Riaz3

, Aasia Khanum4

College of E&ME National University of Sciences and Technology (NUST)

Islamabad, [email protected], [email protected],

3 [email protected], 4 [email protected]

Abstract — Requirement Elicitation is a crucial part ofRequirement Engineering. Using an appropriate method can

help in producing a consistent and complete set of requirements

with reduced cost and time. This paper introduces ways and

guidelines for selecting requirement elicitation techniques.

Different elicitation techniques are analyzed in the light ofdifferent project settings. Guidelines for selecting an appropriate

mix of elicitation techniques are presented to overcome

individual shortcomings of the techniques and maximize the

aggregate advantage.

Keywords — elicitation; requirement; requirementengineering; software

I. INTRODUCTION

Requirement Engineering (RE) can be defined as the process of eliciting, developing and managing the

requirements in a way which can ultimately produce a

successful software system [3]. The impact of RE process on project success has been reported quite a number of times.Requirements Engineering (RE) is said to be a difficult task.

RE process involves all those people who have a stake in a

project. Different stakeholders have different organizational

and individual goals, social positions and personalcharacteristics [4]. Understanding and expression of their

knowledge is different from each other. So requirement

development process can have a large variety depending upon

the different stakeholders of the project.The ultimate aim of software engineering is to develop such

software systems that are up to the mark set by the customer’s

side in terms of needs, schedule and budget. Keeping in view

these aims of software development, success rate of suchdevelopments is not very encouraging. According to the

famous Standish report, success rate of software project is

only 28%. A major contributing factor in such a low rate of

success is said to be unclear and imprecise requirements [2].

Another survey also pointed out that only 12.7% out of 1027

software projects were successful and top reason for the

failure was “unclear

objectives and requirements” [3]. These reports indicate that a

major contributing factor in such a low rate of success ofsoftware project is unclear and imprecise requirements.

There is a number of requirement elicitation

techniques currently used by the software requirement

engineers. These techniques can be grouped as:

Traditional: These include Questionnaire, Interviews

Document Reading, and Laddering etc.

Group Based: For example Requirements Workshop

Brainstorming, and Contextual inquiry etc.

Scenario-Based: Examples include Prototypes, Use casesStoryboards, and Role Playing.

Contextual: Representative techniques in this category are

Ethno methodology, and Protocol analysis

Requirement elicitation is considered to be a very vita

activity in requirement engineering. It is a proven fact that

improper elicitation of requirements leads to a project failureSo for the improvement in the software industry’s success rate

more attention is required in the elicitation process [1].

II. PROBLEM DESCRIPTION AND SCOPE

There is variety of elicitation techniques but it is

considered a difficult task for an organization to decide which

technique or combination of techniques is most suitable for thegiven stakeholders, organizational structure and project to be

developed. This is normally because of lack of understanding

about the available techniques. This inadequate understandingof elicitation technique leads to selection of improper

elicitation technique for a given project, which ultimately canresult in failure of the project. So, it can be very helpful for the

requirement engineers to know about the selection o

appropriate elicitation techniques [4].

The process of requirement elicitation has many difficulties toface and the most prominent is related with the

communication between the stakeholders [5]. So it is again

dependent upon the elicitation technique selected to improvecommunication between stakeholders.

978-1-4244-8058-6/10/$26.00 ©2010 IEEE

2010 6th International Conference on Emerging Technologies (ICET)

265


2/5

Requirement engineers have a variety of elicitation techniques

but flexible guidelines are required to be provided to them,

which can be helpful for the selection criterion of elicitationtechnique [3]. Ganesh [7] has used experimental survey

technique to know about the most effective elicitation

technique from all available ways. This paper is aimed at

providing a guideline for the practitioners for selecting the

elicitation technique that suits their needs.

III. EVALUATION OF TECHNIQUES

A. Basic Elicitation Techniques

Most well known and classical requirement elicitation

techniques are interviews, questionnaire and social analysis.Interview is most effective technique that starts with a set of

pre-defined questions that eventually leads to open discussion

for complex items. The same is the case for questionnaire, but

here we don’t directly communicate with the stakeholder and just get his/her views in a compact and quick way. Social

analysis is carried out using several observation approaches

that can be active, passive, explanatory or ethnography [12].

Observation is the method of collecting requirement by

observing the people during normal work.

1) Benefits: Benefits of these approaches are as follows:

Interviews and questionnaire are economical and easy toimplement.

Interview is most simple and generic way to elicit

requirements from multiple stake holders.

Interviews are effective in understanding the problems in

the existing system and to find the general requirements

of the stakeholder [10].

Questionnaire technique is a good way to collect data in

mass number in a cost effective manner [11].

Social analysis is used to find additional requirementsneeded by the user, when the user is unable to explain

their expected requirements [7].

Social analysis and ethno-methodology is also a good

candidate for those applications which are not timely

constraint.

2) Limitations: Limitations are:

The effectiveness of interview and questionnaire dependson prior preparation and format of the questions.

Questionnaire is highly dependent on its effective design,

knowledge and honesty of the respondent [10, 11].

Effectiveness of these techniques is also dependent on

patience of interviewer and expressiveness of stakeholder. The organization and arrangement of questions also play

an important role in its successful implementation [11].

Interviews lack to decide the boundaries of the proposedsystem and organization procedures using these methods

[10].

Social analysis is best where we have no budget and

schedule constraints [7].

These techniques are considered to be static and less

efficient to collect and investigate all possible scenarios

and constraint regarding any project.

B. Advance Elicitation Techniques

Classical techniques are considered to be static and less

efficient to collect and investigate all possible scenarios and

constraint regarding any project, so trend has shifted to somemore advance and dynamic ways to requirement elicitation

Modern approaches to elicitation techniques are prototyping

scenarios based, user centered view, brainstorming sessions

storyboarding and workshops etc. Prototyping is the GUI based visualization of the actual system parts that give

general idea of actual system functions and workflowScenario and user centered view will give the working method

of different interaction sessions or situations of the systemBrainstorming is a technique used to generate new ideas and

find solution to a specific issue. It consists of several members

from different department and domain experts; every member

is allotted with certain time interval to explain their ideasStoryboard is another way to visualize the proposed system in

form of story and use several active, passive and interactive

story boards.

1 ) Benefits: Benefits are:

Prototyping is a good candidate for greenfield projectswhere it is difficult to capture user requirements andexpectations without providing some model that actually

resembles the appearance of real product [13].

Prototyping is themost effective way to represent thesystem in functional and graphical sense. It captures al

minor user interface level details [13]

Prototyping can reduce development time if evolutionary

prototypes are used, thus increase the level of custome

satisfaction.

Scenarios and user centered view provides flexibility to

find the requirements while analyzing different sessions

and their user response after interaction with the scenario

[7].

Brainstorming session has high bandwidth, thus provide

us with variety of different ideas, selecting the best suitedone based on voting or any other criteria.

Brainstorming encourages out of the box thinking, i.ethinking unlimited by normal constraints.

Advance techniques allow maximum user involvement

that will result in more refined set of user requirements.

Workshop, brainstorming sessions, storyboards are the

most formalized and realistic way to requirement

elicitation.

2) Limitations: Limitations are:

Prototyping is the more expensive than all the otherrequirement elicitation techniques. Though they are more

efficient and effective in requirement elicitation but they

are costly and time consuming.

Workshop, brainstorming sessions, storyboards are quiet

expensive to organize and conduct; it also requires the presence of maximum stakeholders at one place.

266


3/5

IV. PROPOSED GUIDELINES FOR SELECTING

ELICITATION TECHNIQUES

The research objective in this paper is not to introduce

new ways and techniques for requirement elicitation but to

organize and manage the existing ones to achieve high

throughput and quality in requirement elicitation phase. First

theoretical guidelines are provided and then some

mathematical formulation is applied for the guidance on someof the techniques.

A. Selection Parameters:

Here we suggest certain guide lines for selecting the right

elicitation technique for any specific project based onfollowing parameters:

Parameters and their Respective Values

Type of project

Safety Critical Systems

Security Critical Systems

Real Time Systems

Distributed Systems

Interactive Systems

Information Systems Small and medium sized

projects.

Target

Stakeholder Market Need

Specific Organizational Need

Number of

Stakeholders Single

Multiple

Stakeholder

Involvement Maximum

Average

Minimum

ProjectStatus

New System

Existing System

Resource

Constraints Critical

High

Medium

Low

Schedule


High

Medium

Low

Budget


High

Medium

Low

Functional

Correctness

Better to have in Percentage

Quality

Concerns Better to have in Percentage

Depending on all the above attributes and values we select the

appropriate elicitation techniques, these attributes may beindependent or dependent on each other. These attributes will

provide the more systematic and sequential approach to

conduct requirement elicitation process and application of

right elicitation technique.

1) Project nature and type: Initially we need to know

about the project type and nature, and then on this basis we

select the suitable elicitation technique and other dependen

properties.

It necessary for requirement team to be well aware abou

the system domain in order to elicit the requirements

properly.

In case of safety, security and real time systems, there is

high need of accuracy and reliability so we need to followmore practical and advance techniques. Traditiona

approaches may be used to build the initial grounds bu

finally we should move on to some more effective and practical ways to elicit requirements in better way. Mos

suitable ones will be prototyping, brainstorming and

storyboards.

Distributed, informational and interactive systems have

large scope, heavy resource dependent systems, so here

we also need to use advance techniques to effectivelyelicit requirements. They are economically expensive

systems so requirements should also be properly collected

from start.

For Small and medium scale projects, the traditional

approaches are more appropriate and economical. The

most effective one is the interviewing.

System Developers should be meticulously involved inthe whole process of requirement elicitation and domain

study to build an effective system.

2) Target stakeholders: Secondly, we need to know thesystem target stakeholder, whether the system is going to

address the market trends and needs or needs of any

individual/organization.

The system constructed based on the market trend and

needs have no well defined stakeholder but the same

organization that builds the system. In such case, it isrequired to have a deep domain analysis, study of existing

competitor’s product, well defined set reasons and

features of new system by the market analysis.

If we have defined set of stakeholders for the proposedsystem, then we simply inquire them about the entiresystem requirement using adequate elicitation technique

The selection of elicitation technique is dependent on

other stakeholder and system properties.

3) Number of stake holders: Thirdly, we need to identify

the total number of system stakeholders for the proposed

system, define their levels and roles in providing the required

system information and conflict resolution information.

4) Stake holder involvement: Fourthly, we must know

about stakeholder position in the organization and his/her

interest in the project. As we see that the person at higher levein the organization hierarchy will have less involvement i.e

the super class, but as we move down the hierarchy, the

stakeholder involvement is increased though they belong to

the lower ranks and doesn’t pay for it as well. The reason is

that they are more closely linked to the system usage and

operation then higher level. The second reason is that the person at lower level can give more time and concentration

then the one at higher level. But at a stage where the conflictor some higher level decision is required then this super

stakeholder class is involved.

267


4/5

Super stakeholder class is less involved so we should use

an interview or workshop session to elicit requirements

from them.

Lower Stakeholder Class is highly involved so we may

use running models or mockups to elicit the requiredinformation in the better way.

5 ) Project status: For the new system, the work will start

from scratch, having formal and informal meetings with major

system stakeholders and then moving towards the more detailand advance techniques for the system. The more suitable one

will be prototyping if there are no such strict budget

constraints.

For existing systems we can use available system

documents and software to know about the discrepancies

and shortcomings of existing system. We can use ethno-methodology if there are no budget and time constraints

to know about the actual user environment.

6) Budget constraints: The most important and significant

factor is the cost that can be spend for any project. Elicitation

techniques should be selected based on the available budget.

The end product may eventually become useless if it exceeds

it budget so we should only use such techniques that areappropriate and suitable to the defined budget.

7) Schedule constraints: Schedule has their own impactand significance in the project; few are strict deadline specific

while others are less. The elicitation techniques chosen for

strict deadline specific projects should be short, quick and

effective. For example, in hard real-time systems if deadline is

skipped then system has no worth, while others with flexible

deadline has some margin.

8) Resource constraint: The system resources factor also

has major impact on elicitation technique selection. If the

system is rich in resources then we use enhanced and newways for requirement elicitation but if this is not the case then

we may look for some other alternatives.

9) Functional correctness: Before getting into the actualelicitation process, we should know about the customer

expectations for correctness level of functional requirements.

It is quite unrealistic to have zero degree error for any project

because humans are prone to errors. Depending on thecustomer expectation, the appropriate elicitation technique is

used to meet the desired level.

10) Quality concern: Depending on the project nature,

few projects give significant importance to non functionalrequirements as well. For example, safety critical systems

have high reliability requirements. So based on the several

quality concerns, the most suitable and effective elicitationtechniques are selected.

B. Mathematical Formulation of Elicitation Technique

Selection:In the proposed mathematical formulation, nine

popular techniques of elicitation are considered. These

techniques are interview, workshop, questionnaire, active

storyboard, passive storyboard, interactive storyboard,

scenarios, prototyping and ethnography. These techniques are

then compared according to five parameters. These five

parameters are: No. of stakeholders involved (X1), level o

interaction (X2), quality of gathered requirements as a result of

a particular technique (X3), time effectiveness (X4), cos

effectiveness (X5). These five parameters are then given value

by each of the nine techniques at a scale of 1to5 where 5

shows the best possible value and 1 shows the worst for a

particular parameter. Values for parameters are assignedaccording to the inherent characteristics of the techniques and

based on some researches already conducted [1,2,3,4,5,7]

Goodness Count (GC) is calculated with the equation (1).

GC = X1+2X2+2X3+ X4 +2X5 (1)

This paper considers the condition that stakeholders

are not at geographically distant locations. If this constraint is

ignored, results may vary considerably as cost parameter can

change and hence can affect the results.

V. EVALUATION AND RESULTS

Evaluation of the results of the proposed method is

on the basis of the inherent properties of the techniques and

values of parameters are set according to these properties oncomparative basis. Parameters’ values are given in table 1. GCis shown in table 2. Graph of GC is shown in Fig.1.

Table 1: Parameters’ Values

Table 2: GC

Elicitation

Technique

Goodness

Count (GC)

Interview 32

Workshop 35

Questionnaire 25

ActiveStoryboard 25

PassiveStoryboard 23

Interactive

storyboard 30

Scenarios 32

Prototyping 25

Ethnography 18

Technique X1 X2 X3 X4 X5Interview 3 5 4 3 4

Workshop 5 5 5 4 3

Questionnaire 4 1 2 5 5

Active

Storyboard

3 1 4 4 4

Passive

Storyboard

3 1 3 4 4

Interactive

storyboard

3 5 4 3 3

Scenarios 3 5 4 3 4

Prototyping 3 5 3 2 2

Ethnography 2 1 3 2 3

268


5/5

Figure 1: GC graph

Results shows that requirement workshop has highest GC that

means if independently selected, this can outperform other

techniques with the given constraints and conditions.

VI. SUMMARY AND FUTURE WORK

This paper presented guidelines for selecting

elicitation techniques. It also presented flexible selection

criteria for the selection of elicitation technique for a given

project. The technique can be modified by just modifying theweights associated with the different parameters for the

selection, according to the needs and priorities of the project.

Some basic techniques were compared and analyzed on some

important criteria, which are normally considered while

deciding upon the selection of a particular elicitationtechnique. Results show that requirement workshop has the

highest goodness count, means workshop is the best choice if

selected as an individual technique for elicitation. Interviewsand scenarios are also good choices with the given parameters.

Following are some of the possible future extensions of this

paper:

Using more parameters for selection

Instead of individual techniques, different combinations

of techniques can also be analyzed in the same way.

Parameters can be readjusted according to specific type of

projects.So the proposed technique can provide a simple and flexible

mechanism for the practitioners for the selection of elicitation

technique.

REFERENCES[1] Ann M. Hickey, Alan M. Davis, “Requirements Elicitation and

Elicitation Technique Selection: A Model for Two Knowledge-IntensiveSoftware Development Processes”, Proceedings of the 36th HawaiiInternational Conference on System Sciences (HICSS’03), 2002.

[2] Lester O. Lobo and James D. Arthur, “Effective RequirementsGeneration: Synchronizing Early Verification & Validation, Methods

and Method Selection Criteria”, eprint arXiv:cs/0503004, 2005.[3] Sarah Powell, Frank Keenan, Kevin McDaid, “Enhancing Agile

Requirements Elicitation With Personas”, IADIS International Journalon Computer Science and Information Systems, Vol. 2, No. 1, pp. 82-95,ISSN: 1646-3692.

[4] Zheying Zhang, “Effective Requirements Development - A Comparisonof Requirements Elicitation techniques”, SQM2007 conference.

[5] Gabriela N. Aranda1, Aurora Vizcaíno2, Alejandra Cechich1, MarioPiattini2, “Strategies to Minimize Problems in Global RequirementsElicitation”, CLEI ELECTRONIC JOURNAL, VOLUME 11,

NUMBER 1, PAPER 3, JUNE 2008.

[6] www.wikipedia.com

[7] Sai Ganesh Gunda,” Requirements Engineering: elicitation Techniques”,Masters thesis software Engineering 2008, university West, Trollhattan.

[8] Kotonya and Ian Sommerville: “requirements Engineering: A RoaMap”, ACM publication, Sep 2000, pages 35-46.

[9] Merlin Dorfman: “Requirements Engineering”. Carnegie MellonUniversity, interactive publishers, 1999.

[10] Julio Cesar, Paula, “Requirement Elicitation driven by interviews: Theuse of Viewpoints”, IEEE publications, year of Publication 1996.

[11] J.Machael Moore, Frank M.Shipman: “ A general introduction to designof questionnaire for survey research”, University of Leeds, onlinedocument.

[12] http://www.leeds.ac.uk/iis/documentation/top/top2.pdf

[13] Guoguen, J. & Linden,: “Techniques for Requirement Elicitation”, 1s

IEEE International Symposium on Requirements Engineering, SanDiego, USA, 4-6 January 1993.

[14] Andriole s.j: “Fast cheap requirements prototype: or else”, Drexeuniversity, IEEE,vol 11, issue 2, Mar 1994.

Elicitation techniques Comparison

010

20

30

40

I n t e r v i e w

W o r k s h o p

Q u e s t i o n n

a i r e

A c t i v e

S t o r y b o a r

d

P a s s i v e

S t o r y b o a r

d

I n t e r a c t i v e

s t o r y b o a r d

S c e n a r i o s

P r o t o t y p i n

g

E t h n o g r a p

h y

elicitation technique

G o o d n e s s C o u n t

( G C )

269

Guidlines for Selecting Elicitation Tech

Documents

Transcript of Guidlines for Selecting Elicitation Tech