Designing a persistent online strategy game - Department of ...

18 Chapter 3. Requirements engineering with non-functional requirements
3.3.3 Evaluation procedure
When a softgoal interdependencies graph has been established it is time to determine
whether or not the top requirements are satisfied. This is done by taking a proposal for a
design, or feature, and using the evaluation procedure to see how that design would affect
the rest of the system. These decisions are generally “leaf” nodes in the graph. What is
done is that the node gets a label applied to it and the procedure could then be seen as
an algorithm that “calculates” what consequences this has. The label describes to what
extent a node has been satisficed, typically the label should be denied or satisficed though
there are more labels which will be introduced later. When a label has been applied to a
leaf-node the interdependency towards its parent then determines how the label should
be propagated upwards. If for example the “Validation[GoldAccount.highSpending]”
softgoal (as seen in Figure 3.6) would be labelled satisficed the MAKE contribution
towards its parent would result in the parent also being satisficed (though there could be
a conflict if the softgoal “FlexibleUserInterface...” also would be satisficed). This process
then continues until all nodes upwards are calculated. This is not enough however as
uncertainties and conflicts might appear in the graph. To handle this four basic labels
are introduced. These labels are (the graphical representations to be used in the softgoal
interdependencies graphs are shown in Figure 3.7):
– Satisficed (S) - denotes a goal or link that is satisficeable and not deniable.
– Denied (D) - denotes a goal or link that is deniable and not satisficeable.
– Conflicting (C) - denotes a goal or link that is both satisficeable and deniable.
– Undetermined (U) - denotes a goal or link that is neither satisficable nor deniable.
There is however also the possibility that a softgoal might have some support, but not
enough, for it to be either satisficed or denied. If only the previously mentioned labels
were used that would result in the softgoal being undetermined, but it would be better
if the developer could step in and determine if the softgoal actually was satisficed or
not. Therefore two more labels are introduced:
– Weak positive (W+) - represents positive, but inconclusive support
– Weak negative (W-) - represents negative, but inconclusive support
These labels should however be replaced by one of the four basic labels by the developer
and thus not be present in the graph when the procedure is finished (they should not
contribute to the parent label either). In case of the “conflicting label” the developer
can also step in and determine the label that should contribute to its parent.
There is also the issue of how the labels should be propagated through the graph. When
a satisficed label should be propagated through MAKE or BREAK contributions it is
pretty straight forward, but if the label is denied or undecided or if the contribution is
of another type it becomes more difficult. Table 3.1 shows how different labels should
be propagated through various types of contributions.