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

14 Chapter 3. Requirements engineering with non-functional requirements
at one time and unaccomplished at another time. An example of this could be that a
system might have great response time when just a few users are using it, but become
slow if many users interact with it at the same time. Yet another problem is that NFRs
are relative, that is, they can be accomplished to different degrees (for example an
accurate system or a very accurate system). Because of these kinds of difficulties with
determining whether a NFR is accomplished or not, the notion of softgoals is introduced
in the NFR framework. Softgoals, as opposed to ordinary goals, do not have to have
any specific criteria as to whether or not it is satisfied. Instead they can be evaluated
qualitatively. Therefore the word “satisficing”, meaning that something is satisfactory
to a sufficient degree, is used instead of “satisfying”.
The NFR framework presents three types of softgoals [41, 8]. Each of which has an
associated type and a number of topics (one or more). The type describes what the goal
is about and the topics define what it actually implies. For example: a softgoal to have
good performance for a system would be of the type “performance” and have the topic
“system” (generally the declaration would be as follows: “Performance[System]”). The
three different softgoals, all of which appear in the softgoal interdependency graphs, are:
– Non-functional requirements softgoals These describe the general NFRs and
the types thus range over all the types that non-functional requirements can be
(for example, accuracy, performance, security and so on). These work as global
constraints on the system as they can have an impact on the entire system rather
than just small parts. Later the NFR softgoals must be satisficed by the operationalizing
goals.
– Operationalizing softgoals The operationalizing softgoals declare solutions as
to how to satisfice the NFR softgoals. For example: to satisfice a NFR softgoal
stating that an operation cannot take longer than a certain amount of time, an
operationalizing softgoal might state that the operation should be cancelled if the
time limit has been exceeded (this might not be a good solution, but nonetheless
it would satisfice the NFR softgoal). These softgoals also have types and topics in
the same way that NFR softgoals has.
– Claim softgoals These softgoals are always of the type “Claims” and their topics
are “statements” in the form of declaring arguments. They can be both formal and
informal and an informal claim with an argument for choosing a certain solution
might for example look like this: Claim[“data storage performance is more vital
than time performance”]. Thus they represent design rationale as they serve as
argumentation for different solutions.
All of these softgoals can, and really are encouraged to, in turn be refined by forming
subtypes that specifies special cases of the original softgoal. The refinement of softgoals
is called decomposition. More specifically: NFR decomposition, operationalization
decomposition and argumentation decomposition (for NFR softgoals, operationalizing
softgoals and claim softgoals respectively). The softgoals are represented by different
figures in the softgoal interdependencies graphs, these figures along with examples are
shown in Figure 3.1, 3.2 and 3.3.
The difference between the different softgoal representations is, as can be seen in the
figures, that NFR softgoal is a regular cloud, operationalizing softgoals is a cloud drawn
with a thicker line and claim softgoals are drawn with a dashed line.