Requirements Engineering in the

Problem Domain 5
It isn't that they can't see the solution. It is that they can't see the problem.
(Gilbert Keith Chesterton, author, 1874-1936)

5.1 What is the Problem Domain?

The problem domain is the domain in which a system is going to be used.
Therefore it is important to look at requirements from an operational point
of view. A system or any other product enables somebody or some equip-
ment to do something. It is this enabling aspect that is at the heart of
requirements engineering in the problem domain. Faced with the challenge
of eliciting requirements from potential users one might therefore be
tempted to ask a user the question:
What do you want the system to do?
Some users will have little or no idea of what they want the system to do.
Those who have an existing system will usually have ideas about how to
improve the system, but when there is no existing system this source of
inspiration is not available. Answers may be forthcoming from those with
insight into what is possible, but they are most likely to come up with a solu-
tion because the question is focusing on the functionality to be provided by
the intended system.
To avoid this premature jump into the solution domain, it is necessary to ask
the question:
What is the purpose of the system you want?
When considering the purpose of a system, people immediately think about
what they want to be able to do with the system, rather than how they will
do it. What people want to achieve can be stated without any implementa-
tion or solution bias and this leaves the solution space open to the systems
engineers and architects.

E. Hull et al., Requirements Engineering

© Springer-Verlag London 2002
Requirements Englneerfng

It can be argued that even mentioning "the system" in the question could be
misleading and the question reduces to:
What do you want to be able to do?
The answers to this question should be of the form:
I want to be able to ...
This is known as a capability requirement and is one of the key forms of
requirement in the problem domain.
Having established that requirements engineering in the problem domain is
primarily about eliciting capabilities, the next question is
Who should be asked?
This leads to the identification of a group of people that we will refer to as
"stakeholders". These are people or organizations that have some direct or
indirect interest (or stake) in the intended system.
Finally, we must examine what sorts of models are relevant to the problem
domain. Clearly, any models that are used must be understandable to the
stakeholders, because they are going to be responsible for validating them.
Since the stakeholders have been chosen for their specialist knowledge in
the problem, they are generally unwilling or unable to comprehend any
model that is the slightest bit technical. For example, if you were to go into a
car showroom and examine the cars on display, you would be very unlikely
to be interested in a state transition diagram of the engine management sys-
tem. You are more likely to be concerned about the performance of the car in
terms of its acceleration, fuel efficiency, its comfort level and the in-car
entertainment facilities. In other words, you are considering what the car
might be like to drive on a long journey. In your mind's eye you are thinking
about an imaginary journey in the car and considering all the aspects of the
car that would be useful or beneficial during that journey. This is an example
of a use scenario.
It has been found that use scenarios are a very good way of modelling what
people do or want to be able to do. They are directly related to the way they
think about their job or their problems. The scenario can be constructed
with the stakeholders and then used as a basis for discussing the capabilities
that are required.
The final aspect of requirements engineering in the problem domain, is that
there may be some overriding constraints. In the example of buying a car, you
may have a limited budget, or you may require the car to be delivered within a
given period of time. You may want the running costs to be below a given level.

94