Information Technology Reference
In-Depth Information
have a choice of implementing the task “KeywordSearch[product]” to address
the “Accuracy” concern.
In a similar vein, identifying subconcept-superconcept relations in the con-
cept lattice can help to perform trade-off analysis on concrete tasks. In the media
shop case, for instance, the “SSL[protocol]”-labeled concept is a subconcept of
the “PasswordProtection[account]”-labeled one, which implies that in addition to
all the concerns that “PasswordProtection[account]” addresses, “SSL[protocol]”
has (negative or positive) contributions to other softgoals. If these two are com-
petitive tasks for the software system to implement, we may start analyzing the
concerns that are uniquely linked to “SSL[protocol]”, and neglecting the com-
monly shared, identically contributed softgoals by both tasks. If our goal is to
satisfice as many softgoals as possible, 3 based on the context of Fig. 13, we
may choose to include “PasswordProtection[account]” in our architectural de-
sign, because “SSL[protocol]” contributes “Learnability” and “Usability” nega-
tively, and these two tasks have exactly the same contribution relationships to
the rest of the softgoals in the context. Such analysis helps the analyst to specify
preferences and priorities on (aspectual) requirements.
Conflicting candidate aspects in the context can be detected by using the
concept lattice. In our setting, one way is to start with softgoals of stakeholder
interests that form a subconcept-superconcept relationship. If they have differ-
ent signs, i.e., one labeled with “
” and the other labeled with “+”, then we
note them as potential conflict. For example, in Fig. 14, “
Performance” is a
superconcept of “+Confidentiality”. We mark them as potential conflict since all
the tasks that help to fulfill “Confidentiality” will negatively affect media shop's
“Performance”.
Another way of detecting conflicting concepts is to treat the formal context,
such as the one in Fig. 13, as a distance matrix. If the distance between two
softgoals is small with respect to some threshold, and they have different signs
(“+” versus “ ”), then there is a potential conflict between them. This conflict
detection method has a similar flavor to the RGT-based hierarchical cluster
analysis described in Sect. 3.2, in that both methods examine how different
softgoals align a common set of tasks.
In order to perform the trade-off and conflict analyses mentioned above, a
query language or some line diagram slicing algorithms shall be provided to
facilitate the analyst to select and project interested (clustered) concepts in the
concept lattice. However, these features are not yet available for most FCA-
based analysis tools [2, 48]. Our early aspects analysis suggests the need for
improvement in some areas of FCA tool support.
4.3 Discussion
We have applied FCA for conflict detection and trade-off analysis on early as-
pects in requirements goal models, and have seamlessly incorporated this FCA-
based method with the PCT- and RGT-based early aspects alignment method
3 This criterion is intuitive, since softgoals may contradict each other. We will show
the FCA-based conflict detection method later in this section.
Search WWH ::




Custom Search