1. Effective Elicitation through Interviews and
Requirements Modeling
Manik Verma
CEAS
University of Cincinnati
Cincinnati, USA
Vermamk@mail.uc.edu
Abstract
C. J. Davis, Fuller et.al stated that “accurately capturing
system requirements is the major factor in the failure of 90%
of large software projects,” [1] in 2006 resonating on the
findings by Lindquist 2005, who concluded “poor
requirements management can be attributed to 71 percent of
software projects that fail; greater than bad technology,
missed deadlines, and change management issues” [2].
Requirements elicitation in the context is well known to be a
very hard task, much dependent on the experience and
cleverness of the team performing the elicitation. The
gathering of stakeholder requirements comprises an early, but
continuous and highly critical stage in system development.
This phase in development is subject to a large degree of
error, influenced by key factors rooted in communication
problems. The 2006 review by A.Davis, Dieste, Hickey, Juristo
classified research in terms of requirements elicitation and the
promising results are consistent to draw conclusions that
interviewing is cited as the most popular requirements
elicitation method [3]. In such a context the use of interviews
is important in order to incorporate contextual issues and is
also pointed out as the major technique for getting the
requirements from the actors in the organization. The
requirements can then be transformed in a systematic way into
a formal specification that is a suitable basis for design and
implementation of a software system. This paper analyzes
interview processes and proposes a model for simulating them
by aligning the interviews with blackboard model for
formulating requirements in the form of IEEE 830, the
standard requirements specification documents.
I. INTRODUCTION
There exist several requirements acquisition methods, such as
interviews, questionnaires, brainstorming, CRC [4], and
decision-making method [5]. Most software projects usually
adopt the face-to-face interview method with stakeholders as
one of the effective requirements acquisition methods.
However, the face-to-face interview method involves the
following problems [6, 7]. (1) Before a correct answer is not
got yet, interviewers may change the topic and ask a different
question. In such a case, correct requirements cannot be
elicited. (2). Interviewers may ask similar and unnecessary
questions repeatedly. (3) If interviewers are not domain
experts, domain- specific requirements are not grasped
correctly. While performing elicitation through interviews the
three basic questions that needs to be answered are: What to
ask? How to ask? Whom to ask?
So we divide the study on the basis of answering the following
questions through four dimensions of the requirement
elicitation framework as adapted from a classification scheme
by Coughlan and Macredie [8] can be useful to visualize
factors in end user perspective. The key areas under
consideration are: (1) Stakeholder participation and selection;
(2) Stakeholder interaction; (3) Communication activities; and
(4) Techniques.
II. ELICITATION INTERVIEWS
II.1 STAKEHOLDER SELECTION
It has often been argued to decide upon the number of
participants, it has been proposed that a majority of elicitation
of problems can be identified with a small number of
participants [10]. This is coined as the so-called ‘saturation
point’ that can be reached after between 12 and 20
stakeholders. Other studies indicate that correctly identifying
the ‘saturation point’ in interviews is not the only concern but
also how these participants/stakeholders are selected, for
instance in terms of subject matter or domain specific
knowledge. Another implication from these studies concludes
that to construct requirements for larger software sub systems,
several sub-groups of stakeholders proves to be useful. Given
these factors suggested by Morse [11], fewer participants can
be utilized to reach data saturation. A variety of stakeholders
are involved in the execution of elicitation processes and the
formation of stakeholder sub group is vital as it has a strong
bearing on specification outcomes, communication can be
hampered by the inclusion of inappropriate people.
Requirement gathering consultant and end users are examples
of types of stakeholder who are of particular interest in RE
process. They have the responsibility for ensuring that the
requirements are fully specified and represented so as to
produce detailed models of the system. Both types of
stakeholder have to interact with a diverse range of people
from both technical and non-technical domains having a
variety of task knowledge, skill, status and responsibility.

