Object Oriented SRS - Elevator Project

Software Requirements Specifications 4/23/2003Team 2 MSE530

-1-

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


-2-

Change History Date Author Description 03/03/02 Prem

Lanman SRS Baseline

Table 1: Change History


-3-

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


-4-

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


-5-

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


-6-

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 830-

1998. 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.


-7-

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.

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.

EPR

Command

Standard Guest User

Special Guest User (Card Key)

Emergency User (Hard Key)

Master Control User

Micro-Controller

Command

Command

Command Activated Request

Failure


-8-

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.


-9-

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.


-10-

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.


-11-

3.1.4 Communications Interface All system interfaces communicate in order to activate ordered requests. The micro-controller 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.

• Functional Requirement 2. 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.

• Functional Requirement 3. 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.


-12-

• Functional Requirement 4. 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.

• Functional Requirement 6.

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. • Functional Requirement 7.

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: • Functional Requirement 8.

1. Introduction. Get Button Parameters 2. A guest shall be able to operate all elevators using the number pad located

inside.


-13-


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 operator’s actions

shall override any actions activated by a lower priority user. • Functional Requirement 10.

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. • Functional Requirement 11.

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:

• Functional Requirement 12. 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: • Functional Requirement 13.

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.


-14-

3.2.5 Object Request: • Functional Requirement 14.

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 micro-controller. 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.


-15-

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.


-16-

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.


-17-

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


-18-

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.


-19-

Table B17: Requirements Specification Form

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


-20-

6.2 State Transition Diagrams

Guest Control

Card Control

Key Control

Master Control

OnBoard Chip Control

Key Removed

Card Inserted

Control Used

Key Inserted

Passenger leaves

Call button, floor button

Card InsertedControl Used

Key inserted

Key inserted

Control released

Control Used

Key inserted

Card Removed

Figure 2: State Transition Diagram 1


-21-

Normal OperationsMoving to Homefloor

Moving Empty to User

Idle

Moving Full to Destination

Moving Full to User

On Floor with Destintaion

Error

Reset

Moving to Homefloor

Moving Empty to User

Idle

Moving Full to Destination

Arrived at floor / Open doors

Call

Arrived at floor / Open doors

Call / Close Doors

Idle for 30 secs / Close doors

User Presses Floor / Close Doors

Moving Full to User

On Floor with Destintaion

Arrive at Floor / Open Doors

Idle for 20 secs / Close Doors

User Presses Floor / Close Door

Arrived at floor / Open Doors

Call on the way to destination

On power loss / Sink to next floor, open doors

On Unknown Error / Sink to next floor, open doors

Figure 3: State Transition Diagram 2


-22-

6.3 Use Case Diagram

Card UserGuest User Emergency Personnel

Control Panel Users

UC1_Guest_Use_Elevator

UC2_CardUser_Use_Elevator

UC3_EmergencyPersonnel_Use_Elevator

UC4_Guest_Call_Elevator

UC5_CardUser_Call_ElevatorUC6_EmergencyPersonel_Call_El

evator

UC7_TravelOn_Elevator

UC8_User_Use_MasterControl

UC9_User_SelectFloor_DuringTravel

Figure 4: Use Case Diagram


-23-

6.4 Use Case Scenarios Use Case: UC1_Guest_Use_Elevator Actors: Guest User(Initiator), Elevator Purpose: Provide transportation for the user. Overview: The User enters the elevator, chooses a floor, is transported there

and exits. Type: Primary and Essential Pre-Condition: 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


-24-

Use Case: UC2_CardUser_Use_Elevator Actors: Card User(Initiator), Elevator Purpose: Provide transportation for the user. Overview: The User enters the elevator, chooses a floor, is transported there


Actor Action System Response 1) The user calls the elevator. (UC5_CardUser_Call_Elevator)


5) The user disembarks. END Post-Condition: The elevator is empty. Alternative Course NONE Table 4: Use Case Scenario – UC2_CardUser_Use_Elevator


-25-

Use Case: UC3_EmergencyPersonnel_Use_Elevator Actors: Emergency Personnel(Initiator), Elevator Purpose: Provide transportation for the user. Overview: The User enters the elevator, chooses a floor, is transported there


Actor Action System Response 1) The user calls the elevator. (UC6_EmergencyPersonel_Call_Elevator)


