CS/SE 6354 Advanced Software Engineering (Summer 2007)

Ambulance Dispatch System Software Requirements Analysis Document

Submitted to:

Dr. Lawrence Chung Associate Professor, Department of Computer Science, The University of Texas at Dallas, Richardson, TX- 75080

Submitted by:

GoE (Gang of Eight)

1. Anand Rajeevalochana (axr067000) 2. Prashanth Guha (png051000) 3. Santosh Bheemarajaiah (sxb062000) 4. Santhosh Nagaraj (sxn061000) 5. Kiran Kumar Mohan (kkm062000) 6. Arvind Prabhakar (axp065000) 7. Nikhil Narayan (nxn063000) 8. Ramiah Natarajan (rxn059000)

Version: 1.0 Date: 06/20/2007 Table of Contents

1. Introduction 1.1 Purpose of the system 1.2 Scope of the system 1.3 Objectives and success criteria of the project 1.4 Definitions, acronyms, and abbreviations 1.5 References 1.6 Overview 2. Current system 3. Proposed system 3.1 Overview 3.2 Functional requirements 3.3 Nonfunctional requirements 3.3.1 Usability 3.3.2 Reliability 3.3.3 Performance 3.3.4 Supportability 3.3.5 Implementation 3.3.6 Interface 3.3.7 Packaging 3.3.8 Legal 3.4 System models 3.4.1 Scenarios 3.4.2 Use case model 3.4.3 Object model 3.4.4 Dynamic model 3.4.5 User interface—navigational paths and screen mock-ups 4. Glossary 1. Introduction

1.1 The Purpose of the System The Ambulance Dispatch Company (ADC) uses a manual process to dispatch ambulances. Operators receive calls from patients, recording the necessary information on paper forms. Using a map on the wall, the operators attempt to efficiently dispatch ambulances, as best they see fit. New government regulations require that ambulances must be dispatched within three minutes of receiving a call, and arrive on the scene within 14 minutes. ADC does not currently meet these requirements, and needs a software system developed to streamline the ambulance dispatch process. Management at ADC also views this as an opportunity to reduce costs.

1.2 Scope of the System

1.3 Objectives and Success Criteria of the Project The Ambulance Dispatch System is being developed to streamline the ambulance dispatch process for the Ambulance Dispatch Company, allowing them to meet government speed of response standards. In addition, the system will improve the reliability of the current system by reducing dispatches caused by multiple calls, and by logging call information and dispatches. The system shall allow the Ambulance Dispatch Company to meet government regulations, which specify that from the time a call is received: 1) An ambulance must be dispatched within three minutes, and 2) An ambulance must arrive at the call location within fourteen minutes. The system shall detect possible duplicate calls, alerting operators, who will determine whether the call should be ignored. Ambulances should never arrive to find multiple crews dispatched, unless this was intended by the operators. The system shall log all call and dispatch information, allowing operators to manually dispatch calls in the event of a system malfunction. In addition, these logs shall be evaluated to determine regulation compliance. 1.4 Definitions, Acronyms and Abbreviation ADC – The Ambulance Dispatch Company Ambulance Dispatch System – The system being developed for the ADC to streamline their ambulance dispatch process Dispatch – Assigning an ambulance to an incident GUI – Graphical User Interface Incident – An emergency requiring an ambulance Operator – Employee of ADC responsible for taking calls and dispatching ambulances Possible duplicate call – A call found to be very close to other calls currently active that is likely to be about a known incident Supervisor – Senior operator, has additional experience and knowledge

1.5 References [1] Bernd Bruegge and Allen H. Dutoit, Object –Oriented Software Engineering: Using UML, Patterns, and Java, Prentice Hall, 2nd ed., 2004. [2] Columbia University, Project management Resource Centre, Sample Plans. [3] Eric J. Braude, Software Engineering: An Object-Oriented Perspective, John Wiley, 2001 [4] Mansoor Mohsin, Hasan Ramay et. al, JCTS Project Plan, 2002 [5] Philippe Krutchen, From Waterfall to Iterative Development – A Challenging Transition to Project Managers, Rational Edge, Rational Software, 2001. [6] Roger S. Pressman, Software Engineering: A Practitioner’s Approach, McGraw- Hill, 4th ed., 1997.

