16 февраля, в 16:00 по Москве на очередном исследовательском семинаре об искусственном интеллекте и тестировании. Елена Трещева и Дарья Дегтяренко представят научную работу «От составления контракта до спецификации программного обеспечения: Языковые источники неоднозначности».
На семинаре мы:
-рассмотрим подробную классификацию типов неоднозначности, которой склонны обладать тексты, написанные на естественном языке,
вместе проанализируем много примеров неоднозначности, а также
-поговорим о конкретных рекомендациях по снижению степени неоднозначности в текстах спецификаций и контрактов.
Подписывайтесь на Exactpro в социальных сетях:
Подписывайтесь на YouTube канал Exactpro http://www.youtube.com/c/ExactproVlog
Build Software to Test Software
From Contract Drafting to
Linguistic Sources of Ambiguity
2 Build Software to Test Software
Daniel M. Berry, Ph.D.
University of Waterloo, Canada
Erik Kamsties, Ph.D.
University of Essen, Germany
Michael M. Krieger, Ph.D.
University of California, Los Angeles
Meet the Authors
3 Build Software to Test Software
"Please press ANY key to continue..."
4 Build Software to Test Software
Don Gause lists the five most
important sources of
requirements failure as:
- failure to effectively manage
- lack of clear statement of the
design problem to be solved,
- too much unrecognized
- not knowing who is
responsible for what, and
- lack of awareness of
5 Build Software to Test Software
Linguistics vs Pragmatics
–“Interestingly, correct use of the natural
language eliminates most of the ambiguities”.
Two people who know the rules well or two
people who don’t know the rules well tend to
But one person who knows the rules well and
one person who doesn’t tend to communicate
→ Pragmatic Ambiguity
6 Build Software to Test Software
2 Commonalities and Differences
1. the requirement to be precise and accurate, to be self-consistent, and to
anticipate all possible contingencies, and
2. the fact that most such documents are written mostly in natural language.
Beyond these commonalities there are commonalities and differences in the
contents and structure of the documents and in the processes by which the
documents are generated and maintained.
There are commonalities and differences in how the documents are generated
7 Build Software to Test Software
Four Classes of Linguistic Ambiguity
8 Build Software to Test Software
3.3.1 Lexical Ambiguity
Lexical ambiguity – a word has several meanings.
Homonymy – different words have the same written and
phonetic representation, but unrelated meanings and different
etymologies, i.e., different histories of development.
Bank (riverside, ﬁnancial institution), dull (boring, idle), etc.
Polysemy – a word has several related meanings but one etymology. Systematic polysemy
occurs when the reason for the polysemy is confusion between classes, e.g., between unit and
type, and between process and product .
Unit-vs.-type ambiguity - I like this jacket.
Process-vs.-product ambiguity occurs with everyday words like building, shot, and writing.
Behavior-vs.-disposition ambiguity. - This is a fast car.
9 Build Software to Test Software
3.3.2 Syntactic Ambiguity
Syntactic ambiguity, also called structural ambiguity, occurs
when a given sequence of words can be given more than
one grammatical structure = a sentence has more than one parse.
1. Analytical ambiguity occurs when the role of the constituents within a phrase or
sentence is ambiguous.
The Tibetan history teacher.
2. Attachment ambiguity occurs when a particular syntactic
constituent of a sentence, such as a prepositional phrase
or a relative clause, can be legally attached to two parts of
The police shot the rioters with guns.
10 Build Software to Test Software
Syntactic Ambiguity (c’ed)
3. Coordination ambiguity occurs
1. when more than one conjunction, and or or,
is used in a sentence (I saw Peter and Paul and Mary) or
2. when one conjunction is used with a modifier (young man and woman).
4. Elliptical ambiguity occurs when it is not certain
whether or not a sentence contains an ellipsis.
Perot knows a richer man than Trump.
11 Build Software to Test Software
3.3.3 Semantic Ambiguity
Semantic ambiguity – a sentence has more than one way of
reading it within its context although it contains no lexical or
structural ambiguity. Ambiguity with respect to the logical form,
usually expressed in predicate logic, of a sentence.
Semantic ambiguity can be caused by:
1. coordination ambiguity,
2. referential ambiguity, and
3. scope ambiguity.
The quantiﬁer operators include such words as every, each, all, some, several, a, etc., and the
negation operators include not.
All linguists prefer a theory.
No one has seen a pig with wings.
12 Build Software to Test Software
3.3.4 Pragmatic Ambiguity
Pragmatics is the study of the relations between language
The trucks shall treat the roads before they freeze.
... If the ATM accepts the card, the user enters the PIN. If not, the card is rejected.
Every student thinks she is a genius.
13 Build Software to Test Software
3.3.5 Vagueness and Generality
Sue is visiting her cousin.
We ﬁnally reached the bank.
A requirement is vague if it is not clear how to measure whether the requirement is fulﬁlled or
not. A non-functional requirement, e.g., fast response time, is often vague, because there is no
precise way of describing and measuring it, short of arbitrary quantiﬁcation, which leaves us
wondering if the essence of the requirements have been captured.
The only difference between vagueness and generality is the existence of borderline cases.
14 Build Software to Test Software
3.3.6 Language Error
A language error ambiguity occurs when a grammatical,
punctuation, word choice, or other mistake in using the
language of discourse leads to text that is interpreted by
a receiver as having a meaning
other than that intended by the
Every light has their switch.
Everybody brings their lunch.
All lights have their switch.
All lights share their switch.
Each light has its own switch.
15 Build Software to Test Software
- Section 1 - Intro & nature and sources of ambiguity
- Section 2 - Requirements vs legal texts
- Section 3 - Types of ambiguity:
16 Build Software to Test Software
4 - Techniques for Dealing with Ambiguity
Three groups according to the requirements engineering activities:
- Requirements elicitation
- Requirements documentation
- Requirements validation
17 Build Software to Test Software
For requirements elicitation, at least two strategies can be distinguished to
- First, a context must be established, because language is interpreted always in
context, and if this context is not made explicit and agreed to by all the
stakeholders in an elicitation session, misinterpretations are likely.
- Second, the requirement engineer’s paraphrasing what she understood from
the customers’ and users’ statements in her own words is an effective way for
the requirements engineer to get the customers and users to spot their own
18 Build Software to Test Software
For requirements documentation, at least three strategies can be distinguished to
- Increasing the precision of natural language
Glossaries, style guides, sentence patterns, and controlled languages;
- Providing more context information
Comments, rationales, ﬁt criteria, test cases, inverse requirements, and
- Setting up conventions for interpretation
19 Build Software to Test Software
For requirements validation, at least four strategies can be distinguished to detect
- Formalization of informal requirements
- Searching for particular patterns of ambiguity
- Comparing the interpretations of a document by different stakeholders
- Сommunicating an interpretation back to the requirements author, after which
she can easily point out misinterpretations.
20 Build Software to Test Software
5 - Avoiding Ambiguities in Natural Language
Speciﬁcations and Contracts
This section covers a variety of common linguistic, lexical, structural, scope, referential, and
language-error ambiguities that appear in both requirements speciﬁcations and legal
In each case, we
1. give a succinct example of a general problem,
2. give common solutions to the general problem, applied to the succinct example,
3. describe drawbacks of the common solutions,
4. offer a correct solution to the general problem, again applied to the succinct example.
21 Build Software to Test Software
Ambiguous, Vague, and Uncertain Words
and, any, or
after, before, next, previous, etc.
minimum and maximum
a large number of adjectives and adverbs: acceptable, accurate, appropriate, easy, eﬃcient,
essential, immediately, minimum, maximum, periodically, suﬃcient, user-friendly, etc.
also verbs and nouns can be vague: support, handle, process, reject, use, etc. and user.
uncertainty is expressed using words such as not limited to, etc., can, may, probably,
possibly, usually, etc.
22 Build Software to Test Software
all, each, every
a, all, any, each one, some, and the as quantiﬁers
many and few
only, also, others
23 Build Software to Test Software
- Adjectives and other modiﬁers: English grammar teacher
English, i.e., British, teacher of grammar, not necessarily English grammar
teacher of English grammar, with the teacher’s nationality left unspeciﬁed
- Pronoun references: Bob said to Joe that he must leave
- This and Whole Ideas: this that refers to a whole idea vs. this referring to a speciﬁc noun
- Not and because
- And and or in the same sentence
24 Build Software to Test Software
- Assumed parallelism:
Shoes must be worn. Dogs must be carried.
- Than and Different From and Parallelism:
Cleveland is closer to Philadelphia than New York.
The method used for coding is different from structuring.
25 Build Software to Test Software
- Quoted Word vs. Denotation
- Time Expressions
- Ambiguity Even in Formalism!!!
26 Build Software to Test Software
6 - Examples
27 Build Software to Test Software
7 - Writing guides
- General writing
- Technical writing
- Requirements speciﬁcation writing
- Legal document writing
- Guidelines on avoiding and ﬁnding ambiguities
28 Build Software to Test Software
8 - Conclusion
Even with all the systematic techniques and modeling, avoiding and detecting ambiguities
is at best an art.
Fundamentally and ultimately, an ambiguity is anything that causes different people to
understand differently; unfortunately, the set of people that happen to examine a document
may just not have a person that detects an understanding that demonstrates an ambiguity.
Therefore, it will be necessary to improve our skills at avoiding and detecting ambiguities.
We need to teach lawyers and requirements engineers to write unambiguously.
We need to teach lawyers and requirements engineers to spot hidden ambiguities.
29 Build Software to Test Software
- Types of ambiguity (what to expect from the text written in natural language)
- Techniques to deal with ambiguity (metatextual components of documentation)
- Techniques to avoid ambiguity (inventorization of typically “weak” places)
Assessment of the task ahead
- Multiple linguistic levels
- “Artistic” nature of the skill needed for the task
30 Build Software to Test Software