REQ01 Exercise Key
Informal Requirements Specification
Developed with support from the National Science Foundation
A wide variety of approaches and levels of success should be anticipated in evaluating the
exercise reports. Some common issues and areas of evaluation are presented here as an aid
to the instructor.
Definition of terms: elevator system, elevator, floor, inputs, possible elevator movements.
Is it clear that the system can have a single elevator, or a number of elevators?
Are types of inputs distinguished? For example, are "floor requests"
indicated by buttons inside an elevator understood to be distinct from
"elevator calls" indicated by buttons on each floor?
Is it clear that each elevator has its own set of floor requests, while there
is one set of elevator calls for the entire elevator system?
Are significant operations (e.g., moving up or down one floor, choosing a direction
for the next movement, visiting a floor) identified?
Without getting into too much design detail, are the relationships between these
significant operations well defined? For example, is there a defined sequence like
"visit a floor, choose the next direction, move one floor"?
Does the specification use any terms that are not adequately defined?
Scenarios, exceptions, and constraints.
Are special cases (e.g., elevator on top or bottom floor, no requests or calls
pending) properly specified?
Is it clear that the top floor has no "up" call button and the bottom
floor has no "down" call button?
Are any assumptions made about floor numbering? Can the specification deal with
floors below the "first" floor? Can certain floor numbers be omitted
(e.g., some buildings may not have a floor labeled "13")?
Is the operation of the "emergency" button handled properly?
Is it clear what happens to pending floor requests when an elevator is returned
Are multiple-elevator interactions handled reasonably, if not optimally?
Does the specification make any attempt to track which elevator is responding
to a particular call? If so, do the specifications take into account that
another elevator may happen to visit the target floor before the
"assigned" elevator reaches it? What if the assigned elevator
is taken out of service before the call is handled?
Does the specification clearly describe how an elevator's current direction
of movement affects decisions about which direction to move next?
Note that it is easy to go wrong by changing direction too easily (perhaps
carrying an unwilling passenger in the wrong direction) or by failing to
change directions when appropriate (perhaps by sending an empty
"upward bound" elevator
all the way to the top floor even when there are no calls to service
on upper floors).
Are elevators specified to stop when all calls and requests have been handled?
Is it clear where they stop?
Does the specification make clear how a stopped elevator starts moving again
Does the specification clearly state assumptions about situations that need
not (or can not) be handled by the system?
Are vague or "impossible" requirements
(e.g., all floors being given equal priority) noted?
Separation of requirements from design and implementation.
Are there design or implementation details (e.g., request queues,
vectors of calls) embedded in the specification?
Are specifications phrased so as not to preclude alternative designs
and implementation techniques?