1.6 Overview A brief overview of the system in terms of its components Ambulance Ambulance represents ambulances in ADC service. These ambulances shall be located on the system’s map by a location and will be dispatched to incidents. Incident Incident represents an incident that has been input into the system. It shall be have a location on the map, and have an ambulance dispatched to it. Location Locations shall represent places on the map and shall be used to locate ambulances and incidents and calculate best dispatch orders. Map The map shall store locations and path information and shall be used to determine likely duplicate calls and best dispatch orders. 2. Current System Currently, the operators are making use of paper and pencil forms of organization as well as a map on the wall with pins. This is resulting in intolerable overhead as well as difficulties in determining whether or not calls are duplicates. The inefficiency is caused by paper and pencil methods of dispatching ambulances. The Ambulance Dispatch System will replace these simple forms with a computerized system to be used by the operators and their managers to quickly allocate and keep track of ambulances and calls. 3. Proposed System

3.1 Overview Overall the system should be able to handle requests from multiple callers and ultimately dispatch an Ambulance to the incident spot within the acceptable limit of time. Detailed functional requirements specification of the system is given in the next sections of the document.

3.1.1 Potential event list EVENT INPUT AND OUTPUT Call received Call report (in) Ambulance dispatch Dispatch options (out), Dispatch selection(in) Potential duplicate or other problem Potential problem report (out) Potential problem is solved Potential problem response (in) Ambulance position update Ambulance position update (in) Incident report received Incident report (in)

3.2 Functional Requirements Requirement 1 The system shall receive call information from the operators. Use case: 1 Detail: The system shall request information in a format similar to current paper and pencil forms. Requirement 2 The system shall suggest corrections when invalid inputs are entered. Use case: 1.1, 2, 4 Detail: When invalid locations or other information are input, the system will suggest corrections. Requirement 3 The system shall detect possible duplicate calls. Use case: 1, 1.2 Detail: The system shall check all incoming call reports to detect possible duplicates, following the procedure established in use case scenario 1.2. Requirement 4 The system shall suggest the three closest ambulances to each incident within one minute. Use case: 1 Detail: The system will present three dispatch options to the operator whenever possible, allowing the operator to select which ambulance to dispatch. All ambulances presented to the operator should be able to arrive within the fourteen minute window required by the government. Requirement 5 When no available ambulance is within dispatch range, the system shall alert a supervisor. Use case: 1.3 Detail: The system shall alert a supervisor, who will manually dispatch an ambulance and update the system. Requirement 6 The system shall log all call and dispatch information. Use case: All Detail: All transactions with the system shall be logged. Requirement 7 The system shall model a map of the city and the ambulance fleet. Use case: 1, 4, 5 Detail: The system shall keep a map of the city used to allocate ambulances to incidents. The ambulance fleet and map information shall be updateable by supervisors. Requirement 8 The system shall require all users to log in before performing any action. Use case: All Detail: As a security measure, all users must authenticate before using the system.

Primitive form of Class Diagram depicting Functional requirements

3.3 Non-Functional Requirements

3.3.1 Usability

3.3.1a Ease of use Because the goal of this system is to increase the rate at which incidents are handled, the system shall have a GUI so that operators should able to quickly and easily input information and navigate the system. The system shall assist operators by offering suggestions to correct inaccurate data. For example, if an operator misspells the name of a street, the system shall suggest streets with similar spellings and ask the operator to choose the intended name.

