2010 6th International Conference on Emerging Technologies (ICET)

Guidelines for the Selection of Elicitation

Techniques
Sumaira Kausar1, Saima Tariq2, Saba Riaz3, Aasia Khanum4
College of E&ME
National University of Sciences and Technology (NUST)
Islamabad, Pakistan
1
sum_satti@yahoo.com, 2saima_tariq1@hotmail.com,
3
sabarz148@yahoo.com, 4 aasia@ceme.nust.edu.pk
objectives and requirements [3]. These reports indicate that a
major contributing factor in such a low rate of success of
software project is unclear and imprecise requirements.

AbstractRequirement Elicitation is a crucial part of

Requirement 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 of
different 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.
Keywordselicitation;
engineering; software

I.

requirement;

There is a number of requirement elicitation

techniques currently used by the software requirement
engineers. These techniques can be grouped as:

requirement

Interviews,

Group Based: For example Requirements

Brainstorming, and Contextual inquiry etc.

Workshop,

Scenario-Based: Examples include Prototypes, Use cases,

Storyboards, and Role Playing.

INTRODUCTION

Contextual: Representative techniques in this category are

Ethno methodology, and Protocol analysis

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 personal
characteristics [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 customers
side in terms of needs, schedule and budget. Keeping in view
these aims of software development, success rate of such
developments 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

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

Traditional: These include Questionnaire,

Document Reading, and Laddering etc.

Requirement elicitation is considered to be a very vital

activity in requirement engineering. It is a proven fact that
improper elicitation of requirements leads to a project failure.
So for the improvement in the software industrys 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 the
given stakeholders, organizational structure and project to be
developed. This is normally because of lack of understanding
about the available techniques. This inadequate understanding
of elicitation technique leads to selection of improper
elicitation technique for a given project, which ultimately can
result in failure of the project. So, it can be very helpful for the
requirement engineers to know about the selection of
appropriate elicitation techniques [4].
The process of requirement elicitation has many difficulties to
face and the most prominent is related with the
communication between the stakeholders [5]. So it is again
dependent upon the elicitation technique selected to improve
communication between stakeholders.

265

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 elicitation
technique [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.

B.

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 some
more 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 gives
general idea of actual system functions and workflow.
Scenario and user centered view will give the working method
of different interaction sessions or situations of the system.
Brainstorming 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 ideas.
Storyboard is another way to visualize the proposed system in
form of story and use several active, passive and interactive
story boards.

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 dont 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 are:

x

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

x
x
x
x
x
x

Interviews and questionnaire are economical and easy to

implement.
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 requirements
needed 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.

x
x

x
x
x

2) Limitations: Limitations are:

x

x
x
x
x
x

Advance Elicitation Techniques

The effectiveness of interview and questionnaire depends

on 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 proposed
system 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.

Prototyping is a good candidate for greenfield projects,

where it is difficult to capture user requirements and
expectations without providing some model that actually
resembles the appearance of real product [13].
Prototyping is themost effective way to represent the
system in functional and graphical sense. It captures all
minor user interface level details [13]
Prototyping can reduce development time if evolutionary
prototypes are used, thus increase the level of customer
satisfaction.
Scenarios and user centered view provides flexibility to
find the requirements while analyzing different sessions
and their user response after interaction with the scenarios
[7].
Brainstorming session has high bandwidth, thus provide
us with variety of different ideas, selecting the best suited
one based on voting or any other criteria.
Brainstorming encourages out of the box thinking, i.e
thinking 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:

266

Prototyping is the more expensive than all the other

requirement 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.

IV.

PROPOSED GUIDELINES FOR SELECTING

ELICITATION TECHNIQUES

select the suitable elicitation technique and other dependent

properties.
x It necessary for requirement team to be well aware about
the system domain in order to elicit the requirements
properly.
x In case of safety, security and real time systems, there is
high need of accuracy and reliability so we need to follow
more practical and advance techniques. Traditional
approaches may be used to build the initial grounds but
finally we should move on to some more effective and
practical ways to elicit requirements in better way. Most
suitable ones will be prototyping, brainstorming and
storyboards.
x Distributed, informational and interactive systems have
large scope, heavy resource dependent systems, so here
we also need to use advance techniques to effectively
elicit requirements. They are economically expensive
systems so requirements should also be properly collected
from start.
x For Small and medium scale projects, the traditional
approaches are more appropriate and economical. The
most effective one is the interviewing.
x System Developers should be meticulously involved in
the whole process of requirement elicitation and domain
study to build an effective system.

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 some
of the techniques.
A. Selection Parameters:
Here we suggest certain guide lines for selecting the right
elicitation technique for any specific project based on
following parameters:
Parameters and their Respective Values
Type
of x Safety Critical Systems
project
x Security Critical Systems
x Real Time Systems
x Distributed Systems
x Interactive Systems
x Information Systems
x Small and medium sized
projects.
Target
x Market Need
Stakeholder
x Specific Organizational Need
Number of x Single
Stakeholders x Multiple
Stakeholder
x Maximum
Involvement x Average
x Minimum
Project
x New System
Status
x Existing System
Resource
x Critical
Constraints
x High
x Medium
x Low
Schedule
x Critical
Constraints
x High
x Medium
x Low
Budget
x Critical
Constraints
x High
x Medium
x Low
Functional
x Better to have in Percentage
Correctness
Quality
x Better to have in Percentage
Concerns

2) Target stakeholders: Secondly, we need to know the

