Object Oriented SRS - Elevator Project

Software Requirements Specifications
Team 2
4/23/2003
MSE530
Software Requirements Specifications using an

Object-Oriented Approach
EPR - Elevator Project
March 2002
Lorenz Prem
Jeremy T. Lanman
Department of Computing and Mathematics

Embry-Riddle Aeronautical University
-1-

Team 2
4/23/2003
MSE530
Change History
Date
Author
Description
03/03/02
Prem
Lanman
SRS Baseline
Table 1: Change History
-2-

Team 2
4/23/2003
MSE530
Table of Contents
Change History ................................................................................................................... 2
Table of Contents................................................................................................................ 3
List of Figures and Tables................................................................................................... 5
1 Introduction...................................................................................................................... 6
1.1 Purpose...................................................................................................................... 6
1.2 Definitions/Acronyms............................................................................................... 6
1.3 References................................................................................................................. 6
1.4 Overview................................................................................................................... 6
1.5 SRS Standard ............................................................................................................ 7
1.5.1 Layout ................................................................................................................ 7
1.5.2 Organization....................................................................................................... 7
2 Overall Description.......................................................................................................... 7
2.1 Product Perspective................................................................................................... 7
2.1.1 System Interfaces ............................................................................................... 7
2.1.2 User Interfaces ................................................................................................... 8
2.1.3 Hardware Interfaces ........................................................................................... 8
2.1.4 Communication Interfaces ................................................................................. 9
2.1.5 Memory Constraints........................................................................................... 9
2.1.6 Operations .......................................................................................................... 9
2.2 Product Function....................................................................................................... 9
2.2.1 User Characteristics ........................................................................................... 9
2.2.2 Constraints ....................................................................................................... 10
3 Specific Requirements ................................................................................................... 10
3.1 External Interfaces .................................................................................................. 10
3.1.1 User Interface................................................................................................... 10
3.1.2 Hardware Interface........................................................................................... 10
3.1.3 Software Interface............................................................................................ 10
3.1.4 Communications Interface ............................................................................... 11
3.2 Functions................................................................................................................. 11
3.2.1 Object Elevator: ................................................................................................... 11
3.2.2 Object Access: ..................................................................................................... 12
3.2.3 Object Position:.................................................................................................... 13
3.2.4 Object Failure: ..................................................................................................... 13
3.2.5 Object Request:.................................................................................................... 14
3.3 Performance Requirements..................................................................................... 14
3.4 Logic Database Requirements ................................................................................ 15
3.5 Design Constraints .................................................................................................. 15
3.6 Other Requirements ................................................................................................ 15
4 Software Attributes ........................................................................................................ 16
4.1 Reliability................................................................................................................ 16
4.2 Availability ............................................................................................................. 16
4.3 Security ................................................................................................................... 16
4.4 Maintainability........................................................................................................ 16
-3-

Team 2
4/23/2003
MSE530
4.5 Portability................................................................................................................ 16
4.6 Requirement Organization ...................................................................................... 16
4.7 Standard Compliance .............................................................................................. 16
5 Assumptions/Dependencies ........................................................................................... 17
5.1 Assumptions............................................................................................................ 17
5.2 Dependencies .......................................................................................................... 17
6 Appendix........................................................................................................................ 18
6.1 Change Control ....................................................................................................... 18
6.2 State Transition Diagrams....................................................................................... 20
6.3 Use Case Diagram................................................................................................... 22
6.4 Use Case Scenarios ................................................................................................. 23
6.5 Activity Diagrams................................................................................................... 32
6.6 Category Diagram................................................................................................... 36
6.7 Class Diagram......................................................................................................... 37
6.8 Sequence Diagrams................................................................................................. 38
6.9 Requirements Traceability Matrix (RTM).............................................................. 43
6.10 Requirements Elicitation:...................................................................................... 45
6.11 Requirement Specification Forms: ....................................................................... 46
6.12 Requirements Summary....................................................................................... 52
-4-

Team 2
4/23/2003
MSE530
List of Figures and Tables

Table 1: Change History ..................................................................................................... 2
Table 2: Definitions and Acronyms.................................................................................... 6
Figure 1: Context Diagram ................................................................................................. 7
Figure 2: State Transition Diagram 1................................................................................ 20
Figure 3: State Transition Diagram 2................................................................................ 21
Figure 4: Use Case Diagram ............................................................................................. 22
Table 3: Use Case Scenario UC1_Guest_Use_Elevator................................................ 23
Table 4: Use Case Scenario UC2_CardUser_Use_Elevator.......................................... 24
Table 5: Use Case Scenario UC3_EmergencyPersonnel_Use_Elevator ....................... 25
Table 6: Use Case Scenario UC4_Guest_Call_Elevator ............................................... 26
Table 7: Use Case Scenario UC5_CardUser_Call_Elevator ......................................... 27
Table 8: Use Case Scenario UC6_EmergencyPersonnel_Call_Elevator....................... 28
Table 9: Use Case Scenario UC7_TravelOn_Elevator.................................................. 29
Table 10: Use Case Scenario UC8_User_Use_MasterControl...................................... 30
Table 11: Use Case Scenario UC9_SelectFloor_DuringTravel..................................... 31
Figure 5: Activity Diagram - User Call Elevator.............................................................. 32
Figure 6: Activity Diagram 2 - User Travel in Elevator................................................... 33
Figure 7: Activity diagram 3 - User presses a floor button while traveling ..................... 34
Figure 8: Activity Diagram 4 - User uses the Master Control Panel ................................ 35
Figure 9: Category Diagram ............................................................................................. 36
Figure 10: Class Diagram ................................................................................................. 37
Figure 11: Sequence Diagram UC1_Guest_Use_Elevator ............................................ 38
Figure 12: Sequence Diagram - UC2_CardUser_Use_Elevator....................................... 38
Figure 13: Sequence Diagram - UC3_EmergencyPersonnel_Use_Elevator .................... 39
Figure 14: Sequence Diagram - UC4_Guest_Call_Elevator ............................................ 39
Figure 15: Sequence Diagram - UC5_CardUser_Call_Elevator ...................................... 40
Figure 16: Sequence Diagram - UC6_EmergencyPersonnel_Call_Elevator.................... 40
Figure 17: Sequence Diagram - UC7_TravelOn_Elevator............................................... 41
Figure 18: Sequence Diagram - UC8_User_Use_MasterControl..................................... 41
Figure 19: Sequence Diagram - UC9_User_SelectFloor_DuringTravel .......................... 42
-5-

Team 2
4/23/2003
MSE530
1 Introduction
1.1 Purpose
This document details the software requirements for the Elevator project (EPR). It defines
what the problem is, and what problems a complete solution has to solve.
The intended audiences for this document are the development team, the team manager,
the customer and all other stakeholders in the system.
1.2 Definitions/Acronyms
Acronym
Definition
EPR
Elevator Project
DD
Data Dictionary
DFD
Data Flow Diagram
GUI
Graphical User Interface
OOA
Object-oriented Analysis
OOD
Object-oriented Design
RSF
Requirement Specification Form
RTM
Requirements Traceability Matrix
SRS
Software Requirement Specification
STD
State Transition Diagram
Table 2: Definitions and Acronyms
1.3 References
IEEE. IEEE Standard for Software Requirement Specifications. IEEE Std 8301998. Institute of Electrical and Electronics Engineers, Inc. 1998.
Software Requirements Engineering Process, Prem, Lanman, Daytona Beach, FL,
2002
1.4 Overview
A building needs software to control its elevator system. There are five elevators of three
types. Each of the three elevator types has its unique behavior. The building itself has
different types of floors, which also change the behavior of the elevators.
Three types of users can gain access to the elevators: guest users, users with a priority card
and emergency personnel using a key. There are access terminals provided for all three
users on all floors. In addition there is a control terminal in the lobby.
There are special rules for the behavior of the different elevator types depending on the
floor they are located, what action they are performing or just completed and what their
current status is.
-6-

