Using Argumentation to Explain Ambiguity in Requirements Elicitation Interviews
1. Lero - University of Limerick, Ireland *
CNR-ISTI, Pisa, Italy **
Open University, Milton Keynes, UK ^
Kennesaw State University, Marietta (GA), USA‡
Using Argumentation to Explain Ambiguity
in Requirements Elicitation Interviews
Yehia Elrakaiby *
Alessio Ferrari **
Paola Spoletini ‡
Stefania Gnesi **
Bashar Nuseibeh *^
2. What and How
❖ What is the problem that we are addressing?
❖ Explain the occurrence of ambiguity in requirements
elicitation interviews in a formal way
❖ How does your approach/idea/model/etc. assist
practitioners?
❖ It does NOT at the moment, but it establishes the
theoretical basis for the development of intelligent
ambiguity detection tools
2
6. Motivation
❖ During interviews ambiguity may hamper communication
with the customer
❖ The analyst may not understand or misunderstand the
customer’s statements
❖ This may result in problems at later stages of
development
❖ It is important to study the ambiguity phenomenon,
and provide means to explain it
6
7. Motivation
❖ In a previous work*, we found that only 50% of the
ambiguities occurring in interviews can be rooted in
single terms used by the customer (e.g., vague, domain-
specific terms; pronouns and quantifiers)
❖ The remaining 50% are due to entire fragments (i.e.,
sentences). They require the study of the context.
* Alessio Ferrari, Paola Spoletini, Stefania Gnesi:
Ambiguity Cues in Requirements Elicitation Interviews. RE 2016: 56-65
7
9. Goal
❖ Goal - provide a theory for explaining ambiguity cases
that cannot be rooted in single terms
❖ We use argumentation theory as a formal tool to show
that these ambiguities can be represented as ‘attacks’
between arguments of a structured discourse that
occurs in the mind of the analyst (the context)
9
10. Focus: Acceptance Unclarity
❖ Acceptance Unclarity occurs whenever the speech fragment of the
customer is perceived as:
❖ Inconsistent with the current knowledge of the analyst
❖ The train shall be able to stop within 5 meters, after an
obstacle is detected on the line
❖ Trains at full speed require hundreds of meters to stop!
❖ Insufficient to comprehend the problem
❖ The onboard system of the train should use TCP/IP to
communicate
❖ To what device?
10
11. Approach
❖ Method
❖ Isolated a dataset of 77 cases
from the previous study
❖ Identified an initial smaller set
❖ Iterative process
Start/Stop
End
Initial Data Set
Construct/
Revise Theory
Assess
Theory
Valid
Selected 8 fragments
from 6 interviews
Detect & explain
ambiguities
Inspect data set
77 fragements
New Data Set
Undetected cases
Incorrect cases
No Are all cases
adequately covered?
11
12. Overview of Argumentation Theory
❖ An argument is an attempt to persuade someone
of something, by giving reasons or evidence for
accepting a particular conclusion
❖ Argumentation is a form of non-monotonic
reasoning that makes explicit the reasons for the
acceptance of certain arguments (and not
others) and how conflicts are resolved
❖ Dung’s argumentation framework (DAF)
❖ A set of arguments
❖ A set of attacks between arguments
❖ e.g., (G2, B1)
❖ Extensions
❖ Computes a set of justified or accepted
arguments
❖ Several possible semantics
❖ grounded: {}
❖ preferred: {B1} or {G2, G1}
The train shall
stop within 5
meters
trains require
hundreds of
meters to stop
trains do not require
hundreds of meters
because obstacles
can be detected
G1
B1
G2
12
13. Extensions
❖ An argument is an attempt to persuade someone
of something, by giving reasons or evidence for
accepting a particular conclusion
❖ Argumentation is a form of non-monotonic
reasoning that makes explicit the reasons for the
acceptance of certain arguments (and not
others) and how conflicts are resolved
❖ Dung’s argumentation framework (DAF)
❖ A set of arguments
❖ A set of attacks between arguments
❖ e.g., (G2, B1)
❖ Extensions
❖ Computes a set of justified or accepted
arguments
❖ Several possible semantics
❖ grounded: {B1, B2}
❖ preferred: {B1, B2}
But sometimes
obstacles will
not be detected
G1
B1
G2
B2
13
The train shall
stop within 5
meters
trains require
hundreds of
meters to stop
trains do not require
hundreds of meters
because obstacles
can be detected
14. ASPIC+
❖ The general structure of an argument in
natural language is that of premises
(typically in the form of propositions,
statements or sentences) in support of a
claim: the conclusion
❖ ASPIC+ Theory
❖ A logical language
❖ A set of structured arguments
(inference rules)
❖ defeasible/strict
❖ A knowledge base (what is currently
true)
❖ ordinary/axioms
14
Technology
X unavailable
Important
project
obstacles can
be detected
Technology X
can not be
used
Use of braking
technology X
The train shall
stop within 5
meters
15. Overview of Argumentation Theory
❖ Working of ASPIC+
❖ Argument construction
❖ Translation into a Dung’s abstract
argumentation framework
❖ Computation of Extensions
Technology
X unavailable
Important
project
obstacles can
be detected
Technology X
can not be
used
Use of braking
technology X
The train shall
stop within 5
meters
B1
B2
B3
C1
C2
A1
15
16. Overview of Our Argumentation System
Inputs
(I)
Outputs
(O)
AF AAf !" g
❖ Inputs:
❖ the context
❖ Argumentation Framework:
❖ translation into an ASPIC+ argumentation theory + constraints
❖ Computation of Extensions
❖ Outputs
❖ Ambiguity detection and explanation
16
17. Context Model (Input)
❖ Identified based on the data set
realisationstatement
Optative Indicative
Relations
Elements
A Statement refines/satisfies Motivation
A Realisation satisfies Statement
Motivationstatement
statementrealisation
17
Motivation
18. Assumptions & Output
❖ The mental state of the analyst
(context) is modelled as an
argumentation theory which consists of
❖ Statement/Motivation/Realisation
elements (the knowledge base)
❖ Relationships between those
elements (structured arguments)
❖ Determine the status of every argument A
{accepted, conditionally accepted or rejected}
❖ Provide the reason why
❖ is inconsistent with…, irrelevant, unrealisable
or unsatisfiable
preferred
extensions
grounded
extension
ASPIC Theory with
Constraints
(specified using strict rules)
1) Statement satisfaction constraints
2) Motivation satisfaction constraints
3) Statement relevance constraints
4) Realisation relevance constraints
1
2
3
4
18
19. Example1: Inconsistency (Symmetric Attack)
❖ recycling support system:
One of the customers wants a recycling-support system
that, given the envelope of a product, indicates to the user
which trash bin should be used. One of the domain
statements is to fine incorrect recycling. According to the
domain knowledge of the analyst, trash bins are placed
along the streets, and therefore there is no way to trace
the owner of the rubbish, once it is thrown in the trash bin.
The analyst could not see how the municipality identifies
the person who violates the aforementioned rule.
trash bin place
in streets
trace
people
no way to
trace
people
B1
A1
A2
should
fine
B2
(b) V.2
A1
A1,
A2
A1,
B1, B2
❖ Output
❖ A1 is accepted
❖ A2 is accepted only if B1 and B2 are not
accepted
❖ B1 (B2) is accepted only if A1 is not accepted
19
20. Example2: Insufficiency (Asymmetric Attack)
❖ Component Quotes:
One customer wishes to develop a system to
facilitate getting quotes of mechanical components
from different vendors. He says: I should have the
name of the vendor, (optative statement s1). The
analyst could not understand how, in practice, this
information could be retrieved.
❖ Theory is consistent!
get
name
20
21. Example2: Insufficiency (Asymmetric Attack)
ss(get
name)
get
name
B1
A1
-get
name
B2
B1,
B2
❖ Output
❖ A1 is unsatisfied (B1 & B2)
❖ + statements satisfaction constraints
❖ Intuition: Every statement element must be
satisfied
❖ Integration in the model: +elements
+relations such that ss(St) holds whenever St
does not belong to any preferred extensions
of AT<realisation elements, relations>
21
❖ Component Quotes:
One customer wishes to develop a system to
facilitate getting quotes of mechanical components
from different vendors. He says: I should have the
name of the vendor, (optative statement s1). The
analyst could not understand how, in practice, this
information could be retrieved.
22. Conclusion
❖ Ambiguity is a common phenomenon in requirements
elicitation interviews
❖ Detection is essential to correctly model and then
build the target system
❖ Our contribution
❖ Formalisation of acceptance unclarity ambiguities
❖ An argumentation-based framework to detect and
explain ambiguities
22
23. Future Work
❖ Our current assumptions require
❖ Identification of fragments and of their types
❖ Identification of relations between fragments
❖ Possible techniques
❖ Application of machine learning techniques on requirements documents
❖ e.g., TLS is a realisation element whereas confidentiality and
integrity are motivation elements
❖ e.g., TLS is a realisation element that can satisfy both integrity and
confidentiality
❖ Come to a semi-automated process
23