3.3.1b Ease of learning The on screen forms the system uses shall be similar in organization and content to the paper forms currently in use. This will allow operators to quickly understand what information needs to be entered since it will not be very different from the forms that are currently using. System information shall be presented in forms similar to current paper forms. For example, information that is currently presented using a map will displayed by the system using a map. This will allow operators to quickly understand and act on the output of the system. To ensure the system efficiency, ADC shall assess the keyboarding and basic computer usage skills of the operators to ensure that data entry by the operators will be conducted quickly enough to meet system goals. If operators do not possess appropriate skills, they will be trained.

3.3.1c Understandability requirements Forms used by the system to request information from the operators shall be similar to the forms that the operators currently use. Information displayed by the system shall be similar in appearance to current forms.

3.3.1d The style of the product The style shall be simple and professional. Usability shall be the primary concern, so unnecessary embellishments must be avoided.

3.3.2 Reliability Requirements

3.3.2a Reliability and availability requirements The system shall be available for use at all times, though occasionally, system down time is inevitable. Should the system fail, the system shall make available a log of all currently active calls and ambulance locations.

3.3.2b Safety critical requirements The system shall dispatch an ambulance for all calls input into the system, except those marked as duplicates by a supervisor. The system shall recommend ambulances that can arrive at the scene within fourteen minutes from the time the call was received. The system shall alert supervisors when it cannot allocate an ambulance successfully, so that they can manually dispatch an ambulance.

3.3.2c Fault tolerance requirements The system shall be able to operate with incomplete ambulance location information. The system shall notify operators when an address or location cannot be found, and shall provide a means for allocating an ambulance in this situation. The system shall have a manual allocation mode, allowing operators to override the ambulance allocation algorithm in the event of system malfunction. The system shall provide call logs and ambulance location information in the event of system failure, allowing operators to manually dispatch ambulances. 3.3.3 Performance Requirements

3.3.3a Speed and latency requirements The system shall display dispatch options within one minute of call input or notify a supervisor if this is not possible. This will allow operators to dispatch an ambulance within three minutes of receiving the call. The system shall notify supervisors of possible duplicate calls at the time of call input. The system shall immediately notify supervisors of any errors or exceptions. The system shall display alerts within five seconds of the error or exception’s occurrence. The system shall immediately update ambulance locations and status when receiving an ambulance position report from an operator.

3.3.3b Capacity requirements The system shall support twelve operators inputting data simultaneously. The system shall process 200-300 calls per day. The system shall keep logs for five years.

3.3.3c Scalability or extensibility requirements The system shall be capable of serving ADCs current service area, and support growth of up to 10% a year for the next ten years.

3.3.3d Longevity requirements The product shall be expected to operate within ADCs maintenance budget for a minimum of five years.

3.3.4Support Requirements

3.3.4a Supportability requirements A supervisor shall always be available to assist operators with usage questions and decide if the questions are the result of a technical issue that needs to be discussed with a system expert. System experts shall always be available by phone to discuss any technical issues and to asses if an issue requires emergency maintenance.

3.3.5 Implementation Requirements

3.3.7a Implementation The system shall be used in the ADC call center, where each operator will use their own terminal. The system shall clearly present information in a manner that maintains operator focus. While hardware specifics will be determined during the design phase, the system shall allow the use of separate terminals for operator interaction. The system shall store logs and other data in a format accessible by statistics-gathering applications and other analysis programs. In future installments, the system shall interface with a traffic monitoring system. The system shall be easily configurable on the server. Operator terminal software shall consist of a jar file. 3.3.6 Interface Requirements

3.3.6a The interface The product shall be as simple as possible so as to allow fast dispatch, while meeting the information distribution and organization requirements. The interface shall be GUI based. There will be a login window, a data entry window, and there will be a status window, and a statistics window. The data entry window will be used by operators and supervisors to input information. The status window will display errors to the supervisor for resolution. It will also display all active calls. The statistics window will display information such as average response time.

3.3.7 Packaging Requirements

