Semantic Requirements Engineering - Intentional Perspectives on Information Systems Engineering - page 67

development process. If a requirements specification of lower quality was con-
structed in this process, it would be propagated to the latter steps and as a result,
final products of lower quality, e.g. not satisfying customers or users, could be pro-
duced. In this worst case, developers should abandon all of the developed products
and re-do their process from the beginning, i.e. requirements elicitation. It wasted
much more money, human resources and development time.
Roughly speaking, a RE process can be divided into four activities; (1) require-
ments elicitation, (2) requirements specification, (3) requirements validation and
(4) requirements management. There are many excellent techniques of RE to assist
requirements analysts and stakeholders in producing requirements specifications of
higher quality during each of the above activities, and some of them are put into
practice in industry. However, one of the issues of these RE techniques is that many
of them do not handle semantic aspects of requirements. If we can deal with the
meaning of requirements by using automated techniques, we can get more effective
RE techniques to produce requirements specifications of higher quality. As an exam-
ple, consider a part of the model of a lift control system shown in Fig. 1. The model
consists of a sequence diagram specifying a scenario of lift behavior. Although it
is syntactically correct as a sequence diagram, it includes an incorrect part, i.e. a
lift does not stop itself before opening a door, and the lift object should have sent a
message “stop” to itself in the sequence diagram. We can find this missing message
sending, because we understand the meaning of words “Lift” (object), “up”, “open”
etc. which figure in the diagram and know that it is very danger for passengers to
open a door of a lift while it is moving. This point results not from the syntax of
sequence diagrams but from the semantics of the description. To detect this kind of
incorrectness, we should consider the semantics of a subject domain, i.e. domain
semantics in our technology.
Note that we can have a wide variety of subject domains. In this example, we
focus on the domain of lift control, where the information system to be developed
operates, and it is termed the problem domain. Consider the reason why “up” and
“open” are specified as messages in the sequence diagram of Fig. 1. We know that
the concept of messages in sequence diagrams represents actions and that the words
“up” and “open” also denote actions. As well as the meaning of these words, we

Scheduler

Lift Door

1: request

2: up

3: arrived

4: open

Fig. 1 A sequence diagram
for a lift control system