5) The user disembarks. END Post-Condition: The elevator is empty. Alternative Course NONE Table 5: Use Case Scenario – UC3_EmergencyPersonnel_Use_Elevator


-26-

Use Case: UC4_Guest_Call_Elevator Actors: Guest User(Initiator), Elevator Purpose: To describe the events when calling an elevator. Overview: The user calls the elevator to his floor. Type: Primary and Essential Pre-Condition: The elevator is not on the floor of the user.

The user is the highest priority user in the system at the time. Typical Course of Events

Actor Action System Response 1) The user presses the ‘up’ or ‘down’ call button of an elevator.

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


-27-

Use Case: UC5_CardUser_Call_Elevator Actors: Card User(Initiator), Elevator Purpose: To describe the events when calling an elevator. Overview: The user calls the elevator to his floor. Type: Primary and Essential Pre-Condition: The elevator is not on the floor of the user.

The elevator has no floors to go to in memory. The user is the highest priority user in the system at the time.

Typical Course of Events

Actor Action System Response 1) The user inserts his card into the card slot of an elevator on a floor.



4) The doors open. 5) The call button extinguishes. END Post-Condition: The elevator is on the floor of the user. 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


-28-

Use Case: UC6_EmergencyPersonel_Call_Elevator Actors: Emergency Personnel(Initiator), Elevator Purpose: To describe the events when calling an elevator. Overview: The user calls the elevator to his floor. Type: Primary and Essential Pre-Condition: The elevator is not on the floor of the user.

The elevator has no floors to go to in memory. The user is the highest priority user in the system at the time.


Actor Action System Response 1) The user inserts his key into the key hole on a floor.



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 used by another key user. Nothing happens. The use case ends. Table 8: Use Case Scenario – UC6_EmergencyPersonnel_Call_Elevator


-29-

Use Case: UC7_TravelOn_Elevator Actors: User (Initiator), Elevator Purpose: Describe the actions a generic user has to take to select a floor. Overview: Inside the elevator, the user chooses one or more floors on the

panel. The elevator registers the floors. Type: Primary and Essential Pre-Condition: The user is in the elevator.

There elevator has no floors in memory, it still has to go to. The elevator doors are open. The user is the highest priority user in the system at the time.


Actor Action System Response 1) The user selects a floor on the panel. 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. END Post-Condition: 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


-30-

Use Case: UC8_User_Use_MasterControl Actors: Master Control User(Initiator), Elevator Purpose: Describe the actions of a user of the master control panel. Overview: The User assumes control of one or many elevators and moves

them to a specific floor. Type: Primary and Essential Pre-Condition: The master control panel is available.

The user is the highest priority user in the system at the time. Typical Course of Events

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 to wait on. He hits the ‘Enter’ key.

4) The elevator moves to the floor and waits there indefinitely.

5) The user relinquishes control over the elevator.

6) The elevator resumes normal behavior.

END Post-Condition: All elevators are under their own control. Alternative Course Table 10: Use Case Scenario – UC8_User_Use_MasterControl


-31-

Use Case: UC9_User_SelectFloor_DuringTravel

Actors: User (Initiator), Elevator Purpose: Allow the user to press destination buttons while the elevator

moves. Overview: The user presses a destination button while the elevator is moving. Type: Primary and Essential Pre-Condition: The elevator is traveling with the user onboard

The elevator has at least one floor to go to in memory. The user is the highest priority user in the system at the time.


Actor Action System Response 1) The User presses a destination while the elevator is moving.

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


-32-

6.5 Activity Diagrams

User Press Call Button

Light Call Button

Elevator Busy?

Queue Call Request

Move To Floor

No

Open Doors

Turn off Call Button

Busy on other Call button

Yes

Determine highest priority Call

Call is highest Call

Higher Priority User than Initiator Active?

No

Yes

No

Yes

No

Yes

Elev atorUser

Figure 5: Activity Diagram - User Call Elevator


-33-

Select Floor

User Exits

Close Doors

Destination Floors idirection of travel ?

Travel To Floor

Destination Floor Left?

Reverse Direction of travel

No

Open Doors

Arrived?

Last Floor?

Queue Floor Request

Find Destination Floor

No

Yes

Yes

No

Yes

Yes

No

Elev atorUser