3.3.7a The Package Operators shall have access to input incidents and the ability to edit and delete those incidents which they have created. They shall also have access to update ambulance and incident status. Finally, they shall have access to select an ambulance to dispatch. Supervisors shall be able to access all reports in the system for error prevention. Supervisors shall also be able to access records of past and present performance of operators and ambulances. In addition, supervisors shall update ambulance fleet and map information. If there is any possibility of error or duplication of calls, a manager shall be alerted by the system to review the error and respond appropriately.

3.3.8 Legal Requirements

3.3.8a. Compliance requirements Our ambulance system has been set up in accordance with the US Federal laws. The ambulance system is bought from a third party vendor for which our company has purchased the license. This license needs to be renewed every two years once as for the legal contract drawn up. This system cannot be shared with any other party under any circumstances. 3.4 System models

3.4.1 Scenarios

1. Call received and ambulance dispatch Actors: Caller, Operator, Dispatcher  The caller calls the operator and reports the incident.  The operator gets all the possible details like location, kind of incident, name and phone number of the caller, severity, number of people affected etc and logs an incident into the Ambulance Dispatch System.  The Dispatcher gets a message about the incident and will dispatch an ambulance by taking into consideration the following. o Whether the incident is a duplicate one. o How many units are required? o Near by ambulances.

2. Status update about incident Actors: Crew, Ambulance GPS, Supervisor  Crew updates status of incident  Crew updates information about the hospital where the patients are admitted.  Ambulance GPS updates its current location periodically to the ADS.  Supervisor has the authority to manually update status of incident and ambulance.

3. General enquiry about the incident Actors: Caller, Operator, Officer, Supervisor  Caller calls up to enquire the status of the incident reported.  Operator transfers the call to the officer.  Officer responds to the caller by extracting the incident report from ADS.  Use case scenarios: 1.1 Incomplete information The system shall prompt the operator for more information, giving possible suggestions for mistyping or other errors. 1.2 Duplicate call detected The system shall notify a supervisor if it detects a possible duplicate call. The supervisor shall determine whether the call is to be ignored. If the call is ignored, it shall be logged. The system shall continue to process a call if it is validated by the supervisor. 1.3 No available ambulance is within dispatch range The system shall notify a supervisor if no ambulance is within dispatch range. The supervisor shall manually allocate an ambulance and inform the system of their decision.

4. Ambulance position update received Actor: Operator Fit criterion: The operator shall update the ambulance’s position in the system.

5. Incident status report received Actor: Operator Fit criterion: The operator shall input the status report. Use case scenarios: 3.1 Incident requires additional ambulance(s) The operator shall mark the incident complete and then enter a new incident with the same address. 3.2 No incident report is input after mandated fourteen minute response time The system shall notify a supervisor, who shall determine the necessary course of action and update the system, allocating ambulances as necessary.

6. Update ambulance fleet information Actor: Supervisor Fit criterion: The supervisor shall update the system with changes to the ambulance fleet.

7. Update map information Actor: Supervisor Fit criterion: The supervisor shall update the system with changes to the city’s map. 3.4.2 Use Case Diagram

Ambulance Dispatch System

Incident Report

Operator Caller Collect Information

Manage Accounts

Supervisor

Incident Enquiry

Manage Fleet Track Incident Resolve Duplicates Staff <> <> Automatic GPS

Dispatch Ambulance Update Ambulance Location

Update Ambulance Status

Dispatcher

Crew Use Cases

Use Case name Incident Report

Participating Caller, Operator Actors

Entry condition Successful telephone call to Operator

Flow of events  Caller calls up Operator. Operator answers the telephone.  Operator collects information about incident type, severity and location.  Operator collects information from caller about name and phone number.  Operator creates the incident report in the database

Exit condition Operator creates Incident report successfully

Exceptions 1. Call gets disconnected in the middle of conversation. If the Operator has enough information, the incident report is created. 2. If there is not sufficient information, no incident report is created

Special Requirements

Use Case name Collect Information