Team 2
4/23/2003
MSE530
1.5 SRS Standard

1.5.1 Layout
The layout of the SRS will conform to the IEEE standard IEEE Std 830-1998. Additional
sections are included according to the Software Requirement Engineering Process by
Prem and Lanman.
1.5.2 Organization
The SRS requirements will be organized by objects. The objects in the EPR are the three
elevator types. A forth type, a generic elevator, is added in the SRS.
First the generic elevator object will be described. It includes all requirements in common
to the other three elevator types. Then the other three elevator types are discussed after
each other, each time describing their unique requirements.
2 Overall Description
2.1 Product Perspective
The EPR is the software control for a five elevator system with independent control units
in each elevator car and one master control in the lobby.
The elevator project is a special order software system. It will only be used in the stated
configuration of elevators and floors.
Standard Guest User

Special Guest User (Card Key)
Failure
Command
Command
EPR
Emergency User (Hard Key)
Master Control User
Micro-Controller
Command
Command
Activated Request
Figure 1: Context Diagram

2.1.1 System Interfaces
Interface to the system is provided at two different levels for users, with an additional level
for control.
At teach floor there are three methods to call elevators to the floor. They are call buttons
for guests, card access for priority users and key access for emergency personnel. At the
floor level, all the access methods will do is call an elevator to the floor and make it open
its doors.
-7-

Team 2
4/23/2003
MSE530
Inside the elevator there is a panel with buttons for all floors. Pressing them will make the
elevator go to the desired floor, as long as there are no restrictions on the user. In addition
there is a card reader and a key access port inside the elevator. These two control methods
allow prioritized usage of the elevator.
In the hotel security office there is a master control terminal. It gives direct access to
movements and behavior of all elevators.
2.1.2 User Interfaces
There are four different ways for a user to interact with the system:
Guest User: The guest user is the most typical user of the elevator system. On each
floor there are up and down call buttons for the elevators. Depending on which way
to go and which elevator type used, the user presses on of the call buttons. Once in
the elevator the user chooses his destination by pressing the appropriate key inside
the card. The elevator moves to the desired floor and the user disembarks.
Card User: A card user has priority over other users. At a floor the user uses his
access card in one of the card readers for on of the three elevator types. The
elevator arrives and the user enters. In the elevator, the user inserts the card into the
card reader and leaves it there. As long as the card is in the reader the user has
control over the elevator. He can choose to move to different floors by pressing the
appropriate button the elevators control panel. Once the elevator arrives on the
destination floor, it will remain there until the card is removed or the user moves it
to another floor. Total control will remain with the user until a higher priority user,
like a key user, takes command of the elevator.
Emergency Personnel: By US law, emergency personnel must have access to all
elevators using a key. At all floors there are key holes for the emergency personnel
to call the elevator. Once inside the user inserts the key into the elevator panel and
gets control over the elevator as if he were a card user. The only difference is that a
key user has total control. He cannot be overruled by any other users.
Master Control Panel: The master control panel is located in the security office. It
gives emergency access to the elevators. It can move any elevator to any floor as
long as it is not under control of a key user. It overrules all other users. Once on a
floor the elevator will wait there either for a user or until it is released by the
control panel.
2.1.3 Hardware Interfaces

On each elevator car there is a process responsible for it. It performs all elevator functions
needed for a one elevator system. If the elevator is by itself, this hardware is able to make
the elevator function properly.
In the lobby there is a master control panel, which controls the five elevators as a system of
elevators. This hardware has to work in conjunction with the onboard chips.
-8-

Team 2
4/23/2003
MSE530
2.1.4 Communication Interfaces

The main control panel shall communicate with the onboard processor. It shall do so in a
safe way. It can request actions for the onboard processor, but the decision to comply with
the request shall remain with the onboard processor.
In the event of a communication failure individual elevators shall remain functional as one
elevator systems.
2.1.5 Memory Constraints
The implementation of the onboard software is constrained by the capabilities of the
processor and its memory size.
The master control in the lobby does not have any constraints.
2.1.6 Operations
Besides the normal behavior of elevators related to responding to a call and moving to the
destination floor of the passenger, the elevators have idle behavior and special behavior
according to their type.
Movement of the three guest elevators is coordinated using a minimum wait first,
minimum travel second algorithm. In other words, the elevator will minimize the amount
of a time a passenger has to wait for an elevator. In case of a tie between elevators or
passengers, the elevator will be picked, which has the minimum travel to the user.
When idle all elevators will return to their home floor, where they will open their doors
and wait for passengers. Depending on the type of the elevator the home floor is different.
The express elevator is special in another sense, as it does not always open its door when
waiting on a floor.
The onboard processor in each elevator car also sends messages about its status to the
master control panel in the security office. It also responds to commands received from
there.
Some floors like the presidential floor and the service level can only be reached using
certain access types. This is done for security reasons.
In case of a power outage or other unforeseen problems, the elevators will sink to the next
lower floor and open their doors, if possible.
2.2 Product Function

2.2.1 User Characteristics
Guest users are assumed to have no experience with elevators. All controls on an elevator
should be intuitive to a person, who knows what elevators do, but has never used one.
-9-

Team 2
4/23/2003
MSE530
Card and key access is only used by trained users. Operation of these methods shall be
simple enough so that operators can train each other.
2.2.2 Constraints
The project is safety critical. Under no circumstances shall a user of the system be harmed
or harm others through proper or improper use of the elevators.
The project shall conform to any rules for elevators in place in the United Sates of
America.
3 Specific Requirements
3.1 External Interfaces
The external interfaces of the EPR system are relative to the five elevators which contain
independent control units in each car, and one master control. These interfaces are
described below:
3.1.1 User Interface
The User Interface defines the human-computer interaction of the EPR system. The system
requires interaction from various users:
The standard guest user interacts with the button interface within the car, and the
outside panels
The special guest user interacts with the system with a card-key (soft-key) inside
the car in order to be given special preference
The emergency personnel user interacts with the system with a hard-key inside and
outside of the system in order to be given complete control of all elevators
The master control user interacts with the system within the master control unit.
This person is given special preference privileges (usually reserved for maintenance
crew or building managers)
3.1.2 Hardware Interface
The software shall interface with the electromechanical machinery that controls the
elevator's movements. The software shall interface with a breaking mechanism in case of
emergencies. The opening/closing of doors shall be controlled by the software based on
sensor inputs. The hardware interface is supported by the main control panels (buttons,
key accesses, and micro-controller communications).
3.1.3 Software Interface
Software interface is supported by the main control panels and operating system in which
hosts the algorithms for calculating distributed travel and wait time information.
Additionally, the algorithms define and export system commands for main control panels,
and micro-controller. For testing purposes the software shall be capable of interfacing with
software simulators on a PC computer using GUI applications.
-10-