Figure 6: Activity Diagram 2 - User Travel in Elevator


-34-

User Press Floor

Floor In direction of Travel?

New Floor closest Floor?

Yes

Assign new Destination

Queue Floor

No

Continue Movement

Change Movement

Yes

No

Elev ator (from UC7_Trav elOn_Elev ator)User (from UC7_Trav elOn_Elevator)

Figure 7: Activity diagram 3 - User presses a floor button while traveling


-35-

User request Elevator Control

Select Floor

Elevator under Key Access?

Close Doors

Move To Floor

Open Doors

Elevator Traveling?

No

Yes

No

Yes

Elev atorUser

Figure 8: Activity Diagram 4 - User uses the Master Control Panel


-36-

6.6 Category Diagram

Elevator

ES Controller

Control PanelCall Methods

A one elevator sub-system

The Call Methods - Input sub-system

Additional Interface to the system.

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.

Figure 9: Category Diagram


-37-

6.7 Class Diagram

ServiceElevatorElevatorType : int

OpenDoors()CloseDoors()Travel()Idle()

GuestElevatorElevatorType : int


ExpressElevatorElevatorType : int


FailureFailureType : int

GetFailureType()SetFailureType()

KeyCardAccessType : int

GetKeyCardParameters()SetKeyCardParameters()InitiateRequest()

HardKeyAccessType : int

GetHardKeyParameters()SetHardKeyParameters()InitiateRequest()

ButtonsButtonType : intAccessType : int

GetButtonParameters()SetButtonParameters()InitiateRequest()GetButtonType()SetButtonType()

MasterControlAccessType : int

GetMasterControlParameters()SetMasterControlParameters()InitiateRequest()

ControlPanelMinimumWait : intMinimumTravelTime : intRequestType : intFailureType : int

CalculateMinimumWait()CalculateMinimumTravelTime()ValidateRequestType()ValidateFailureType()CheckRequestPrecedence()ActivateRequest()

ControllerElevatorType : intAccessType : intMinimumWait : intMinimumTravelTime : int

GetElevatorType()SetElevatorType()GetAccessType()SetAccessType()GetMinimumWait()SetMinimumWait()GetMinimumTravelTime()SetMinimumTravelTime()

Figure 10: Class Diagram


-38-

6.8 Sequence Diagrams

UC1_Guest_Use_Elevator

Guest User presses call button

System activates controller

System activates request with one of three guest elevators

: GuestUserElevator_CATCall_Methods

_CATControl_Panel

_CAT

Use_Button

Use_Guest_Elevator

Activate_Controller

Failure

Figure 11: Sequence Diagram – UC1_Guest_Use_Elevator

UC2_CardUser_Use_Elevator

Card User swipes key card


System activates request with one of three guest elevators or express elevator

: CardUserElevator_CATCall_Methods

_CATControl_Panel

_CAT

Use_KeyCard

Use_Guest_Elevator

Activate_Controller

Use_Express_Elevator

Failure

Figure 12: Sequence Diagram - UC2_CardUser_Use_Elevator


-39-

UC3_EmergencyPersonnel_Use_Elevator

Emergency Personnel User inserts hard key


System activates request with all elevators

: EmergencyUser

Elevator_CATCall_Methods_CAT

Control_Panel_CAT

Use_HardKey

Use_Guest_Elevator

Act ivate_Controller


Use_Service_Elevator

Failure

Figure 13: Sequence Diagram - UC3_EmergencyPersonnel_Use_Elevator

UC4_Guest_Call_Elevator

Guest User presses call button


System processes guest user request

System activates request with one of three guest elevators

: GuestUser

Elevator_CATES_Cont roller_CAT

Call_Methods_CAT

Control_Panel_CAT

Call_Guest_Elevator

Activate_Controller

Push_Button

Process_Request

Failure

Figure 14: Sequence Diagram - UC4_Guest_Call_Elevator


-40-

UC5_CardUser_Call_Elevator

KeyCard User swipes key card


System processes keycard user request

System activates request with one of three guest elevators or express elevator

: CardUser

Elevator_CATES_Controller_CAT

Call_Methods_CAT

Control_Panel_CAT

Call_Guest_Elevator

Activate_Controller

Swipe_KeyCard

Process_Request

Call_Express_Elevator

Failure

