Name: Neha Tiwari Date: 5th April 2023

Course: Master of Information Technology

IT8x10 Business Analysis for Information Technology
Assignment 1: Annotated Bibliography

Introduction
Role of domain knowledge in requirements elicitation via interviews and ambiguity, tactic
knowledge in requirements elicitation interviews.
The requirement engineering process starts with the requirement elicitation activity, this
activity involves multiple requirement elicitation techniques and among them, taking
interviews with various stakeholders is a common one. Every working system has an
information system embedded in a specific manner, having prior knowledge about that
business or organization plays a vital role in the requirement elicitation process.
Domain knowledge refers to the knowledge of Industry, Business, Challenges, Opportunities,
Risks, Methods, and Competitions, it is about the environment in which the IT system
operates, encompassing the understanding of industry dynamics and business processes of the
target enterprise.
A business analyst is responsible to use the elicitation technique of interview to elicit
information from a person or a group of people in a particular setting by asking a list of
questions to drill down their requirements and documenting the responses, having prior
knowledge of the domain helps the business analyst to cover the three main stages of an
interview: Planning and preparation, Interview and Follow-up.
It is considered that having domain knowledge while drilling down the client requirements
always helps business analysts to get to the root of the requirements, however, there are a few
shortcomings of having prior knowledge of the particular sector, for instance: the experience
or knowledge acquired in the previous projects can be exploited, domain knowledge not only
inclined to a first solution attempt, which eventually decreases the chances of finding a
perfect and appropriate solution to the problem.
On the other hand, ambiguity in communication during requirement elicitation via interview
is often a core barrier to knowledge transfer, which could lead to incorrect & unclear client
requirements.
This paper summarises and explains, how business analysts who have domain knowledge can
lead to getting best outcome of requirement elicitation via interview sessions with clients. In
addition, examining the presence of ambiguity in requirements elicitation interviews, when
client requirements are still under the elicitation process. This incorporates an empirical study
to find out the perceived and actual effects of previous domain knowledge in the process of
requirement elicitation through interview sessions with multiple stakeholders, in addition to
this, it also covers interviewing 34 customer analysts to define a framework to categorize an
ambiguity in four categories: incorrect, correct disambiguation, multiple and unclear
understanding.
 Annotation 1:
“The Role of domain knowledge in Requirements Elicitation
via interviews: an exploratory study”

The requirement engineering process incorporates stages of requirement elicitation activity

which includes surfacing, learning, and tracking down the needs (current requirements) of the
various stakeholders of the existing system.
The outcome during this elicitation process must be interpreted, sculpted, and validated
before the business analysts can feel self-reliant about the client’s needs or requirements for
completeness and correctness.
Conducting interviews with various stakeholders consider the best practice to drill down the
requirements and document them in a systematic manner, during interview sessions, business
analysts might have domain knowledge. Business analysts’ domain knowledge always plays
a vital role in client interaction to understand clients’ pain points and current state, however,
there are positive and negative impacts.
This paper outlines an empirical study that depicted the actual and perceived effects of prior
experience/domain knowledge on requirements elicitation/requirement engineering through
interviews with the stakeholders. Involving in interview sessions with stakeholders
overcomes the barrier (communication) between business analysts and stakeholders caused
by an absence of their domain knowledge, thus it seems beneficial to have domain knowledge
prior to involving in human interaction. The experiments conducted by I. Hadar, P, Soffer,
and K. Kenzi in their study depict that in dealing with creative problems, domain knowledge
not only fixates knowledgeable subjects but also incorporates their prior experience with
respect to the problem. In their experiments they have come up with two broad research
questions:
1) “What are the positive and negative effects of domain knowledge on requirements
elicitation via interviews, as perceived by analysts with and without domain
knowledge?”
2) “Is there a difference in the actual interview conducted by analysts with and without
domain knowledge?”
This paper has explained the pros and cons of having domain knowledge (both business
analysts and developers) in requirement elicitation techniques via interviews along with the
outcomes of the actual interviews conducted with analysts with and without domain
knowledge.
Research Method
This paper has an amalgamation of qualitative and quantitative methods. Specifically, in
order to answer the question “What are the positive and negative effects of DK on
requirements elicitation via interviews, as perceived by analysts with and without domain
knowledge?” The authors have applied a qualitative approach, University students
participated to fill out the questionnaires along with the class discussions. And to address the
question “Is there a difference in the actual interview conducted by analysts with and without
domain knowledge?”—the authors have applied a quantitative research approach to the
comparison between the interviews conducted by the two different sets of populations:
business analysts with and without domain knowledge.

