Another Elevator System in Volere Pattern

Transcription

1 Another Elevator System in Volere Pattern

2 A software-based system is required to control lifts (elevators) manufactured by Skyhi Lifts. Lifts are constrained to shafts (one lift per shaft) and are moved up and down by winding motors (one winding motor per lift). ****************************************************************************** Initial Notes of Interview ****************************************************************************** Lift Controller --Notes of interview Client-Skyhi elevator Co.\ Contact (technical) Jason Hukins , X 4783.I/v 15/6. Previous software (s/w) contractor unsatisfactory. (Late and buggy!). Full hardware (h/w) details available. Looking for full specs by 1/10. Will pay installment for specs and negotiate for the rest (Andy can cover this - needs to contact Geoff Shepperd (finance director).) H/w all to hand - full specs available (got copies). Interface blocks all operate at 0.5 V (20 ma) - direct port connection no prob. Max 4 lifts per controller, max 20 floors. One lift per shaft (next generation won't be!). All lifts, same # of floors. Requirements: All lifts (if > 1) to be used approximately equally. Indications: Sensors: Lift only reverses direction if no outstanding lift calls in current direction (lift send-button inside lift, lift call-button outside lift!) Must not change motor polarity whilst moving! (It'll blow) In emergency, stop all motors (if poss.) Lift calls should be serviced by the lift that will get there soonest (approx.). Tricky to predict - could pick up more calls on the way. Services calls in the order it gets there - not the order they are made. Light for each floor - one set in each lift + one set on each floor (all switch together - can treat as one set). Switch on basis of nearest floor so one off, one on when about half way between. 3 sets for each floor - warning either side + at. Go hi (5V) when lift present (\ie 20 cm either side). If stopping, send slow signal to motor within 0.3 secs of warning and stop 0.2 +/- 0.1

3 secs after at signal. (Stop delay has to be configurable.) Top and bottom floors only have one set of warning sensors. (Obviously?) Lift must always stop when arriving at top or bottom! Lift normally moves at 1.2m/sec. In slow mode, 0.3 m/sec. Takes approx. 1 sec to slow (\ie about 0.75 m) and moves about 0.15 m between stop signal and actually stopping. Lift will stop at a floor if there is a lift-send or a lift-call and moving right way or if top/bottom. Doors: Doors cycle every time it stops. (Note -- cannot cancel a request.) Controller only needs to send open/close signal -- doors handle the rest. Door sensors (just the one pair per lift) go hi when shut/open. Never move lift with doors open! Also one block sensor per door but connects direct to door controller - we don't need to worry. If lift call or send request while doors open or closing, open again and restart wait. (Wait is 4 secs +/- 0.5). To start lift go straight to fast, to stop must go to slow first (except in emergency?). Next meeting wed - 10:00 - ring on Tue to confirm.

4 REQUIREMENTS IN VOLERE PATTERN

5 Project Drivers 1. The Purpose of the Project a. The User Business or Background of the Project Effort Skyhi Lifts manufactures elevators. The company requires a softwarebased controller to control these elevators. b. Goals of the Project The goal of the project is to develop a software based controller. 2. The Client, the Customer and other Stakeholders a. The Client Skyhi Lifts b. The Customer Real state developers c. Other Stakeholders 1. Business Analysts 2. Usability Experts 3. Legal Experts 4. Developers and Testers 5. Hardware Vendors 6. Others 3. Users of the Product a. The Hands-On Users of the Product - Through sensors and buttons general public will be using the product. As the product is embedded software, there is no direct interaction with human. Here the users are the sensors, motor and buttons. - Maintenance and Service Technicians needs to change the setup through some interface which is not specified. Missing requirement. b. Priorities Assigned to Users Key Users: Sensors, motor and buttons. Secondary Users: Maintenance and Service Technicians c. User Participation

6 d. Maintenance Users and Service Technicians In order to service elevators the maintenance users and service technicians requires the product to have some features in this regard. So, there are some missing requirements which are to be listed under nonfunctional requirements. Project Constraints 4. Mandated Constraints a. Solution Constraints Description: The product shall operate at 0 5v (20mA), having direct port connection. Rationale: All interface blocks operates at that voltage. Fit Criterion: All signals received and generated by the controller should be at 0 5v (20mA). b. Implementation Environment of the Current System Max 4 lifts per controller, max of 20 floors, one lift per shaft and all the lifts have the same number of floors. c. Partner or Collaborative Applications Door Controller d. Off-the-Shelf Software e. Anticipated Workplace Environment - embedded software f. Schedule Constraints All requirements identified, must be implemented within stated deadline. g. Budget Constraints 5. Naming Conventions and Definitions a. Definitions of all Terms

7 - as necessary b. Data Dictionary for Any Included Models - as necessary 6. Relevant Facts and Assumptions a. Facts Previous software contractor unsatisfactory (late and buggy). b. Assumptions Functional Requirements - All the H/W involved will work according to the specifications required. - Others. 7. The Scope of the Work a. The Current Situation A software based controller is required to control elevators/lifts. Lifts are constrained to shafts as one per shaft. These lifts are moved by winding motors. A controller must able to operate 1 to 4 lifts and each lift operable up to 20 floors. Users can call a lift to a floor through a button outside the lift (call buttons) and can send a lift to a floor through buttons inside the lift (send buttons). There are indicators to show the users current floor location of each lift. Doors of the lifts are controlled by the door controllers. b. The Context of the Work Floor Sensors Sensed Data Motor Instructions Winding Motor Indicators Indicator info Lift Controller System Send Signal Send Door Signal Open/Close Signal Call Signal Door Sensors Door Controller Call