Figure 15: Sequence Diagram - UC5_CardUser_Call_Elevator

UC6_EmergencyPersonnel_Call_Elevator

Emergency Personnel User inserts hard key


System processes emergency user request

System activates request with one of three guest elevators, express elevator, or service elevator

: EmergencyUser

Elevator_CATES_Cont roller_CAT

Call_Methods_CAT

Control_Panel_CAT

Call_Guest_Elevator

Activate_Controller

Insert_HardKey

Process_Request

Call_Express_Elevator

Call_Service_Elevator

Failure

Figure 16: Sequence Diagram - UC6_EmergencyPersonnel_Call_Elevator


-41-

UC7_TravelOn_Elevator


System activates request

System activates elevator

: SoftwareElevator_CATES_Controller

_CATControl_Panel

_CAT

Activate_Controller

Activate_Request

Activate_Elevator

Failure

Figure 17: Sequence Diagram - UC7_TravelOn_Elevator

UC8_User_Use_MasterControl

Master User operates from control panel


System activates request with all elevators

: MasterUserElevator_CATCall_Methods

_CATControl_Panel

_CAT

Use_MasterControl

Use_Guest_Elevator

Activate_Controller


Use_Service_Elevator

Failure

Figure 18: Sequence Diagram - UC8_User_Use_MasterControl


-42-

UC9_User_SelectFloor_DuringTravel

User selects floor


System activates request

System activates elevator

: UserElevator_CATCall_Methods

_CATES_Controller

_CATControl_Panel

_CAT

Activate_Controller

Activate_Request

Activate_Elevator

Select_Floor

Failure

Figure 19: Sequence Diagram - UC9_User_SelectFloor_DuringTravel


-43-

6.9 Requirements Traceability Matrix (RTM)

Name Jeremy T. Lanman (Team 2) Date 3/22/02Course MSE530

Entry# Para # TPT Problem Statement Type Build # Use Case Name Class Method Category1 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.

HW B1 N/A

2 2.2 A guest shall be able to operate all elevators using the number pad located inside.

SW B1 UC1_Guest_Use_Elevator Elevator_CAT

3 2.3 An operator shall be able to operate all elevators using a key-card

SW B1 UC2_CardUser_Use_Elevator Elevator_CAT

4 2.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.