2. II.2 COMMUNICATION METHODS
Requirements, in essence, can be said to be the embodiment of
everything a user values [12]. The successful communication
of these values, requires a clear understanding of the context
which embeds requirements. Thus this highly complex
environment demands communication interfaces, between the
users having social perception and the analysts coming from a
technical background [13]. Hence, eliciting requirements is a
highly complex activity that must incorporate negotiation and
collaboration with all its stakeholders, in order to build strong
foundation for the requirements to emerge in this
communication oriented RE process. This also involves
overcoming basic semantic differences dividing the two groups
(users and analysts) attempting to engage in meaningful
dialogue [14]. For communication to occur reliably in the
elicitation of requirements, there needs to be a shared
understanding, which can only occur through co-operation and
negotiation. Communication activities can be categorized by
behavior in three ways [15]
(1)Knowledge acquisition: There are links that need to be made
between the different stakeholders’ domains of knowledge and
experience and of the technological options, so as to achieve a
shared understanding and common vision of a future system. It
can be seen as the preparation stage for future knowledge
negotiations.
(2)Knowledge negotiating: Requirements need to be negotiated
as part of an iterative process, which helps to define the
requirements (assuming knowledge of requirements has been
satisfactorily acquired) through a sharing of multiple
stakeholder perspectives.
(3)Stakeholder acceptance: Acceptance of the system implies
integration of stakeholder viewpoints where both parties co-
operate to understand the scope of the system and the changes
that impact upon the organization.
II.3 INTERVIEW TECHNIQUES
Independent of the type of interview (e.g. structured or
unstructured) this elicitation technique depends on interactional
talk. Since the discovered data is, in this sense, partly a
function of the talk between a client and an analyst, the study
of this talk is central to the understanding of how information is
captured and the client-analyst relationship in general [16].
Researchers have argued that communication between analysts
and users is often problematic due to issues such as cognitive
limitations and vocabulary differences [17,18]. Sutton [19]
suggests that “Different social realities bring forth different
languages and users are most of the time inhabiting worlds with
very different concerns and objects of interest from each other,
let alone from providers”.
II.4 ANALYST VS STAKEHOLDER KNOWLEDGE
Komiya et.al. performed research on the interview processes
for requirements elicitation done by expert analysts, and
suggested analysis of experts’ knowledge as follows [6]
I) Project specific knowledge: a) Problem domain knowledge:
e.g. knowledge on specific domains such as insurance,
banking, healthcare while dealing with domain intensive
projects. b) Knowledge on implementation environments such
as computers, network, operating systems, etc.
2) Project independent knowledge: a) Knowledge on
documentation: e.g. standards of document formats such as the
IEEE830 form suggest what contents and where the analysts
should describe as requirements specification documents. b)
Knowledge on how to interview with stakeholders: e.g. the
analysts should ask for concrete illustrations.
Quadrant (a) represents common knowledge to both analyst
and client. Interviews help to increase the size of this quadrant.
Quadrant (c) represents that knowledge that the analyst has that
the client does not. The analyst would be seeking to teach the
client part of this knowledge. Quadrant (b) represents
knowledge that the client and analyst wants to extract this. It
includes functional models of the business. Quadrant (d)
represents discovery knowledge that sprouts from the dialogue
or
interview.

3. III. STRUCTURING INTERVIEWS
The interview analyst can prepare a basic set of questions that
fit in best with domain and type of project under consideration.
According to Wetherbe's work on executive information
requirements [20], a common mistake in determining
requirements is asking the wrong question: "What information
do you need from the new system?” . It is debatable that this is
an obvious and valid question but, research says that it is not all
helpful to clients attempting to determine what information
they need. Wetherbe proposes an approach to interviewing that
uses indirect questions. This scheme is composed of types of
questions abstracted from three methods/techniques defined:
BSP (Business System Planning) [21],CSF (Critical Success
Factors) [22] and EM (End Means Analysis)
The heuristics provide knowledge required to validate the
answers given by respondents and also analyses the ability of
these questions in capturing maximum information i.e. the
usability aspect for scrutiny of the subset of questions. After
the specific set of questions have been decided upon, it is
equally important to define the control or the order of questions
and their heuristic's application. A proposed model for
shortlisting questions is represented in the figure below:
Another option would be combining the two already
existing models in order to narrow the candidates for the
questions set in order to elicit requirements from interviews,
blackboard model and state transition. The candidates can be
selected based on the usability of the questions asked from the
stakeholders until now. The blackboard model is helpful in
holding the captured information in the IEEE 830, the formal
requirement specification document. Whereas the each state in
the state transition model can represent the state of the
blackboard, depicting the information that has been elicited,
and decide what questions the analyst should ask. Whenever a
response is received from the stakeholder, i.e. whenever a
question is answered, this triggers a transition in the state
transition model and guides the analyst for next question and
the corresponding IEEE 830 fields are filled with the answer.
IV. PERFORMING INTERVIEWS
A set of interviews (semi-structured) must be
conducted with the aid of pre-structured and prompt questions,
while being restricted to steer the interview within the time
frame allocated for each participant. As we know that the
saturation point can be reached with lesser number of
participants, hence the analyst must decide the number of
participants and time slot based on the individual project
requirements and time. A set of specific questions must be
prepared, designed in a manner to probe user experience,
thoughts and opinions relating to the different dimensions of
the project framework so that each of the requirements can be
used to derive use cases that can be transformed into
specifications which can be implemented. The sequence of
questions can be continued in the given time frame as long as
the dialogue does not digress from the flow of the interview,
and extra some unplanned questions can be asked from
respondents in order to seek clarification, enquire or reassure
that all relevant information only has been captured.
The analyst asks the questions and annotates factual
information in a clear manner extracting from respondents
answer. The two proposed solutions to capture non ambiguous
and only the required information are as follows:
1) The feedback mechanism: First, the analyst must also
comment on the answers he is annotating, by providing
his/own insight from the understanding. Second at the end of
the interview after analyzing the answers, the analyst may ask
the respondent to rate the answers provided with a metric rating
system on the basis of confidence/surety and authenticity of the
information provided.
2) Substantiate base lining: After every interview the analyst
shortlists major outputs so forth called as “boilerplate facts”
and the subsequent respondents can be asked to rate these facts.
After a determined number of approvals or threshold, a
boilerplate fact is marked as a candidate requirement and
baseline is performed. Hence by adding important information
to the boilerplate and reassuring validity of these facts, it can be
ensured that all the information captured is authentic and also
important.
At the end of the interview a report is generated which mirrors
the knowledge base and provides some diagnoses of the
captured information.

