QuARS (Quality Analyzer for Requirements Speci cations) is a tool able to perform an analysis of Natural Language (NL) requirements in a systematic and an automatic way by means of natural language processing techniques with a focus on ambiguity detection. QuARS allows the requirements engineers to perform an early analysis of the requirements for automatically detecting potential linguistic defects.
QuARS performs a linguistic analysis of a requirement document in plain text format and points out the sentences that are defective according to the expressiveness quality model according to the process depicted in Figure 1.
The defect identi cation process is split in two parts: (i) the "lexical analysis" capturing optionality, subjectivity, vagueness, and weakness defects by identifying candidate defective words that are identi ed into a corresponding set of dictionaries; and (ii) the "syntactical analysis" capturing implicity, multiplicity and underspeci cation defects.
Optionality means that the requirement contains an optional part (i.e. a part that can or cannot be considered) and example of Optionality-revealing words are: possibly, eventually, in case, if possible, if appropriate, if needed, . . . .
Subjectivity means that the requirement expresses personal opinions or feelings, i.e. similar, similarly, having in mind, take into account, as [adjective] as possible,. . . .
Vagueness means that the requirement contains words having a no uniquely quanti able meaning and example of Vagueness-revealing words are: adequate, bad, clear, close, easy, far, fast, good, in front, near, recent, signi cant, slow, strong, suitable, useful, . . . .
Weakness means that the sentence contains a "weak" verb. A verb that makes the sentence not imperative is considered weak (i.e. can, could, may, . . . ).
Implicitly means that the requirement does not specify the subject or object by means of its speci c name but uses a pronoun or other indirect reference. Demonstrative adjectives (this, these, that, those) or Pronouns (it, they...) or terms having the determiner expressed by a demonstrative adjective (this, these, that, those) or implicit adjective (i.e. previous, next, following, last...) or preposition (i.e. above, below...) are considered implicity indicators.
Multiplicity: the occurrence of multiplicity-revealing terms: and/or, or, ... is considered a multiplicity indicator, as well as the presence of itemized lists.
Under-speci cation means that the requirement contains a word identifying a class of objects without a modi er specifying an instance of this class. The occurrence of wordings needing to be instantiated (i.e. information, interface, that must be better de ned, ow instead of data ow, control ow, access instead of write access, remote access, authorized access, testing instead of functional testing, structural testing, unit testing, etc.) is considered an under-speci cation indicator.
Negative Examples the system shall be.., possibly without.. ..in the largest extent as possible.. the C code shall be clearly commented.. the initialization checks may be reported.. the above requirements shall be veri ed.. the mean time..and restore service..
..be able to run also in case of attack.
In Table 1 we can see some examples of requirements that contain linguistic defects.
When the analysis is performed, the list of defective sentences is displayed by QuARS and a log le is created.
The defective sentences can be tracked in the input requirements document and corrected, if necessary. Metrics
measuring the defect rate and the readability of the requirements document under analysis are calculated and
stored. The available metrics are the Coleman-Liau Formula readability metrics [
Ambiguity defects that are found in a requirements document may be due to, intentional or unintentional,
references made in the requirements to issues that may be solved in di erent ways, possibly envisioning a set of
di erent products rather than a slngle product. We therefore can use the analysis ability of QuARS to elicit
the potential variability hidden in a requirement document. Variability may be due to vagueness and vagueness
occurs whenever a requirement admits borderline cases, e.g., cases in which the truth value of the sentence
cannot be decided since vague terms are used in it. QuARS allows the creation of new dictionaries useful for
de ning new indicators characterising potential variability in requirements. Variability may be revealed by the
occurrence of variability-revealing terms such as: if, where, whether, when, choose, choice, implemented,
implement, implements, provided, provide, provides, available, feature, range, select, selected, selects, con gurable,
con gurate, . . . [
The QuARS GUI is composed of three main frames. The Input Frame that allows to load, display and edit input le containing the requirements to be analyzed (the supported le format is plain text). The Dictionary Frame that allows the user to select, display and edit the dictionary corresponding to the type of analysis of interest. The Output Frame where the results of the analysis are displayed. Figure 2 shows the QuARS GUI. Figure 3 reports the output of an analysis performed according to the vagueness criterion. 2
QuARS: Application Experiences
QuARS has evolved from an initial prototype to the current reliable and user-friendly version after subsequent
experiments over several case studies aimed at evaluating the e ectiveness of the methodology and identifying
improvement opportunities in terms of both usability and provided functionalities. Some of the case studies [
In [?, 10] QuARS has been instead used to study a classi cation of the forms of ambiguity that indicate variation points starting from the analysis of documents describing real systems, since ambiguity or underspeci cation at requirements level can in some cases give an indication of possible variability, either in design choices, in implementation choices or con gurability.
All these experiments provided us with feedbacks to evolve the tool itself, and allowed us to gather a record of information on the:
E ectiveness of the tool in nding defects: the number of defects found in the NL requirement document depends more on the experience and skill of the requirements engineer than on the company maturity. Frequency and typology of false positives: the presence of false positives has been observed in every case study. It can be considered as a physiological side e ect of the application of the tool. The rate of false positives respect to actual defects has been rarely over 10%.
E ort required to apply the tool and to tailor the dictionaries for speci c application: the e ort required to perform the analysis of a requirements document is relatively low. The main e ort is due to the preparation of the input document since this has to be in plain text format.
This work was partially supported by the H2020 Shift2Rail project AstRAIL.