Team 2
4/23/2003
MSE530
3.1.4 Communications Interface

All system interfaces communicate in order to activate ordered requests. The microcontroller is the external interface that communicates with the control panel of the EPR
system. This communication allows for failure messages, and requests to be sent and
received by the main system.
3.2 Functions
The EPR shall contain the following functionality organized by object:
3.2.1 Object Elevator:
Functional Requirement 1.
1. Introduction. Call function.
2. The inputs are the call buttons which determine the user's location and
direction of travel, and the sensors which indicate the car location.
Quantities and ranges are software specific.
3. Upon receiving a call request, the software shall locate the closest car
traveling in the proper direction, and send that car to that location. It shall
serviced eventually with equal priority. If both call buttons are initiated
simultaneously the software shall determine which direction will be
serviced first. When a car has no request, the software shall send the car to a
holding floor to wait for further requests.
4. The hardware controls the door and car movement signals.
1. Introduction. Visit function.
2. The inputs are the visit buttons which determine user's direction of travel,
and the sensors which indicates the car location. Quantities and ranges are
software specific.
3. When the user initiates a visit button the software shall stop the car at that
location. If the request is contrary to the direction of travel, the car shall
travel to the furthest destination in that direction and then service visits to
other directions. When all visits have been serviced the car shall be sent to a
holding floor with to wait for further requests.
4. The hardware controls door and car movement signals.
1. Introduction. Emergency function.
2. The input is the emergency button.
3. When the emergency button is pressed, the software shall stop the car and
initiate a routine to restore service.
4. The hardware controls car movement signal.
-11-

Team 2
4/23/2003
MSE530
1. Introduction. Sensor function.
2. The input shall be signals from the sensors located in each car.
3. The signal from the sensor shall be used to determine rate of travel and car
location.
4. The output shall pass information to the floor indicator and hardware
mechanism which control rate of travel.
Fuctional Requirement 5.
1. Introduction. Service Elevator.
2. There shall be one service elevator accessing all floors.
3. The home floor of the service elevator shall be the service level.
4. The service elevator shall only service the presidential suit when used with
swipe card access, key access or the override mechanism.
5. There shall be one up and down call button on each floor, except on the
presidential level.
1. Introduction. Express Elevator
2. The express elevator shall only service the presidential suit when used with
swipe card access, key access or the override mechanism.
3. The express elevator shall wait with doors closed, except on the presidential
level, where they are open.
4. The calling button on the top floor of the presidential elevator shall have
priority over all other floor buttons.
5. The home floor of the presidential elevator shall be either the presidential
floor, the lobby, the service level, the recreation level or the garage. The
specific home floor is picked as the one the elevator has been on last.
6. There shall be two call buttons for the express elevator on all floors.
1. Introduction. Guest Elevators
2. There shall be one up and down call button on each floor to call the next
available elevator of the three, except on the presidential level.
3. The guest elevators home floor is the lobby.
4. The guest elevators shall only service the presidential suit or the service
level when used with card access, key access or the override mechanism.
5. The key access at all floors shall call all three elevators in unison.
3.2.2 Object Access:
1. Introduction. Get Button Parameters
2. A guest shall be able to operate all elevators using the number pad located
inside.
-12-

Team 2
4/23/2003
MSE530
1. Introduction. Get Soft-Key Parameters
2. An operator shall be able to operate all elevators using a key-card.
The operator gains control over the elevator from the

moment the key-card is inserted to the moment it is removed as long
as there is no higher priority user.
As soon as the key card is inserted the operators actions

shall override any actions activated by a lower priority user.

1. Introduction. Get Hard-Key Parameters
2. Emergency personal shall be able to operate the elevator using the
emergency key.
Emergency personal shall have control over the elevator from the
moment they insert the key to the moment it has been removed.
As soon as the key is inserted the actions by the emergency personal
shall override any actions activated by a lower priority user.

1. Introduction. Get Master Control Parameters
2. There shall be an override control panel in the hotel security office that can
direct any elevator to any floor at any time.
The override panel shall be able to direct any elevator to any floor
and make it wait there with its doors open.
3.2.3 Object Position:

1. Introduction. Get Position Parameters
2. After the traveler exits all elevators shall remain on the floor with the doors
open for 20 seconds before they return to their home floor.
3.2.4 Object Failure:

1. Introduction. Get Failures
2. There shall be micro controller on each elevator taking care of bounce
control.
The micro controller shall provide the following messages and
actions: Stop + Alarm, Messages to the Security panel, Records of
Access, go to lobby, power loss.
3. Failure messages by any elevator shall be monitored on the override panel.
-13-

Team 2
4/23/2003
MSE530
3.2.5 Object Request:

1. Introduction. Process Requests
2. Operators shall have precedence over each other in the following order
starting from the lowest: user, operator, override control, emergency
personnel.
3. In car users shall have priority over call button users of the same level and
below.
4. When idle, all elevators shall return to their home floor and wait with doors
open (except the express elevator).
5. An elevator shall stop for a call, when this call is coming from somewhere
in the direction of travel of the elevator.

1. Introduction. Validate Requests
2. When a call button is pressed one elevator of the three shall be called.
3. When the call button is pressed which elevator is going to come, is
determined by minimum wait schedule first and by the minimum travel
schedule second
4. Get Request Type Receive request type from list file
5. Get Minimum Wait Time Receive wait time from control board
6. Get Minimum Travel Time Receive travel time from control board
7. Check Request Precedence Order requests based on user preference, then
by wait and travel time information
8. Return Requests Send requests to micro-controller
9. Process Failure Analyze failure
Get Failure Type Receive failure type from list file
Return Failure Type Send failures to request processor
10. Activate Request Execute request for specified guest (user)
3.3 Performance Requirements

The EPR system shall be built upon an embedded processor. The processor must be
capable of handling real-time functionality activated by the defined users and microcontroller. In addition, the system must be safety-critical. All failures reported by the
micro-controller must be handled instantaneously to allow for user and system safety.
The software shall control n-cars in a building with m-floors. The maximum number of
commands the software shall handle is (m*n)+2*(m-1)+n, where m is the number of floors
and n is the number of cars. The software shall have a floor travel time variable of x
seconds, based on sensor inputs, which if exceeded, the software shall recognize an error
and take corrective action.
-14-

Team 2
4/23/2003
MSE530
3.4 Logic Database Requirements

A one-to-many relational database shall be used in order to validate various user requests
and failure types. Moreover, failures are to be logged for reference. The database shall be
concurrent with the performance requirements of the EPR system.
3.5 Design Constraints

The EPR system shall run on an embedded system that handles safety-critical
functionality. The system shall use a real-time processor with dynamic memory allocation
in order to handle continuous activity. Also, user and software interfaces shall be simple
and user-friendly, and comply with the following:
Standards Compliance. The software shall adhere to Fire Department codes and
regulations, and Building codes related to public safety.
Hardware Limitations. This software shall run only on a simulator, but it must be
easily transferable to the field.
3.6 Other Requirements

A degraded mode of operation should be possible in which each car can operate
independently of central scheduling. The software shall have power failure and error
recognition codes acting as a safety net, thus keeping the software from performing any
major catastrophic functions.
-15-

