18-649 Project 1 Requirements Exercise

(Project 1 part A)

Please submit all project-related correspondence

Intro to Writing Requirements:

Write detailed requirements for one set of initial behavioral conditions.

For Project 1 you will follow the process outlined here to generate requirements for the FrontDoorControl[j] object. There is one FrontDoorControl[j] for each of the two front doors. Note that there are also one BackDoorControl[j] for each of the two back doors, but for this project we will only be following the process for the FrontDoorControl[j].

There are four sets of Initial conditions given. Pick ONE set and complete and hand in Process Steps 1-7. Grading is five points per Process Step.

An example is provided for you here.

Initial Conditions:

Initial Conditions Set #1

• A passenger in the front hallway makes a front hall call when the elevator is at another floor.
• A front door reversal occurs when the passenger enters.
• The car isn’t overweight after the passenger gets on.
• The passenger pushes a back car call button after successfully entering.

Initial Conditions Set #2

• A passenger in the front hallway makes a front hall call when the elevator is at another floor.
• No front door reversal occurs when the passenger enters.
• The car is overweight after the passenger gets on.
• The passenger pushes a back car call button after successfully entering.

Initial Conditions Set #3

• A passenger in the front hallway makes a front hall call when the elevator is already at that floor.
• No front door reversal occurs when (if) the passenger enters.
• The car is not overweight after (if) the passenger gets on.
• The back car call button for the passenger’s floor is already lit, so the passenger doesn’t push it again.

Initial Conditions Set #4

• A passenger wants to get out of the elevator at a floor.
• The passenger has pushed the front car call button for this floor.
• There aren’t any passengers in the front hallway, so there are no front hall calls at this floor.
• The exiting passenger doesn’t activate a front door reversal.

Process Steps:

1. Scenario
   • Create a small storyline for how someone might use the elevator system to match the initial condition set.
2. Write requirements using precise words
   • From the scenario, generate a few (probably 2-5) requirements. Use ‘shall’ when the behavior is required; use ‘should’ when the behavior is optional but desirable.
3. Write requirements using consistent terms
   • Revise the requirements from Step 2 to use the terms in the Interface section below.
4. Number requirements
   • I use ‘R’ for requirements and the initials of the object, so my requirements are numbered R-FDC1, R-FDC2, R-FDC2.1, R-FDC2.2, R-FDC3, etc.
5. Testable
   • Write a test case for each requirement.
6. Traceability to high-level requirements
   • For each of the high-level requirements given in the High-Level Requirements section below, state how each of your new requirement supports (or doesn’t contradict) the high-level requirement.
7. Process audit
   • Send your Project 1 to one of your team mates. Have them review the work and then email you back the checklist for Steps 1-6 given below. An independent reviewer often helps spot problems. You should fix any problems they find, as it will probably improve your grade. Yes, just submitting the checked-off checklist counts for points. Now what other class gives you that?

Interface:

The interfaces to the FrontDoorControl and BackDoorControl are given below. Use these terms for step #3. This is part of the interface of the elevator simulator, so this will help prepare for the next projects. Although this project is only about the front doors, the interface for the back doors is given as well for you to familiarize yourself with them. For the subscripts, “j” is used for door stuff – there are two doors on both the back and front of the elevator, so “j” can be “RIGHT” or “LEFT”. “f” is used for floors – the value of “f” is from 1 to 8. “d” is used for directions – the value of “d” is either up or down

Output for the FrontDoorControl

The FrontDoorControl commands these objects:

• FrontDoorMotor[j]
  • Moves the front door [j]
  • One per FrontDoorControl
  • Can be commanded to Close, Open, and Stop
  • They shall both commanded to do the same thing
• Buzzer
  • An annoying buzzer
  • One per elevator
  • Can be commanded to True (on) or False (off)

Input for the FrontDoorControl

The FrontDoorControl receives information from these objects (but cannot directly change their value):

• AtFrontFloor[f]
  • True if the elevator is at the floor f where there is an entrance/exit to the front hallway, false otherwise. There is one per floor.
• DriveSpeed
  • Tells what speed the drive is commanded to – can be Fast, Slow, or Stop.
• FrontDoorClosed[j]
  • True if the front door, j, is completely closed. Otherwise false. One per door. They might be different!
• FrontDoorOpen[j]
  • True if the front door, j, is completely open. Otherwise false. One per door. They might be different!
• FrontDoorReversal[j]
  • True if the front door, j, is blocked by a passenger. Otherwise false. One per door. They might be different!
• FrontCarCall[f]
  • True if a passenger has pushed a front car call button for floor f. Otherwise false. The front car call buttons are the ones inside the elevator.
• BackCarCall[f]
  • True if a passenger has pushed a back car call button for floor f. Otherwise false. The back car call buttons are the ones inside the elevator.