SW B1 Duplicate (#3) Elevator_CAT

5 2.3.2 As soon as the key card is inserted the operator’s actions shall override any actions activated by a lower priority user.

SW B2 UC5_CardUser_Call_Elevator Call_Methods_CAT

6 2.4 Emergency personal shall be able to operate the elevator using the emergency key.

SW B1 UC3_EmergencyPersonnel_Use_Elevator Elevator_CAT

7 2.4.1 Emergency personal shall have control over the elevator from the moment they insert the key to the moment it has been removed.


8 2.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.


9 2.5 There shall be an override control panel in the hotel security office that can direct any elevator to any floor at any time.

SW B1 UC8_User_Use_MasterControl Control_Panel_CAT

10 2.5.1 The override panel shall be able to direct any elevator to any floor and make it wait there with its doors open.

SW B1 Duplicate (#9) Control_Panel_CAT

12 2.6 Operators shall have precedence over each other in the following order starting from the lowest: user, operator, override control, emergency personnel.

SW B1, B2 N/A

13 2.7 In car users shall have priority over call button users of the same level and below.

SW B3 UC7_TravelOn_Elevator Elevator_CAT

14 2.8 When idle, all elevators shall return to their home floor and wait with doors open (except the express elevator).

SW B1, B2 N/A

15 2.9 An elevator shall stop for a call, when this call is coming from somewhere in the direction of travel of the elevator.


16 3.1 There shall be micro controller on each elevator taking care of bounce control

HW N/A

17 3.1.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

SW B5 N/A

18 3.2 Failure messages by any elevator shall be monitored on the override panel.

SW B5 N/A

EPR Requirements Traceability Matrix (EPR RTM)


-44-

19 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.


20 3.4 There shall be key access at the call button of all floors.

SW B1 Duplicate (#6) Call_Methods_CAT

21 3.5 There shall be one service elevator accessing all floors.

HW N/A

22 3.5.1 The home floor of the service elevator shall be the service level.

HW N/A

23 3.5.2 The service elevator shall only service the presidential suit when used with swipe card access, key access or the override mechanism.

SW B4 UC9_User_SelectFloor_DuringTravel Call_Methods_CAT

24 3.5.3 There shall be one up and down call button on each floor, except on the presidential level.

HW N/A

25 3.6 There shall be one express elevator. HW N/A

26 3.6.1 The express elevator shall only service the presidential suit when used with swipe card access, key access or the override mechanism.

SW B4 Duplicate (#23) ES_Controller_CAT

30 3.6.2 The express elevator shall wait with doors closed, except on the presidential level, where they are open.


31 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) Call_Methods_CAT

32 3.6.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.


33 3.6.5 There shall be two call buttons for the express elevator on all floors.

HW N/A

34 3.7 There shall be three guest elevators. HW N/A

35 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.

HW N/A

36 3.7.2 The guest elevators home floor is the lobby.

SW B2 UC4_Guest_Call_Elevator Elevator_CAT

37 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.


38 3.7.4 The key access at all floors shall call all three elevators in unison.

SW B2 UC6_EmergencyPersonnel_Call_Elevator ES_Controller_CAT

39 3.7.5 When a call button is pressed one elevator of the three shall be called.


40 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.

SW B1, B2 N/A


-45-

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

Guest Elevator Service Elevator Express Elevator Level

UP

Dow

n

Key

Car

d

Up

Dow

n

Key

Car

d

Up

Dow

n

Key

Car

d

Comment

Presidential X X X Any method calls the next available elevator

Guest X X X X X X X X X X X X Recreation X X X X X X X X X X X X Lobby X X X X X X X X X X X X Service X X X X X X X X X X X X Garage X X X X X X X X X


-46-

6.11 Requirement Specification Forms: Company ERAU Date 12/02/2002 Project Elevator-Problem Version 1 Project # 1 Customer Gutcher 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. Constraints (if any) : 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. Constraints (if any) : One number pad per car. Test Conditions : None 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. Constraints (if any) : Only one key card at a time. Test Conditions : None 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. Constraints (if any) : None Test Conditions : None RSF #: R005 Date : 12/02/2002 Importance : 5 Requirement Type : Functional Description: As soon as the key card is inserted the operator’s actions shall override any

actions activated by a lower priority user. Constraints (if any) : None Test Conditions : None RSF #: R006 Date : 12/02/2002 Importance : 7 Requirement Type : Functional


-47-

Description: Emergency personal shall be able to operate the elevator using the emergency key.

Constraints (if any) : Only one key at a time. Test Conditions : None 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : None RSF #: R011 Date : 12/02/2002 Importance : 8 Requirement Type : Functional


-48-

Description: In car users shall have priority over call button users of the same level and below. Also counts for key and keycard access.

Constraints (if any) : Test Conditions : None 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). Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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.

Constraints (if any) : These messages are safety critical. Test Conditions : None RSF #: R016 Date : 12/02/2002 Importance : 3 Requirement Type : Functional Description: Failure messages by any elevator shall be monitored on the override panel. Constraints (if any) : None Test Conditions : 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.


-49-

Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : None RSF #: R019 Date : 12/02/2002 Importance : 6 Requirement Type : Functional Description: There shall be one service elevator accessing all floors. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : None RSF #: R023 Date : 12/02/2002 Importance : 4 Requirement Type : Functional Description: There shall be one express elevator. Constraints (if any) : None Test Conditions : None RSF #: R024 Date : 12/02/2002 Importance : 4 Requirement Type : Functional


-50-

Description: The express elevator shall only service the presidential suit when used with swipe card access, key access or the override mechanism.

Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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.

Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : None RSF #: R029 Date : 12/02/2002 Importance : 5 Requirement Type : Functional Description: There shall be three guest elevators. Constraints (if any) : None Test Conditions : 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.


-51-

Constraints (if any) : None Test Conditions : None RSF #: R031 Date : 12/02/2002 Importance : 3 Requirement Type : Functional Description: The guest elevators home floor is the lobby. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : 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. Constraints (if any) : None Test Conditions : None


-52-

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 operator’s 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

card access, key access or the override mechanism. 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 card access, key access or the override mechanism.

15.2. The express elevator shall wait with doors closed, except on the presidential level, where they are open.


-53-

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.

Documents

Object Oriented SRS - Elevator Project