Effective Requirements Development - A Comparison of
Requirements Elicitation techniques
Zheying Zhang
Department of Computer Sciences
University of Tampere
FIN-33014 Finland
+358 3 35518571
(A working paper, and the abstract is accepted
by the SQM2007 conference)
1 INTRODUCTION
Requirements engineering process is a human endeavor. People
who hold a stake in a project are involved in the requirements
engineering process. They are from different backgrounds and
with different organizational and individual goals, social
positions, and personalities. They have different ways to
understand and express the knowledge, and communicate with
others. The requirements development processes, therefore, vary
widely depending on the people involved. In order to acquire
quality requirements from different people, a large number of
methods exit. However, because of the inadequate understanding
about methods and the variability of the situations in which
requirements are developed, it is difficult for organizations to
identify a set of appropriate methods to develop requirements in a
structured and systematic way. The insufficient requirements
engineering process forms one important factor that cause the
failure of an IT project [29].
The diversity of people involvement in requirement engineering is
an objective phenomena. It is impractical to limit the diversity of
people involved. However, the methods to develop requirements
are under the engineer’s control. Instead of developing
requirements passively, the requirements analysts shall
proactively identify and foresee the potential problems in the
requirements development process and select a proper method to
diminish the problems to some extent. Therefore, an overall
knowledge about the requirements development methods is
important for engineers to predict the requirements development
process and select a proper method.
In this paper, we elaborate on an extensive comparison of
requirements development methods, and identify common factors
that affect the method selection. Furthermore, we discuss the
generic guideline that can be used as a starting point for method
selection. Requirements elicitation occurs at an early stage of
requirements development. As it is a critical but error-prone stage
in the requirements development, our discussion focuses on the
methods for requirements elicitation.
The remainder of the paper is organized as follows. The next
section presents the motivation to develop a comprehensive
framework for requirements method selection by illustrating the
variation of a requirements engineering process and reviewing the
research on requirements elicitation methods. Section 3 concerns
the category of requirements methods, and distinguishes between
four types of requirements elicitation methods based on the means
of communication. Section 4 discusses the main factors that
influence on method selection at the requirements stages. On the
basis of method category and the factors regarding method
selection drawn out from section 3 and section 4, section 5 further
illustrates the level of applicability of different methods in
different situational context in a matrix and presents the strategies
to select proper methods for requirements elicitation. Section 6
summarizes our research and highlights the further research.
2 RESEARCH BACKGROUND
In Figure 1, we illustrate main activities in the requirements
development process: elicitation, analysis, specification, and
validation [18].
Figure 1 Requirements development process
Requirements are elicited through consultation with stakeholders.
The stakeholders not only refer to human being, such as end users,
customers, decision-makers or developers, but also refer to the
physical, organizational, or legislation environment where the
desired system is to be used [18, 28, 32]. Because different
stakeholders have distinct ways to store, recognize and express
their knowledge about the problem domain, a single method is
unlikely enough to elicit requirements from different stakeholders.
In addition, because the situational context changes during the
elicitation process, and the requirements analysts’ experience and
knowledge varies, it is hard to use a single generic-purpose
method to elicit all needed requirements in one elicitation session.
Therefore, requirements elicitation takes place in a set of sessions,
in parallel or in sequence. Each session includes a (set of)
method(s) in line with the situational context. New understanding
about the desired system is extracted, recorded and analyzed.
These activities are repeated until the problem domain and the
Stakeholders
viewpoints
(Knowledge
Sources)
Session 1/
Method. #1
Elicitation
Understood
Knowledge
New
understood
.
.
.
SRS
Ver. n
Session n/
Method. #n
Analysis Specification Validation
Understood
knowledge
Structured
Req.
New/Modified
Req.
SRS
Inconsistent, missing or
ambiguous req.
Needed knowledge
desired system are well understood and documented in a
structured way - system/software requirements specification
(SRS). The SRS will be further validated before it is baselined as
the contract between customers and the development team.
During the validation process, omitted, redundant, and
inconsistent requirements are identified, negotiated, and
compromised by iterating the same activities.
Requirements development, therefore, is an iterative and
incremental process, in which eliciting requirement from various
sources is the most challenging activity, and shall be performed in
a proactive manner. The development team shall not only well
understand every requirements elicitation method, but also select
methods that fit into the situational context and the characteristics
of stakeholders.
Understanding requirements elicitation methods and foreseeing
the need to use them in different contexts are essential for
requirements elicitation. In order to help engineers understand and
select different methods, many framework regarding requirements
development methods are discussed in literature. Many
frameworks highlight the communication and the user
involvement as the key issues in method selection. For example,
Byrd et al. [2] compare knowledge elicitation techniques suitable
for two identical research disciplines: requirements analysis and
knowledge acquisition. The comparison demonstrates the match
between elicitation techniques and communication obstacles, and
the match between certain elicitation types and problem domain
categories. The authors’ objective is to seek the categorization
scheme to facilitate the merging of research across these two
research disciplines. Instead of a specific framework for
requirements development methods comparison, the framework is
built on the basis of common aspects covered by both research
disciplines. Coughlan and Macredie [4] study socially oriented
methodologies for requirements elicitation by using a four-
dimensional framework: user participation and selection, user-
designer interaction, communication activities, and techniques,
and further classify methodologies on the basis of user control and
scope of design problem. As pointed out by authors, the
framework is theoretical in nature. It lacks practical guidance for
method selection.
Many existing framework lacks an extensive study of a wide
variation of methods for requirements development. For example,
the ACRE framework presented by Maiden and Rugg [21] is
concerned with assisting analysts in acquiring requirements from
stakeholders. The framework guides the method selection by
defining a set of facets to evaluate the strengths and weaknesses
of each method. It, however, only focused on requirements
acquisition from human-being and left out the methods for
extracting requirements from physical environments. Hudlicka
[15] compares the effectiveness of requirements elicitation
methods, but the discussion is limited to indirect knowledge
elicitation methods, such as repertory grid analysis, multi-
dimensional scaling, and hierarchical clustering. Christel and
Kang [3] study several methods in relation to problems faced in
requirements elicitation practice, and illustrate the level of
applicability of methods to address those problems. Because the
discussed methods are classified based on the activities to which
they are applied rather than the nature and characteristics of
methods, the classification is somehow confusion and insufficient.
In summary, requirements elicitation is a synthetic process
consisting of social communication and information mining. Most
literature only focuses on the communication and user
involvement perspective to evaluate a set of requirements
development methods, and lacks extensive discussion of a wide
range of methods. Besides, the literature does not address
specifically, in any substantial way, how requirements elicitation
methods are deployed in different contexts to develop customer-
centered products. In order to support analysts to understand and
select methods for requirements development, the following
sections categorize requirements methods based on their
underlying nature, and discuss the guidelines and facets to
evaluate them.
3 REQUIREMENTS ELICITATION
TECHNIQUE CATEGORY
This section concerns the category of requirements methods. As
requirements development is an intensive interaction process
between stakeholders and the analysts, we distinguish between
four types of elicitation methods according to the means of
communication: observational, conversational, analytic, and
synthetic. Each type presents a specific interaction model between
analysts and stakeholders, and reflects the nature of a method
herein. Understanding the method category helps engineers
understand different elicitation methods and guides them to select
an appropriate (set of) method(s) for requirements elicitation.
Furthermore, it provides an enriched base for us to predict the
trends in requirements elicitation method, and to provide
strategies for requirements development.
3.1 Conversational methods
The conversational method provides a means of verbal
communication between two or more people. Because
conversation is a natural way to express needs and ideas, and ask
and answer questions, it is effective to develop and understand the
problems and to elicit generic product requirements. Methods in
this category are also referred as verbal methods [1]. A typical
conversational method is interviews. It is commonly used in
requirements elicitation [18]. Other methods under this category
include workshop, focus groups, brainstorming, etc. as illustrated
in Table 1.
Table 1 List of conversational methods
Method Conductor
Description
Interviews
[8, 18, 19]
An
experienced
analyst with
generic
knowledge
about the
application
domain
Analyst discusses the desired product with
different groups of people and builds up an
understanding of their requirements. If the
interview is conducted with pre-defined
agenda and questions, it is called structured
interview; otherwise, it is an open-ended
interview.
+ Product features
Workshop,
focus
groups
[8,
19]
An
experienced
outside
facilitator
Stakeholder representatives gather together
for a short but intensely focused period to
create or review high -level features of the
desired products.
+ Product features
Brain-
storming
An
experienced
Stakeholder representatives gather together
and rapidly develop a large and broad list
[19] outside
facilitator
of ideas. It encourages “out -of-the-box”
thinking without normal constraints, and
involves both idea generation and idea
reduction.
+ Product features
+ Innovation/new ideas regarding products
Conversation is one of the most prevalent yet invisible forms of
social interaction. People are usually happy to describe their work
and difficulties they face. The verbally expressive demands, needs
and constraints are often called non-tacit requirements [21].
Because verbal communication is practical and efficient to collect
non-tacit knowledge [21], conversational methods form the
primary approach to non-tacit requirements elicitation. By
conducting interviews, workshops or brainstorming, the
requirements are articulated by stakeholders and communicated
with the analysts.
Conversational methods are very commonly used in requirements
development. However, they are labor intensive [3, 8]: meeting
setup and transcript producing and analyzing from records of a
live interaction take time. Meanwhile, it is challenge to facilitate
the elicitation process, especially when workshop or
brainstorming is used, e.g. scheduling the meeting and ensuring
that the representatives to be present in the meeting [18].
3.2 Observational methods
The observational method provides a means to develop a rich
understanding of the application domain by observing human
activities. In addition to non-tacit requirements, some
requirements are apparent to stakeholders, but difficult to
verbalize. We call them tacit requirements [21]. Verbal
communication is often helpless when collecting tacit
requirements. Therefore, observing how people carry out their
routine work forms a means of acquisition of information which
are hard to verbalize. Methods under this group include
ethnographic studies, as illustrated in Table 2.
Table 2 List of Observational methods
Method
Conductor Description
Social
analysis,
Observati
on,
Ethnogra
phic study
[18, 21,
24]
An observer spends a period in a society or
culture on making detailed observation of
all their practices.
+ Initial understanding of the system and
the application domain
+ Detailed understanding of
social/organizational cultures, work setting
(team interaction and collaborative work),
and work flow
+ Information relevant to design solutions
Protocol
analysis
[8, 21]
The observer
must be
accepted by
the people
being studied
as a “kindred
spirit” and
must be
sufficiently
familiar that
they carry on
with their
normal
pract ices as
if he was not
there.
A subject is engaged in some task, and
concurrently speaks out loud and explains
his thought.
+ Interact ion problems in existing systems
+ Work context and work flow
Observational methods appear to be well suited when people find
it difficult to articulate their needs and when analysts are looking
for a better understanding of the context in which the desired
product is to be used [30]. Examples of tacit information include
the routine work that people perform daily in an intuitive way and
the organizational or social contexts that potentially affect the
requirements. As people are familiar with the context and
situation of their work, they do not consciously think about the
routine and the working environment. It is difficult for them to
articulate how work is done, although the routine work sometime
is easy to show to others [18]. Therefore, to be immersed in the
real work situation to obtain the observational evidence can help
engineers understand in depth the pattern of work, the social
group, the organization, and the broader context within which the
product is used.
As observation methods fall into the category of longitudinal
studies, it, in general, takes longer period than the other methods
[23], which forms a main disadvantage of such methods,
especially when the project has tight schedule at the requirements
stage. Besides, Observation requires sensitivity and
responsiveness to the physical environment. It is easy for
observers to perceive a rich picture about the work context, but it
is normally hard to specify and analyze their perception.
In addition, observational methods are used for understanding
complex societies rather than making judgments about how ways
of working could be improved or supported [18]. They are good to
uncover basic aspects of routine order, such as the typical pattern
of work, and provide the information most relevant to designing
solutions [16]. Therefore, it is often a good practice to start with
an observational method to get an initial understanding of the
desired product when the development team lacks experiences of
product development in a given domain.
3.3 Analytic methods
By using the conversational methods or the observational
methods, requirements are directly extracted from people’s
behavior and their verbalized thought. Besides, the knowledge
implied though not directly expressed, such as the experts’
knowledge or the information about regulations or legacy
products, also provides engineers rich information in relation to
the product. Analytic methods provide ways to explore the
existing documentation or knowledge and acquire requirements
from a series of deductions. They are illustrated in Table 3.
Table 3 List of analytic methods
Method Source Description
Requireme
nt reuse
[6,
17, 18, 31]
Documentatio
n
Reuse of the glo ssaries and specification
of legacy systems or systems within the
same product family to identify
requirements of the desired system
+ Domain requirements
+ User interface characteristics
+ Organizational policies, standards,
legislation, etc.
Documenta
tion studies
/content
analysis
Documentatio
n
A common method consisting of reading
and studying available documentation for
content that is relevant to and useful on
the requirements elicitation tasks.
+ Organizational policies, standards,
legislation, etc.
+ Market information
+ Specification of legacy systems
Laddering
[25]
Expert ’s
knowledge
It involves the creation, reviewing and
modification of hierarchical content of
expert’s knowledge, often in the form of
ladders (i.e. tree diagrams).
+ Organizational culture
+ Domain knowledge
Card
sorting [26]
Expert’s
knowledge
The expert is asked to sort into groups a
set of cards each of which has the name
of some domain entity written or
depicted on it.
+ Domain knowledge
Repertory
grid [2, 9]
Expert’s
knowledge
Stakeholder is asked for attributes
applicable to a set of entities and values
for cells in entity -attribute matrix
A variety of documentation may shed light on requirements of the
desired product. It includes problem analysis, organizational
charts, standards, user manuals of existing systems, survey report
of competitive systems in market, and so on. By studying it,
engineers capture the information about the application domain,
the workflow, the product features, and map it to the requirements
specification. Also, they identify and reuse requirements from the
specification of the legacy or similar products. It is always worth
probing and rummaging for reports and recorded information
relevant to the desired product.
In analytic methods, the mapping techniques are useful for
knowledge acquisition. As discussed in [2], multidimensional
scaling [2, 33] enables users to acquire conceptual structure,
cognitive mapping [2, 22] to identify factors and determine cause-
effect relationships of a task or process, and variance analysis [2,
10] to use existing system as a basis for determining new system
requirements. These techniques are commonly regarded as
knowledge acquisition technique, but also are adaptable in
requirements elicitation.
Instead of requirements reuse, documentation studies, and the
related mapping techniques where documentation forms a main
source of requirements, the deducted information from experts’
knowledge and experience form another source of requirements in
analytic methods. Requirements can be dug up from domain
experts’ knowledge. As illustrated in Table 3, laddering [25] is
used to elicit explanation and clarification of technical terms or
subjective terms, and to elicit how experts structure their
knowledge about a domain, and card sorting [26] and repertory
grid [2, 9] provide ways to elicit attributes that are not
immediately and easily articulated by the expert.
In general, the analytic methods are not vital to requirements
elicitation, since requirements are captured indirectly from other
sources, rather than end users and customers. However, they form
complementary ones to improve the efficiency and effectiveness
of requirements elicitation, especially when the information from
legacy or related products is reusable.
3.4 Synthetic methods
No single method is enough to requirements development.
Considering the context and the circumstances involved, different
methods can be selected at distinct elicitation sessions (as shown
in Figure 1), even within one session. For example, it is often a
good idea to start with an informal open-ended interview or
documentation study before an analyst starts the ethnographic
study [18]. The combination of open-ended interview and the
ethnographic studies helps the engineer uncover the basic aspects
and gain a generic knowledge of the application domain, which
supports the follow-up ethnographic study.
Instead of combination of individual methods, the synthetic
method forms a coherent whole by systematically combining
conversation, observation, and analysis into single methods.
Analysts and stakeholder representatives communicate and
coordinate in different ways to reach a common understanding of
the desired product. They are also referred as collaborative
methods [11]. Examples of synthetic methods are illustrated in
Table 4.
Table 4 List of Synthetic methods
Method Conductor Description
Scenarios,
passive
storyboards
[5, 18, 19]
It is an interaction session to describe a
sequence of actions and events for a
specific case of some generic task
which the system is intended to
accomplish.
+ Clarified system requirements
related to procedures and data flows of
a task.
+ In a highly uncertain situation, an
effective and relatively inexpensive
way to develop an initial set of
requirements.
Prototyping,
Interactive
storyboards
[18, 19, 24]
It provides stakeholders with a
concrete (although partial) model or
system that they might expect to be
delivered at the end of a project. It is
often used to elicit and validate system
requirements.
+ Product feature and detailed
specifications – an early and realistic
view of what was feasible
JAD/RAD
sessions
It stands for Joint Application
Development/Rapid Application
Development and emphasizes user
involvement through group sessions
with unbiased facilitator.
Contextual
inquiry [14]
Analyst s and
stakeholder
representatives
communicate
and coordinate
to reach a
common
understanding
of the
requirements
It is a combination of open-ended
interview, workplace observation, and
prototyping. This method is primarily
used for interactive systems design
where user interface design in critical.
The synthetic methods combine different communication
channels, and provide models to demonstrate the system feature
and interaction. They provide good cues for requirement
recognition in the form of rich semantic models [21]. For
example, the prototypes provide users an initial version of the
system which can remind them of the fine grained functions
which are often otherwise overlooked. Storyboard is a method
between scenarios and prototyping. It offers a continuum of
possibilities ranging from sample outputs to live interactive demos
[19].
Instead of methods restricted at the requirements stage, the
synthetic methods are often deployed at other stages of the
product development life cycle. Because the objective of synthetic
methods is to improve the communication between developers
and the customers, they are suitable for different stages of the
development process. They effectively harmonize the
requirements stage with the rest development activities.
3.5 Summary
No matter what development project is, requirements
development nearly always takes place in the context of a human
activity system, and problem owners are people [24]. It is
essential for requirements engineers to study how people perceive,
understand, and express the problem domain, how they interact
with the desired product, and how the physical and cultural
environments affect their actions. The four types of techniques
present different approaches to these questions. The
conversational methods provide a direct contact channel between
engineers and stakeholders, and the requirements are mainly non-
tacit. The observational methods provide an indirect channel by
observing user’s interaction with his work setting and context, and
the requirements fall into tacit knowledge. The analytic methods
form one complementary indirect contact channel to extract
requirements proactively. The synthetic methods focus more on
collective effort on clarifying the features of desired products, and
the communication channel is therefore a mix of direct contact
and indirect contact. Each type of techniques has trade-offs. In
reality, of course, the boundary between different types of method
is blurred. Some methods are used synthetically, like the example
of open-ended interview and ethnographic study mentioned in
section 3.4. The method selection should be done according to the
understanding of the nature of each method, the problem domain,
the organizational context, types of requirements source, etc. The
analyst needs to learn several if he wants to become adept at
eliciting requirements.
4 PERSPECTIVES OF METHOD
SELECTION
Having studied the nature of the requirements elicitation methods,
this section further discusses the factors that affect the method
selection. The factors are presented mainly from four
perspectives: the abstraction level of requirements, the
requirements source, the communication obstacles, and the level
of certainty.
4.1 Requirements abstraction level
In general, requirements engineers go through two phases in
requirements elicitation: problem analysis and product
specification. The former phase is to perceive the problem domain
by understanding the situation of concern and setting boundaries
[1], while the latter to focus on features of the product by
collecting complete and concise requirements. Accordingly,
requirements can be distinguished between two abstraction levels:
the generic knowledge of problem analysis and the specific
knowledge of the product description. The generic knowledge is
on a higher abstraction level than the specific one. It mainly refers
to the business requirements such as the product vision, project
scope, and the constraints. The specific knowledge mainly refers
to the product features including functional and nonfunctional
requirements. The specific requirements are aligned with the
context and objectives established by the business requirements.
Taking into account the nature of requirements on different
abstraction levels, a proper set of elicitation methods have to be
chosen. For example, as business requirements identify the
primary benefits from the desired product, they should be
gathered from individuals who have a clear sense of the ultimate
value the product will provide to business and its customers.
Therefore, conversational methods are good options for
knowledge acquisition from project managers or customer
representatives. However, if the desired product is a brand-new
one in market, due to the limited understanding of product
domain, observational methods can be applied for generic
knowledge acquisition from the environment where the product is
put into use. Furthermore, synthetic methods can be regarded as a
comprehensive approach to eliciting product features, and the
analytic methods form a good complementary approach if similar
products have already been produced by the organization.
4.2 Requirements source
Stakeholders form the sources of requirements. As discussed in
section 3.3, stakeholders not only refer to human being, but also
the physical, organizational, or political environment in which the
desired product is put into use. Therefore, the source of
requirements exists in different forms: knowledge embedded in
human being and the knowledge embedded in the physical
environments. Accordingly, different elicitation approaches shall
be applied. The engineer shall ensure that the selected method can
effectively utilize the requirements sources in terms of the data
available and the process to acquire the knowledge.
The knowledge of human being is the primary source of
requirements and accessible by using almost every method:
conversation, observation, analysis, and synthetic methods. Most
ideas for product development and improvement come from
customers and end users [12].
Besides, because human being not only have individual
knowledge about the problem domain and the desired products,
but also hold a social position in organizations or departments
where there are subtle power and influence relationships between
the different people [18], they play different roles in a variety of
projects and influence them, and their goals and desires are
conformed to the organizational business objective. Due to the
diverse social positions, it is difficult to extract all needed
knowledge from stakeholders. For example, the organizational
knowledge might be difficult to elicit by using interviews
primarily because of political and social factors [18]. Identifying a
method that fits into the elicitation context is therefore important
to elicit concise and complete requirements.
In general, a high-level strategy for requirements development can
be summarized based on features of the different types of
methods. The conversational methods are effective for developing
an understanding of the problem and the desired product from
different stakeholders. The observational methods are suitable for
understanding customers or end users’ work when they find it
difficult to articulate the work setting, the work flow, and the
social and organizational factors that influence the problem. The
synthetic methods are more effective for intensive communication
and collaborations between stakeholders and engineers, which
inspires stakeholders to recognize the omissions, errors and
inconsistencies of existing requirements and identify further
requirements. The analytic methods are relatively effective for
eliciting requirements from existing documentation and domain
experts. Besides, requirements engineers shall understand the
organizational and political context, the stakeholder knowledge
background, their characteristics, and their social positions when
adapting a method for requirements development.
The environment in which the product is put to use forms another
form of the requirements source. They include legislation,
standards, organizational structure, characteristics of the systems
coexisting with the desired system, as well as the specification of
legacy systems. Most of them are presented in the form of
documentation, which is accessible by analytic methods, such as
social studies, documentation studies and requirements reuse.
Analysts are main actors when acquiring requirements from the
environment.
4.3 Communication obstacles
A product is not independent but exists in an environment
containing many other products which affect its functionality.
Method selection within managerial, organizational and political
constraints is a complex and subjective decision [21], and this
paper does not attempt to provide a complete guidance. Instead,
we discuss the communication barriers in stakeholder and analyst
interaction.
The importance of communication between stakeholders and
analysts at the requirements stage has been widely studied [2, 7,
13, 18]. Various communication barriers are discussed. For
example, Valusek and Fryback {Valusek, 1987 #452} categorize
barriers into within the individual, between a user and an analyst,
and among users. This category has been widely used in the
related research {Valenti, 1998 #450}. As software development
projects become a global collaboration across national borders,
organizations face challenges in enabling effective requirements
elicitation from multi-site organizations. Besides the existing
research results, this paper takes into account the globalization
phenomena and addresses obstacles caused by the nature of
different communities, societies, or individuals, i.e. culture
diversity. In detail, we analyze the culture diversity on three
levels: national culture, organizational culture, and individual
cognitive limitations.
The national culture defines “a collective mental program” of
people [7, 13]{Damian, 2003 #451}. Individuals from different
cultural backgrounds may have different languages, beliefs,
values, attitudes, competencies, and perceptions of priority, which
results in different behaviors in cooperation. Accordingly,
analysts shall using an appropriate method to interact wit h
stakeholders from different nationalities. For example,
brainstorming or workshops are much less effective for idea
generation if the participants are habitually reserved in speech,
while observations are appropriate for collecting information from
reticent people.
The organizational culture covers many facets of organizational
operation [27], such as management structure and style, common
work habit and interaction patterns. Besides, the nature of the
work place, norms, values inherent in an organization can also be
considered as organizational culture [18], such as the
terminologies used within an organization, the product
development maturity levels, the sources available for
requirements development, etc. The organizational culture
influences the features of the desired product, and is worth
studying. However, it is implicit and embedded in the
organizational operation. Therefore, observational methods and
analytic methods are more effective than conversational methods.
Meanwhile, scenarios and storyboards can facilitate effective
communication by providing a tangible reference that all
stakeholders could use to express their thought.
The individual cognitive limitations refer to cognitive
shortcomings of human as information receiver, information
processor and problem solvers [2]. At the requirements stage, they
mainly refer to the ability of comprehension, the capacity of
memory and recall, the information processing activities, and the
decision-making processes. The cognitive limitations vary from
people to people, so different methods may be suitable for
different people to elicit requirements within the same context.
For example, the experts and novices have apparently different
cognitive capability, because of the different working experiences,
knowledge backgrounds and mind sets. It results in different
views and scopes to perceive and solve the problem domain.
Therefore, interview may be suitable for an expert to elicit domain
information, while prototyping is a more likely method for a
novice. Furthermore, the tangible information is easy for
individuals to perceive and analyze. Most synthetic methods
deliver concrete concept or process models, which is an effective
support to alleviate the individual cognitive limitations.
In addition, the international cooperation highlights the problem
of communication across space and time [20] {Damian, 2003
#451}. Global teams use a variety of techniques to diminish
communication barriers caused by space and time, such as phone,
email, videoconference, and groupware tools. These techniques
are applicable for requirements elicitation and can be used
together with most requirements elicitation methods.
4.4 Level of certainty
When selecting a method, an important factor influences on
method selection is whether the organization is acquainted or
unfamiliar with the application domain. An acquainted domain
implies a higher level of certainty with the problem than the new
domain.
An acquainted domain reflects a relatively mature problem
situation. The problem in existing domain is easy to understand
and structure, which means the product vision and the scope are
well stated, the domain knowledge has been existing between
engineers and stakeholders, and the glossary of specific
terminologies is available, etc. On the basis of a clearly defined
business objective and the vision and scope statements, the
engineers can easily start eliciting requirements with
conversational methods, such as interviews, or some synthetic
methods like evolutionary prototyping. The level of uncertainty is
relatively low.
However, a brand-new product implies a higher level of
uncertainty. The application domain is not as well-understood as
the domains for which products have been developed, and
problems emerge in the domain which may not be faced by the
requirements analysts before. Before composing the high-level
business objective and product vision, the engineer have to
acquaint himself with the domain. In such a context, observational
and analytic methods are more effective than the conversational
methods at the initiation stage of requirements elicitation.
Meanwhile, as the problem domain is unstructured, synthetic
methods such as prototyping and scenarios fit well to improve the
understanding and communication between stakeholders and
engineers. More specifically, scenarios or storyboards provide an
effective and relatively inexpensive way to communicate specific
system features in situations of highly uncertainty {Holbrook,
1990 #449}.
4.5 Summary
We have discussed four perspectives for requirements method
selection. These four perspectives are not mutually exclusive and
there are obviously interrelationships between them. For example,
the abstraction level is reflected in the perspective of level of
certainty, and requirements resource is closely related to the
communication environment. Besides, there are many other trivial
factors that influence the method selection. They are more related
to a specific situation or context. The discussion does not, by any
means, aspire to reject or overwrite the existing frameworks [2-4,
15, 21] to guide the selection of requirements development
methods. Rather, we aim at providing a simple and feasible in-
practice alternative for methods selection, and guidance on when a
specific elicitation technique should be used, based on which the
engineers can gain more experience on method selection in
practice.
5 MATRIX OF METHOD SELECTION
In an attempt to understand the appropriate use of different types
of requirements methods, a matrix is constructed to summarize the
level of applicability of methods in different situational contexts.
The perspectives influencing on method selection form the
situational contexts of requirements development, and are listed in
the left column of the matrix. The method category, listed in the
top row of the matrix, represents different channels to acquire
requirements. In different situational contexts, distinct
communication channels are created between analysts and
stakeholders. Accordingly, a set of methods can be selected to
meet the needs of a specific situational context, as shown in Table
5.
Table 5 Matrix of method selection
Perspective
+++: Methods strongly
recognize the issue and
provide a means to deal with it,
++: Methods support the
issues, but not as strongly as
the previous one,
+: Methods address the issues,
but weak or indirectly,
-: Methods do not address the
issues.
Conversational methods
Observational methods
Analytic methods
Synthetic methods
Problem analysis
++ +++ ++ + Abstraction
level
Product
description
++ + ++ +++
Human being +++ + + ++ Requiremen
ts source
Other - +++ ++ -
environments
National culture ++ + + +++
Organizational
culture
+ +++ ++ +
Cognitive
limitation
++ + + ++
Comm.
obstacles
Geographically
distributed
environment
++
telecon
ference
- +
email
+
groupware
tools
Existing domain
+++ + +++ ++ Level of
certainty
New domain ++ ++ + +++
The matrix represents different levels of applicability the methods
address in different situational contexts. It is illustrative, rather
than comprehensive, so method types rather than every individual
method are presented. On the basis of the matrix, a set of
guidelines for method selection is summarized as below.
• The conversational methods are handy and commonly
used throughout the requirements development process.
It is applicable in almost every situation when
stakeholders are people.
• The observational methods are less effective than the
others. However, they work perfectly at the beginning
of a development project to achieve the basic
understanding of the physical, organizational, political
and cultural environment where the desired product is
put in use.
• The analytic methods provide approaches to acquiring
corporate knowledge from exiting documents and the
experts. In contrary to the observational methods which
are more suitable for requirements elicitation in an
unfamiliar application domain, analytic methods
provide effective support of requirements elicitation in
application domains where the domain related
documentation and experts are available. Its underlying
principle is to reuse the corporate knowledge that exists
in different forms.
• The synthetic methods are more comprehensive than
any individual methods, and of course consume more
resource to perform. It is always a good choice when the
project resources allow. Meanwhile, the synthetic
methods are effective to refine the functional
requirements.
The matrix is rooted in theory and empirical findings from
decision-making and cognitive psychology. It provides a practical
starting point for organization to select appropriate methods at the
requirements stage. In practice, as organizations’ business
objectives and their development strategies vary, the different
situational contexts influence on the development activities and
method selection differently. The level of applicability of every
method has to be further adjusted and customized in different
organizations and their work settings. For example, the method
selection at the requirements stage shall conform to the
development method deployed by organizations. That is to say,
prototype is a rather good choice for organizations that apply the
prototype model for the product development; while analytic
methods might not be appreciated in organizations that deploy
agile development methods which emphasizes more interactions
with end users than analysis of existing documentation.
6 CONCLUSION
Requirements elicitation is a critical step in the requirements
development process. It is consequently imperative that
requirements engineers apply appropriate methods to perform the
process sufficiently. This paper has attempted to present
meaningful insights into the feature of different types of
requirements elicitation techniques, based on which a practical
guideline for method selection is suggested. The classification of
requirements elicitation methods is based on the nature of the
techniques. It reveals the different communication channels for
the analysts to elicit requirements, and provides the contextual
situation for method selection.
It is worth outlining that the techniques discussed in this paper are
based on the implicit assumption that the human stakeholders and
the requirements analysts are cooperative and sincere. The
stakeholders are willing to share knowledge with the analysts and
the analysts prepared carefully before conducting an elicitation
session. Requirements engineering is a complex social interaction
process, the techniques discussed in our paper provide analysts a
proper and contextual means to perform the process. Besides, the
analysts should possess interpersonal skills to help build
consensus between heterogeneous groups of stakeholders. Such
social skills are as important as the techniques used in the
engineering process.
7 ACKNOWLEDGMENTS
I wish to thank Jarkko Lehto and Mauri Tikka from Nokia
Research Center for their constructive comments and Kari
Känsälä (Nokia) and Kai Vuolajärvi (University of Jyväskylä) for
their support of the project.
8 REFERENCES
1. Avison, D.E. and Fitzgerald, G. (eds.). Information Systems
Development: Methodologies, Techniques and Tools.
McGraw-Hill Book Company, 1995.
2. Byrd, T.A., Cossick, K.L. and Zmud, R.W. A Synthesis of
Research on Requirements Analysis and Knowledge
Acquisition Techniques. MIS Quarterly, 16 (1). 117 - 138.
3. Christel, M.G. and Kang, K.C. Issues in requirements
elicitation Technical report CMU/SEI-92-TR-12 ESC-TR-
92-012, Carnegie Mellon University, Pittsburgh, PA, 1992,
80.
4. Coughlan, J. and Macredie, R.D. Effective communication in
requirements elicitation: A comparison of Methodologies.
Requirments Engineering, 7. 47 -60.
5. CREWS. CREWS: Cooperative requirements engineering
with scenarios, 1999.
6. Cybulski, J.L. and Reed, K., Requirements Classification and
Reuse: Crossing Domain Boundaries. in Conference on
Software Reuse, ICSR'2000, (Vienna, Austria, 2000), 190-
210.
7. Dafoulas, G. and Macaulay, L. Investigating Cultural
Differences in Virtual Software Teams. EJISDC, 7 (4). 1-14.
8. Goguen, J.A. and Linde, C. Techniques for Requirements
Elicitation Proceedings IEEE International Symposium on
Requirements Engineering, IEEE CS Press, San Diego, CA,
1993.
9. Gutierrez, O. Some aspects of information requirements
analysis using a repertory grid technique. in Gallier, R.D. ed.
Information Analysis: Selected Readings, Addison-Wesley,
1987, 347 -362.
10. Hawgood, J., Land, F. and Mumford, E., A participative
approach to forward planning and system change. in
Proceedings of the 2nd Conference of the European
Cooperation in Informatics, (Venice, Italy, 1978), 39 -81.
11. Hickey, A.M., Dean, D.L. and Nunamaker, J.F. Establishing
a foundation for collaborative scenario elicitation. The
DATA BASE for Advances in Information Systems, 30 (3,
4).
12. Hippel, E.V. Lead users: A source of novel product concepts.
Management Science, 32 (7). 791-805.
13. Hofstede, G. Cultures and Organisations. McGraw-Hill,
1991.
14. Holtzblatt, K. and Beyer, H. Making customer-centered
design work for teams. Comm. ACM, 36 (10). 93 - 103.
15. Hudlicka, E., Requirements elicitation with indirect
knowledge elicitation techniques: comparison of three
methods. in Requirements Engineering, (Colorado Springs,
CO, 1996), 4 - 11.
16. Hutchings, A.F. and Knox, S.T. Creating products: Customer
demand. Comm. ACM, 38 (5). 72-80.
17. Knethen, A.v., Paech, B., Kiedaisch, F. and Houdek, F.,
Systematic requirements recycling through abstraction and
traceability. in IEEE Joint International Conference on
Requirements Engineering, (2002).
18. Kotonya, G. and Sommerville, I. Requirements Engineering:
Processes and Techniques. John Wiley & Sons, 1998.
19. Leffingwell, D. and Widrig, D. Managing Software
Requirements - A User Case Approach, 2nd Ed. Addison-
Wesley, 2003.
20. Lloyd, W.J., Rosson, M.B. and Arthur, J.D., Effectiveness of
elicitation techniques in distributed requirements
engineering. in IEEE Joint International Conference on
Requirements Engineering, (2002), 311 - 318.
21. Maiden, N.A.M. and Rugg, G. ACRE: Selecting Methods for
Requirements Acquisition. Software Engineering Journal, 11
(3). 183 - 192.
22. Montazemi, A.R. and Conrath, D.W. The use of conginitive
mapping for information requirements analysis. MIS
Quarterly, 10 (1). 45-56.
23. Myers, M.D. Investigating information systems with
ethnographic research. Communications of the AIS, 2.
24. Nuseibeh, B. and Easterbrook, S., Requirements engineering:
a roadmap. in Proceedings of the Conference on The Future
of Software Engineering, (Limerick, Ireland, 2000), ACM
Press, 35 - 46.
25. Rugg, G., Eva, M., Mahmood, A., Rehman, N., Andrews, S.
and Davies, S. Eliciting information about organizational
culture via laddering. Information Systems Journal, 12 (3).
215-229.
26. Rugg, G. and McGeorge, P. The concept sorting techniques.
The Encyclopedia of Library and Information Science, 65
(28). 43 - 71.
27. Scholl, R.W. Organizational Culture - The Social
Inducement System, University of Rhode Island, 2003.
28. Sharp, H., Finkelstein, A. and Galal, G., Stakeholder
identificaiton in the requirements engineering process. in
First International Workshop on the Requirements
Engineering Process: Innovative Techniques, Models and
Tools to support the RE process, (Florence, Italy, 1999).
29. Standish Group. 2004 CHAOS Demographics and Project
Resolution, 2004.
30. Viller, S. and Sommerville, I., Social analysis in the
requirements engineering process: from ethnography to
method. in Proceedings of the 4th International Symposium
on Requirements Engineering (RE'99), (Limerick, Ireland,
1999), IEEE CS press.
31. Woo, H.G. and Robinson, W.N., Reuse of scenario
specifications using an automated relational learner: a
lightweight approach. in IEEE Joint International Conference
on Requirements Engineering, (2002), 173 - 180.
32. Vries, H.d., Verheul, H. and Willemse, H., Stakeholder
identification in IT standardization processes. in MIS
Quarterly Special Issue Workshop on Standard Making: A
Critical Research Frontier for Information Systems, (Seattle,
2003).
33. Wright, G. and Ayton, P. Eliciting and modeling expert
knowledge. Decision Support Systems, 3 (4). 13-26.
