CS/SE 3RA3: Sample Solutions to Assignments 2

Total of this assignment is 100 pts. Each assignment is worth 10%.

If you think your solution has been marked wrongly, write a short memo stating where markingin wrong and what you think is right, and resubmit to me during class, office hours, or just slipunder the door to my office.

1

Q1[10]

1 Introduction

1.1 Purpose

The purpose of this software requirement specification document is to provide a complete

description of the requirements in order to design controller software of an elevator

system for a hotel.

The intended audience of this document is all of the stakeholders for a project involving

the development of elevator controller software. This includes the software development

team and the hotel owner, the hotel's architect, the hotel's restaurant's manager, the front

desk, the hotel staff, and the hotel's elevator technician.

1.2 Scope

This elevator system is meant to be deployed in the hotel. The controlling software that is

specified within this document is responsible for controlling the elevator's movement

between floors. This document entails the specification of the software only. The

software is not responsible for any of the elevator's physical mechanisms and therefore

any requirements relating to said mechanisms are not included in this document.

The goal of creating this software is to make an elevator system that is fully operational

for use in the hotel. This would make traveling from different floors much faster and

much more convenient.

1.3 Definitions, Acronyms, and Abbreviations

These definitions will be used throughout the requirements and the rest of the document.

Call button- This refers to either the "up" or "down" buttons a person presses to call the

elevator to a floor.

Stop button- This refers to the set of buttons located inside the elevator that are pressed

to indicate that a person would like the elevator to stop and open its doors on a floor.

Requested floor-Refers to a floor for which the elevator has been requested to stop at.

Up request- Refers to when a request is made to move to a floor higher than the elevator

currently is (This could be via call button or stop button)

Down request-Refers to when a request is made to move to a floor lower than the

elevator currently is (This could be via call button or stop button)

Floor stop- Refers to the elevator stopping and opening its doors once when it arrives at

a requested floor.

Request queue- Refers to the order in which the elevator plans to perform floor stops at

requested floors. The request at the top of the queue is the next planned destination.

2

Requests are removed from this theoretical queue after the elevator makes a floor stop.

Service mechanism- This refers to a mechanism that must be operated in order to bring

the elevator out of its "out of service mode".

Floor display- Refers to the electronic display on each floor the elevator is able to stop at.

This display is meant to show the current direction of travel and the location of the

elevator to the users on the outside of the elevator.

Elevator display- Refers to the electronic display inside the elevator. This display is

meant to show the current direction of travel and the location of the elevator to the users

on the inside of the elevator.

Site manager's console- This refers to an electronic device that is a part of the elevator

system. It is meant to display information about the elevator. The console is also capable

of receiving commands from this console to put it into "out of service" mode.

1.4 Overview

This document is divided into five sections, including the above Introduction section.

In section 2 the general description of the software system to be built is given. In this

section, the factors that affect the product and its requirements are described. This is to

provide a context for the requirements that are later given.

In section 3 the specification of the software's requirements are defined. This includes a

description of the functionality of the system, as well as the required behavior. This

section also covers design constraints and software quality attributes of the software.

Section 4 and 5 come from the model design part of my PhD course project, just show to

those who are interested in the model design of this system. And they are not required in

the solution of this assignment.

2 Overall Description

2.1 Product Perspective

The controller software specified in this SRS is a part of a larger system- the elevator

system. The software therefore must be able to interface with the elevator system's

physical mechanisms such as the buttons, the site manager's console, the floor displays,

and the elevator display.

2.2 Product Functions

This subsections contains a description of the main functions the controller software must

have.

a) Control Doors

The controller software decides where and when the elevator closes and opens its doors.

3

b) Control Movement

The controller software is able to determine how the elevator moves. The software must

be able to monitor and influence the speed, acceleration, and direction of movement. The

controller is able to determine where the elevator's destination in response to request

and/or floor buttons being pressed.

c) Maintain Request Queue

The controller software controls the order in which the elevator makes floor stops in

response to request and call buttons being pressed. The controller does this by

maintaining the Request Queue. It adds requested floors as

d) Emergency Function

The controller can cause the elevator system to go into an "out of service mode" in case

of emergency While in this mode, all request and call buttons pressed will not cause the

elevator to move. The elevator will remain stopped until the service mechanism is used to

cause the elevator to out of this mode

e) Ensure load is safe

The controller receives signals from the load sensors in the elevator and determine

whether the load has exceeded the capacity of the elevator.

f) Display Direction and Floor

The controller interacts with the displays to indicate to passengers its current direction of

travel and the current floor.

2.3 User Characteristics

Users of the elevator system, and therefore the controller software, are described below:

Hotel Guests- These are guests staying at the hotel. They have a wide variety of degrees

of technological expertise. It is expected that the majority of them understand Arabic

numbers. (1,2,3,4,5,6...)

Hotel Staff- These users are staff of the hotel. They may use the elevator to transport

cleaning supplies or other equipment relating to their work around the hotel. They may

also use the parking garages . It is expected that the majority of them understand Arabic

numbers. (1,2,3,4,5,6...)

Restaurant Staff- These users are staff of the hotel's restaurant. They may use the

elevator to deliver room service to guests of the hotel.

Elevator Technician-These users service the elevator and will put the elevator in and out

of "out of service mode" It is expected that the elevator technician will receive training on

how to operate the elevator system in such a manner.

4

2.4 General Constraints

Budget- The controller software must cost no more than the budget allocated by the Hotel

Owner to develop.

Time constraints- The controller software must be ready to use in time for the hotel's

grand opening.

2.5 Assumptions and dependencies

The requirements for the controlling software described in this SRS are based on the

following assumptions:

There is only one elevator car that is to be used in the hotel's system.

The physical mechanisms for the elevator system have already been decided and have

some kind of interface ready to communicate with the controller software.

The site manager has a console in his office that is already decided and has some kind of

interface ready to communicate with the controller software.

The elevator system has load sensors that take measurement of the weight put on the

floor of the elevator.

There is an external mechanism that is part of the elevator that creates unique signals for

all the buttons in the elevator.

2.6 Apportioning of Requirements

This section identifies requirements that may be delayed until future versions of the

system

In the future, the hotel management may decide to expand the elevator shaft to operate

more than one elevator car. The controller software may be expanded on to operate

multiple elevator cars simultaneously.

3. Specific Requirements

3.1 Functional Requirements

Functional Requirements

1. The elevator will make a floor stop if a call button is pressed on said floor. The

elevator will make this floor stop at the requested floor in 17 floor stops or less. The

elevator will make a floor stop if a stop button is pressed for a certain floor in 17 stops or

less provided that the passenger pressed a stop button that causes the elevator to travel in

the direction they indicated when they pressed the call button, that is, if they made an up

request with the call button they select a higher floor when they press the stop button.

2. When the elevator approaches a requested floor it will make a floor stop. It will slow

down at a rate to be determined by the elevator expert/safety standards until it has

5

completely stopped moving. After it stops, it will open its doors for a period of 10

seconds. Once 10 seconds is up, the elevator will attempt to close its doors. If the close

door button inside the elevator is pressed, it will attempt to close its doors earlier than the

10 seconds previously mentioned.

3. If the elevator door is open and the close door button is pressed, the elevator will make

an attempt to close its doors after 3 seconds.

4. When the elevator attempts to close its doors the system will be able to detect any

obstructions that are in the way of the doors closing. In the event that the system detects

an obstruction the doors will not fully close- instead they will open fully as soon as the

system detects there is an obstruction. (This requirement is not a part of the logic of the

elevator moving from floor to floor, however I've included it here to clarify the "attempt

to close its doors" statement.)

5. The controller maintains the Request Queue in response to requests and calls.

If the queue is empty, a request/call will become the first requested floor in the queue

( becomes the elevator's current destination). Whenever an elevator makes a floor stop at

a floor corresponding to a request or call, that floor is removed from the queue.

3.2 External Interface Requirements

EXI1. The controller must be able to receive and interpret signals from sensors that

measure which floor the elevator has most recently made a floor stop, or if the elevator is

moving, the last floor it passed.

EXI2. The controller must be able to receive and interpret signals created due to buttons

being pressed.

EXI3. The controller must be able to receive and interpret signals from a load sensor

which measures how much force (weight) the elevator floor is experiencing

EXI4. The elevator system must incorporate the hotel’s intercom system to allow for

communications between the elevator and the control room.

EXI5. The system must interact with the fire alarm system to ensure passengers don’t

use the elevators during a fire.

EXI6. The system must interact with the hotel’s power system for the electricity to

function.

3.3 Performance Requirements

a) Speed Requirements

SP1. All valid interactions between the user and the product should have a maximum

6

response time of ½ a second before showing a sign to the user that the request

was received. (A response could be a beep or light).

SP2. The software must be able to show the locations and status of the elevators in

real time. (No more than 1 second delay between the actual elevator position,

and it’s location in the software.)

SP3. The system shall move the elevators at the same speed as the system as is. (The

acceleration rate, deceleration rate and cruising speed should be identical).

b) Safety Critical Requirements

SC1. The warning signal sent to the site manager must send the elevator’s position in

