ACM SUi-SOFT

SOFTWARE ENGINEERING NOTES vol 14 no 5

J ull~~89 Page 80

Looking for the event list

Eduardo Miranda,Buenos Aires, Argentina
1. Introduction
In modern structured analysis [1,2] a list of
all
the
external
and temporal stjmuli to which the system must respond to
fulfil its purpose is constructed. This list, called the event list,
is used to establish system boundarjes, as partition criteria and as
a starting point for requirement analysis.
How to build such list is a key issue and is actually a
only partially answered.
Ward
[2,3]
suggests
a
brainsto~ming approach to its construction. He advices work to be
done by a group and not to be considered complete until
every
conceivable event to which the system might respond,
no matter
how far-fetched, has been examined and accepted or rejected.
To
discover
new events, system developers can apply the following
questions to an event list already founded:
question

- Are there any variations of these events that are

significant?
- Are the opposite, or negative, of these events of
interest to the system?
- Are there any events that must precede/follow
these events ?
- What if the events fail
knowledge
deal.

to occur?

This paper presents a complementary strategy based on the

of the state of the objects with which the system has to

2. The state transition approach to event finding

At the beginning of requirement analysis,
and
knowing
the system purpose, it will be possible to identify objects that
will
be part of the system essential
memory.
These objects
usually evolve through a series of states which the user is aware
of.
The question is in response to what, does a state change
take place ?
The answer is simple: changes are due to events for
which the system must provide a preplanned response.
knows
As states are in the application domain, the user
them,
the originating events should be there too. Experience st"lo\t>JS
that
the state concept is more familiar to him/her than the event
events
concept.
Thus,
studying the states to find
out
the
facilitates the user analyst-dialogue.

SOFTWARE ENGINEERING NOTES vol 14 no 5

ACMSIGSOFT

Jul1989 Page 81

As an
example of how the method wo~ks,
a
simplified
library*system 15 presented. Figure 1 depicts a state
transition
dIagram
of
the five possible states a book can be in,
from
a
librarian point of view.

i\ar-rlva
. 1

loan

r-etur-n

r"-'" "" ...." ..........-........... -, ." ....... '...-.-..............-........... > r---- --.....-.-.-_ ....-, .--........ -.- .-.....' ...-.......-.. > r---- . -- .........- ............,
l a.vailable I
retur-n
I on loan
i reservation I reserved
I
L.._... " ""'" .............. _ ... <................... _
....._......._........... l_.... __... __._.....__ _ ._ ....1 <._._.. _.. __............_.....___._._ l_. __....._. ___......._..... _...... _.....1
r-.
I r-ene\Ji ng
f - .. _-_ ..
..

return

o.
i

Ii thdrawal

expiration of
loan

V
,------------1

[-----------------1
'out of circ}

l__--=:~:_~_~~:....__. I

L._. _____._....... _........_.... .

fig.

L_.1

_......._---..-... -._.. _-_..--_ .. ...._.-_.(

1 State transition diagram for a book in the library system

The event list derived from this state transition

diagr-am
is shown
in
Table
1. This list can
be augmented
applying
the
procedure to other objects in the system, looking for
what
causes
relations among
those objects to be established
and
using
the
brainstorming approach outlined at the beginning of this work.

3. Summary
The state transition approach
complement~
the pure
brainstor-ming
strategy as a starting point in finding the event
list.
Its graphic representation by means of
states
transition
diagram
and
its intuitive nature facilitates
the
user-analyst
communication.
This
technique serve both as an explanation and
as
a
checking
tool. Attaching the corresponding process name to each
transition helps to guide a walkthrough of the system
behavioral
model.

l'!.~.:,t~:::.;

(:il t.hDU';'~,

p,;:'t t

(,1"

t.h::: ~:tc:\t E t"-,;:;n~':t ti on C/i e.c,!r',.'.'-', l <::.. n:ct <"r', (!~.".s.ent i c.:-.]
thE' f,!.?'ti--,CiC!
i t intEq~'21tF'~ r:', ce.1. '>' lA",. 'U', the
oJ.. hr::1"

to~ls

of

s.tru=tured 2rGlvsis.

SOFTWARE ENGINEERING NOTES vol 14 no 5

ACMSIGSOFT

..... _......... ----...-.... -_.-.-" ..- .. --.- --_...._---_..----_ .... -........ _... -----.-._ .. '. _...... _,.. _--_ ..-... _.... _..,_.. __ .... __._-.-_...._...

-----------------~-----.-

i Event

... --.-..

J ul1989 Page 82
---- -- ..-- ..... --- ..-....

,'

Respon'::.E"

_. __ ....... ____ . _. ___."_' ._ ...... ,._,_ ... _____ ... ___._ .. _. ____ .. _. __ . ___ .___" ___ ._,, ... _____ .. L .. _...... _ .. __________ .. ___ .__ ..._... _..._.. __.... __..... __ .___ .. _._,_.. _....___ ,_ .... ______.___ ._. ______ .,

A book is acquired

IE! u.pdated catalog

I

A library member borrows

a. book
A library member returns
a book

A library member renews

!
I

!E: updated book status

u.pdated member's on-loan list
\

lEI updated book status

updated member's on-loan list
I

I
i

lEI updated book return date

a loan
i

A library member asks forlEI updated book status

a book already borrowed
I
updated waiting list

IA
I

loan period

e~pires

II A
!

book is taken out of

circulation

i... __ __ . _ _ __ ,,_. ________ , ____ ___ ____ _______ .. _'. _______ 0 _ _

I'TI
! I
lEi
I I'

_____ ___

!... _ . ___

overdue notice
updated member status

~_.

__ .. ___ .... _. __ . ,. _ _ _ _ _ .... __ ",, ___ . _. __ ...... ______ . _ .. _ _ _ _ _ _ _ _ _ ... __ . M

E Table 1 -

updated book status

External, T -

_ ...

~._

...

_~

Temporal

Event list derived from the state transition diagram

4. Acknowledgments
I
wish to thank Raul Martinez, Pilar Barrio and to my
coleagues at vee for their helpful comments on an earlier version
of this article.

5. References
1. Essential
System
Prentice-Hall.
2.

Analysis,

McMenamin

System Development Without Pain,

Ward,

and

Palmer,

Prentice-Hall.

3. Structure Development for Real-Time System'::,

Mellor, Prentice-Hall.

Ward

and