Requirements Specification: Ambulance Dispatch System
Requirements Specification: Ambulance Dispatch System
Requirements Specification: Ambulance Dispatch System
Submitted to:
Dr. Chung
Submitted by:
Chris Rohleder, Jamie Smith, and
Jeff Dix
Date Submitted:
February 14, 2006
Requirements Specification
TABLE OF CONTENTS
1.0
1.1
1.2
1.3
1.4
1.5
2.0
2.1
2.2
INTRODUCTION......................................................................................................................................1
PURPOSE ...................................................................................................................................................1
SCOPE .......................................................................................................................................................1
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS .....................................................................................1
REFERENCES .............................................................................................................................................2
OVERVIEW................................................................................................................................................2
GENERAL DESCRIPTION .....................................................................................................................3
SYSTEM FUNCTIONS .................................................................................................................................3
USER CHARACTERISTICS ..........................................................................................................................3
3.0
4.0
5.0
6.0
REQUIREMENTS DETAIL.....................................................................................................................6
Requirements Specification
ii
Requirements Specification
LIST OF FIGURES
Figure 1: Activity Diagram of a 911-Incident Call
iii
Requirements Specification
iv
1.0
Requirements Specification
INTRODUCTION
This section introduces the requirement specification document for the Ambulance Dispatch System. It
provides the purpose and scope of the system. Any definitions and references are listed in this section as
well as an overview of the remaining requirements specification document.
1.1
PURPOSE
This requirements specification document describes the functions and requirements specified for this
Ambulance Dispatch System (ADS). This dispatch system is needed to help ensure that the ambulance
dispatching company meets all federal mandates about the speed at which an ambulance is dispatched. In
order to make this possible, the system greatly decreases the amount of paperwork that must be filed.
This system shall also help the company ensure that they are providing an adequate amount of
ambulances for each of their service areas by enabling the management to track the status of each
ambulance and a log of ambulance activity.
1.2
SCOPE
The ADS shall assist the operators and dispatchers in quickly and efficiently dispatching ambulances to a
911-incident call. This system shall reduce the paperwork that is currently filed for each 911 call, which
shall in turn help the company meet the federal mandates. This reduction of paperwork will allow the
company to keep costs low. (These mandates state that an ambulance must be dispatched within an
average of 3 minutes of a 911-incident call. The ambulance must arrive at the scene of the incident within
an average of 11 minutes of its dispatch.) The ADS shall allow operators to input the 911 call
information. The system shall assist the operator in determining the uniqueness of calls and assist the
dispatcher in locating a nearby ambulance. The system prioritizes calls and allows the dispatcher to
update the status of each ambulance. All 911 call information, ambulances dispatches, and ambulance
status shall be logged and stored in a central computer database.
The ADS shall not replace the way in which dispatchers contact ambulances and ambulances contact
dispatchers, through hand-held radios. The system shall not take into account congested roads and areas
of high traffic. The dispatchers should be aware of traffic conditions when an ambulance is dispatched.
An interface among ambulances and hospitals shall not be implemented in this system. Regarding
hospitals, ambulances should continue the way in which they currently operate. The system shall not
determine if a 911-incident call is a duplicate of a currently pending claim; however, the system shall
provide an interface to assist the operator in making this decision. The system shall not decide what
ambulance to dispatch; this remains the dispatchers decision.
1.3
Requirements Specification
Operator The persons who receive the 911-incident calls and input the call information into the system.
The operator also determines the uniqueness of each call.
UNIX A multi-user, general purpose computer operating system.
Windows 2000, XP Microsofts proprietary computer operating system.
1.4
REFERENCES
1.5
OVERVIEW
This document provides a high-level description of the Ambulance Dispatch System. It identifies the
involved users and helps to explain their roles. The document then describes general software and
hardware constraints as well as any assumptions and dependencies concerning the system. The majority
of this document focuses on the specific requirements list. A master list of specific requirements is given
first, followed by each requirement explained in detail in the next section. The external interfaces are
addressed in the subsequent section. External interface requirements are requirements involving user
hardware, software, and communications interfaces. This requirements document concludes with general
design constraints specified by the customer along with the business requirements this software must
meet.
Requirements Specification
2.1
SYSTEM FUNCTIONS
The ambulance dispatch system shall help ensure ambulances are dispatched quickly and efficiently inorder to reduce costs for the ambulance providers and increase their ability to save more lives. To
facilitate these needs, the system shall allow operators to input information pertaining to a particular
incident. Based upon the severity of the incident, the system shall prioritize each call to ensure
ambulances are dispatched, first to the people who need the most help. The system shall also use the
information provided to help the operators determine the uniqueness of a call. The system shall keep
track of all ambulances; this shall allow the dispatchers to select the nearest or most available ambulance
to send to an incident. The dispatcher can update the ambulances progress allowing the management to
know how quickly their ambulances are responding to an incident. This can be used to make sure the
ambulance providers are meeting all federal mandates and are providing the right amount of services for
their area.
2.2
USER CHARACTERISTICS
There are three main groups of users which will use the system. The first group of users is the System
Administrators. The System Administrators are concerned with data integrity and system stability. This
group has the highest computer skill set and is capable of supporting a computer network. Their
interaction with the system is very limited and is only necessary for backing up and archiving data from
the database or to provide basic computer support to the other users of the system.
The management team makes up the second group. They interact with the system to view reports and
statistics about the quality of service their employees are providing. They have basic computer
experience and are familiar with word processors, e-mail clients and other management reporting
systems. They spend most of their time ensuring that incoming calls are answered quickly and that
ambulances are allocated efficiently.
The final group is the operators and dispatchers. They are proficient in typing and have intermediate
computer knowledge. They are used to working quickly and efficiently and are capable of working under
high-pressure situations. They are the only group which deals directly with customers over the phone on
a daily basis. This group communicates with the customers to determine the type of assistance the
customer requires, and then they deploy an ambulance if this service is necessary.
Requirements Specification
Requirements Specification
Requirements Specification
6.1.1
DESCRIPTION
The system shall allow the operator who receives an incoming 911call to input information, which is the
beginning process of dispatching an ambulance.
6.1.2
INPUT
The operator shall input the necessary information in the tab labeled Log Calls in the systems user
interface. The system shall have nine types of data in which the operator must input to begin the
ambulance dispatch process.
The first fields are designated the Name of Caller. There shall be separate text fields for the first name,
last name, and middle initial of the caller. A string of characters shall be the type of data that is input in
these fields. This shall not be a required field.
The Contact Phone Number of the caller shall be the second type of information that the operator must
input. This phone number must be in the format ###-###-####, where # is a number from 0 to 9, and
shall be input in a text field. This shall be a required field for the ambulance dispatch process.
The Location of Incident is a required field that must be input by the operator. In this text field, the
operator will input the address of the incident. If the exact address is not known, the operator will input
an approximate address of where the incident is located. (In the Other Relevant Information text field
at the bottom of the screen, the operator may input a more descriptive explanation of where the incident
has occurred.)
The Type of Incident is the fourth set of fields in which the operator shall input information. Two
fields exist under Type of Incident. The first is a drop down box where the operator shall select one
from many general incident descriptions (i.e.: car accident, domestic violence). The second field is a text
field where the operator shall input a more descriptive explanation of the specific event. These two fields
under Type of Incident are required fields.
The Priority field is a required field where the operator shall select a priority number that corresponds
to the severity of the incident. This field consists of a drop down box. The operator must select one
priority number ranging from 1 to 5 where 1 is the least urgent and 5 is the most urgent type of incident.
The Number of Patients field is a required field where the operator shall input the number or
approximate number of patients that are involved in the incident. This field shall consist of one text box
and shall only accept an integer number (0, 1, 2, 3, 4, 5). This field is important because an ambulance
can only hold two patients at one time.
The Name of Patient(s) text field is where the operator will input the name(s) of the persons involved in
the incident. This field shall only consist of one text field; the operator separates the individual name
with commas or semicolons. This is not a required field for an ambulance to be dispatched.
Requirements Specification
The final field for operator input is the Other Relevant Information field. This field shall simply consist
of one text field where the operator can input any other important or relevant information that pertains to
this incident and the ambulance driver(s) who are dispatched. This is not a required field.
A button for processing the information shall be located near the bottom of the screen. The operator shall
press this button once s/he has entered the necessary information.
6.1.3
DISPLAY
The nine types of operator input fields shall be positioned in the center of the Log Calls tab screen.
Each type of field will be placed one right below the other. The Process Claim button shall be located
near the bottom of the screen, under all of the input fields.
6.1.4
SYSTEM PROCESSING
The system is essentially idle while the operator is inputting the information that relates to an incident.
Once the operator clicks the Process Claim button, the system determines if the operator has input the
correct type of information. If the operator has not input the correct information as defined by the input
section of this requirement description, the system shall alert the operator. The system shall display
which information must be corrected, and the operator shall be able to correct the input data. Once the
information is accepted by the system, the information is encrypted and sent over the TCP/IP network to
the server. This server places the data into its proper table in the database. The system shall then proceed
to the next part of the dispatch process: prioritizing the calls, determine the uniqueness of the calls, and
locating the nearest three ambulances. These processes are described in the subsequent requirement
descriptions.
6.1.5
SYSTEM OUTPUT
The system shall display an error message if any of the information that the operator has entered is
incorrect as defined by the input section of this requirement description. In the Log Calls tab where the
operator inputs the information, the system shall alert the operator of incorrect information by displaying
a red arrow by the type of information that is incorrect. The text color of the type of information that is
incorrect shall also change to red from black.
Once the operator has clicked the Process Claim button and the information entered is correct, the
system shall advance to a screen to allow the operator to continue or cease the dispatch process based on
whether the call is unique. This screen and process is described in REQ 2: Uniqueness of Call. (The
advancement to this screen will also let the operator know that the system accept the input information.)
All information the operator inputs shall be stored in the database on the server.
6.1.6
OTHER
N/A
6.1.7
CONSTRAINTS
The speed at which calls are inputted and logged depends on the operators typing speed as well as the
state of mind of the caller and how quickly the operator is able to question the caller. The quickness of
the processing of claims also depends on the amount of traffic the network and server are experiencing.
6.1.8
DATA HANDLING
6.2
6.2.1
DESCRIPTION
Requirements Specification
The system shall help determine the uniqueness of each 911-incident call. This process shall occur after
the operator has clicked the Process Claim button. The system shall display incidents that are similar to
the current call, and the operator shall make the final decision whether to continue dispatching an
ambulance for this incident.
6.2.2
INPUT
The operator has already input information about each incident in the systems user interface. This
information is then stored into a designated table in the database.
For this process, the operator shall be able to choose if s/he believes that this call is a duplicate call of an
incident that is already pending. If the operator believes this is a duplicate event, s/he shall select the
event for which this is a duplicate call. The operator shall then click the Duplicate Call button. A
confirmation message shall appear, and the operator shall confirm, or cancel, if this is a duplicate call.
In the event that the operator believes that this call is unique, s/he shall click on the Continue button.
The screen will advance to the dispatchers screen. (This screen is described in Section 7.0 of this
document.)
6.2.3
DISPLAY
During this process, the system shall display a list of incidents, which are currently pending and match 3
of the 5 required inputs of the current call. This list will occupy the majority of this screen and will be
displayed in a list where the operator can select the event. The operator shall select a certain event if s/he
believes that the current call is a duplicate call for this already pending event.
Two buttons will be located near the bottom of the screen under the list of currently pending, matching
events. The first button will be titled Duplicate Call which the operator can click is s/he believes the
current call is a duplicate call of an already pending event. If this button is pressed, a message box shall
appear asking the operator to confirm that this is a duplicate call. The operator can click Confirm or
Cancel in this message box. If Confirm is clicked, the screen shall return to the Log Calls tab.
However, if Cancel is clicked, the operator shall return to the current screen to determine if the current
call is unique.
The second button on the Uniqueness Call screen is titled Continue. If this button is clicked, the screen
will advance to the dispatchers screen. (This screen is described in Section 7.0 of this document.)
6.2.4
SYSTEM PROCESSING
Once the operator has input information about each incident in the systems user interface, this
information is then stored into a designated table in the database. The system shall then query the
database and populate a list of currently pending incidents that match 3 of the 5 required inputs of the
current call.
If the operator determines the current call, to be a duplicate call, the system shall log, in the database, the
incidents that are determined to be duplicates. Otherwise, the system shall advance to the dispatchers
screen. (This screen is described in Section 7.0 of this document.)
6.2.5
Requirements Specification
SYSTEM OUTPUT
The system shall output a populated list of the currently pending incidents that match 3 of the 5 required
inputs of the current call. If the Duplicate Call button is pressed, the system shall output a confirmation
message box to which the operator shall respond. The system shall log, in the database, the incidents that
are determined to be duplicate.
6.2.6
OTHER
N/A
6.2.7
CONSTRAINTS
The operator must rely on his/her expertise, as well as the information in the currently pending incident,
to determine whether an incident is unique. The operator might also be able to ask questions to the caller
to help clarify if this call is a duplicate and if an ambulance is currently being dispatched to this incident.
If the operator is still unsure whether this is a duplicate call, it is safer to continue with the dispatch
process.
6.2.8
DATA HANDLING
The database in Requirement 7 is required to store and access the information pertaining to each 911incident call.
6.3
6.3.1
DESCRIPTION
Requirements Specification
The system shall prioritize the 911-incident call based on its priority.
6.3.2
INPUT
The input necessary is the priority of the call. This can be found in the database.
6.3.3
SYSTEM PROCESSING
Each 911-incident call shall be placed in a priority queue based on the incidents priority. The calls that
are most urgent, those with the highest priority, will be acted on first.
6.3.4
SYSTEM OUTPUT
The priority queue shall be stored in the database. Each time an element is added, removed, or changed in
a queue, the queue shall be updated in the database.
6.3.5
OTHER
N/A
6.3.6
CONSTRAINTS
N/A
6.3.7
DATA HANDLING
The database in Requirement 7 is required to store and access the information pertaining to each call
incident.
10
Requirements Specification
6.4
6.4.1
DESCRIPTION
The system shall find the nearest ambulances and the dispatcher shall choose the number needed to
dispatch. For each set of 2 patients at an incident, 3 available ambulances will be shown (if there is only
one patient, 3 ambulances will be shown as well). The dispatcher can then select the appropriate number
of ambulances to dispatch to the incident. (Each ambulance can carry two patients.)
6.4.2
INPUT
The approximate amount of time for each ambulance to become available is the necessary input. This can
be retrieved from the database. Also, there shall be a button for each ambulance listed so the user can
select the ambulance to associate with this incident. The user can then input the approximate time for
each ambulance to arrive at the scene, and from the scene to the hospital.
6.4.3
DISPLAY
The appropriate number of ambulances shall be outputted along with a checkbox for each so the
dispatcher can select the ambulances s/he will dispatch. A new window is then brought up where the
dispatcher can input the approximate time it will take each ambulance to arrive at the scene and the
approximate time it will take the ambulance to get from the scene to the hospital.
6.4.4
SYSTEM PROCESSING
The system shall locate the appropriate number of ambulances that have the least amount of time before
they complete their current job. Once an ambulance(s) has been selected, the dispatcher must input the
estimated time for the ambulance to arrive at the scene and the estimated time from the scene to the
hospital. This information shall be entered into two text boxes.
6.4.5
SYSTEM OUTPUT
The ambulances with the least amount of time before they are ready to be dispatched shall be displayed,
along with the time until they are free.
6.4.6
OTHER
N/A
6.4.7
CONSTRAINTS
The number of ambulances the system shall display cannot exceed the total number of operational
ambulances.
6.4.8
DATA HANDLING
The database in Requirement 7 is required to access information about the status of each ambulance in
order to decide which ambulances will be ready the quickest, and to store the new status of the selected
ambulance.
11
Requirements Specification
6.5
6.5.1
DESCRIPTION
6.5.2
INPUT
There shall be two buttons, one to be pressed once the ambulance reaches the scene and the other once the
ambulance has reached the hospital.
6.5.3
DISPLAY
All currently pending incidents and ambulances will be displayed on the left side of the screen in a list.
The system shall allow the dispatcher to choose which ambulance to update. Once an ambulance is
chosen, the system will display two buttons. The dispatcher will press one of the buttons when the
ambulance reaches the scene of the incident. S/he will press the second button once the ambulance
reaches the hospital. Both of these buttons update the status of the ambulance.
6.5.4
SYSTEM PROCESSING
When either of the status update buttons is pressed, the system calculates the actual time. This is
described in more detail in Requirement 6.
6.5.5
SYSTEM OUTPUT
The output of the ambulance status update is the actual time recorded by the system for each ambulance
phase (from dispatch to the incident and from the incident to the hospital). The actual time the system
records is described in more detail in Requirement 6.
6.5.6
OTHER
N/A
6.5.7
CONSTRAINTS
N/A
6.5.8
DATA HANDLING
The database in Requirement 7 is required to store the status updates of each ambulance.
12
Requirements Specification
6.6
6.6.1
DESCRIPTION
The system shall log the actual time it took for the ambulance to reach the scene, as well as how long for
it to reach the hospital.
6.6.2
INPUT
Refer to Requirement 5.
6.6.3
SYSTEM PROCESSING
When the system updates the status of an ambulance, as stated in Requirement 5, it calculates the actual
time it took for that phase of the process. This is accomplished by subtracting the current time from the
time the ambulance was dispatched.
6.6.4
SYSTEM OUTPUT
The system shall store the actual time calculated in the database for logging purposes so that it can be
determined whether the federal mandates are being met.
6.6.5
OTHER
N/A
6.6.6
CONSTRAINTS
The dispatcher will have to notify the system when the ambulance has finished its task. Communication
from the ambulance to the dispatchers is not automated.
6.6.7
DATA HANDLING
The database in Requirement 7 is required to store the actual time of each phase of the ambulance
process.
13
Requirements Specification
6.7
6.7.1
DESCRIPTION
The system shall provide a MySQL database to allow for quick accessing of information and to ensure the
information is protected.
6.7.2
INPUT
The operator shall input information about each incident into the systems user interface. This
information is then stored into a designated table in the database.
6.7.3
DISPLAY
The systems user interface shall display information from the database. The operators and managers
shall have the ability to retrieve information from the database.
6.7.4
SYSTEM PROCESSING
Once the operator clicks the Process Claim button after they have logged all the relevant information
from the caller, the information is encrypted and sent over the TCP/IP network to a server. This server
places the data into its proper table in the database. The users can also request certain information from
the database, and the database shall process the request and return the relevant information to the users
computer. The users computer then processes this information and displays it in the user interface.
6.7.5
SYSTEM OUTPUT
The database shall record all system events to log files on the server. System events include errors, data
access times, and backup times. This output shall be accessible to the system administrators so they can
determine if the database is functioning correctly.
6.7.6
OTHER
The database requires a Linux, UNIX or Windows environment with at least 100 Gigabytes of free harddrive space, 1 Gigabyte of RAM and MySQL properly installed and configured.
6.7.7
CONSTRAINTS
The amount of traffic the database can handle is determined by the speed of the server or the speed of the
network. A dedicated server or multiple servers are necessary if the number of calls the operators receive
on average is very large.
6.7.8
DATA HANDLING
14
Requirements Specification
6.8
6.8.1
DESCRIPTION
The system shall provide a user interface to allow the managers to view how long it takes an ambulance
to respond to an incident after it has been logged by the operators.
6.8.2
INPUT
The managers can view response times and statistics for a particular date or a particular ambulance either
by selecting a daily, weekly, monthly, yearly or by ambulance view. This information is selected from a
dropdown box. Once a view is selected, the manager must click the View Report button to see the
information.
6.8.3
DISPLAY
The user interface shall have a dropdown box and button on the top left hand side of the display. Once
the user clicks the button, the information requested is populated in the center of the screen. If no
information is returned from the database, the following message shall be displayed: No information
found.
6.8.4
SYSTEM PROCESSING
Once the desired view is selected from the dropdown box and the View Report button is pressed, the
users computer shall query the database for the desired information. If the database returns data, this
data is processed and displayed in a readable form, or else an appropriate error message is generated
informing the user why the data is not available.
6.8.5
SYSTEM OUTPUT
All output is sent to the systems user interface. The management reports are accessible via a tab marked
Management Reports, which is found at the top of the main user interface.
6.8.6
OTHER
N/A
6.8.7
CONSTRAINTS
If the number of ambulances and incidents is very large during a certain time, some of the views such as
yearly could return more data than the computer can process in memory. In this case, an error message is
generated. The only remedy for this is to place more memory in the computer or to narrow the view to
something which would return less data.
6.8.8
DATA HANDLING
15
Requirements Specification
6.9
6.9.1
DESCRIPTION
The system shall provide an interface for viewing the information about all previous calls for 2 years.
6.9.2
INPUT
The user can search the system for incidents by inputting the callers telephone number, the callers name,
the callers address, or the date of the call.
6.9.3
DISPLAY
The user shall see four text fields and a Search button on the upper left hand side of the systems user
interface. Each text field shall have a description of the type of filter (i.e.: address or name) to the left of
the text field. The information the user requests is displayed in the center of the user interface sorted by
timestamp.
6.9.4
SYSTEM PROCESSING
Once the user clicks search, the computer queries the database using the text from the fields to narrow
down the results. If all text fields are empty, the system shall return every call which has been logged in
the database. The relevant information is returned to the requesting computer which processes the data
and displays the information.
6.9.5
SYSTEM OUTPUT
All output is directed to the systems user interface and is displayed under a tab marked View Calls. If
no information is found, the system shall generate an error message telling the user what to do.
6.9.6
OTHER
N/A
6.9.7
CONSTRAINTS
The amount of information the interface can display to the user is determined by their computers
memory. To view large amount of data, the user might need to increase the computers memory or view
smaller amounts of information.
6.9.8
DATA HANDLING
16
Requirements Specification
7.1
USER INTERFACES
The user interface shall follow basic Windows style and functionality conventions. The interface has
three tabs at the top left-hand side of the screen, which will allow users to easily switch between the
different parts of the program. The first tab, named Log Calls, shall have all the fields necessary for an
operator to input information about a new incident or call. Once the information is logged and the submit
button is pressed, the screen is changed to the dispatchers view. In this screen, the dispatcher can see the
three closest ambulances to the incident. Once an ambulance is selected, the dispatcher is taken to
another screen which has two text fields and two buttons. The first text field is to enter the estimated time
it should take for the ambulance to get to the incident and the second field is the estimated time required
to get from the incident to the hospital. The buttons represent the actual time taken for these events.
After one of the tasks has been completed, the user clicks the button, and the system calculates the actual
time.
The second tab allows operators and dispatchers to view information about previous calls. This interface
uses text boxes to allow the user to search for specific strings. The third tab allows managers to view
statistical information about the calls which are made over a certain period of time. This interface has
dropdown boxes which the user can use to refine their search.
7.2
HARDWARE INTERFACES
The application can run on any hardware which supports Windows 2000 or Windows XP. The system
must have at least 100 Megabytes of free disk space to install the program and 512MB-1GB of memory is
required to load the application. The program does not write information directly to the users computer,
but instead uses a database which is located on a network server. The users computer transfers and
receives data from the server using basic networking protocols. All systems information is stored in the
servers database which stores the data on the servers disk.
7.3
SOFTWARE INTERFACES
The system requires a properly configured version of Windows 2000 or Windows XP to run the
application. These computers must have Microsoft .NET Framework 1.1 or greater installed. The
systems server can use either Windows, Linux or UNIX, but it must have MySQL properly installed and
configured.
7.4
COMMUNICATIONS INTERFACES
All data transferred between the server and the individual computers shall use the TCP/IP networking
protocol over an Ethernet connection. This network is closed and is not accessible from the internet. This
ensures unauthorized access is prohibited.
17
Requirements Specification
18