• FrontHallCall[f, d]
  • True if a passenger has pushed a front hall call button on floor f. Otherwise false. The front hall call buttons are the up/down buttons in the front hallway.
• CarWeight
  • Tells how much weight is in the elevator.
• MaxCarCapacity
  • The maximum weight the elevator can hold.

Output for the BackDoorControl

The BackDoorControl commands these objects:

• BackDoorMotor[j]
  • Moves the back door [j]
  • One per BackDoorControl
  • Can be commanded to Close, Open, and Stop
  • They both shall be commanded to do the same thing
• Buzzer
  • An annoying buzzer
  • One per elevator
  • Can be commanded to True (on) or False (off)

Input for the BackDoorControl

The BackDoorControl receives information from these objects (but cannot directly change their value):

• AtBackFloor[f]
  • True if the elevator is at the floor f where there is an entrance/exit to the back hallway, false otherwise. There is one per floor.
• DriveSpeed
  • Tells what speed the drive is commanded to – can be Fast, Slow, or Stop.
• BackDoorClosed[j]
  • True if the back door, j, is completely closed. Otherwise false. One per door. They might be different!
• BackDoorOpen[j]
  • True if the back door, j, is completely open. Otherwise false. One per door. They might be different!
• BackDoorReversal[j]
  • True if the back door, j, is blocked by a passenger. Otherwise false. One per door. They might be different!
• FrontCarCall[f]
  • True if a passenger has pushed a front car call button for floor f. Otherwise false. The front car call buttons are the ones inside the elevator.
• BackCarCall[f]
  • True if a passenger has pushed a back car call button for floor f. Otherwise false. The back car call buttons are the ones inside the elevator.
• BackHallCall[f, d]
  • True if a passenger has pushed a back hall call button on floor f. Otherwise false. The back hall call buttons are the up/down buttons in the back hallway.
• CarWeight
  • Tells how much weight is in the elevator.
• MaxCarCapacity
  • Tells how much weight is in the elevator.

High-level Requirements:

There are eight high level requirements. Note that fulfilling all of the safety requirements fulfills R-T2 and R-T2.1. So, you only need to do traceability to six high-level requirements: R-T1, R-T3, R-S1, R-S2, R-S3, and R-S4.

Top-level requirements

• R-T1. All passengers shall eventually be delivered to their intended destination floor.
• R-T2. Any unsafe condition shall cause an emergency stop.
  • R-T2.1. An emergency stop should never occur.
• R-T3. Performance should be optimized to the extent possible, where performance is defined by the following formula:
  Performance = (4 * average_passenger delivery_time) + maximum_passenger_delivery_time
  Delivery time= Time passenger exits – Time passenger arrives at floor

Safety requirements

• R-S1. If the elevator is not at a floor and any FrontDoorMotor[j] or BackDoorMotor[j] is commanded to Open, the EmergencyBrake shall be activated.
• R-S2. If the elevator is at a floor with no front exit and FrontDoorMotor[j] is commanded to Open, the EmergencyBrake shall be activated.
  Similarly for the back door, if the elevator is at a floor with no back exit and BackDoorMotor[j] is commanded to Open, the EmergencyBrake shall be activated.
• R-S3. If any FrontDoorReversal[j] is true and any FrontDoorMotor[j] is commanded to something other than Open for greater than 200 msec (accumulated while FrontDoorReversal[j] remains true), the EmergencyBrake shall be activated.
  Similarly for the back door, if any BackDoorReversal[j] is true and any BackDoorMotor[j] is commanded to something other than Open for greater than 200 msec (accumulated while BackDoorReversal[j] remains true), the EmergencyBrake shall be activated.
• R-S4. If CarWeight > MaxCarCapacity and the Drive is commanded to something other than Stop, the EmergencyBrake shall be activated.

NOTE: while not explicity required, the doors have to open to let people in and out or else the passengers will never be delivered, which violates TR1.

Checklist for Process Audit:

Enter ‘Yes’ after each Step if you feel the Step has been satisfactorily completed. If you find a problem, please briefly describe the problem so the author can fix it.

Step 1: Is there a scenario?

Step 2: Do the requirements use only shall and should, or the appropriate words from the lecture?

Step 3: Do the requirements use the terms given in the Interface section to describe sensors, actuators and controllers on the elevator?

Step 4: Are the requirements numbered?

Step 5: Is there a test given for each of the requirements?

Step 6: Traceability – Does *each* requirement either support or not contradict *each* of the high-level requirements?

Put the name of the person who did the checking here (name and andrew ID):

Important note: you must actually do the check for these steps for this to be an honest response. Being dishonest about this is fraud, and is equivalent to cheating in this course. For example, if you just put "yes" next to each checklist item when nobody else did the checking, that's fraud. (Students have attempted to do this in the past looking for "easy points".) If, however, someone else actually does the checklist and honestly misses something, then that's not fraud -- that's just reality.