The number. Req. 7 If successful, the driver

The Ambulance tracking System supports
the following users: the admin and the ambulance driver. The admin tasks
consist of logging into the system, emergency data entry, monitoring the
progress of the system, and logging out of the system. The ambulance driver is
the key person to respond to the status queries. This setup leads to the
following functional requirements:

 

1.1.1          
Logging In

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

Req. 1 The user
will log into the system by entering his/her dispatcher identification number
and password.

Req. 2 The user
identification number will be a 5 digit decimal number.

Req. 3 After
logging in, the user will be taken to the user home screen.

1.1.2          
Data Entry

Req. 4 After answering a call, the admin will gather
and enter the information into the system.

 

1.1.3          
Data Entry
Corrections/Suggestions

Req. 5 The
system will correct formatting errors and offer suggestions (i.e. allow address
and emergency abbreviations) to the dispatcher during the data entry process.

1.1.4          
Caller Address
Location

Req. 6 As soon as the
call is received, the system will automatically start the address location
procedures based on the caller’s phone number.

Req. 7 If successful, the
driver will verify the address with the caller.

Req. 8 If not, the driver
will ask the caller about his/her location.

 

1.1.5          
Duplicate Calls
Detection

Req. 9 The system will detect potential duplicate calls (calls from 2 or more
people describing the same emergency) by performing a quick comparison of the
locations and emergency descriptions of all incoming calls and notifying
responsible dispatchers if a similar emergency is already in the system. 

 

 

 

1.1.6          
 Ambulance
Location

Req. 10 The
system will locate the 3 available ambulances that are closest to the emergency
location and present them to the dispatcher in a graphical format, i.e. by
displaying a map and marking locations of the emergency and the ambulances.

Req. 11 After
the admin chooses one of them the system should transmit the emergency
information to the ambulance’s mobile receiving unit and start the status monitoring
process.

1.1.7          
No Available
Ambulances

Req. 12
In case the system cannot find any available ambulances in the area, the system
will query the status of the ambulances currently allocated to other
emergencies, select 3 that are soon-to-be-available, and present them to the
dispatcher. He/she should make the final decision.

1.1.8          
Exception Message

Req. 13 An exception
message will be generated for the admin if no ambulance is allocated within 11
minutes of the admin’s data entry.

Req. 14 This
exception message will read: “ERROR: NO AMBULANCES HAVE BEEN
ALLOCATED”.

Req. 15 Upon
receiving this message, the user will be required to manually select an
ambulance by entering the ambulance’s identification number.

Req. 16 Ambulance
identification numbers will be 3 hexadecimal digits.

 

1.1.9          
Communication with
the Ambulance

Req. 17 The system will
have an interface to communicate with the ambulance driver.

Req. 18 The system will
allow sending the emergency information to the ambulance as well as querying
the ambulance about the status of the emergency.

1.1.10      
Hospital Availability

Req.
19 As soon as the user allocates an
ambulance to the emergency, the system should present him/her with 3 hospitals
closest to the emergency location.

1.1.11      
Monitoring
Performance and Position

Req. 20 The system will
track the ambulance’s performance and position.

Req. 21 The ambulance’s
performance will be based on the time it takes to arrive at the scene once
allocated and the time to get the patient to the hospital.

Req. 22 The ambulance’s
position will be displayed on the map for the user to monitor. 

 

1.1.12      
Monitor Display

Req. 23 The user monitor will display the
following data after s/he has completed the data entry:

 

·        
Location of the emergency

·        
Location of the
ambulance(s) in route to the emergency.

·        
Location of the nearest 3
ambulances to the emergency location.

·        
Location of the nearest 3
hospitals to the emergency location.

 

 

1.1.13      
Monitoring Complete

Req. 24 The user will
close out the monitoring of an emergency once the allocated ambulance(s)
has/have arrived at a hospital.

Req. 25 The driver will
click “Emergency Resolved” to close out the monitoring phase of the
system.

Req. 26 The driver will
be returned to the driver home screen when clicking “Emergency
Resolved”.

Req. 27 The driver can also go to an open emergency request to see
its status.

 

1.1.14      
Information Logging

Req. 28 The system will log all calls and the
related emergency information for future review and statistical purposes.

 

1.1.15      
Emergency
Transfer/Sharing

Req. 29 The driver will
be able to transfer the emergency to another driver in case s/he has to log out
of the system.

Req. 30 The driver will
also be able to share the emergency information with other driver in case
he/she needs help.

1.1.16      
Logging Out

Req. 31 The driver will
log out of the system by clicking “Log Out”.

Req. 32The driver will
not be allowed to log out while currently monitoring an ongoing emergency
unless s/he transferred or shared the emergency with at least one other driver.

 

1.2           
Non-Functional Requirements

 

1.2.1          
Usability

·        
Simple to Operate: The software should
be easy to learn and operate; the user should not require special skills or
training to operate the system.

·        
Simple design: The user interface
should be kept as simple as possible so as not to make the application too
confusing for the user to understand i.e., user friendly interface.

·        
User awareness: User manual and
in-build help file will be provided for the user. Tool tip text will also be
provided for quick help.

 

 

 

1.2.2          
Reliability

·        
The system should be up and
running 24 X 7 X 365 and should be crash safe during 95% of its runtime. 

·        
Mean time between failures
(MTBF): The MTBF (if any) should not be less than 6 months.

·        
Mean time to repair (MTTR):
In case of a failure that leads to a system outage, the MTTR should not be more
than 2 hours.

 

1.2.3          
Performance

·        
Short response time: Any page of the
application should not take more than 4 seconds to load. The load time of the
application should not be more than 4 seconds.

·        
Population Support: The application
should be able to support 250 concurrent users without any performance
degradation.

 

1.2.4          
Supportability

·        
Advanced technologies: As technology
is changing so fast, the system should be able to support new technologies for
tracking which will be faster and reliable than the ones present now.

·        
GPS: The system should be able to
support GPS tracking in the future.

·        
Address location using phone
coordinates: The system should support locating the address, using phone
coordinates of the person making the call.

 

1.2.5          
Implementation

·        
Programming language: Java and allied
technologies should be used for development of the application.

·        
Apache’s Tomcat Web-Server should be
used to deploy the application.

·        
MySQL should be used as the database.
Business Objects will be used for reports.

                           

1.2.6          
Packaging

The software
will also be available online, and anybody authorized by the system
administrator can access the system.

 

1.2.7          
Legal

Data from the user should adhere to the
rights of data privacy of the user. All the content must be procured
through legal channels and there should be no copyright violations.

 

 

 

 

 

1.2.8          
Security

As the system will be dealing with
delicate data, the system should be secure. The data should be stored in a
highly secure manner and should be immune from any hacking attempts.

 

1.2.9          
Scalability

The system
designed will be optimum for the 250 users.
The system
should be able to scale up to 500 concurrent users (if there is a need in
the future) by installing additional hardware components with no
degradation in the performance of the system.

 

1.2.10       Schedule Constraints

The entire system should be up and
running in the user’s production environment by 30th June.

 

1.2.11       Standards Constraints

·        
All the documents delivered should
adhere to the IEEE standards for software engineering

x

Hi!
I'm Owen!

Would you like to get a custom essay? How about receiving a customized one?

Check it out