4. V. BARRIERS TO INTERVIEWS
The three major types of discrepancies in requirements
elicitation that have been highlighted over years of research
are: a) wrong information b) missing information, incomplete
knowledge ,lack of clarity due to missing rules and facts, and c)
inconsistency in information, contradiction between two stated
facts.
The following are the candidate reasons explaining such
anomalies in information received from stakeholders [23]:
 Barriers to verbalization
One major issue with the interviews could be that, the
elicited information entirely depends on the ability of the
respondent to verbalize. The issue is that the respondent can
verbalize or state only those problems and project aspects that
they in retrospect remembered from experience or had reflected
upon deliberately. Sometimes a simulation of the scenario or a
clear understanding is also poorly communicated. The
requirements sometimes incorporate contextual issues by
highlighting those problems that the end-users’ experience or
regarded as the most important.
 Barriers to understanding
Requirements elicitation is also hampered if the
stakeholders involved face barriers in understanding. The
barriers are major results of the manifestations of difference in
understanding which obstruct the interpretation of knowledge
shared and therefore impair the elicitation. There lies a huge
gap between end user’s expectations and level of ability
required by technology to implement that required change into
a deliverable product. This type of understanding in the sense is
important for clients to visualize the strengths and capabilities
that the supplier package can offer. This issue can be handled
or averted by adequate knowledge transfer to the client for
better understanding of the offered technology or package so
that they can realize what can be expected from the offered
system or solution?
 Barriers to innovation
Stakeholder’s innovative thinking and performance is often
stifled due to routine and traditional styles of work. The
creativity seems to diminish and this leads to emergence of
constrained behavior where the stakeholders resist any
opportunity to creative change even for better. This in turn
creates another gap between understanding of the stakeholders
(i.e. end user and analyst) where one argues to allow existing
assumptions to remain unchallenged, and the other tries to
introduce new ideas. There might be some aspects of current
system that the analyst feel are redundant, but they might as
well be very ingrained but it becomes difficult for the
stakeholder to articulate as to why things are done a certain
way Consequently, such a lack of understanding and mistrust
leads to inefficient requirements specifications.
 Barriers towards change