Team 2
4/23/2003
MSE530
4 Software Attributes
4.1 Reliability
The system is safety critical. If it moves out of normal operation mode, the requirement to
drop to the next lower floor and open its doors is given priority. This emergency behavior
shall not occur without reason.
4.2 Availability
When in normal operating conditions, request by a user for an elevator shall be handled
within 1 second. Immediate feedback of the systems activities shall be communicated to
the user by lighting the call button pressed.
At peek system load, individual users at either the control panel in the security office, at
the call buttons or inside the elevator shall not experience any delay in the elevators
response to their commands longer than 1 second.
4.3 Security
There shall be no security mechanisms in place to keep unwanted users out of the system.
However, all users of the system shall not be able to perform actions or request actions
from the elevator system, which will cause harm to any person or damage to the system or
its environment.
4.4 Maintainability
1. There shall be design documents describing the internal works of the software.
2. There shall be an access on the control panel and inside the elevators for the
purpose of upgrading the software or flashing any firmware.
4.5 Portability
There are no portability requirements.
4.6 Requirement Organization

All requirements shall be organized according to object. First general requirements for all
elevator types shall be described. Following are sections for each elevator type and their
special requirements. Last are requirements related to other objects like the elevator control
panel and any others.
4.7 Standard Compliance

The elevator systems hardware and software shall be built according to the 2002 standard
for elevator systems issued by the government of the United States of America.
-16-

Team 2
4/23/2003
MSE530
5 Assumptions/Dependencies
5.1 Assumptions
Embedded real-time environment, or compatible, available on platform

If the client changes or upgrades their office system, the EPR system will not be
guaranteed to function unless the new operating system is fully compatible with the
current system as described in section 3 of this document.
All timings stated in this SRS shall be adhered to within +/- 10%
All requirements are addressed in this version of the EPR system. No requirements
are delayed to future versions.
5.2 Dependencies
The number of cars and floors on the building.

Power source
Elevator hardware
-17-

Team 2
4/23/2003
MSE530
6 Appendix
6.1 Change Control
Requirement changes shall be documented in the form of an RSF. The RSF trace number
shall be extended by one level and an alphabetic character shall be appended to indicate a
changed requirement. For example a change in REQ.100 will result in REQ.100.A, if it is
the first changed version of the requirement. The SRS shall be changed according to the
new requirements. The old RSFs shall be placed under version control along with the old
SRS. At any one time there shall only be one SRS and RSF document with no duplicate
requirements in them. All previous changes to requirements shall be in previous SRS and
RSF versions.
RSF Form Instructions:
This version of a Requirement Specification Form is used for both elicited and derived
requirements. To distinguish between the two types the RSF identifier is used. Elicited
requirements have identifiers with only one number. Derived requirements have two or
more numbers. These numbers represent the requirement s they are derived from.
Example:
R023
R023-001
R023 is an elicited requirement, because it is at level one. R023-001 is a derived
requirement form R023. There is no limit on the length of the chain of reference with the
RSF number.
-18-

Team 2
4/23/2003
MSE530
Table B17: Requirements Specification Form

Company
Project
Customer
RSF #:
Importance :
Requirement Type :
Description:
Date
Project #
Date :
Elicitation Type :
Constraints (if any) :

Test Conditions :
RSF #:
Importance :
Requirement Type :
Description:
Date :
Elicitation Type :

Test Conditions :
RSF #:
Importance :
Requirement Type :
Description:
Date :
Elicitation Type :

Test Conditions :
RSF #:
Importance :
Requirement Type :
Description:
Date :
Elicitation Type :

Test Conditions :
-19-

Team 2
4/23/2003
MSE530
6.2 State Transition Diagrams

OnBoard Chip
Control
Passenger leaves
Guest
Control
Key Removed
Call button, floor button

Key inserted
Key Inserted
Card Removed
Card Inserted
Key
Control
Control Used
Card Inserted
Control released
Control Used
Key inserted
Card
Control
Control Used
Master
Control
Figure 2: State Transition Diagram 1
-20-
Key inserted

Team 2
Moving to Homefloor
4/23/2003
MSE530
Normal Operations
Arrived at floor / Open doors
On Floor with
Destintaion
Idle for 30 secs / Close doors

Idle
Call / Close Doors
Arrived at floor / Open Doors
Call
On Unknown Error / Sink to next floor, open doors
Arrived at floor / Open doors
Arrive at Floor / Open Doors
Error
Reset
Moving Empty to
User
Moving Full
to User
User Presses Floor / Close Door
Idle for 20 secs / Close Doors
User Presses Floor / Close Doors
Moving Full to
Destination
Call on the way to destination
Figure 3: State Transition Diagram 2
-21-
On power loss / Sink to next floor, open doors

Team 2
4/23/2003
MSE530
6.3 Use Case Diagram
Guest User
Card User
Emergency
Personnel
Control Panel
Users
UC2_CardUser_Use_Elevator
UC1_Guest_Use_Elevator
UC3_EmergencyPersonnel_Use_E
levator
UC8_User_Use_MasterControl
UC5_CardUser_Call_Elevator
UC4_Guest_Call_Elevator
UC6_EmergencyPersonel_Call_El
evator
UC7_TravelOn_Elevator
UC9_User_SelectFloor_DuringTrav
el
Figure 4: Use Case Diagram
-22-

Team 2
4/23/2003
MSE530
6.4 Use Case Scenarios

Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
Guest User(Initiator), Elevator
Provide transportation for the user.
The User enters the elevator, chooses a floor, is transported there
and exits.
Primary and Essential
The user is the highest priority user in the system at the time.
Typical Course of Events

Actor Action
System Response
1) The user calls the elevator.
(UC4_Guest_Call_Elevator)
2) The user enters the elevator and selects a
floor. (UC7_TravelOn_Elevator)
5) The user disembarks.
END
Post-Condition:
The elevator is empty
Alternative Course
NONE
Table 3: Use Case Scenario UC1_Guest_Use_Elevator
-23-

Team 2
Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
4/23/2003
MSE530
Card User(Initiator), Elevator
and exits.

Actor Action
System Response
(UC5_CardUser_Call_Elevator)
END
Post-Condition:
The elevator is empty.
Alternative Course
NONE
Table 4: Use Case Scenario UC2_CardUser_Use_Elevator
-24-

Team 2
Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
4/23/2003
MSE530
UC3_EmergencyPersonnel_Use_Elevator
Emergency Personnel(Initiator), Elevator
and exits.

Actor Action
System Response
(UC6_EmergencyPersonel_Call_Elevator)
END
Post-Condition:
The elevator is empty.
Alternative Course
NONE
Table 5: Use Case Scenario UC3_EmergencyPersonnel_Use_Elevator
-25-

Team 2
Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
4/23/2003
MSE530
Guest User(Initiator), Elevator
To describe the events when calling an elevator.
The user calls the elevator to his floor.
The elevator is not on the floor of the user.

Actor Action
1) The user presses the up or down call
button of an elevator.
System Response
2) The call button lights up.
3) The elevator moves to the floor the user
is on.
4) The doors open.
5) The call button extinguishes.
END
Post-Condition:
The elevator is on the floor of the user.
Alternative Course
3) The elevator is busy moving another user. The call by the user on the floor is
registered and the elevator will move to him as soon as it is done with the other user, or
when it travels past the floor of the first user.
3) The elevator is busy and other call buttons have been pressed calling it. The call button
request is queued until the elevator can service it.
Table 6: Use Case Scenario UC4_Guest_Call_Elevator
-26-