the shaft. (Which floor it is on, or which floors it is between.)

SC2. The system must comply with all applicable elevator system safety laws

c) Precision Requirements

PR1.The speed measurements shall be accurate to one decimal place.

PR2. The elevator shall not be deemed at a floor until the holding car has lined up

with the appropriate markers to be fully at the floor.

d) Reliability and Availability Requirements

RA1. The controller software must be available for use 24 hours per day, 365 days per

year.

e) Capacity Requirements

CA1. The controller software must be able to hold up to 100 requests in its Request

Queue.

3.5 Software Quality Attributes

a) Security

SE1. Only security, emergency, and managerial personnel will be authorized to read or

manipulate the controller software's data.

SE2. The software must be protected from all unauthorized attempts to read or

manipulate its data.

b) Maintainability

MA1. The system software is to be updated on an “as-needed” basis.

MA2. The software is to be easily modifiable in case the client needs further features.

7

c) Portability

PO1. The software is expected to run on Windows, Macintosh, and Linux environments

3.6 Other Requirements

a) Cultural and Political Requirements

CP1. The product will not use any text, images, or media that will offend the countries

that purchase it.

CP2. The product shall show a disclaimer explaining that any similarities to any cultural

or political symbol or figure is coincidental.

b) Legal Requirements

LE1. The elevator system shall comply with all national and federal elevator regulation

laws.

LE2. The elevator system shall comply with all relevant elevator standards.

LE3. The elevator system must comply with all relevant privacy acts.

c) Look and Feel Requirements

LF1. The elevator should function the same way as the other elevators from the system as

is.

d) Usability Requirements

US1. The software must be simple for a person aged 12‐65 in able condition to

understand and use all its features.

US2. The emergency functionality should be easy to use for people aged 6‐70.

US3. The elevator system shall have a display that clearly indicates the current direction

the elevator is travelling (Up, down, or none) and which floor the elevator has most

recently passed or is stopped at depending on the measurement from the "floor sensor"

(EXI1)

e) Operational Requirements

e1) Expected physical environment

EP1.The product will be used by elevator callers, who will be standing up, inside the

hotel in climate controlled conditions.

EP2. The product will be used by elevator passengers, who will be standing up, inside

the elevator car in climate controlled conditions.

EP3. The product will be used by site managers who will be sitting down, inside an

8

office in climate controlled conditions.

e2) Expected Technological Environment

ET1. Elevator callers will call an elevator with the up/down buttons on the floors of

the hotel.

ET2. Elevator passengers will interact with the elevator using the button dashboard

inside the elevator.

ET3.Site managers will interact with the elevator using the computers in their office.

4. Ambiguous and Questionable Information (Not Required)

a) In the item c, there is no specified button used to control the door status (open or

closed) of each elevator, and no specified determinants about which situations can lead

the door status transition.

b) In the item d, there is no detailed definition of “equal priority”.

c) In the item f, there is no specified information about which situations mean the

elevator “out of service”. (For example, the door cannot be open or closed, the elevator

does not move, the elevator does not stop in the required floor, etc.)

d) In the item f, how does the mechanism can decide to cancel the “out of service” status?

i.e., in which situations, the mechanism can cancel the “out of service” status of the

elevator.

e) What about the following specific situation: the elevator is currently stopped at the

floor i and the user inside presses the button of floor i again.

f) There is no specified information about in which situations the elevator would change

its moving direction.

g) There is no information about total weight limitation or the number of users limitation

for each elevator system.

5. Optimization Rules for Ambiguous and Questionable Points (Not Required)

a) In the item a, “The illumination is cancelled when the corresponding floor is visited by

the elevator.” will be interpreted as “Switch off the floor button as soon as the elevator

reaches the floor coming from below or above”.

b) The item b will be interpreted as following several aspects: (1) In each floor (except

the top and ground floor), outside the elevator, there are two buttons (“up” and “down”)

can be chosen by user. In other words, in the top floor, outside the elevator, there is only

a “down” button. Similarly, there is only a “up” button in the ground floor. And in the

other floors, there are both “up” and “down” buttons outside the elevator. (2) Switch off

the “up” (“down”) button as soon as the elevator reaches the floor coming from below

9

(above). (3) If the both “up” and “down” button are pressed in some floor, and the

elevator is coming from up-down direction, as soon as the elevator reaches the floor, the

“down” button will switch off; otherwise, if the elevator is coming from down-up

direction, as soon as the elevator reaches the floor, the “up” button will switch off. (4)

The algorithm design to decide which requests to service first is un-valuable and waste of

time since there could be so many kinds of requests changes during the service. However,

we still need to guarantee following four points for all requests: (a) provides service to all