Stakeholder’s commitment towards the activity of
requirements elicitation can be inhibited predominantly by fear
to loss of job. It leads to loss of interest and a sense of
negligence towards communication and ultimately towards the
acceptance of the system. This mainly happens when very little
has been done to communicate to end users about the role of
the new system and the changes that it will ensue. This can be
handled by ensuring corrective change management sessions.
One useful concept to detect such barriers is framing.
Framing facilitates the listener to interpret the speakers’
instructions, about what has been said and how to understand
the utterance [24, 25, 26]. Through subtle but profound signals
like pitch, voice, intonation, and facial expression the
contextual information can be extracted. These also provide a
frame additional information about the context indirectly.
Gumperz [27] refers to these signals as “contextualization
cues” which may be prosodic, paralinguistic and non-verbal.
These help in highlighting the shared experiences, and are
powerful means of meaningful negotiating and is the legitimate
and preferred style of communicating in workplace settings
[28].
Many experts assess early the immediate gaps in knowledge
among the stakeholders, and deliberately direct the elicitation
in the direction of achieving these intermediate goals.
Examples include particular non-behavioral requirements, user
interface, and database contents. This often drives the expert
analyst toward specific modeling notations to supplement the
elicitation technique.
VI. MODELING SPECIFICATIONS FROM REQUIREMENTS
An explicit requirements elicitation phase results of which is an
adequate starting point for the development of the formal
specification. The different phases in the RE process provide
feedback to one another, it is not the specification which is
based on the requirements, but the specification phase can
reveal important omissions and errors in the requirements that
were elicited. We can thus find a way to formally express the
requirements, which can be termed as the specifications. The
proposal is to formalize the requirements as constraints on
events or operations that can be incorporated in the context of
the system. Hence by this approach the transformation of
informal to formal means of requirement specification is
performed early in the application development process. The
advantage that requirements can be analyzed, e.g., for
consistency, and correctness.
VI.1 FORMALIZING REQUIREMENTS
The major difference between requirements and specifications
is that requirements refer to the entire system, whereas
specifications refer only to the part of the system to be
implemented by the application. Hence in order to express
requirements small implementation from the model of the
entire application is considered i.e., some sequences of events
or some specific use case. The basic steps for requirements to
specification modeling are:
1. 1. Defining the domain: All necessary entities and functions
must be introduced in a natural language giving brief
description.

