REQ01 Exercise Key

Informal Requirements Specification

Developed with support from the National Science Foundation

Version 1.0

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.

1. 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?
2. 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 to service?
   • 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 when necessary?
   • 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?
3. 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?