2.6.1 Artefacts supported
The following table (Table 2-1) shows the coverage of imperfect information support in terms of the artefacts supported by the approaches surveyed.
Requirements Relations btw requirements
Soft. development process (sources, artefacts, method_
logical, rules, decisions)
Yen93 and Lee03 x x
Liu96 x x
Tekinerdoğan03 x
Akşit01, Marcelloni01,
Marcelloni04 and Marcelloni04a
x
Noppen07 x x
Kiyavitskaya08 and Gleich10 x
Chantree06 and Yang11 x
NFRF x x x
VIM x x
Preview x x
Weston09 and Sardinha09 x x
Table 2-1 Artefacts supported by the approaches studied.
The approaches studied are divided essentially in two groups: the ones that focus more on the RE phase and thus support this phase artefacts: requirements and relationships between them; and the ones that work with the software development process supporting issues such as quality of knowledge sources, the decisions concerning, for instance, the classification of artefacts together with the associated inconsistencies.
77
2.6.2 How imperfection is supported, what for and with what user interaction
The following table (Table 2-2) shows, for each work surveyed the SE activity supported, and type of support provided concerning imperfect information. It also shows the technique used, and the type of user interaction provided.
SE activities and type of support Technique User interaction Yen93 and
Lee03
RE: model vague requirements;
exploration of trade-offs among vague requirements; identify and classify relations btw requirements
Fuzzy logic Not implemented
Liu96 RE: model imprecise
requirements; derivation of the classification of relationships between imprecise requirements, but from relationships already identified and classified
Fuzzy logic Not implemented
Tekinerdoğan03 Development process: evaluation of domain knowledge sources
Fuzzy logic Not implemented
Akşit01, Marcelloni01, Marcelloni04 and
Marcelloni04a
Development process: model and handle inconsistencies (not obeying consistency constraints) in development decisions.
Fuzzy logic Not implemented
Noppen07 RE: model multiple interpretations of ambiguous requirements Development process: support the tracing between the FR and the components that implement it;
support quality estimations for NFR; support analysis of designs based on different trade-offs
Fuzzy logic and probability theory
Directed graph structure, tree structure and textual descriptions
Kiyavitskaya08 and Gleich10
RE: identification of potentially ambiguities, computes the level of ambiguity of each case, and shows what is potentially ambiguous
Gleich10: adds ‘why’ explanation, for every ambiguity detected
Natural language processing
Tool showing the identified ambiguities and other computed information
Gleich10: the tool is web-based
Table 2-2 SE activities, types of support, technique used and user-interaction provided by the approaches studied.
78
SE activities and type of support Technique User interaction Chantree06 and
Yang11
RE: ambiguity classification into nocuous and innocuous; identify the potential dangerous ambiguity cases
Corpus-based statistics information and machine learning
Chantree06: not implemented
Yang11: classifier, which notifies authors that text may lead to
misunderstandings NFRF RE: detection of conflict – through
detection of negative contributions of both explicit and implicit
interdependencies among softgoals;
help detect ambiguity through refining or operationalizing of softgoals; record the developer consideration of soft goals and his decisions
RE goal-oriented approach
Diagram-based visualization;
not implemented: it’s a methodological proposal
VIM RE: detection of conflict through detection of inconsistency in the rules defined for a notation; inconsistency management
RE viewpoint -oriented approach
Frame-based visualization with text , tables, and diagrams
Preview RE: identification of conflicts, through the notion of viewpoint focus – requirements belonging to viewpoints whose foci intersect; selection of the most problematic requirements – the ones with higher numbers of conflicts and overlaps
RE viewpoint -oriented approach
Not implemented: it’s a methodological proposal
Weston09 RE: identification of conflict using the logical conjunction of the formalisation of semantics-based compositions, in particular temporal overlap between compositions
RE aspect-oriented approach
Not implemented:
proposal for implementation steps
Sardinha09 RE: identification of conflict – 1st structuring requirements using semantics-based composition; 2nd applying a Bayesian learning method to classify text, retrieving the probability of a word belonging to the conflict class
RE aspect-oriented approach and Bayesian learning method
Table-based interface showing the list of words and its associated probabilities for being classified as conflict or harmony.
Table 2-2 (cont.) SE activities, types of support, technique used and user-interaction provided by the approaches studied.
In a first group of works [Yen93, Lee03, Liu96, NFRF, VIM, Tekinerdoğan03, Akşit01, Marcelloni01, Marcelloni04, Marcelloni04a, and Noppen07]) the focus is to set up mathematical foundations (using fuzzy logics, probability theory, and other RE
79 models) to integrate imperfect information in the artefacts (e.g. requirements, architectural components). It is upon these mathematical foundations that additional formalisms (e.g. graphs, trees) are built to support imperfection handling and decision (in the face of imperfection). These approaches are designed to provide support for software engineers in activities where the communication and interaction with tools is technical. In fact, in these approaches, the information about the imperfection is
“coded” in the formalisms, which requires that software engineers are knowledgeable in the formalisms. This can raise questions about ease of use, even for software engineers.
This thesis proposes a separation between the mechanisms for identifying and collecting the information about the imperfection in requirements, from the communication mechanism. Such a separation enables to choose a communication mechanism much more adequate to the RE tasks, than the formalisms proposed by the first group of works, described in this Chapter.
In the second group of works for ambiguity and conflict detection [Kiyavitskaya08, Gleich10, Chantree06, Yang11, Weston09, Sardinha09], the focus is to identify and sometimes also manage ambiguity and/or conflict, and to provide this information as lists of pieces of text with probable ambiguity or conflict cases. Usually the output incudes more characteristics such as a value of probability for that imperfection, and in some cases even explanations for the notification of possible imperfection presence.
The fact that these works present the identified ambiguities and conflicts as text lists, make them the “perfect” tools/approaches (in the current state-of-the-art) to integrate into an approach to identify and handle imperfection in RE, together with a communication mechanism that can be separately developed to be the most appropriate both for software engineers and stakeholders.
80