Ninth IEEE International Workshop
on Software Specification and Design (IWSSD-9)
Case Study
This case study is intended to help give some focus to IWSSD-9
submissions. You are encouraged, but not required, to use it. It will
help attendees understand your paper and will clarify how different
contributions fit together. You should feel free to interpret the case
study as you choose, you may wish to extend it or cut bits out
depending on what you want to say. Just make sure that you are clear
about this.
This case study is due to Axel van Lamsweerde and can be found in:
Feather, M., Fickas, S., Finkelstein, A. & van Lamsweerde, A.,
``Requirements and Specification Exemplars'', Automated Software
Engineering, (1997), accepted for publication and to
appear.
The Meeting Scheduler System
Foreword
This preliminary description is deliberately intended to be sketchy and
imprecise. Acquisition, formalization and validation processes are needed
to complete it and illuminate the many shadowy areas.
A number of features of the Meeting Scheduler System were inspired from
experience in organizing meetings (faculty meetings, ESPRIT project
meetings, Program Committee meetings, etc.).
Scheduling Meetings: Domain Theory
Meetings are typically arranged in the following way. A meeting initiator
asks all potential meeting attendees for the following information based
on their personal agenda:
- a set of dates on which they cannot attend the meeting (hereafter
referred to as the exclusion set);
- a set of dates on which they would prefer the meeting to take place
(hereafter referred to as the preference set).
A meeting date is defined by a pair (calendar date, time period). The
exclusion and preference sets are contained in some time interval
prescribed by the meeting initiator (hereafter referred to as date range).
The initiator also asks active participants to provide any special
equipment requirements on the meeting location (e.g., overhead-projector,
workstation, network connection, telephones); he/she may also ask important
participants to state preferences for the meeting location.
The proposed meeting date should belong to the stated date range and to
none of the exclusion sets; furthermore it should ideally belong to as many
preference sets as possible. A date conflict occurs when no such date can
be found. A conflict is strong when no date can be found within the date
range and outside all exclusion sets; it is weak when dates can be found
within the date range and outside all exclusion sets, but no date can be
found at the intersection of all preference sets. Conflicts can be resolved
in several ways:
- the initiator extends the date range;
- some participants remove some dates from their exclusion set;
- some participants withdraw from the meeting;
- some participants add some new dates to their preference set.
A meeting room must be available on the selected meeting date. It should
meet the equipment requirements; furthermore it should ideally belong to
one of the locations preferred by as many important participants as
possible. A new round of negotiation may be required when no such room can
be found.
The meeting initiator can be one of the participants or some representative
(e.g., a secretary).
System Requirements
The purpose of the meeting scheduler system is to support the organization
of meetings - that is, to determine, for each meeting request, a meeting
date and location so that most of the intended participants will
effectively participate. The meeting date and location should thus be as
convenient as possible to all participants. Information about the meeting
should also be made available as early as possible to all potential
participants. The intended system should considerably reduce the amount of
overhead usually incurred in organizing meetings where potential attendees
are distributed over many different places. On the other hand, the system
should reflect as closely as possible the way meetings are typically
managed (see the domain theory above).
The system should assist users in the following activities.
- Plan meetings under the constraints expressed by participants
(see domain theory above).
- Replan a meeting dynamically to support as much flexibility as
possible. On one hand, participants should be allowed to modify
their exlusion set, preference set and/or preferred location
before a meeting date/location is proposed. On the other hand, it
should be possible to take some external constraints into account
after a date and location have been proposed (e.g., due to the
need to accommodate a more important meeting). The original
meeting date or location may then need to be changed; sometimes
the meeting may even be cancelled. In all cases some bound on
replanning should be set up.
- Support conflict resolution according to resolution policies stated by
the client.
- Manage all the interactions among participants required during the
organization of the meeting. To communicate requests, to get replies even
from participants not reacting promptly, to support the negotiation and
conflict resolution processes, to make participants aware of what's going on
during the planning process, to keep participants informed about schedules
and their changes, to make them confident about the reliability of the
communications, etc.
- Keep the amount of interaction among participants (e.g., number and
length of messages, amount of negotiation required) as small as possible.
The meeting scheduler system must in general handle several meeting
requests in parallel. Meeting requests can be competing by overlapping in
time or space. Concurrency must thus be managed.
Back to main IWSSD-9 page