Ambiguity in Software Engineering

Ambiguity Problems in Software Engineering
Alessio Ferrari1
1ISTI-CNR, Pisa, Italy
alessio.ferrari@isti.cnr.it
25 Nov, 2016
A. Ferrari (ISTI) Ambiguity 1 / 95

Software Everywhere

Big Software

Big Failures

Software Engineering
Software engineering it the systematic design and development of
software products and the management of the software process.
Software engineering has as one of its primary objectives the
production of programs that meet speciﬁcations, and are demonstrably
accurate, produced on time, and within budget.

Software Engineering

Requirements

Requirements Engineering
Requirements engineering is the branch of software engineering
concerned with the real-world goals for, functions of, and
constraints on software systems.
It is also concerned with the relationship of these factors to
precise speciﬁcations of software behavior, and to their evolution
over time and across software families.

The Requirements Process (Requirements Deﬁnition)
Elicitation
Analysis
Documentation
Validation
Transcripts
of Meetings
with Customers
Models
Structured
Requirements
Document
Requirements
with
Defects

Examples of Requirements
Deﬁnitions: ETCS, driver, RBC, DMI, etc.
ETCS shall provide the driver with information to allow him to drive
the train safely.
If the supervision is performed by a RBC it shall be possible to
prevent movements of a traction unit in its area if not authorised
by the RBC.
In case the transition has to be acknowledged and the driver fails
to acknowledge as required, the ETCS shall initiate a brake
application.
Partial Supervision shall be indicated on the DMI.
Diagrams: to understand how requirements relate to each other

Observations
Requirements processes differ from company to company, and
from market type to market type
Safety-critical companies shall write requirements, in other cases
this is not required
Small companies might have a single customer asking for a
simple application, requirements might come from one person
Business-to-Business software might involve more stakeholders
(e.g., a system to assist doctors in diagnoses)
Consumer’s software (e.g., MS Word) is for the market,
requirements come from several people (that nevert asked for a
product)
Often, a product is already developed and requirements imply
changes to the product
Requirements belong to different classes
(functional/non-functional)

Concepts: Requirement, Speciﬁcation, Domain Assertion

Michael Jackson’s Model
When we build a SYSTEM we make a change in a portion of the
WORLD that we call ENVIRONMENT
ENVIRONMENT SYSTEM
WORLD
INTERFACE
The SYSTEM and the ENVIRONMENT interact through an
INTERFACE (i.e., sensors and actuators)

Concepts
ENVIRONMENT SYSTEM
WORLD
INTERFACE
RD S P M
Domain
Assertion
Requirement Speciﬁcation Program Machine

Concepts
Domain assertions (D): all the conditions over phenomena of the
environment that we know (or presume) to be true, regardless of
the system
Requirements (R): all the conditions over phenomena of the
environment that we want to make true by developing the system
Speciﬁcations (S): description of conditions and actions
occurring at the interface between the environment and the
system. Provides enough information for a programmer to build
the system
Program (P): implementation of the speciﬁcations
Machine (M): hardware, sensors and actuators that support the
program

Example: Patient Monitoring System
ENVIRONMENT
SYSTEM
D1: there is always a nurse close enough
to hear the buzzer
D2: the sound from the heart below a
threshold T indicates that the heart is
about to stop
R: the system shall notify the nurse if the patient's heartbeat stops
S: if the sound from the sensor falls below a
threshold T, the system shall actuate the buzzer
P: the program
M_v: the sensor and the buzzer
M_h: the rest of the harware