Participating Operator, Supervisor Actors

Entry condition Caller has called about incident.

Flow of events  Operator asks caller name and phone number.  Operator asks about incident information.

Exit condition Caller name, phone number, incident information are available

Exceptions 1. Call gets disconnected in between. No information is returned 2. Information given is incorrect. No information is returned

Special Requirements Use Case name Incident Enquiry

Participating Caller, Operator, Supervisor Actors

Entry condition Caller provides information about previously reported incident

Flow of events  Operator collects information about incident.  Transfers call to Supervisor.  Supervisor tracks the incident and gets incident report.  Supervisor Provides information to Caller.  Caller and Supervisor end the call

Exit condition Caller gets the information he needs

Exceptions 1. Connection may get disconnected. Supervisor hangs up

Special Requirements

Use Case name Track Incident

Participating Staff Actors

Entry condition Incident ID is provided

Flow of events Staff provides incident ID and retrieves incident information from the database.

Exit condition Incident information is displayed on screen

Exceptions Invalid ID provided to ADS. ADS throws up an error

Special Requirements Use Case name Resolve Duplicates

Participating Dispatcher Actors

Entry condition ADS provides possible duplicates about incident to the Dispatcher

Flow of events Dispatcher sees the possible duplicates and rejects the incident if it is found to be duplicate

Exit condition Dispatcher gets information if this is a new incident or a duplicate one

Exceptions Duplicates not resolved

Special Efficiently resolving the duplicates to avoid multiple ambulance to Requirements the same location.

Use Case name Dispatch Ambulance

Participating Dispatcher Actors

Entry condition A list of incidents that needs Ambulance units are displayed.

Flow of events  Dispatcher sees the list of incidents.  Resolves the duplicates.  Dispatches ambulance to the incident location.

Exit condition Ambulance sent to the incident location

Exceptions 1. Ambulance not available. Dispatcher waits for 11 mins. If no ambulance available within 11 minutes, throws an exception to Supervisor

Special Ambulance needs to be sent in 11 min after receiving the call. Requirements Use Case name Update Ambulance Status

Participating Crew, Dispatcher Actors

Entry condition Ambulance ID is provided

Flow of events  Dispatcher updates ambulance status as allotted.  Crew updates ambulance status whether servicing, en route, completed.

Exit condition Ambulance status is valid

Exceptions Status updated when the ambulance is being served.

Special Status needs to be updated as soon the ambulance is ready to serve the Requirements next incident. Need not wait till it reaches the home location.

Use Case name Update Ambulance Location

Participating Ambulance GPS Actors

Entry condition Ambulance GPS reports location

Flow of events  Ambulance GPS reports location.  The ambulance location is updated in the database.

Exit condition Ambulance GPS is valid

Exceptions Ambulance GPS not working.

Special Requirements Use Case name Manage Fleet

Participating Supervisor Actors

Entry condition Demand for more ambulance

Flow of events  Supervisor gets new Ambulance information, adds the location and crew information into database.  If Supervisor wants to reallocate the ambulance, he updates information  If supervisor wants to remove an ambulance from service, he deletes it from the database

Exit condition Necessary updates are completed

Exceptions More than >MAX_AMBULANCES in one location

Special Balance the number of ambulances in each location. Requirements

Use Case name Manage Accounts

Participating Supervisor Actors

Entry condition New employee joined the company

Flow of events  Supervisor gets information about new Supervisor, Dispatcher, Operator or Crew.  Supervisor adds the information about the Staff to the database.  Supervisor wants to remove a staff from the database.  He deletes the details from the database

Exit condition Successful addition

Exceptions ID already existing in ADS.

Special Requirements Use Case name Login

Participating Staff Actors

Entry condition Staff provides a valid user name and password

Flow of events  Staff provides a user name and password to login to system.  If the information is correct, the homepage of the corresponding Staff is displayed

Exit condition If information correct, homepage is displayed