Finding and conclusion

This paper has come up with the findings and insights as to both the positive and negative
effects of domain knowledge on requirements elicitation through interview sessions with
stakeholders, as perceived by participants with and without domain knowledge, and depicts
the existence of an actual effect on the course of the interviews. To summarize, the main
objective of this paper is to provide experimental evidence of the demonstration of domain
knowledge with respect to past documented observations.
 Annotation 2:
“Ambiguity and tacit knowledge in requirements elicitation
Interviews”
The prime aim of this paper is to provide insight into obscurity in requirement elicitation
interviews. Ambiguity or incomplete communication plays a vital role in unclear
requirements documentation. Drilling down the requirements or requirements engineering
process has many hurdles and among them, ambiguity in communication is the root cause of
the wrong requirement documents. Alessio F, Paola S & Stefania G has performed a set of
interviews of 34 customer-analyst interviews, in this paper, they have analyzed the role of
ambiguity during requirement gathering via interviews. They have come up with a
framework that has four main sub-phenomena.
In this paper, they have focused on 37 unstructured interviews, where clients or customers are
free to talk where they are not guided by a set of predefined questions. Ambiguity refers to
the misunderstanding scenarios when clients’ expressions are misunderstood by the
requirement-gathering team. It also aims to bridge the gap between natural language
understanding and artificial intelligence techniques with the principle of understanding
ambiguity in interviews while the requirement elicitation process. Authors have observed the
happening of ambiguity by conducting a set of realistic or face-to-face interviews between
the customer/client and the requirement-gathering team and they find out that ambiguity in
natural language requirement documents and its “classical lexical, syntactic, semantic clues”
led to the very limited level of ambiguity however, pragmatic and contextual aspect appeared
to be dominant. Thus, in this paper authors have defined a framework in terms of the category
of the ambiguities in requirement elicitations interview sessions (proposed by Gervasi et al.
on tacit knowledge).

The pragmatic facet

It has been observed during the interviews that ambiguating in drilling down the requirements
appeared as different from the ambiguating appeared in natural language requirements, they
related to the vague terms “like as possible”.
Interpretation of the requirement, acceptance of the requirement, and access to the
requirement, these all terms that have been outlined in a framework proposed by the authors.
This paper aims to outline the fundamental challenges in terms of ambiguity that arise during
requirement elicitation interviews:
 Identification of ambiguity cues
 Ambiguity-based elicitation methodologies
 Ambiguity in the process
 Ambiguity on the customer’s side

On the other hand, tacit knowledge was first explained and introduced by Polany, which is
basically the role of language used during communication (Interviews). Polany has
mentioned that it’s the art of transferring knowledge by using examples.

Findings and conclusion

This paper represents that ambiguity is a “subjective phenomenon”, which specifically
derives from signer to reader, ambiguity also refers to a situational and contextual
phenomenon. Ambiguity has many names like: “interpretation unclarity, acceptance
unclarity, multiple understanding, detected and undetected incorrect disambiguation, and
correct disambiguation”. Thus, its requirement analysts’ or business analysts’ responsibility
to get a clear view of their perception of clients’ words.

References

Hadar, I., Soffer, P., & Kenzi, K. (2012). The role of domain knowledge in requirements
elicitation via interviews: An exploratory study. Requirements Engineering, 19(2), 143-159.
https://doi.org/10.1007/s00766-012-0163-2

Ferrari, A., Spoletini, P., & Gnesi, S. (2016). Ambiguity and tacit knowledge in requirements
elicitation interviews. Requirements Engineering, 21(3), 333-355
DOI 10.1007/s00766-016-0249-3