Team 2
Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
4/23/2003
MSE530
Card User(Initiator), Elevator
The elevator has no floors to go to in memory.

Actor Action
1) The user inserts his card into the card
slot of an elevator on a floor.
System Response
2) The call button lights up.
is on.
4) The doors open.
END
Post-Condition:
Alternative Course
2) The elevator is used by another card user. Nothing happens. The use case ends.
Table 7: Use Case Scenario UC5_CardUser_Call_Elevator
-27-

Team 2
Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
4/23/2003
MSE530
UC6_EmergencyPersonel_Call_Elevator
Emergency Personnel(Initiator), Elevator
The elevator has no floors to go to in memory.

Actor Action
System Response
1) The user inserts his key into the key hole 2) The call button lights up.
on a floor.
is on.
4) The doors open.
END
Post-Condition:
Alternative Course
3) The elevator is used by another key user. Nothing happens. The use case ends.
Table 8: Use Case Scenario UC6_EmergencyPersonnel_Call_Elevator
-28-

Team 2
Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
User (Initiator), Elevator
Describe the actions a generic user has to take to select a floor.
Inside the elevator, the user chooses one or more floors on the
panel. The elevator registers the floors.
The user is in the elevator.
There elevator has no floors in memory, it still has to go to.
The elevator doors are open.

Actor Action
1) The user selects a floor on the panel.
END
Post-Condition:
4/23/2003
MSE530
System Response
2) The elevator registers the floor. Goto
step 1. , until user has entered all floors he
wants to go to.
3) Elevator closes doors.
4) Elevator moves to closes floor in the
direction of travel.
5) Elevator arrives at floor and opens its
doors.
7) As long as there are floors in the
memory of the elevator, goto step 3.
There are no floors left the elevator has to go to

The elevator has its doors open
Alternative Course
4) There are no floors to go to in the direction of travel. The direction of travel is reversed
and the next floor in this direction is the new destination.
Table 9: Use Case Scenario UC7_TravelOn_Elevator
-29-

Team 2
Use Case:
Actors:
Purpose:
Overview:
Type:
Pre-Condition:
4/23/2003
MSE530
Master Control User(Initiator), Elevator
Describe the actions of a user of the master control panel.
The User assumes control of one or many elevators and moves
them to a specific floor.
The master control panel is available.

Actor Action
System Response
1) The user selects an elevator.
2) The elevator data is displayed.
3) The user selects a floor for the elevator
4) The elevator moves to the floor and
to wait on. He hits the Enter key.
waits there indefinitely.
5) The user relinquishes control over the
6) The elevator resumes normal behavior.
elevator.
END
Post-Condition:
All elevators are under their own control.
Alternative Course
Table 10: Use Case Scenario UC8_User_Use_MasterControl
-30-

Team 2
4/23/2003
MSE530
Use Case:
UC9_User_SelectFloor_DuringTravel
Actors:
Purpose:
User (Initiator), Elevator

Allow the user to press destination buttons while the elevator
moves.
The user presses a destination button while the elevator is moving.
The elevator is traveling with the user onboard
The elevator has at least one floor to go to in memory.
Overview:
Type:
Pre-Condition:

Actor Action
1) The User presses a destination while the
elevator is moving.
System Response
2) The new floor is saved in memory.
3) The system reevaluates the next floor it
has to go to.
4) The elevator continues its travel.
END
Post-Condition:
The elevator is traveling with the user onboard

The elevator has at least one floor to go to in memory.
Alternative Course
3) There is a new target floor. The elevator changes its destination and moves to the new
destination floor.
Table 11: Use Case Scenario UC9_SelectFloor_DuringTravel
-31-

Team 2
4/23/2003
MSE530
6.5 Activity Diagrams

User
Elev ator
User Press Call

Button
Yes
No
Higher Priority User

than Initiator Active?
Light Call
Button
Yes
No
No
Busy on other
Call button
Yes
Elevator Busy?
Determine highest
priority Call
Call is highest
Call
No
Queue Call
Request
Yes
Move To Floor
Open Doors
Turn off Call

Button
Figure 5: Activity Diagram - User Call Elevator
-32-

Team 2
4/23/2003
MSE530
User
Elev ator
Select Floor
Queue Floor
Request
No
Last Floor?
Yes
Close Doors
Reverse Direction of
travel
No
Yes
Destination Floors i
direction of travel ?
Find Destination
Floor
Travel To Floor
No
Arrived?
Yes
User Exits
Open Doors
Yes
No
Figure 6: Activity Diagram 2 - User Travel in Elevator
-33-
Destination
Floor Left?

Team 2
4/23/2003
MSE530
User (from UC7_Trav elOn_Elev ator)
Elev ator (from UC7_Trav elOn_Elev ator)
Yes
User Press
Floor
No
Floor In direction
of Travel?
No
New Floor
closest Floor?
Yes
Queue Floor
Assign new
Destination
Change
Movement
Continue
Movement
Figure 7: Activity diagram 3 - User presses a floor button while traveling
-34-

Team 2
4/23/2003
MSE530
User
Elev ator
User request
Elevator Control
No
Yes
Elevator under
Key Access?
Select Floor
Yes
No
Elevator
Traveling?
Close Doors
Move To Floor
Open Doors
Figure 8: Activity Diagram 4 - User uses the Master Control Panel
-35-

Team 2
4/23/2003
MSE530
6.6 Category Diagram

The system is a collection of individual elevator systems. The elevator package itself is a one
elevator system. The ES Controller manages the 5 elevator system using 5 one elevator
systems. It adds the IO interface of the control panel to the system.
ES Controller
Elevator
A one elevator
sub-system
Call Methods
The Call
Methods - Input
sub-system
Figure 9: Category Diagram
-36-
Control Panel
Additional
Interface to the
system.

Team 2
4/23/2003
MSE530
6.7 Class Diagram
Failure
FailureType : int
GetFailureTy pe()
Set FailureType()
ExpressElevator
Elevat orType : int
OpenDoors()
CloseDoors()
Travel()
Idle()
Guest Elevator
Elevat orType : int
OpenDoors()
CloseDoors()
Travel()
Idle()
ServiceElevator
Elevat orType : int
OpenDoors()
CloseDoors()
Travel()
Idle()
ControlPanel
MinimumWait : int
MinimumTravelTime : int
RequestType : int
FailureType : int
CalculateMinimumWait()
CalculateMinimumTravelTime()
ValidateRequestType()
ValidateFailureType()
CheckRequestPrecedence()
ActivateRequest()
Controller
Elevat orType : int
AccessType : int
MinimumW ait : int
MinimumTravelTime : int
GetElevatorType()
Set ElevatorType()
GetAccessType()
Set Ac cessType()
GetMinimumWait()
Set MinimumWait()
GetMinimumTravelTime()
Set MinimumTravelTime()
MasterControl
Acces sType : int
Get MasterControlParameters ()
Set Mas terControlParameters()
InitiateRequest()
Figure 10: Class Diagram
-37-
Buttons
ButtonType : int
AccessType : int
GetButtonParameters()
SetButtonParameters()
InitiateRequest()
GetButtonType()
SetButtonType()
KeyCard
AccessType : int
GetKeyCardParameters()
SetKeyCardParameters()
InitiateRequest()
HardK ey
AccessType : int
GetHardKeyParameters()
SetHardKeyParameters()
InitiateRequest()

