System Requirement Specification

Document Sample
System Requirement Specification Powered By Docstoc
					System Requirement Specification

       February 10th, 2006

         Team Members:
            Paul Johnson
             (Team Leader)

           Charlie Martin

           Eric Anderson

          Jonathan Greene
Table of Contents

Introduction                        2

         History                    2

         Overview                   2

         Purpose                    3

Use-Case Diagram                    3

System Requirements Specification   4

Methodology                         5

Issues                              6

Specific Requirements               6

        In the early nineteen nineties, the London Ambulance Service (LAS) attempted to
implement a fully automated system for assigning an ambulance to an emergency. This attempt
failed for wide variety of reasons. The problems began as soon as the project did as the LAS had
completely unrealistic expectations for the complexity of the project to be developed in the
amount of time allowed by its firm deadline. The developer for the new system, Systems
Options, was chosen solely on the basis that they were part of the lowest bidder for the overall
system, and did not have the necessary experience or personnel to complete such a project. Still,
they were awarded the contact, and attempted to implement the emergency response system the
LAS wanted. Although a design specification was approved before the final contract was
awarded, it was not complete. During the development of the project, there was no quality
assurance for either the project as a whole, or the code being developed by Systems Options. No
testing plans were in place, and the software was never adequately tested before its integration
was attempted. Finally, and perhaps most serious, changes were made to code without records of
the change. All of these problems led to a massive failure once the system was put into use. Less
than a month after the final system was introduced (and quickly taken out of service), a partial
system completely locked up and crashed. The cause of the crash was later found to be an error
in the code that did not release memory after an ambulance was mobilized in response to an
emergency. This example shows the importance of careful planning and testing to the successful
implementation of a software system.

          An efficient ambulance dispatch system is a valuable resource in times of emergencies.
The faster an ambulance can be dispatched to the site of an accident, the less severe the victim’s
condition will be upon arrival, possibly saving lives. In order to create such a system, several
issues must be addressed, such as organizing information received from a call in an efficient
manner, finding the best ambulance to drive to the scene, and handling such events as receiving
multiple reports about the same accident. An ambulance dispatch system is also important in
order to help meet the government standard of no more than 3 minutes to dispatch an ambulance
after a call, and an additional 11 minutes to arrive to the scene of the accident. While a dispatch
system cannot help with much during the time after which the ambulance has been dispatched
and before it has arrived at the scene of the accident, it can certainly speed up the process of
          By using a software dispatch system to replace a manual dispatch system consisting of
several sheets of paper and people trying to make sense of them, the process of dispatching will
speed up, while costs will be reduced since the system can replace some operators. Information
regarding each incident can be stored with minimal clutter, in an easy-to-read format, allowing
operators and dispatchers to work more efficiently and speedily.

         This project is designed to replace a manual ambulance dispatching system with a
 software dispatch system, designed to reduce costs and shorten the dispatch time. This project
 will help operators manage information received from calls. Also, this is designed to help meet
 the government requirement of 3 minutes to dispatch an ambulance, and an additional 11
 minutes to arrive to the scene of the accident.

 Use-Case Diagram

System Requirement Specifications

NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described
in RFC 2119 <>.


Dispatcher:      The person responsible for designating which ambulance is assigned to each specific

Operator:        The person responsible for taking phone calls from people who are reporting accidents.

Pending call: It is a call on file which has not yet been assigned to an ambulance.

   1.   Must replace the forms used by operators and the board used by dispatchers.

   2.   The system must not dispatch ambulances or take calls.

   3.   Must aid in fulfilling governmental requirements.

            3.1. Must aid in the obtaining an average dispatch time of 3 minutes.

            3.2. Must aid in the obtaining an average arrival time of 11 minutes

   4.   The system must provide interfaces for the dispatchers and operators.

            4.1. The operator interface should consist of a form to input information about a call.

                    4.1.1   For a given call, the system must keep track of the address or location,
                            incident type, severity of call, time of call.

                          The levels of severity: low, serious, severe, life-threatening.

                    4.1.2   The system should keep track of a phone number and name when available.
                            For the user, these fields must not be required.

                    4.1.3   The system must keep track of the user or alias that accepted a call, when
                            requirement 4.1 is satisfied.

            4.2. The dispatcher interface should consist of a table of pending calls and a list of dispatched

                    4.2.1   The system must keep track of each ambulance's status.

                    4.2.2   The system must allow for the dispatcher to assign an available ambulance to
                            a pending call.
                   4.2.3     The system must log time taken to dispatch ambulance.

                   4.2.4     Such an action must update the ambulance's status and remove the call from
                             the pending call list.

                   4.2.5     The system must allow for the dispatcher to view the all ambulances and

                          The system must allow for the dispatcher to change the
                                           association of any ambulance and any call.

           4.3. The system should allow the dispatcher to change any ambulance assignments and
                status and have appropriate changes apply.

                 4.3.1     An example appropriate change would be when a dispatched ambulance is re-
                           assigned to a different call and the original call would be made pending.

   5.   Must keep logs to allow for auditing.

           5.1. Logins or some type of alias to be used to keep track of user interaction with the system.

        The work was divided equally between the four team members in our group. Over phase
1 of the project, we had three meetings, each in which everyone was able to attend. The first
meeting we discussed what questions to ask the customer, and some basic ideas we had about the
system we were trying to improve. We also elected Paul Johnson as the team leader for the first
phase by unanimous decision. For the second meeting we hashed out a rough system
requirements specification, as well as talked about what sort of diagram(s) we wanted to use.
For the third and final meeting we attempted to get as close to a final System Requirement
Specification (SRS) as possible, as well as create all the necessary parts of the first deliverable.
This included the use-case diagram (Eric), the introduction (Charlie and Jonathan), as well as the
SRS (Eric and Paul) and the Methodology/Issues/Specific Requirements (Paul). Everyone e-
mailed the parts of the project to Paul, and he then compiled the pieces together and created the
finalized deliverable.
        There were no major issues that arose during our meetings but several disputes came up.
The first one was what priority wording system to use. (Shall, must, should… etc) Eric found a
good system which he thought we should use at: Paul
disagreed and thought we should just stick with the one given in class. In the end, we decided to
use the system Eric found. We also took a few minutes to decide what diagrams to include in the
deliverable. Paul was for having multiple diagrams, including the UML state diagram. The
others disagreed and only wanted to create a use-case diagram. We debated some on the points
of the use-case diagram, such as its simplicity and the ease at which you could understand it at a
glance. In the end, we concluded that having one very clear and concise diagram was better than
having several others that might be contradictory to each other.

Specific Requirements
         There are several requirements that must be fulfilled in order for our system to be
implemented. One is there must be a single computer to act as the server, as well as several
others to act as clients. These computers must be connected to each other through a network.
They do not have to be connected to the internet, however. The operators and dispatchers must
have at least some knowledge of computers. Ideally they will have good typing skills, as they
will be required to talk to someone through the phone or radio, and type at the same time. There
will be no need for the system we plan on implementing to connect to either the telephone lines,
the radios used to dispatch the ambulances or the ambulances themselves, so these systems can
remain as they were before. The detailed specifications of the computers are not a major concern
as this system will be located in a small town and will not have to service large numbers of calls
at the same time. The server should at least have a 1 GHz processor and 1GB of memory.