Exceptions If username or password is incorrect, the login screen is displayed again

Special Requirements 3.4.3 Class Diagram ( Object Model )

OperatorController

updateIncidentDetails() AmbulanceCrew 1 getIncidentInfo() accesses

1 Operator AmbulanceEntity AmbulanceDispatchSystem homeLocation belongsTo receiveCallAndReportIncident() streetNumber alertDispatchController() receiveCallAndTransferToCustCareOfficer() streetName getPossibleDuplicateCalls() zipCode calls showAmbulances() 1 currentLocation trackAmbulance() creates accesses 1 Caller 1 Ambulance reportIncident()

1..* updateAmbulanceDetails() updateLocation

stationedAt allottedTo 0..* Incident 1 0..* DispatcherController Station tracks 0..* updateDetails() allocateAmbulanceToIncident() getNoOfAmbulance()

IncidentEntity Dispatcher 1 incidentID dispatchAmbulance() Supervisor callerName callerContact resolveDuplicates() typeOfEmergency 1 addFleet() noOfPersonInjured deleteFleet() noOfAmbulances AmbulanceGPS handleNoAmbulance() Notes doAcctManagement() receiveCallAndUpdateCustomer() updateAmbulancePosition() 3 .4.4 Sequence Diagram ( Dynamic Model )

DispatchAmbulance

:Dispatcher ADS Supervisor

login()

fetchIndicentReport(ID)

IncidentReport

listPossibleDuplicates

[duplicate]:DeleteIncident()

isAmbulanceAvailable()

availableAmbulance

dispatchAmbulance(ID)

[ambulanceNotAvailable]:inform()

Incident Report

:Caller :Operator ADS

login()

requestIncidentInfo()

Incident Info

getCallerInfo()

callerInfo

createIncidentReport()

incidentID

incidentID IncidentEnquiry

:Caller :Operator Supervisor ADS

login()

inquireAboutIncident()

intimateEnquiry()

collectIncidentID()

IncidentID

fetchIncidentReport(ID)

IncidentReport

Staff ADS

login()

loginForm

login(userID,passwd)

[valid]HomePage()

[invalid]:loginForm Manage Fleet

Supervisor ADS Ambulance

ManageAmbulance()

AmbulanceManagementForm

[ADD]addAmbulance()

newAmbulance()

[TRANSFER]:transferAbulance(ID,Loc1,Loc2)

changeLocation(ID,Loc1,Loc2)

[DELETE]deleteAmbulance(ID)

deleteAmbulance(ID)

Manage Accounts

Supervisor ADS

login()

manageAccount()

accountForm

[ADD]:addStaff(EmployeeID)

[DELETE]:deletStaff(EmployeeID) Update Location

AmbulanceGPS ADS

*updateLocationInfo()

Update Ambulance Status

Crew ADS Ambulance

getAmbulance(ID)

ambulanceReference

ambulanceReference.updateStatus(statusMsg)

updateStatus(statusMsg) 3.4.5 Navigational Path and Screen Mock ups 1. Login Screen

2. Incident Report 3. Incident Report Create – Success Screen

4. Dispatch Ambulance 4. Glossory

1. Caller: The caller who calls about the incident report

2. Operator: The staff who takes calls of any incident and creates incident report

3. Dispatcher: The staff who dispatches the ambulance.

4. Scenarios: Sequence of events occurring in the domain.

5. Crew: Ambulance crew.

6. ADS: Ambulance Dispatch System, the software being developed.

7. AGPS: Ambulance GPS.

8. Supervisor: The staff who is responsible to handle exceptions.

9. Incident report: The report which shows details about the incident reported by the caller. Each incident report has an ID.

10. Fleet: Ambulance list

11. Enquiry: The caller can call up regarding a previous incident. Handled by Supervisor.

12. Station: The home location of an ambulance.

13. Duplicated Report: A possible duplicate incident report which is reported by another caller or the same caller twice.