Team 2
4/23/2003
MSE530
6.8 Sequence Diagrams

UC1_Guest_Use_
Elevator
Guest User presses
call button
System activates
controller
: GuestUser
Call_Methods
_CAT
Control_Panel
_CAT
Elevator_CAT
Use_Button
Activate_Controller
System activates
request with one of
three guest elevators
Use_Guest_Elevator
Failure
Figure 11: Sequence Diagram UC1_Guest_Use_Elevator
UC2_CardUser_Use
_Elevator
Card User swipes key
card
System activates
controller
: CardUser
Call_Methods
_CAT
Control_Panel
_CAT
Elevator_CAT
Use_KeyCard
Activate_Controller
System activates
request with one of
or express elevator
Use_Guest_Elevator
Use_Express_Elevator
Failure
Figure 12: Sequence Diagram - UC2_CardUser_Use_Elevator
-38-

Team 2
UC3_Emergency
Personnel_Use_
Elevator
Emergency Personnel
User inserts
hard key
: Emergency
User
4/23/2003
MSE530
Call_Methods
_CAT
Control_Panel
_CAT
Elevator_CAT
Use_HardKey
System activates
controller
Act ivate_Controller
Use_Guest_Elevator
System activates
request with all
elevators
Use_Service_Elevator
Failure
Figure 13: Sequence Diagram - UC3_EmergencyPersonnel_Use_Elevator

UC4_Guest_Call_
Elevator
Guest User presses
call button
System activates
controller
System processes
guest user request
: GuestUser
Call_Methods
_CAT
ES_Cont roller
_CAT
Control_Panel
_CAT
Elevator_CAT
Push_Button
Activate_Controller
Process_Request
Call_Guest_Elevator
System activates
request with one of
Failure
Figure 14: Sequence Diagram - UC4_Guest_Call_Elevator
-39-

Team 2
4/23/2003
MSE530
UC5_CardUser_Call_
Elevator
KeyCard User swipes
key card
System activates
controller
: CardUser
Call_Methods
_CAT
ES_Controller
_CAT
Control_Panel
_CAT
Elevator_CAT
Swipe_KeyCard
Activate_Controller
System processes
keycard user request
Process_Request
Call_Guest_Elevator
System activates
request with one of
or express elevator
Call_Express_Elevator
Failure
Figure 15: Sequence Diagram - UC5_CardUser_Call_Elevator

UC6_Emergency
Personnel_Call_
Elevator
Emergency Personnel
User inserts hard key
System activates
controller
: Emergency
User
Call_Methods
_CAT
ES_Cont roller
_CAT
Control_Panel
_CAT
Elevator_CAT
Insert_HardKey
Activate_Controller
System processes
emergency user
request
Process_Request
Call_Guest_Elevator
System activates
request with one of
three guest
elevators, express
elevator, or service
elevator
Call_Express_Elevator
Call_Service_Elevator
Failure
Figure 16: Sequence Diagram - UC6_EmergencyPersonnel_Call_Elevator
-40-

Team 2
4/23/2003
MSE530
UC7_TravelOn_
Elevator
System activates
controller
: Software
ES_Controller
_CAT
Control_Panel
_CAT
Elevator_CAT
Activate_Controller
System activates
request
Activate_Request
Activate_Elevator
System activates
elevator
Failure
Figure 17: Sequence Diagram - UC7_TravelOn_Elevator
UC8_User_Use_
MasterControl
Master User operates

from control panel
System activates
controller
: MasterUser
Call_Methods
_CAT
Control_Panel
_CAT
Elevator_CAT
Use_MasterControl
Activate_Controller
System activates
request with all
elevators
Use_Guest_Elevator
Use_Service_Elevator
Failure
Figure 18: Sequence Diagram - UC8_User_Use_MasterControl
-41-

Team 2
4/23/2003
MSE530
UC9_User_Select
Floor_DuringTravel
User selects floor

System activates
controller
: User
Call_Methods
_CAT
ES_Controller
_CAT
Control_Panel
_CAT
Elevator_CAT
Select_Floor
Activate_Controller
System activates
request
Activate_Request
Activate_Elevator
System activates
elevator
Failure
Figure 19: Sequence Diagram - UC9_User_SelectFloor_DuringTravel
-42-

Team 2
4/23/2003
MSE530
6.9 Requirements Traceability Matrix (RTM)

EPR Requirements Traceability Matrix
(EPR RTM)
Name
Course
Entry#
1
3
4
10
12
13
14
Date
Jeremy T. Lanman (Team 2)

MSE530
Para #
TPT Problem Statement
2.1 The system shall be used in a
building with the following floors
starting at the bottom: garage,
service, lobby, recreation, 29 guest
floors, presidential-level.
2.2 A guest shall be able to operate all
elevators using the number pad
located inside.
2.3 An operator shall be able to operate
all elevators using a key-card
Type
HW
Build #
B1
N/A
SW
B1
Elevator_CAT
SW
B1
Elevator_CAT
2.3.1 The operator gains control over the SW