5. 2. Introducing all the events in context of the system, by defining
the input and output parameters and a relation between these
parameters. Classification of the events as: (i) Influenced by the
environment but not the application (ii) influenced by the
environment and application.
3. State facts, assumptions, and requirements concerning the
system in natural language. Facts express things that will
always hold true in the context of the application domain.
4. Formalize the facts, assumptions, and requirements as
constraints on the possible traces of system events.
5. Also express negative requirements, i.e., to require that certain
things do not happen as constraints on the system. Constraints
do not restrict the specification or system behavior
unnecessarily.
VI.2 REQUIREMENT VS SPECIFICATION
Specification is supposed to be a model of the application to be
built in order to satisfy the requirements. It is developed by
expressing properties of the system and continuously adding
more details to build the model, starting from requirements
acquired. A specification makes statements about the
application, as it is the foundation on the basis of which further
design and implementation is to be developed.
Though elicitation is independent of the specification language,
the development of specification does depend to a certain
extent on the specification language and its expression.
Augmenting of the specification is done by incorporating the
requirements one by one into formal language. Adding of a
validation condition. This can be any constraints on the system
which expresses facts. These constraints must not be violated.
This allows to define a notion of correctness of a specification
with respect to requirements, facts, and assumptions. The
approach is to define operations for each event of the desired
system, identified in requirements elicitation phase and also
define system operation from use cases.
VII. CONCLUSION
Trying to derive the real requirements requires an in-depth
understanding and reflection on the part of the users, and
effective communication techniques on the part of the
consultants. While the state of my research has not allowed me
to reach definitive conclusions. Instead this paper is an
important contribution to RE process by proposing techniques
that can be implemented into the requiremets elicitation
through interviews, which can help solve the discussed issues
regarding improper requiremet elicitation. The paper also
provides some basic idea on modelling the specifications on
basis of the elicited requirements, in a manner that both thse
different phases can contribute to make each other better.
Various factors have been discussed, which exemplify the
synchronization between these two very important phases in
requirements engineering life cycle. Future research will allow
me to draw extended conclusions by providing heuristics and
data quantifying the success and failure of the proposed
techniques and providing a critique on the same. The specific
solution to a wider range of issues, by means of new techniques
proposed, and specific guidance to practicing analysts to
ultimately improve the state of the practice in requirements
elicitation has been provided.
VIII. ACKNOWLEDGEMENT
The author would like to thank all the experts and class of
requirements engineering who gave so unselfishly of their time
to the cause of improving the state of requirements elicitation
practice. I would also like to thank Professor Nan Niu and the
UC College of Engineering and Applied Sciences for
establishing an environment where research is rewarding,
rewarded, and enjoyable.
IX. REFERENCES
[1] Davis, C. J., Fuller, R. M., Tremblay, M. C., & Berndt, D. J.
(2006). Communication challenges in requirements elicitation
and the use of the repertory grid technique. Journal of Computer
Information
[2] Lindquist, C. (2005). Required: Fixing the requirements mess:
The requirements process, literally, deciding what should be
included in software, is destroying projects in ways that aren’t
evident until it’s too late. Some CIOs are stepping in to rewrite
the rules. CIO, 19(4),
[3] Davis, A., Dieste, O., Hickey, A., Juristo, N., & Moreno, A.
(2006). Effectiveness of requirements elicitation techniques:
Empirical results derived from a systematic review. 14th IEEE
International Requirements Engineering Conference (RE'06).
[4] A, Anton and C. Potts, "The Use of Goals to Surface
Requirements for Evolving Systems", Proc. -- 201h ICSE,
pp.157-166, 1998
[5] C. H. Kepner and B. B. Tregoe, "The Rational Manager,"
Princeton Research Press, 1965.
[6] S. Komiya, et. al., "A Method for Implementing a System to
Guide Interview-driven Software Requirements Elicitation",
Knowledge- Based Engineering, 10s Press, pp.175-182, 2000.
[7] H .Kaiya, M. Saeki, and K. Ochimizu, "Design of a Hyper
Media Tool to Support Requirements Elicitation Meetings,"
Proc. of the 7th International Workshop on Computer-Aided
Software Engineering,
[8] J. Coughlan, R.D. Macredie, Effective communication in
requirements elicitation: a comparison of methodologies,
Requirements Engineering 7 (2) (2002) 47–60
[9] Virzi, R.A., 1992. Refining the test phase of usability evaluation.
How many subjects are enough? Human Factors 34 (4), 457–
468.
[10] Griffin, A., Hauser, J.R., 1993. The voice of the customer.
Marketing Science 12 (1), 1–27.
[11] J.M.Morse, Determining sample size, Qualitative Health
Research10 (1) (2000) 3–5.
[12] A.M. Davis, The harmony in requirements, IEEE Software 15
(2) (1998) 6–8.

6. [13] E.J. Garrity, Synthesizing user centered and designer centered IS
development approaches using general systems theory,
Information Systems Frontiers 3 (1) (2001) 107–121.
[14] R.P. Bostrum, Successful application of communication
techniques to improve the systems development process,
Information Management 16 (5) (1989) 279 – 295.
[15] D.B. Waltz, J.J. Elam, B. Curtis, Inside a software design team:
knowledge acquisition, sharing, and integration,
Communications of the ACM 36 (10) (1993) 63 – 77.
[16] RosíoAlvarez - Discourse Analysis of Requirements and
Knowledge Elicitation Interviews.
[17] Agarwal, R. and Tanniru, M.R. 1990. “Knowledge Acquisition
Using Structured Interviewing: An Empirical Investigation,”
Journal of Management Information Systems, Vol. 7, No.1,
pp.123-140.
[18] Byrd, T. A., Cossick, K.L., Zmud, R.W. 1992. “A Synthesis of
Research on Requirements Analysis and Knowledge Acquisition
Techniques,” MIS Quarterly, Vol. 16, No.1, pp. 117-138.
[19] Sutton, D. C. 2000. “Linguistic Problems with
Requirements and Knowledge Elicitation,”
Requirements Engineering, Vol. 5, pp. 114-124.
[20] Wetherbe James c. Executive Information Requirements:
Getting It Right MIS Quarterly, March
[21] Information Systems Planning Guide, Application Manual,
GE20-0527-3, Third Edition, IBM Corporation (July 1981)
[22] Rockart, J. F. Critical Success Factors Harvard Business
Review, 1979, (March-April), vol57, (2) pp. 81 -- 91
[23] Communication issues in requirements elicitation: a content
analysis of stakeholder experiences - Jane Coughlan*, Mark
Lycett, Robert D. Macredie
[24] Bateson, G. 1972. Steps to an Ecology of the Mind. New York:
Ballantine
[25] Goffman, E. 1974. Frame Analysis. New York: Harper and
Row.
[26] Tannen, D. and Wallat, C. 1987. “Interactive Frames and
Knowledge Schemas in Interaction: Examples from a Medical
Examination/Review,” Social Psychological Quarterly, Vol. 50,
No. 2, 205-216.
[27] Gumperz, J. J. 1982. Discourse Strategies. Cambridge:
Cambridge University Press.
[28] Sarangi, S. and Roberts, C. 1999. “The Dynamics of
Interactional and Institutional Orders in Work-Related Settings.
In Sarangi, S. and Roberts, C. Talk, Work and Institutional
Order: Discourse in Medical, Mediation and Management
Settings. Berlin: Mouton De Gruyter, pp. 1-60