Information Technology Reference
In-Depth Information
4.3
Lessons Learned
The specification problems that were detected by our subjects were highly different
from the problems addressed by the automatically generated questions. The problems
most often marked by the human analysts were pertinent to unclear phrasing. The auto-
matically generated questions, to the contrary, addressed missing specification pieces.
For example, our subjects marked following phrases as problematic:
- For the Steam Boiler Specification:
•
“Once all the units which were defective
have been repaired
, the program
comes back to normal mode.”
Evaluator's comment: how is it detected that all the units have been repaired?
•
“...when either the
vital units
havea failure...”
Evaluator's comment: which units count as “vital”?
“
As soon as
the water measuring unit is repaired...”
Evaluator's comment: what does “as soon as” really mean?
- For the Instrument Cluster Specification:
•
•
“...and the instrumentcluster
is activated temporarily
.”
Evaluator's comment: by whom is the instrument cluster activated? And what
does “temporarily” really mean?
•
“The system displays the
calculated speed
”
Evaluator's comment: how is the speed calculated?
•
“The input signals from the motor
are sent regularly
”
Evaluator's comment: to which component are they sent? And what does “reg-
ularly” mean?
These phrases are indeed problematic if we want to build a system model, but they
represent fuzzy specification, not completely missing facts.
In order to address such fuzzy phrasings, it makes sense to apply the previously de-
veloped tool that detects poor phrasings [9]. In its current version, the tool detects poor
phrasings listed in the Ambiguity Handbook [10]. Adding further patterns for prob-
lematic phrases, however, is a matter of minor extension of the configuration files. An
integrated tool, detecting both missing specification pieces (as in the presented paper)
and poor phrasings, would provide a reliable means of specification analysis.
5
Related Work
Work related to the presented paper can be subdivided in two areas: work on text-based
modeling and work on natural language processing (NLP) in requirements engineering.
Both areas are presented below.
5.1
Text-Based Modeling
Saeki at al. [11], Overmyer et al. [12], and Ermagan et al. [13] introduced tools provid-
ing modeling approaches. The approach by Saeki et al. allows the user to mark words in
the requirements documents, and then to assign the marked word to some noun or verb
