Designing a persistent online strategy game - Department of ...
Designing a persistent online strategy game - Department of ...
Designing a persistent online strategy game - Department of ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
22 Chapter 3. Requirements engineering with non-functional requirements<br />
<strong>of</strong> different importance, in the same way as the interdependencies discussed earlier. An<br />
example <strong>of</strong> such a correlation catalogue is shown in table 3.2. It presents the correlation<br />
between a few NFR s<strong>of</strong>tgoals and operationalizing s<strong>of</strong>tgoals where the operationalizing<br />
s<strong>of</strong>tgoals are presented on the top <strong>of</strong> the table and the NFR s<strong>of</strong>tgoals are represented to<br />
the left.<br />
Table 3.2: Correlation catalogue (adapted from Chung et al. [8]).<br />
Non-functional<br />
requirements<br />
s<strong>of</strong>tgoal<br />
Accuracy[Info]<br />
Compressed-<br />
Format-<br />
[Info]<br />
Confidentiality[Info]<br />
HELPS<br />
ResponseTime[Info] HURTS HURTS<br />
Space[Info]<br />
HELPS<br />
Operationalizing s<strong>of</strong>tgoal<br />
Validation- Flexible-<br />
[Info] User-<br />
Interface-<br />
[Employee,<br />
Info]<br />
HURTS<br />
WHEN<br />
[condition]<br />
Perform-<br />
First[Info]<br />
HELPS<br />
As seen in table 3.2 there can be empty cells in the catalogues, this simply represent<br />
an undefined correlation. It is also possible to have conditions in the correlation rules,<br />
these are represented by a “WHEN [condition]” clause.<br />
3.4 Eliciting requirements<br />
To define the requirements for a system it is important to gather initial information about<br />
the system one is about to design. The information gathered can then be used in different<br />
methods and frameworks, such as the Non-Functional Framework described earlier, to<br />
further define and specify the requirements. The need to gather more information during<br />
the process might <strong>of</strong> course also arise. This is a natural part <strong>of</strong> the design process.<br />
There are several techniques for finding, or gathering, information about a system. The<br />
most basic one is perhaps introspection, where the designer simply tries to imagine what<br />
a system has to accomplish and in what way it has to do it [23]. This might actually<br />
give quite a lot <strong>of</strong> information, but <strong>of</strong> course has its drawbacks since the designer does<br />
not have the same idea <strong>of</strong> a system that the user might have. It can differ in many ways,<br />
experience, skill, goals and so on. There are therefore several data-gathering techniques<br />
that can be used to find information about a system. The actual amount <strong>of</strong> techniques<br />
is hard to say, but most <strong>of</strong> them build on the following basic techniques [52]:<br />
– Questionnaires<br />
– Interviews