8 c. Work Partitioning Event Name Input and Output Summary 1. Gets a call signal Call Signal (IN) Getting a call, the controller decides which lift is to service the call and assign the call to that lift. 2. Gets a send signal Send Signal (IN) Gets a send signal and assign it to the lift from which it was sent. 3. Sending indicator signal Indicator info (OUT) When between two floors sends indicator information to corresponding lift and floor. 4. Getting floor sensor signal Sensors data (IN) Motor Instruction (OUT) Gets sensor data. If stopping, provide appropriate motor instruction. 5. Sending door Open/Close Signal (OUT) Sends open/close door signal open/close signal 6. Getting door signal Door Signal (IN) Motor Instruction (OUT) accordingly. Provide winding motor instruction according to door signal (open/closed). 8. The Scope of the Product a. Product Boundary In this case the work scope is the product boundary. b. Product Use Case List Call 1 Process call signal 2 Process send signal Send Indicator 3 Process indicator Service 4 Process sensor Floor Sensors Door Controller 5 Process door open/close signal Sensor Info 6 Process motor command Winding Motor Door Sensor

9 c. Individual Product Use Cases 1. Product Use Case Name: Process call signal Trigger: Call signal Preconditions: Interested Stakeholders: The client, customer. Actor: Call button Activity Diagram: Start Call lift Lift > 1 Lift = 1 Determine one to service the call Assign Call to Service List End Outcome: The call is saved in the service list. The call is assigned to the lift which can service the call the soonest. Note: Other product use cases to be detailed similarly. 9. Functional and Data Requirements a. Functional Requirements Requirement #: 1 Requirement Type: 9 Event/Use case #: 1 Description: The product shall establish a call signal if it is originated from a Call-Button outside the lift. Rationale: To service a call from the outside of the lift from any floor. Originator: Requirement Analyst Fit Criterion: Any call-button press to be recorded as call signal and correctly identified. Customer Satisfaction: Priority: High 3 Customer Dissatisfaction: 5 Conflicts: Supporting Material: History: Created October 19, 2008 Volere

10 List other functional requirements accordingly. b. Data Requirements Provide class model. Nonfunctional Requirements Look and Feel Requirements a. Appearance Requirements Not applicable b. Style Requirements Not applicable 11. Usability and Humanity Requirements a. Ease of Use Requirements b. Personalization and Internationalization Requirements c. Learning Requirements d. Understandability and Politeness Requirements e. Accessibility Requirements 12. Performance Requirements a. Speed and Latency Requirements b. Safety-Critical Requirements Some of the requirements under this section are: 1. Product shall not allow lifts to move while the doors are open. 2. Lifts are not allowed to stop from fast mode. 3. The product shall not allow lifts to move above the top floor. 4. The product shall not allow lifts to move below the bottom floor. Etc. Snow card has to be used for all non-functional requirements as well. c. Precision or Accuracy Requirements d. Reliability and Availability Requirements e. Robustness or Fault-Tolerance Requirements f. Capacity Requirements g. Scalability or Extensibility Requirements h. Longevity Requirements 2 In case of non-functional requirements each requirement doesn t have to be accurately identified to a specific sub-type. Example, it is important to identify a performance related requirement as Type 12 but it is not critical to identify it as a Safety-Critical or Speed and Latency or any other sub-type.

11 13. Operational and Environmental Requirements a. Expected Physical Environment b. Requirements for Interfacing with Adjacent Systems c. Productization Requirements d. Release Requirements 14. Maintainability and Support Requirements a. Maintenance Requirements b. Supportability Requirements c. Adaptability Requirements 15. Security Requirements a. Access Requirements b. Integrity Requirements c. Privacy Requirements d. Audit Requirements e. Immunity Requirements 16. Cultural and Political Requirements a. Cultural Requirements b. Political Requirements 17. Legal Requirements a. Compliance Requirements b. Standards Requirements Project Issues 18. Open Issues Emergency is mentioned but no clarification is given. Need to gather more information on this issue. 19. Off-the-Shelf Solutions 20. New Problems Functionality wise the new software-based controller and the old one will be doing the same thing. As such, this section is not applicable. 21. Tasks

12 Here provide a suitable product development life cycle and development plan as you feel appropriate for the product. 22. Migration to the New Product The new product will be replacing the existing product, which is buggy! And also the product is an embedded system when implemented will be working independent of the current product. So, no such issue will arise and also haven t been specified in the document. 23. Risks Following two were encountered by the previous contractor: - schedule pressure - low quality 24. Costs 25. User Documentation and Training Not specified in the document. But, every production must have documentations of the product on how they operate. Also, the maintenance personal might require training and/or document on how to add or delete a lift from a controller and others. This can be identified as missing requirement. 26. Waiting Room 27. Ideas for Solutions Specify any ideas for solution for the product that has been discussed in document.