system target stakeholder, whether the system is going to
address the market trends and needs or needs of any
individual/organization.
x 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 is
required to have a deep domain analysis, study of existing
competitors product, well defined set reasons and
features of new system by the market analysis.
x If we have defined set of stakeholders for the proposed
system, then we simply inquire them about the entire
system 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 level
in 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 doesnt 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 conflict
or some higher level decision is required then this super
stakeholder class is involved.

Depending on all the above attributes and values we select the

appropriate elicitation techniques, these attributes may be
independent 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
267

x
x

then compared according to five parameters. These five

parameters are: No. of stakeholders involved (X1), level of
interaction (X2), quality of gathered requirements as a result of
a particular technique (X3), time effectiveness (X4), cost
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 assigned
according 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).

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 required
information 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 detail
and advance techniques for the system. The more suitable one
will be prototyping if there are no such strict budget
constraints.
x For existing systems we can use available system
documents and software to know about the discrepancies
and shortcomings of existing system. We can use ethnomethodology if there are no budget and time constraints
to know about the actual user environment.

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.

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 are
appropriate and suitable to the defined budget.

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 on
comparative basis. Parameters values are given in table 1. GC
is shown in table 2. Graph of GC is shown in Fig.1.

7) Schedule constraints: Schedule has their own impact

and 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.

Table 1: Parameters Values

Technique
Interview
Workshop
Questionnaire
Active
Storyboard
Passive
Storyboard
Interactive
storyboard
Scenarios
Prototyping
Ethnography

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 new
ways 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 actual
elicitation 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 the
customer expectation, the appropriate elicitation technique is
used to meet the desired level.

X1
3
5
4
3

X2
5
5
1
1

X3
4
5
2
4

X4
3
4
5
4

X5
4
3
5
4

3
3
2

5
5
1

4
3
3

3
2
2

4
2
3

Table 2: GC
Elicitation
Goodness
Technique
Count (GC)
Interview
32
Workshop
35
Questionnaire
25
Active
Storyboard
25
Passive
Storyboard
23
Interactive
storyboard
30
Scenarios
32
Prototyping
25
Ethnography
18

10) Quality concern: Depending on the project nature,

few projects give significant importance to non functional
requirements as well. For example, safety critical systems
have high reliability requirements. So based on the several
quality concerns, the most suitable and effective elicitation
techniques 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
268

[9]

Elicitation techniques Comparison

[10]

40
30
20
10
0
Ethnograp
hy

Prototypin
g

Scenarios

Interactive
storyboard

Passive
Storyboar
d

Active
Storyboar
d

Questionn
aire

Workshop

[11]
Interview

Goodness Count
(GC)

[8]

[12]
[13]

elicitation technique

[14]

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 the
weights 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 elicitation
technique. Results show that requirement workshop has the
highest goodness count, means workshop is the best choice if
selected as an individual technique for elicitation. Interviews
and scenarios are also good choices with the given parameters.
Following are some of the possible future extensions of this
paper:
x Using more parameters for selection
x Instead of individual techniques, different combinations
of techniques can also be analyzed in the same way.
x 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]

[2]

[3]

[4]
[5]

[6]
[7]

Ann M. Hickey, Alan M. Davis, Requirements Elicitation and

Elicitation Technique Selection: A Model for Two Knowledge-Intensive
Software Development Processes, Proceedings of the 36th Hawaii
International Conference on System Sciences (HICSS03), 2002.
Lester O. Lobo and James D. Arthur, Effective Requirements
Generation: Synchronizing Early Verification & Validation, Methods
and Method Selection Criteria, eprint arXiv:cs/0503004, 2005.
Sarah Powell, Frank Keenan, Kevin McDaid, Enhancing Agile
Requirements Elicitation With Personas, IADIS International Journal
on Computer Science and Information Systems, Vol. 2, No. 1, pp. 82-95,
ISSN: 1646-3692.
Zheying Zhang, Effective Requirements Development - A Comparison
of Requirements Elicitation techniques, SQM2007 conference.
Gabriela N. Aranda1, Aurora Vizcano2, Alejandra Cechich1, Mario
Piattini2, Strategies to Minimize Problems in Global Requirements
Elicitation, CLEI ELECTRONIC JOURNAL, VOLUME 11,
NUMBER 1, PAPER 3, JUNE 2008.
www.wikipedia.com
Sai Ganesh Gunda, Requirements Engineering: elicitation Techniques,
Masters thesis software Engineering 2008, university West, Trollhattan.

269

Kotonya and Ian Sommerville: requirements Engineering: A Road

Map, ACM publication, Sep 2000, pages 35-46.
Merlin Dorfman: Requirements Engineering. Carnegie Mellon
University, interactive publishers, 1999.
Julio Cesar, Paula, Requirement Elicitation driven by interviews: The
use of Viewpoints, IEEE publications, year of Publication 1996.
J.Machael Moore, Frank M.Shipman: A general introduction to design
of questionnaire for survey research, University of Leeds, online
document.
http://www.leeds.ac.uk/iis/documentation/top/top2.pdf
Guoguen, J. & Linden,: Techniques for Requirement Elicitation, 1st
IEEE International Symposium on Requirements Engineering, San
Diego, USA, 4-6 January 1993.
Andriole s.j: Fast cheap requirements prototype: or else, Drexel
university, IEEE,vol 11, issue 2, Mar 1994.