requests from floors and within elevators eventually (b) handle all floors’ requests

sequentially according to elevators’ status, moving routes and their current locations (we

will give an example to explain it in details) (c) always guarantee that the elevator which

is working (with the same route as the request floor) or idle in the nearest location

relative to the request floor will respond and handle the new request. If both of them are

available, the one which is working will respond and handle the new request. (Because

starting an idle will require more cost) For instance, if an elevator is moving by down-up

direction, and there is a new request in the below floor. Then the one which is working in

the same direction (up-down) and in the nearest location relative to the request floor will

respond and handle this new request; else if there is no elevator worked in the same

direction, but there exist another elevator which is idle now and it stops in the nearest

location relative to the request floor, it will be active, and then respond and handle this

new request (if there is more than one elevator are idle, always is the one in the nearest

floor to respond and handle this request); else there is no idle elevator and no one is

working in the same direction, then this request will add to the working list of all elevator.

Then the one first moves to that request floor will handle this new request. At the same

time, this elevator will send a broadcast notice to other elevators, and the others will

remove this request from their working lists (d) once one elevator responds a request, it

has to complete it and all the other elevators cannot respond and handle this request again

(except the responded elevator changes to “out of service” status before it handles this

request). (Remarks: in our design, the word “respond” means that the elevator adds the

request floor (floorID) in its working list and the word “handle” means that elevator

arrives that request floor and completes that request)

c) The elevator status stated in the item c is the description of “idle” status in our design.

d) Each elevator has a dynamic working list. When it responds a new floor request, the

elevator will insert that floorID to an appropriate position of its working list. The elevator

will change its moving direction until it meets the first request in its working list which is

in the reversed direction. In addition, after a request is handled, it will remove from the

working list. And the elevator always guarantee to provide the service to the head floorID

in its working list.

e) Since there are no “open” and “close” buttons in this elevator system, the door of the

elevator would be open in three situations: (a) The elevator arrives at the destination of its

10

working list (b) After the elevator changes to “out of service” status, it will force to open

after it moves to the next floor (c) There is some one standing at the door line. And the

door would be closed in three situations: (a) After specified open time of the system (b)

The elevator is in the idle status (c) During the move.

f) In the item f, after an emergency button is pressed, the site manger will check the

elevator. If the emergency status is approved, all the requests in the elevator’s working

list will be cleaned, those requests would change to new requests and be responded and

handled by other elevators. If the emergency status is not approved, then the “out of

service” will be cancelled in specified time of the system and the elevator will recover to

working status.

Q2[4=2+2]

Marking Scheme：

Required to provide at least two correct specification and corresponding fit

criterion.

Specification #1 -The doors shall open and close gradually to allow people to easily enter

and exit the car.

Fit Criterion- 90% of time the time (when the lift car is at ground floor) the door shall

not take more than 2 seconds to completely open. Otherwise on any other floor door can

take 2-3 seconds to open

Specification #2 - If the system fails due to heavy load that is more than 1587 kgs, the

users should not be put in any danger

Fit Criterion- The user using the lift should be alerted and then feedback sound should

be given to the user indicating the amount of users to be dismounted from the elevator.

Specification #3 - The system should implement an algorithm to minimize average wait

times.

Fit Criterion- The system should implement an algorithm to minimize wait times in such

a way that average wait time for an elevator will not exceed 60 seconds.

11

Q3[10]

Marking Scheme：

1) The diagram should contain as many as entities and relationships described in

your Q1.

2) Properties of entities

3) Cardinality constraints (such as 0...m, 1...m, etc.) would be another evaluation of

your ER diagram.

12

Q4(6+6=12)

Context Diagram

13

Data-Flow Diagram

14

Q5[10]

Marking Scheme：

1) At least three types of user should be covered and well-described.

or

2) If you included Passenger/User and Site Manager/ Operator only, AND you

provided a very good use case diagram, also could be full-mark.

15

Q6[5+5=10]

16

Q7[5+5+5=15]

17

18

19

Q8[10=3+7]

Marking Scheme：

1) Describe the safety critical [3]

2) Provide the correct and detailed predicate calculus [7]

The follow is a sample solution:

Q9[4=2+2]

20

Q10[10]

Marking Scheme：

Provide at least two well-defined roles.

The follow is a sample solution:

Q11[5]

Marking Scheme：

Provide at least five inspection points.

The follow is a sample solution:

a) Are all vocabulary terms used consistently?

b) Are there fit criterion for all requirements that need it?

c) Are the system's assumptions and dependencies realistic?

d) Is the Request Queue explained clearly enough?

e) Are there any system behaviors left undefined?

21