Requirements Engineering: focus on Natural Language Processing, Lecture 1

Requirements Engineering:
focus on Natural Language
Requirements Processing
Alessio Ferrari1
1ISTI-CNR, Pisa, Italy
January 13, 2016
A. Ferrari (ISTI) Requirements Engineering 1 / 76

Objectives of the Course
Objectives: lesson 1
Understand what are requirements, speciﬁcations
and domain assertions
Understand the problems behind requirements elicitation
and SRS deﬁnition
Learn how to write a decent SRS
Objectives: lesson 2
Learn the basics of Natual Language Processing (NLP)
Learn the relation between NLP and Requirements
Learn the basics of GATE to detect NL ambiguities in
requirements
Learn the basics of Python NLTK (for further manipulation of NL
requirements)

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 Process (Revision)

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

Requirements Elicitation: Ambiguity Problems

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

Interviews
Requirements AnalystCustomer

Tacit Knowledge
Tacit Knowledge

Ambiguity
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(k )∧
(¬ACCESSIBLEa,i(k) ∨ interpretablea,i(k ))
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 k
Let us focus on the second line of the equation, which is:
¬interpretablea,i(k) ∨ ¬acceptablea,i(k)∨
interpretablea,i(k )

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

Unclarity
INTERPRETATION
ACCEPTANCE
SPEECH
FRAGMENT
ACCESS
Requirements
Goals
Domain
Speciﬁcation
k k'
k
kCONCEPT
?
¬ACCESSIBLEa,i(k) ∧ ¬interpretablea,i(k )

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 fee”

INTERPRETATION
ACCEPTANCE
SPEECH
FRAGMENT
ACCESS
Requirements
Goals
Domain
Speciﬁcation
k k'
k k'
kCONCEPT
k'k
ACCESSIBLEa,i(k) ∧ ACCESSIBLEa,i(k )

Example
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?)

Incorrect Disambiguation
INTERPRETATION
ACCEPTANCE
SPEECH
FRAGMENT
ACCESS
Requirements
Goals
Domain
Speciﬁcation
k k'
k
kCONCEPT
k'?
¬accessiblea,i(k) ∧ interpretablea,i(k )

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

Correct Disambiguation
INTERPRETATION
ACCEPTANCE
SPEECH
FRAGMENT
ACCESS
Requirements
Goals
Domain
Speciﬁcation
k k'
k
kCONCEPT
k
k'
ACCESSIBLEa,i(k) ∧ interpretablea,i(k ) ∧ ¬acceptablea,i(k )

Re-deﬁnition of strict-Ambiguity
Let us exclude Correct Disambiguation:
ambiguous-stricti(k) = articulatedc,i(k) ∧ ¬articulatedc,i(k )∧
(¬ACCESSIBLEa,i(k) ∨ interpretablea,i(k ))∧
¬(ACCESSIBLEa,i(k) ∧ interpretablea,i(k ) ∧ ¬acceptablea,i(k ))

Your Turn!
I am pretending to be the owner of a gym, and I’m coming to you
to build a smart gym
5 minutes to prepare some questions
Interview me, keeping in mind ambiguity issues and tacit
knowledge
Keep in mind that you have to elicit both R and D
Hence, identify potential users, objects and principles in the
domain
Take notes
Be careful that you’re speaking to someone who is not a software
engineer

Requirements Analysis (Hints and References)

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

Templates for your exercise

FORMAT1. The system [shall|should] be able to < capability >
(Il sistema [deve|dovrebbe] essere in grado di <capacità>)
Example: The system shall be able to monitor the number of cars
in the parking
This format is also employed in case of statements that involve
mandatory (shall) or optional (should) functionalities, which are
unconditional and independent from the actions of the
operators.
Statements of this type are normally associated to interface
functions, internal procedures, or procedures that manage internal
data structures.

FORMAT2. The system [shall|should] allow the < user > to < action >
(Il sistema [deve|dovrebbe] permettere a <utente> di <azione>)
Example: The system shall allow the car driver to pay the parking
This format is employed in case of statements that involve
mandatory (shall) or optional (should) functionalities, which are
unconditional and dependent from the actions of the operators.

FORMAT3. The system [shall|should] < action >, [when|after|before|if]
< condition > {, [when|after|before|if] < condition >}
(Il sistema [deve|dovrebbe] <azione>, [quando|dopo|prima|se]
<condizione> {,[quando|dopo|prima|se] <condizione>})
Example. The system shall release the receipt, if the car driver
has payed the required amount
This format is employed when the action depends on one or more
conditions.
All conditions are considered in a logical AND relationship. If we
want to express logical OR among conditions, it is recommended
to add a new requirement or speciﬁcation.

FORMAT4. [FORMAT1|FORMAT2|FORMAT3], < procedure >
Example. The system shall signal the unavailability of receipts,
before the user inserts coins, through a message on the screen
This format is employed to specify functionalities that have an
associated procedure, or that are performed through a
well-deﬁned interface device.
The format shall be used when it is useful to explain HOW the
system is expected to perform a certain action.

Your Turn!
Write (part of) R, S for the smart gym following the templates
Write D in NL without templates, in a rigorous language
You can use the same template for R and S, the only difference
resides in the vocabulary that you use
If you speak only about elements in the interface, then it is S
If you speak about elements in the environment and (optionally)
about elements in the interface, then it is R
While you write a new entity or action, store it in the vocabulary
and tell if it belongs to the interface or to the environment
You have 30 minutes
Hints
Hint 1 identify interfaces, users, and main functions of your system
Hint 2: try to list as many R as possible; select one; write S for that;
state the D that are needed to satisfy R
Hint 3: if needed, partition the system into sub-systems

Examples
R, S, D
R1: (F1) The system shall be able to monitor the workout of the
customer
R2: (F2) The system shall allow the trainer to visualise the
workout of the customer
S1: (F1) The system-CentralUnit shall be able to store the data
coming from the wrist-band of the customer
S2: (F3) The system-UI shall visualise the workout plot of the
customer, when the trainer presses the button B, if the system-UI
is in Page P.
D1: Each customer is equipped with a wrist-band
D2: The wrist-band records the data concerning the workout of
the customer

Summary of the Templates
F1: The system [shall|should] be able to < capability >
(unconditional user-independent capability)
F2: The system [shall|should] allow the < user > to < action >
(unconditional user-dependent action)
F3: The system [shall|should] < action >, [when|after|before|if] <
condition > {, [when|after|before|if] < condition >} (conditional
action)
F1|F2|F3, < procedure > (if I have to tell HOW)

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

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 as a resource to disclose
tacit knowledge." Requirements Engineering Conference (RE), 2015 IEEE 23rd
International. IEEE, 2015.

TODO: for next lecture
Mandatory:
Provide me your e-mail address to have the material:
alessio.ferrari@isti.cnr.it
Download GATE Developer:
https://gate.ac.uk/download/ (VERSION 8.0)
Make sure that it works (. . . open the application)
Optional:
Download and Install Python 2.7.5
(https://www.python.org/download/releases/2.7.5/)
Download and Install Python NLTK
(http://www.nltk.org/index.html)

Requirements Engineering: focus on Natural Language Processing, Lecture 1

More Related Content

Similar to Requirements Engineering: focus on Natural Language Processing, Lecture 1 (20)

More from alessio_ferrari (8)

Recently uploaded (20)

Requirements Engineering: focus on Natural Language Processing, Lecture 1