Objective of Requirements Engineering
Identify R, S and D, so that if a system whose behaviour satisfies S is
installed in the environment, and the environment has the properties
described in D, then the environment will exhibit the properties
described in R.
D, S ` R
Read it as: The Specification S, under the constraints expressed
in D, satisfies the Requirements R
Requirements speak the language of the environment (i.e., the
domain – medical, public administration, etc.)
Specifications speak the language of the interface, and are
expressed in terms of shared phenomena

Observation
The formalisation is useful if I am using a formal language to
define requirements and specifications
The formalisation is only a guideline in practice, because the R
and D speak about the world, which is not formal!
In practice, requirements and specifications are rarely formal
Requirements and specifications are often expressed in Natural
Language (NL)
The formalisation is still useful, and, even when expressing R, S
and D in NL, you should keep it in mind

Requirements or Speciﬁcations?
1 Only authorised people shall be able to enter the park
2 The system shall allow only authorised people to enter the park
3 Only people who has payed the fee shall be able to enter the park
4 The system shall release a receipt, after the user has inserted coins, if
the user has introduced 3 coins
5 The system shall open the barrier, if 3 coins have been introduced
6 The system shall enter in state COUNT_COINS, when the coin sensor
senses the introduction of 1 coin, and the system is in state
WAIT_COINS
7 The system shall enter in state RELEASE_RECEIPT, if the user has
introduced 3 coins

Rule of Thumb
If a Customer can read it, it’s a Requirement
If a Customer cannot read it, it’s a Speciﬁcation

Adding some Confusion: System and Software Specifications
If I am defining System Specifications (S-SYS), then the hardware
elements are part of the system, and part of them appear in the
interface (as in the previous example)
If I am defining Software Specifications (S-SW), then the
hardware elements are part of the environment, and hence in the
specification I will speak about abstract variables to be set. These
variable are considered to be part of the interface (i.e., they are
the variables used by the drivers).

Example: Patient Monitoring System
ENVIRONMENT
SOFTWARE
D1: there is always a nurse close enough
to hear the buzzer
D2: the sound from the heart below a
threshold T indicates that the heart is
about to stop
R (S-SYS): if the sound from the sensor falls below a threshold T,
the system shall actuate the buzzer
S (S-SW): the software shall set BUZZER = ON,
if SOUND < T.
P: the program
M: see previous slide

This is just a practical solution!
This is just a practical solution to overcome the problem of
separating system and software specifications, as asked in the
context of embedded safety-critical systems.
In this lecture, we will mainly speak about system specifications.
If sensors and actuators are just keyboards and screens, then the
software specification is the system specification.
WARNING: in the literature, when you read software specification,
the authors often mean system specification.

Adding more Confusion: Software Requirements Specification
We have seen that Requirements and Specifications are different
So what the hell is a Software Requirements Specification (SRS)?
It is a document that specifies the Requirements OR the
Specification, OR both
It depends on who is going to read the document

So What to Do?
Keep in mind the distinction between R, S and D
When you write a statement, make an effort to place it in R, S or D
If a company has a single standard document to edit R and S,
follow that, and separate R, S, and D
If a company distinguishes between user/customer requirements
and system/software requirements, then place R and D in the
former, S in the latter, and trace them.
If a company further distinguishes between system and software
requirements, then follow the suggestion given in a previous slide.
If a company does not have a standard document to edit
requirements and speciﬁcations, then use the template in the
IEEE Std 830-1998(R2009), which is nice.
Consider who’s going to read the document! (Customer,
Developer, Tester, etc.)

Adding more and more Confusion: Goals
A requirement tells us WHAT the system shall do
A GOAL tells us WHY the system shall do that thing
Example
Requirement: the system shall notify the nurse if the patient’s
heartbeat stops
Goal: patients whose heartbeat is going to stop shall be saved
Expectation: when the nurse hears the buzzer, the nurse saves
the patient
Goals are useful in Requirements Analysis
(Completeness) Which other requirements are needed to address
the GOAL?
(Alternatives) Is there an alternative approach?
(Obstacles) What can be an obstacle for that GOAL?

Requirements Elicitation: Ambiguity Problems

Requirements Elicitation
Requirements Analyst
Customer
Other Stakeholders Existing Documentation
Legacy Software
REQUIREMENTS

Interviews
Requirements AnalystCustomer

Tacit Knowledge
Tacit Knowledge

Ambiguity and Tacit Knowledge
During requirements elicitation interviews, ambiguity may hamper
communication with the customer
Ambiguity is also a resource to disclose tacit knowledge
The customer might use domain-speciﬁc terms, or might express
concepts that are complex to be communicated
The occurrence of an ambiguity might reveal the presence of
unexpressed, system-relevant knowledge that needs to be elicited

Ambiguity as a Resource to Disclose Tacit Knowledge
Tacit Knowledge
≠

Deﬁnition of Ambiguity
Ambiguity in Interviews
An ambiguity occurs in a requirements elicitation interview when a
customer articulates a unit of information, and the meaning assigned
by the requirements analyst to such articulation differs from the
meaning intended by the customer.
Unit of information: system need or domain-related aspect
Articulation: any speech fragment
We include cases where the analyst cannot give any interpretation

Example: Ambiguity in Interviews
Web-based platform where the citizens can send suggestions for
laws to the parliament
Ambiguity: “I want a dashboard to show (to the representatives
of the parliament) what’s going on in speciﬁc areas” (thematic or
geographical?)

Context of the Analyst
INTERPRETATION
ACCEPTANCE
SPEECH
FRAGMENT
ACCESS
Requirements
Goals
Domain
Speciﬁcation
k
k
k
kCONCEPT
ACCESSIBLEa, i(k) = interpretablea,i(k) ^ acceptablea,i(k)

Phenomenology of Ambiguity

Ambiguity
ambiguousi(k) = articulatedc,i(k) ^ ¬articulatedc,i(k0
)^
(¬ACCESSIBLEa,i(k) _ interpretablea,i(k0
))
The customer articulates a unit of information k
through a speech fragment i
The unit of information k cannot be accessed
or i is interpreted as k0
Let us focus on the second line of the equation, which is:
¬interpretablea,i(k) _ ¬acceptablea,i(k)_
interpretablea,i(k0
)

Categories of Ambiguity
k k0
Phenomenon
¬interpretable(k) ¬acceptable(k) ¬interpretable(k0
) - interpretation unclarity
interpretable(k) ¬acceptable(k) ¬interpretable(k0
) - acceptance unclarity
interpretable(k) acceptable(k) interpretable(k0
)
acceptable(k0
) multiple understanding
¬acceptable(k0
) correct disambiguation
- ¬acceptable(k) interpretable(k0
)
acceptable(k0
) undetected incorrect disambiguation
¬acceptable(k0
) detected incorrect disambiguation
Four Main Classes
Unclarity
Multiple Understanding
Incorrect Disambiguation
Correct Disambiguation

Ambiguity Types: Correct Disambiguation
View of the
Problem

Ambiguity Types: Correct Disambiguation
What I hear has an interpretation
The interpretation is consistent
The interpretation is sufﬁcient
In practice: what I hear does not rise any question

Ambiguity Types: Interpretation Unclarity
?

Ambiguity Types: Acceptance Unclarity

Example
Interpretation Unclarity
Use of domain jargon (e.g., “connoisseurship method” for History
of Arts expert)
Use of vague terms (e.g., “(The app changes the color of the wall)
taking light into account”)
Acceptance Unclarity
(Domain) “If you do not recycle a thing because the municipality
did not signal that it was recyclable, you will not get a ﬁne”

Ambiguity Types: Detected Incorrect Disambiguation

Ambiguity Types: Undetected Incorrect Disambiguation

Example
Detected Incorrect Disambiguation: Fitness Tamagochi
“You can decide what type of character you want to create”
(Acceptance Unclarity - Domain) “So, you can choose the
character?”
“Actually you cannot [...] you can possibly become (a speciﬁc
character)”
Undetected Incorrect Disambiguation: Automated Baby-swinger
“I want something that can change. A component that relax her
(the daughter) is that she feels the novelty in the movement”
Incorrect disambiguation: change in frequency
“You can choose different sequences of movement, three in this
direction, two in this direction” (Acceptance Unclarity - Req)
Correct interpretation: change in direction

Ambiguity Types: Multiple Understanding

Example
Multiple Understanding
Web-based platform where the citizens can send suggestions for
laws to the parliament
“A dashboard to show (to the representatives of the parliament)
what’s going on in speciﬁc areas” (thematic or geographical?)
“The application should be connected to a social network”
(internal or external?)

Which are the Triggers?
We have unpacked ambiguity from the point of view of the Analyst
Do we have speciﬁc terms/fragments in the words of the customer
that typically trigger the ambiguity?
Can we categorise them?

Term Triggers
Under-specified terms (U): people, knowledge, movement, area,
rule, data, category, interface, thing, detail
I “The interface shall be coded in Java”
Vague terms (V): minimal, as much as possible, later, taking into
account, based on, appropriate
I “The loading time shall be minimal”
Pronouns (P): he, she, it, this, those, which, that
I “The system sends a message to the receiver, and it sends an
acknowledge message”
Quantifiers (Q): all, for each, many, some, both
I “All lights have a switch”
Domain-specific terms (D-S): connoisseurship method, herpes
zoster, systemic disease, Program

Same Category of Trigger, but Different Ambiguity Type
Example 1 - Under-speciﬁed Term ! Multiple Understanding
Mobile application that monitors the use of the mobile phone
Example: “Maybe the system could give me also some
recommendations”
Interpretations: Positive (this app could be useful to you) or
negative recommendations (do not use this app)
Example 2 - Under-speciﬁed Term ! Undetected Incorrect
Disambiguation
A system to monitor the diet of patients for research purposes
Example: “We analyse a representative sample of the population”
representative sample == volunteers (Undetected incorrect
disambiguation)
“People tell lies about their diet” (Acceptance unclarity)
representative sample == randomly selected people

Quantitative View - Domain Experts (DE) set
term (U)
32%
term (V)
4%
term (Q)
3%
term (P)
1%
term (D-S)
13%
Fragment
47%
DE set

Quantitative View - Software Engineers (SE) set
term (U)
39%
term (V)
7%
term (Q)
3%
term (P)
3% term (D-S)
8%
Fragment
40%
SE set

Observations
The majority of ambiguity cases were due to under-specified
terms and by fragments
Example: “What type of information would you like to search?”
“For example, the name of a street”
Current research concerning cues in NL requirements accounts
for about 10% of the ambiguity cases in interviews (pronouns,
quantifiers and vague terms)
The remaining 90% of the cases (under-specified, domain-specific
and fragments) require further research

Requirements Analysis (Pointers)

Requirements Analysis
Requirements analysis is what you do after you met the customer, to:
Reason on R and D, to write down a document that the customer
can read
Reason on R, D, and S to write down a (possibly separate)
document that your programmers can read
Often, you are going to write a single SRS with both R, S, and D
From now on, I will speak about writing a SRS, meaning a
document including R, S, and D
Several techniques exist, I will give you just some pointers, since this
lecture focuses on ambiguity

Example: Car Park System
I want to build a system to automate the payment for a private car
park
The typical scenario is:
1 a car enters from an entrance barrier and the driver takes an
entrance receipt from an entrance device
2 the driver parks the car
3 when the driver has to leave the park, he goes to a payment
machine and inserts the entrance receipt
4 the machine computes the amount of money due
5 the driver pays and the machine releases an exit receipt
6 the driver inserts the exit receipt in an exit device, and the driver
exits from the exit barrier
The system also monitors the number of free places in the park

Pointer 1: Context Diagram
System
Car
Barrier
Park
Coin
Customer
Shared Phenomena

Pointer 2: Prototyping and Mock-ups
Googlehttp:/carpark.it
My-Car Park Monitor
Select a date
30 329 1 23128
2421 23 25 272622
201814 17 191615
129 1187 10 13
S
6
F
5
T
4
W
3
T
21
M
30
S
December 2008
Select Today
Check Failed
Payment Machine
See Car Park
Occupation

Pointer 3: Use Case and UML
Enter Car Park
Car Driver
Car Park Surveillant
Monitor Car Park
Exit Car Park
Pay Parking

Pointer 4: Goal Modelling
Profits
Improved
Automatic Car
Park Defined
Car Entrance
Automated
Car Exit
Automated
Payment
Automated
Verification of
Payment
AchievedOpen Barrier
Achieved
Close After
Pass Achieved
Trigger to Open
Barrier
Achieved
Open Barrier if
Payment
Achieved
Button System
Implemented
Open Photocell
System
Implemented
Verify Money
Achieved
Release
Receipt
Achieved
AND
OR
Open Button
Controller
Photocell
Controller
Counter
Implemented
Close Photocell
System
Implemented
Payment MachineBarrier Controller Exit Controller

Documentation: Using NL Templates

Documentation: Using NL Templates
SRS are written in Natural Language (NL), because several
stakeholders with diverse skills have to interact with them
SRS are written in NL, because formalisation is not possible at
this stage of the development
As spoken language is ambiguous, so it is written language
In a conversation, I can ask clariﬁcations, but when a document is
written, it is not always that easy

Rupp’s Template (more appropriate for R)
between. For an automated tool to deem R1 as conformant,
it has to correctly distinguish these three slots in the follow-
ing: “monitor system configuration changes posted to the
database”. A second important issue is that even when a
slot falls in between fixed elements, e.g., hwhom?i, and is
thus easy to delineate, there is no way to distinguish an
acceptable filler for the slot from an unacceptable one, e.g., a
grammatically-incorrect phrase. For instance, in R1, we may
accept “system administrator” as correctly filling hwhom?i,
but we may be unwilling to accept a grammatically-incor-
rect phrase such as “system administer” for the slot.
and define the glossary terms after the requirements have
sufficiently matured and are thus less likely to change. This
strategy avoids wasted effort at the glossary construction
stage, but it also means that the glossary will not be ready
in time to support activities such as template conformance
checking (TCC), which often take place during requirements
writing. Furthermore, the literature suggests that glossaries
may remain incomplete throughout the entire development
process [14], thus providing only partial coverage of the
glossary terms. This implies that automated techniques for
checking conformance to templates would have limited
effectiveness if such techniques rely heavily on the glossary
Fig. 1. Rupp’s template [5].
ARORA ET AL.: AUTOMATED CHECKING OF CONFORMANCE TO REQUIREMENTS TEMPLATES USING NATURAL LANGUAGE PROCESSING 945

EARS Template (more appropriate for S)
[16], [17], [18] and discussed in Section 2.1. In both of
the studies that use Rupp’s template, the require-
ments were written directly by professionals. As for
the two studies using EARS, one—which is the larg-
est case study reported in this article—was written
directly by professionals as well, while the remain-
ing study uses transformed requirements from one
of our two case studies based on Rupp’s template.
The results from our case studies indicate ﬁrstly, that
templates and NLP to the extent needed in our approac
Section 3 describes our approach for automation of TC
Section 4 discusses tool support. Sections 5 presents the ca
studies we have conducted to evaluate our approac
Section 6 identiﬁes the limitations and analyzes threats
validity. Section 7 compares our approach with relat
work. Section 8 concludes the article with a summary a
directions for future work.
. 3. The EARS template [16].
6 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 41, NO. 10, OCTOBER 2

Validation: Sins of the Requirements Engineer, and NL Ambiguity

9 Sins of the Requirements Engineer
Noise: Presence into the text of an element not adding problem
relevant information
“The car park has three elevators”
Silence: Existence of a characteristics of the problem not covered
by any text element
Have I though about the limit in the number of places
in the car park?
“If the user has inserted the correct amount of
money, the system shall release a receipt” (what if
the amount is not correct?)
Overspeciﬁcation: Presence into the text of an element not
corresponding to any characteristic of the problem but to
possible implementation characteristics
“When a car enters the park, the system shall add
one to the car counter”

9 Sins of the Requirements Engineer (continue)
Contradiction: presence into the text of two or more elements
deﬁning system characteristics in a inconsistent way
“Only when the red button is pressed, the system
shall release the receipt”
“The system shall release the receipt when the user
inserts coins”
Ambiguity: presence into the text of an element that makes possible
different interpretations of one characteristic of the system
“When the user presses the button, the system shall
release the receipt” - which button?

9 sins of the Requirements Engineer (continue)
Forward references: presence into the text of an element using
characteristics of the problem defined below
Consider the red button is defined after you tell how
to use it
Wishful thinking: presence into the text of an element defining a
characteristic of the problem so that a possible solution of
this problem cannot be realistically validated
“The car park receipt shall not be thrown away after
parking”

9 sins of the Requirements Engineer (continue)
Synthesis presence of a requirement that states more than one
functionality, and hence needs multiple-tests
“The system shall allow the car driver to enter and
exit from the park”
Repetition: presence of multiple statements expressing the same
requirement
“The system shall show the amount of money due,
after the user has inserted the entrance card”
“If the user provided the entrance card, the system
shall visualise the amount of money due”

9 Sins - Summary
1 Noise = irrelevant information
2 Silence = absence of relevant information
3 Overspeciﬁcation = implementation-related information
4 Contradiction = contradictory information
5 Ambiguity = multiple interpretations possible
6 Forward references = wrong information sequence
7 Wishful thinking = potential validation problems
8 Synthesis = potential validation problems
9 Repetition = potential validation problems, and ambiguity

Ambiguity in NL Requirements
Templates are useful to reduce ambiguity, but ambiguity might still
be there
Moreover, templates are not always used in practice
We need more ﬁne-grained lenses to reduce ambiguities
Previously, we have classiﬁed ambiguities depending on the way
they are perceived by a listener
The previous classes can be applied also for written text,
substituting the listener with the reader
Here, we classify the triggers of ambiguity in written language,
which can lead to different classes of ambiguities from the point of
view of the reader
These triggers can be applied also to spoken language, but they
are harder to detect (verba volant, scripta manent)

Categories of Ambiguity
Pure Ambiguities
Lexical: the terms used have different vocabulary meanings
Syntactic: the syntactic structure has more than one
interpretation
Semantic: no lexical or syntactic ambiguity, but the expression is
ambiguous
Quasi-Ambiguities
Vagueness: there are cases in which the meaning of the
expression cannot be established
Generality: the expression is too abstract

Lexical Ambiguities
Homonymy: words have unrelated meanings, but they have the
same written representations
Example: I went to the bank. (bank = ground close to a lake;
ﬁnancial institution)
Polysemy: words have related different meanings, but they have
the same written representations
Example: There is a mole at work. (mole = animal; spy)
These types of ambiguity are rare in requirements, but it’s good to
know they exist, since they can occur during elicitation (e.g., “rilevato
sul piano cutaneo” - homonymy).

Syntactic Ambiguities
Analytical: a complex noun group with modifiers, and you do not
know which to which noun the modifiers refer
Example: The principal system administrator shall be able to
enter the data-base (principal = system or administrator?)
Attachment: a preposition (e.g., “with”, “for”, “by”) can be
attached to different parts of the sentence
Example: The system shall produce a resumee using a template
for the final assessment (for the final assessment: is the template,
or is it an objective?)
Coordination: complex combinations of AND/OR, or modifier +
AND/OR
Example: The system shall produce the plot or the data-log and
the legend.
Example: Novel employees and directors shall be provided with
a user-name and password

Syntactic Ambiguities (continues)
Elliptical: omission of words, which are expected to be deduced
from the context
Example: The system produces a positive notiﬁcation in case of
success, and in case of failure doesn’t (does not produce any
notiﬁcation at all?)
Anaphoric: usage of pronouns (e.g., he, it, his, this), which can
be referred to different nouns.
Example: “When the system sends a message to the receiver, it
shall provide an acknowledgement” (it = “system” or “receiver”?)
These are less frequent in spoken language, but rather frequent in
written requirements.

Semantic Ambiguities
These are due to ambiguous interactions of logical quantiﬁers (every,
each, all, any, some, none, a, etc.), and to the use of plurals.
Example: All lights have a switch (one for all, or one for each?)
Example: An alert shall be raised for each failure-mode (the
same alert?)
Example: The wrist-bands contain movement sensors (one-one,
one-many, many-one, many-many?)
Hint: do not use plurals, and be careful with quantiﬁers
These are also due to the usage of synonyms in requirements
Example: The system shall allow the car driver to insert coins
Example: The system shall release the receipt if the user has
payed

Generality
These cases are due to the usage of terms (names or verbs) that
are too abstract
They are not classiﬁed as ambiguities, because, depending on the
context, a more detailed description might not be required.
In requirements and speciﬁcations, generality can be reduced
through the vocabulary
Example: The system shall be able to produce the report
Example: The system shall be able to alert the user in case of
failure
Example: The system shall be able to produce a graph of the
workout of the customer
In the literature, generality problems are often marked as “pragmatic
ambiguities”. This often causes confusion. Pragmatic ambiguities are
concerned with the effect, while here we focus on triggers.

Vagueness
Vagueness occurs when an expression (often, adjective or
adverb) has not a uniquely quantiﬁable meaning.
Several vague expression can be listed (accurate, suitable,
appropriate, clearly, better, accordingly, depending on, if
necessary, if needed, etc.)
In general, avoid adjectives and adverbs
Example: The system shall be able to show the graph of the
workout if required
Example: The system shall be able to show a suitable
representation of the workout
Example: When appropriate, the system shall display low levels
of workout

Detecting Pragmatic Ambiguity (aka Generality, aka
Under-speciﬁcation)

A Mole at Work
There is a
MOLE
at WORK
mh...

Pragmatic Ambiguity depends on the CONTEXT
Fe
-
+
Common Sense
Knowledge
Domain Knowledge
Other Requirements
Other Misterious Things

Approach for Pragmatic Ambiguity Detection

Domain knowledge acquisition for different readers
DOCUMENT SET 1 DOCUMENT SET 2

Different readers analyse the same requirement
REQUIREMENT

Different readers compare their interpretations

Overview
REQUIREMENT
DOMAIN
DOCUMENTS
Domain Knowledge
Graph Construction
Requirement Interpretation
Interpretation Comparison

Domain Knowledge Modelling
We model the domain knowledge as a weighted graph
Each node is a concept
Each edge represents a connection among concepts
The weight of the edge represent how close is the connection
between two concepts
The lower the weight, the closer the connection
The weight is derived from the number of co-occurrences
We build this weighted graph starting from Web pages
concerning the domain of the requirements document

Domain Knowledge Graphs
0.17
0.05
0.167
0.33
0.25
0.25
0.16 0.037
0.1
0.25
0.11 0.071
0.17
0.5
0.5
0.33
0.33
patient
observ
deathlocat
visit time
careinform
patient
risk
deathlocat
visit sourc
care
sign
contact
hospit
hospit
Lower weights indicate stronger connections

Requirements interpretation as a least-cost path search
Interpreting a requirement is activating the concepts of the
requirement in the knowledge graph
Activating two concepts in a requirement implies the activation of
other neighboring concepts
The concepts that are activated are those that are more closely
connected with the concepts in the requirement (i.e., their edges
have lower weight)
The interpretation of the requirement is a least-cost path search
within the domain knowledge graph

Requirements Interpretation
REQ. 1 - The system shall store patient data
system
store
patient
data
button
feedback
screen
database
retrieve
memory
content
location
vaccine
name
sickness
doctor
surname
ram
disk

Interpretation Comparison
system
storepatient
data
button
feedback screen
database
retrieve
memory
content
location
vaccine
name
sickness
doctor
noise
return
health
duration
care
9
10
5
9
9 + 10 + 5
σ = = 0.38 ="#< 0.5
AMBIGUITY
surname
ram
disk

Further Readings
Gunter, Carl, et al. “A reference model for requirements and speciﬁcations.” Requirements
Engineering, 2000. Proceedings. 4th International Conference on. IEEE, 2000.
Jackson, Michael. “The meaning of requirements.” Annals of Software Engineering 3.1
(1997): 5-21.
Zave, Pamela, and Michael Jackson. “Four dark corners of requirements engineering.”
ACM transactions on Software Engineering and Methodology (TOSEM) 6.1 (1997): 1-30.
Berry, Daniel M. "From contract drafting to software speciﬁcation: Linguistic sources of
ambiguity-a handbook version 1.0." (2000).
Gleich, Benedikt, Oliver Creighton, and Leonid Kof. “Ambiguity detection: Towards a tool
explaining ambiguity sources.” Requirements Engineering: Foundation for Software
Quality. Springer Berlin Heidelberg, 2010. 218-232.
Van Lamsweerde, Axel. "Goal-oriented requirements engineering: A guided tour."
Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on.
IEEE, 2001.
Ferrari, Alessio, Paola Spoletini, and Stefania Gnesi. "Ambiguity and tacit knowledge in
requirements elicitation interviews." Requirements Engineering Journal (REJ), Springer,
2016.
Ferrari, Alessio, Stefania Gnesi. "Using collective intelligence to detect pragmatic
ambiguities." Requirements Engineering Conference (RE), 2012 IEEE 23rd International.
IEEE, 2012.

Ambiguity in Software Engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Ambiguity in Software Engineering

Similar to Ambiguity in Software Engineering (20)

More from alessio_ferrari

More from alessio_ferrari (9)

Recently uploaded

Recently uploaded (20)

Ambiguity in Software Engineering