18-649 Project 1 Requirements Exercise

(Project 1 part A)

Please submit all project-related correspondence

Changelog:

• Dated entries will be added here if the project is changed after it has been posted.
  

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 DoorControl[b,r] object.  There are four DoorControl[b,r], one for each of the two front and back doors.  Note that you should generate requirements for a generic door module that can be instantiated for any of the four doors using parameters for the hallway and side.

There are four sets of Initial conditions given. Complete the 7 process steps for one scenario.  Choose the appropriate scenario based on your AndrewID, as described in the project writeup. 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.

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
   • Once you have completed steps 1-6, find a classmate who has also completed steps 1-6.  Trade projects and them review your work according to the process audit checklist below. Have them send their review to you by email, and include it in your project writeup.  An independent reviewer often helps spot problems. You should fix any problems they find, as it will probably improve your grade. 
     
   • In order to receive full credit for this project, you must have someone review your work AND you must review someone elses work.  Be sure to include the name and AndrewID of the person whose work you reviewed and the name and AndrewID of the person who reviewed your work.  If they are the same person, be sure you clearly say so.
     

Interface:

The interfaces to the DoorControl is 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.
Subscripts used in describing controller replication:

• f - floor, 1-8
• b - hallway, FRONT or BACK
• r - side, LEFT or RIGHT
• d - direction, UP or DOWN

A note on notation for replicated controllers

• "set mDoorMotor[b,r] to CLOSE" - refers to the particular mDoorMotor output for hallway b, side r.
• "if any mDoorMotor[b,r] is set to CLOSE" - this statement would be considered true if any of the four door motor messages (front-left, front-right, back-left, back-right) were set to CLOSE.
• "if all mDoorMotor[b,r] are set to CLOSE" - considered true if all four door motors were set to CLOSE
• "if any mDoorReversal[b,*] is true" - use the star notation to denote replication in one dimension but not another.  This statement would be considered true either the left or right door reversal on the b hallway of the car was true.  This notation does not check the door reversals on the opposite hallway.
  

Output for the DoorControl

The DoorControl commands these objects:

• DoorMotor[b,r]
  • Moves the door [b,r]
  • One per DoorControl
  • Can be commanded to Close, Open, Nudge, and Stop
  • Both doors on one side shall be commanded the same.
  mDoorMotor[b,r]
• a network copy of the DoorMotor setting
  

Input for the DoorControl

The DoorControl receives information from these objects via network messages.  These are inputs to the door and cannot be modified in the DoorControl.

• mAtFloor[f,b]
  • True if the elevator is at the floor f where there is a landing at hallway b, false otherwise. There are at most two per floor.
• mDriveSpeed
  • Tells the current speed and direction of the car. Speed is a numeric value, which can be compared to the system constants FastSpeed, SlowSpeed, or LevelSpeed, as well as numeric values such as 0. Direction can be Stop, Up, or Down.
• mDoorClosed[b,r]
  • True if the door, b, r, is completely closed. Otherwise false. One per door. Values might be different for different sensors!
• mDoorOpen[b,r]
  • True if the door, b, r, is completely open. Otherwise false. One per door. Values might be different for different sensors!
• mDoorReversal[b,r]
  • True if the door, b, r, is blocked by a passenger. Otherwise false. One per door. Values might be different for different sensors!
• mCarCall[f,b]
  • True if a passenger has pushed a car call button for floor f at hallway b. Otherwise false. The car call buttons the buttons inside the elevator.
• mHallCall[f,b,d]
  • True if a passenger has pushed a hall call button for direction d on floor f at hallway b. Otherwise false. The hall call buttons are the up/down buttons in the hallway.
• mCarWeight
  • Tells how much weight is in the elevator.

Constant Definitions

• MaxCarCapacity
  • The maximum weight the elevator can hold.

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 DoorMotor[b,r] is commanded to Open, the EmergencyBrake shall be activated.
• R-S2. If doorMotor[b,r] is commanded to Open at a floor where there is no landing on side b, the EmergencyBrake shall be activated.
  
• R-S3. If any DoorReversal[b,*] is true and any DoorMotor[b,r] is commanded to something other than Open for greater than 50 msec (accumulated while either DoorReversal[b,*] 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.