elevator from the moment the keycard is inserted to the moment it is
removed as long as there is no higher
priority user.
2.3.2 As soon as the key card is inserted
SW
the operators actions shall override
any actions activated by a lower
priority user.
2.4 Emergency personal shall be able to SW
operate the elevator using the
emergency key.
2.4.1 Emergency personal shall have
SW
control over the elevator from the
moment they insert the key to the
moment it has been removed.
2.4.2 As soon as the key is inserted the
SW
actions by the emergency personal
shall override any actions activated
by a lower priority user.
2.5 There shall be an override control
SW
panel in the hotel security office that
can direct any elevator to any floor at
any time.
2.5.1 The override panel shall be able to
SW
direct any elevator to any floor and
make it wait there with its doors open.
B1
Duplicate (#3)
Elevator_CAT
B2
Call_Methods_CAT
B1
UC3_EmergencyPersonnel_Use_Elevator
Elevator_CAT
B1
Duplicate (#6)
Elevator_CAT
B1
Duplicate (#6)
Elevator_CAT
B1
Control_Panel_CAT
B1
Duplicate (#9)
Control_Panel_CAT
B1, B2
N/A
B3
B1, B2
N/A
B3
Duplicate (#13)
2.6 Operators shall have precedence

SW
over each other in the following order
starting from the lowest: user,
operator, override control, emergency
personnel.
2.7 In car users shall have priority over
SW
call button users of the same level
and below.
2.8 When idle, all elevators shall return to SW
their home floor and wait with doors
open (except the express elevator).
15
2.9 An elevator shall stop for a call, when SW

this call is coming from somewhere in
the direction of travel of the elevator.
16
3.1 There shall be micro controller on

HW
each elevator taking care of bounce
control
3.1.1 The micro controller shall provide the SW
following messages and actions: Stop
+ Alarm, Messages to the Security
panel, Records of Access, go to
lobby, power loss
3.2 Failure messages by any elevator
SW
shall be monitored on the override
panel.
17
18
3/22/02
Use Case Name
N/A
B5
N/A
B5
N/A
-43-
Class Method
Category
Elevator_CAT
Elevator_CAT

Team 2
19
20
21
22
23
24
25
26
30
31
32
33
34
35
36
37
38
39
40
4/23/2003
MSE530
3.3 After the traveler exits all elevators

shall remain on the floor with the
doors open for 20 seconds before
they return to their home floor.
3.4 There shall be key access at the call
button of all floors.
3.5 There shall be one service elevator
accessing all floors.
3.5.1 The home floor of the service
elevator shall be the service level.
3.5.2 The service elevator shall only
service the presidential suit when
used with swipe card access, key
access or the override mechanism.
3.5.3 There shall be one up and down call
button on each floor, except on the
presidential level.
3.6 There shall be one express elevator.
SW
B3
Duplicate (#13)
Elevator_CAT
SW
B1
Duplicate (#6)
Call_Methods_CAT
3.6.1 The express elevator shall only

service the presidential suit when
used with swipe card access, key
access or the override mechanism.
3.6.2 The express elevator shall wait with
doors closed, except on the
presidential level, where they are
open.
3.6.3 The calling button on the top floor of
the presidential elevator shall have
priority over all other floor buttons.
SW
B4
Duplicate (#23)
ES_Controller_CAT
SW
B4
Duplicate (#23)
ES_Controller_CAT
SW
B4
Duplicate (#23)
Call_Methods_CAT
3.6.4 The home floor of the presidential

SW
elevator shall be either the
presidential floor, the lobby, the
service level, the recreation level or
the garage. The specific home floor is
picked as the one the elevator has
been on last.
3.6.5 There shall be two call buttons for the HW
express elevator on all floors.
3.7 There shall be three guest elevators. HW
B4
Duplicate (#23)
ES_Controller_CAT
HW
N/A
HW
N/A
SW
B4
UC9_User_SelectFloor_DuringTravel
HW
N/A
HW
N/A
3.7.1 There shall be one up and down call

button on each floor to call the next
available elevator of the three, except
on the presidential level.
3.7.2 The guest elevators home floor is the
lobby.
3.7.3 The guest elevators shall only service
the presidential suit or the service
level when used with card access,
key access or the override
mechanism.
3.7.4 The key access at all floors shall call
all three elevators in unison.
3.7.5 When a call button is pressed one
elevator of the three shall be called.
HW
3.7.6 When the call button is pressed

which elevator is going to come, is
determined by minimum wait
schedule first and by the minimum
travel schedule second.
Call_Methods_CAT
N/A
N/A
N/A
SW
B2
Elevator_CAT
SW
B2
Duplicate (#36)
ES_Controller_CAT
SW
B2
UC6_EmergencyPersonnel_Call_Elevator
ES_Controller_CAT
SW
B2
Duplicate (#36)
Elevator_CAT
SW
B1, B2
N/A
-44-

Team 2
4/23/2003
MSE530
6.10 Requirements Elicitation:

Method: The customer presented a two page document, which described the initial
problem statement. The team had one half hour to prepare for a question answer session.
This session lasted for about an hour. The result and only deliverable is the following RSF
document. For any additional questions about the problem, the customer will be available
using email.
Button, key and card access list
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
-45-
X
X
X
X
X
X
X
X
X
X
Card
Guest
Recreation
Lobby
Service
Garage
Key
Presidential
Down
Express Elevator
Up
Card
Key
Down
Up
Service Elevator
Card
Key
Down
Guest Elevator
UP
Level
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Comment
Any
method
calls the
next
available
elevator

Team 2
4/23/2003
MSE530
6.11 Requirement Specification Forms:

Company
Project
Customer
ERAU
Elevator-Problem Version 1
Gutcher
Date
Project #
12/02/2002
1
RSF #:
R001
Date :
12/02/2002
Importance : 10
Requirement Type :
Functional:
Description: The system shall be used in a building with the following floors starting at the
bottom: garage, service, lobby, recreation, 29 guest floors, presidential-level.
2 sub-levels and 32 above ground
Test Conditions : None
RSF #:
R002
Date :
12/02/2002
Importance : 10
Requirement Type :
Functional
Description: A guest shall be able to operate all elevators using the number pad located inside.
One number pad per car.
RSF #:
R003
Date :
12/02/2002
Importance : 5
Requirement Type :
Functional
Description: An operator shall be able to operate all elevators using a key-card.
Only one key card at a time.
RSF #:
R004
Date :
12/02/2002
Importance : 5
Requirement Type :
Functional
Description:
The operator gains control over the elevator from the moment the key-card is
inserted to the moment it is removed as long as there is no higher priority user.
None
RSF #:
R005
Date :
12/02/2002
Importance : 5
Requirement Type :
Functional
Description: As soon as the key card is inserted the operators actions shall override any
actions activated by a lower priority user.
None
RSF #:
R006
Date :
12/02/2002
Importance : 7
Requirement Type :
Functional
-46-

Team 2
4/23/2003
MSE530
Description:
Emergency personal shall be able to operate the elevator using the emergency
key.
Only one key at a time.
RSF #:
R007
Date :
12/02/2002
Importance : 7
Requirement Type :
Functional
Description: Emergency personal shall have control over the elevator from the moment they
insert the key to the moment it has been removed.
None
RSF #:
R007
Date :
12/02/2002
Importance : 7
Requirement Type :
Functional
Description: As soon as the key is inserted the actions by the emergency personal shall
override any actions activated by a lower priority user.
None
RSF #:
R008
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: There shall be an override control panel in the hotel security office that can direct
any elevator to any floor at any time.
None
RSF #:
R009
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The override panel shall be able to direct any elevator to any floor and make it
wait there with its doors open.
None
RSF #:
R010
Date :
12/02/2002
Importance : 5
Requirement Type :
Functional
Description: Operators shall have precedence over each other in the following order starting
from the lowest: user, operator, override control, emergency personnel.
None
RSF #:
R011
Date :
12/02/2002
Importance : 8
Requirement Type :
Functional
-47-

Team 2
4/23/2003
MSE530
Description:
In car users shall have priority over call button users of the same level and below.
Also counts for key and keycard access.
RSF #:
R012
Date :
12/02/2002
Importance : 7
Requirement Type :
Functional
Description: When idle, all elevators shall return to their home floor and wait with doors open
(except the express elevator).
None
RSF #:
R013
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: An elevator shall stop for a call, when this call is coming from somewhere in the
direction of travel of the elevator.
None
RSF #:
R014
Date :
12/02/2002
Importance : 10
Requirement Type :
Functional
Description: There shall be micro controller on each elevator taking care of bounce control.
None
RSF #:
R015
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The micro controller shall provide the following messages and actions: Stop +
Alarm, Messages to the Security panel, Records of Access, go to lobby, power
loss.
These messages are safety critical.
RSF #:
R016
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: Failure messages by any elevator shall be monitored on the override panel.
None
RSF #:
R017
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: After the traveler exits all elevators shall remain on the floor with the doors open
for 20 seconds before they return to their home floor.
-48-

Team 2
4/23/2003
MSE530

None
RSF #:
R018
Date :
12/02/2002
Importance : 5
Requirement Type :
Functional
Description: There shall be key access at the call button of all floors.
None
RSF #:
R019
Date :
12/02/2002
Importance : 6
Requirement Type :
Functional
Description: There shall be one service elevator accessing all floors.
None
RSF #:
R020
Date :
12/02/2002
Importance : 6
Requirement Type :
Functional
Description: The home floor of the service elevator shall be the service level.
None
RSF #:
R021
Date :
12/02/2002
Importance : 5
Requirement Type :
Functional
Description: The service elevator shall only service the presidential suit when used with swipe
card access, key access or the override mechanism.
None
RSF #:
R022
Date :
12/02/2002
Importance : 6
Requirement Type :
Functional
Description: There shall be one up and down call button on each floor, except on the
presidential level.
None
RSF #:
R023
Date :
12/02/2002
Importance : 4
Requirement Type :
Functional
Description: There shall be one express elevator.
None
RSF #:
R024
Date :
12/02/2002
Importance : 4
Requirement Type :
Functional
-49-

Team 2
4/23/2003
MSE530
Description:
The express elevator shall only service the presidential suit when used with swipe
None
RSF #:
R025
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The express elevator shall wait with doors closed, except on the presidential level,
where they are open.
None
RSF #:
R026
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The calling button on the top floor of the presidential elevator shall have priority
over all other floor buttons.
None
RSF #:
R027
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The home floor of the presidential elevator shall be either the presidential floor,
the lobby, the service level, the recreation level or the garage. The specific home
floor is picked as the one the elevator has been on last.
None
RSF #:
R028
Date :
12/02/2002
Importance : 7
Requirement Type :
Functional
Description: There shall be two call buttons for the express elevator on all floors.
None
RSF #:
R029
Date :
12/02/2002
Importance : 5
Requirement Type :
Functional
Description: There shall be three guest elevators.
None
RSF #:
R030
Date :
12/02/2002
Importance : 7
Requirement Type :
Functional
Description: There shall be one up and down call button on each floor to call the next available
elevator of the three, except on the presidential level.
-50-

Team 2
4/23/2003
MSE530

None
RSF #:
R031
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The guest elevators home floor is the lobby.
None
RSF #:
R032
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The guest elevators shall only service the presidential suit or the service level
when used with card access, key access or the override mechanism.
None
RSF #:
R033
Date :
12/02/2002
Importance : 3
Requirement Type :
Functional
Description: The key access at all floors shall call all three elevators in unison.
None
RSF #:
R034
Date :
12/02/2002
Importance : 2
Requirement Type :
Functional
Description: When a call button is pressed one elevator of the three shall be called.
None
RSF #:
R035
Date :
12/02/2002
Importance : 6
Requirement Type :
Functional
Description: When the call button is pressed which elevator is going to come, is determined by
minimum wait schedule first and by the minimum travel schedule second.
None
-51-

Team 2
4/23/2003
MSE530
6.12 Requirements Summary

1. The system shall be used in a building with the following floors starting at the bottom:
garage, service, lobby, recreation, 29 guest floors, presidential-level.
2. A guest shall be able to operate all elevators using the number pad located inside.
3. An operator shall be able to operate all elevators using a key-card.
3.1. The operator gains control over the elevator from the moment the key-card is
inserted to the moment it is removed as long as there is no higher priority user.
3.2. As soon as the key card is inserted the operators actions shall override any actions
activated by a lower priority user.
4. Emergency personal shall be able to operate the elevator using the emergency key.
4.1. Emergency personal shall have control over the elevator from the moment they
insert the key to the moment it has been removed.
4.2. As soon as the key is inserted the actions by the emergency personal shall override
any actions activated by a lower priority user.
5. There shall be an override control panel in the hotel security office that can direct any
elevator to any floor at any time.
5.1. The override panel shall be able to direct any elevator to any floor and make it
wait there with its doors open.
6. Operators shall have precedence over each other in the following order starting from
the lowest: user, operator, override control, emergency personnel.
7. In car users shall have priority over call button users of the same level and below.
8. When idle, all elevators shall return to their home floor and wait with doors open
(except the express elevator).
9. An elevator shall stop for a call, when this call is coming from somewhere in the
direction of travel of the elevator.
10. There shall be micro controller on each elevator taking care of bounce control.
10.1. The micro controller shall provide the following messages and actions: Stop +
Alarm, Messages to the Security panel, Records of Access, go to lobby, power
loss.
11. Failure messages by any elevator shall be monitored on the override panel.
12. After the traveler exits all elevators shall remain on the floor with the doors open for 20
seconds before they return to their home floor.
13. There shall be key access at the call button of all floors.
14. There shall be one service elevator accessing all floors.
14.1. The home floor of the service elevator shall be the service level.
14.2. The service elevator shall only service the presidential suit when used with swipe
14.3. There shall be one up and down call button on each floor, except on the
presidential level.
15. There shall be one express elevator.
15.1. The express elevator shall only service the presidential suit when used with swipe
15.2. The express elevator shall wait with doors closed, except on the presidential level,
where they are open.
-52-

Team 2
4/23/2003
MSE530
15.3. The calling button on the top floor of the presidential elevator shall have priority
over all other floor buttons.
15.4. The home floor of the presidential elevator shall be either the presidential floor,
the lobby, the service level, the recreation level or the garage. The specific home
floor is picked as the one the elevator has been on last.
15.5. There shall be two call buttons for the express elevator on all floors.
16. There shall be three guest elevators.
16.1. There shall be one up and down call button on each floor to call the next available
elevator of the three, except on the presidential level.
16.2. The guest elevators home floor is the lobby.
16.3. The guest elevators shall only service the presidential suit or the service level
when used with card access, key access or the override mechanism.
16.4. The key access at all floors shall call all three elevators in unison.
16.5. When a call button is pressed one elevator of the three shall be called.
16.6. When the call button is pressed which elevator is going to come, is determined by
minimum wait schedule first and by the minimum travel schedule second.
-53-

Object Oriented SRS - Elevator Project

Uploaded by

Copyright:

Available Formats

Object Oriented SRS - Elevator Project

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object Oriented SRS - Elevator Project

Uploaded by

Copyright:

Available Formats

Software Requirements Specifications

Software Requirements Specifications using an

Department of Computing and Mathematics

Software Requirements Specifications

Table 1: Change History

Software Requirements Specifications

Software Requirements Specifications

Software Requirements Specifications

List of Figures and Tables

Software Requirements Specifications

Software Requirements Specifications

1.5 SRS Standard

Standard Guest User

Figure 1: Context Diagram

Software Requirements Specifications

2.1.3 Hardware Interfaces

Software Requirements Specifications

2.1.4 Communication Interfaces

2.2 Product Function

Software Requirements Specifications

Software Requirements Specifications

3.1.4 Communications Interface

3.2.1 Object Elevator:

Software Requirements Specifications

3.2.2 Object Access:

Software Requirements Specifications

The operator gains control over the elevator from the

As soon as the key card is inserted the operators actions

Functional Requirement 10.

Functional Requirement 11.

3.2.3 Object Position:

Functional Requirement 12.

3.2.4 Object Failure:

Functional Requirement 13.

Software Requirements Specifications

3.2.5 Object Request:

Functional Requirement 14.

Functional Requirement 15.

3.3 Performance Requirements

Software Requirements Specifications

3.4 Logic Database Requirements

3.5 Design Constraints

3.6 Other Requirements

Software Requirements Specifications

4.6 Requirement Organization

4.7 Standard Compliance

Software Requirements Specifications

Embedded real-time environment, or compatible, available on platform

The number of cars and floors on the building.

Software Requirements Specifications

Software Requirements Specifications

Table B17: Requirements Specification Form

Constraints (if any) :

Constraints (if any) :

Constraints (if any) :

Constraints (if any) :

Software Requirements Specifications

6.2 State Transition Diagrams

Call button, floor button