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

12 Chapter 3. Requirements engineering with non-functional requirements
[46] states the following as the main activities that RE consists of:
– Eliciting requirements This activity focuses on finding, preferably a complete
set of, requirements. This is however a complex task and not just a matter of going
out and finding requirements that are already defined and articulated. Therefore
the word “eliciting” is preferred instead of “finding”.
– Modelling requirements Modelling or “the construction of abstract descriptions
that are amenable to interpretation” can be used both to elicit requirements, where
it prompts to gather more information, and to analyse systems.
– Communicating requirements The ability to communicate (and document)
requirements so they can be read, analysed, (re)-written and validated is very important.
Since there has to be a communication with the stakeholders in these
processes an understandable documentation of the requirements becomes vital.
Communication is especially important for validation since it is the process of
making sure that the elicited requirements actually match up with the requirements
of the stakeholders.
– Agreeing requirements Managing the sometimes conflicting requirements of
different stakeholders is another part of the process. Negotiating and resolving
these conflicts thus becomes very important.
– Evolving requirements As the environment in which the system operates changes,
so do the requirements. It is therefore important to be able to handle these changes.
This typically means that it has to be possible to add, remove and correct requirements.
The reasons for having to do this can vary, but changes in the stakeholders
needs or simply that a requirement has been overlooked are some examples.
Each of these activities is comprised of numerous of methods and techniques, some of
which will be discussed later.
3.2 Non-functional requirements
There are essentially two types of requirements, functional requirements and non-functional
requirements. Functional requirements states what the system should do while the nonfunctional
requirements states constraints on how the system, or the development of
the system, should do things [52]. A functional requirement could for example be that
a system should support input of user information while a non-functional requirement
could be that the inputted information cannot exceed a certain amount of storage space.
These requirements can then be refined into lower levels of requirements specifying the
requirement in greater detail. The non-functional requirements will be the focus of the
report from here on.
Because non-functional requirements can be a vast amount of different things there is
a need to explain this in greater detail. Below follows some of the different things that
can be seen as non-functional requirements (even though they might actually become
functional through refinement) [52, 47]. This is however not in any way a complete list,
since such a list does not exist: