Software This’ Instruction’ section should also be removed

Software Requirement Specifications
It’s an Emergency
Version: 1.1

Project Code

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

order now



Dr Farooque Hassan Kumbhar

Co Supervisor

Ms. Mehwish Amjad



Project Team

Syed Arsalan Hussian(k132133)
Syed Muhammad Ifrahim (k132216)
Ayaz Latif(k132409)

Submission Date




–       No section of template should be deleted. You can write ‘Not applicable’ if a section is not applicable to your project. But all sections must exist in the final document.

–       All comments/examples mentioned in square brackets () are in the template for explanation purposes and must be replaced / removed in final document.

–       This’ Instruction’ section should also be removed in final document.

–       MS-Word Reviewing feature must be used to get the document reviewed by supervisors or co-supervisors.



Document History

Revision history will be maintained to keep a track of changes done by anyone in the document.


Name of Person


Description of change


Ayaz Latif


Initial Creation


Ayaz Latif


Solved error and used research






















Distribution List

Following table will contain list of people whom the document will be distributed after every sign-off




Dr Farooque Hassan Kumbhar


Ms Mehwish Amjad

Co- Supervisor






Document Sign-Off

Following table will contain sign-off details of document. Once the document is prepared and revised, this should be signed-off by the sign-off authority.

Any subsequent changes in the document after the first sign-off should again get a formal sign-off by the authorities.



Sign-off Authority

Sign-off Date
























Table of Contents


1.   Introduction. 7

1.1.       Purpose of Document 7

1.2.       Intended Audience. 71.3          Abbreviations …………………………………………………………………………………………7

1.4.       Document Convention. 7

2.   Overall System Description. 8

2.1.       Project Background. 8

2.2.       Project Scope. 8

2.3.       Not In Scope. 8

2.4.       Project Objectives 8

2.5.       Stakeholders 8

2.6.       Operating Environment 8

2.7.       System Constraints 8

2.8.       Assumptions & Dependencies 8

3.   External Interface Requirements 9

3.1.       Hardware Interfaces 9

3.2.       Software Interfaces 9

3.3.       Communications Interfaces 9

4.   Functional Requirements 10

4.1.       Functional Hierarchy. 10

4.2.       Use Cases 10

4.2.1.     Title of use case 10

5.   Non-functional Requirements. 11

5.1.       Performance Requirements 11

5.2.       Safety Requirements 11

5.3.       Security Requirements 11

5.4.       User Documentation. 11

6.   References. 12

7.   Appendices. 13



1.  Introduction


1.1.               Purpose of Document

The purpose of this document is to provide a detailed overview of the IEA. It will explain the purpose and features of the system. What the system will do, the constraints and environment under which it will operate and how the system will react to the external spurs. The document is proposed for both the developers and the stakeholders of the system.

1.2.               Intended Audience

The intended audience of this document is all major stakeholders which include the development team, the supervisor, the co-supervisor and anyone evaluating the project.

1.3            Abbreviations        




It’s an Emergency


Requirements Specifications


The Global Positioning System












1.4            Document Convention

Several formatting conventions have been followed throughout the entire document:

1.  All text contained in this document is 11pt Arial font.

2.  Section titles are 18pt Arial font.

3.  Subsection titles are 14pt Arial font.

4.  Any further subsection breakdown is 12pt Arial font.

5.  All sections and subsection are numbered using the X.X.X…  format where X represents numbers.


2.  Overall System Description

2.1.               Project Background

The current system has been managed by a native way which is engaged by calling. All the current ambulance system lies on calls from the user. The most human operator uses traditional or computer based ambulance dispatched system to send an ambulance. These types of system can get wrong data from a caller and send it to dispatch system 3. The user needs to call ambulance system department about the availability of it and assign ambulance for them to the reported location. All the important data including user’s name, CNIC, address, and incident are collected through conversion which can be the reason of intentional or unintentional error or also can be a fraud call or human delay causing a backlash in the system. Therefore, our systems will be designed in a way to secure such incidents and dealt with it appropriately.
The reason for using firefly algorithm is that it has better efficiency then GA and PSO algorithm, as it follows 4

a) Light intensity will be varying

b) The attractiveness will be calculated.

Basically, the FA has two advantages over other algorithms. They have the power of automatically subdivision and can also deal with the multimodality. In addition, for control the randomness as iterations proceeds for speeding up the convergence by tuning the parameters. All these advantages make firefly algorithm to deal comfortably with problems related to clustering.

2.2.               Project Scope

The project It’s an Emergency is an android application to provide emergency service. The benefit of this project is anyone can call ambulance at any time. They can check nearest one available. The communication gap between citizens and police is reduced which inculcates a sense of trust and strength amongst the people. The system will be designed to be very easy to learn and use. The emergency is categorized into priority. User is also indicated nearest hospital availability. A form is provided where user can ask questions regarding any issue and can also file a complaint. This form is then forwarded to the respective department. This project contains efficiency of emergency system.









2.3.               Not In Scope


Mobile Phone which have no internet connection are out of scope.

Area which have jammers installed, to cover them is not in our scope.





2.4.               Project Objectives


People who are in need of an ambulance those peoples who have meet with the accident and people at home surviving with very bad diseases, pregnant women are our main target audience. They can call the ambulance by the click of button at their desired place. It can also be used by the people in surrounding of the accident place in case the men who are not able to call the ambulance due to his injuries, the people on his surrounding can call the ambulance for him to send him hospital as soon as possible so he can get treatment and soon can recovers from his injuries.


2.5.               Stakeholders


Stakeholders of the system are Dr. Farooque Hassan Kumbhar, Miss Mehwish Amjad, Syed Arsalan Hussain, Ayaz Latif, Syed Muhammad Ifrahim and FAST-NUCES. This system would be used by the Government and the organization who are having the facility of ambulances. The team would be required to deploy it on a big scope which includes developer for further updates, technical teams etc.



2.6.               Operating Environment


The software will run on the android operating system KitKat to the latest one. All system that are supports this version of android operating system will be able to run the software.








2.7.               System Constraints


Some of the Factors are as follow.




Hardware constraints

Mobile phone jammers would be problem because they will jam the signals of mobile phone so user can not use their mobile data.

Cultural constraints (includes language etc.)

Language could be the problem because our application would be in English but it would only require a button press to call an ambulance.

Legal constraints

Wrong use of it will get you a challan.


Environmental constraints

Enviroment should not have jammers so user can call the ambulance in any area for their emergency.


User constraints.


Project is developed for the people in emergency, wrong call of the ambulance can cause huddles.




2.8.               Assumptions & Dependencies

The system is dependent upon the Web server and Android System. The application user should have the camera and gps equipped smart phone and should also know how to use the application. The user must have access to the internet connection.


3.  External Interface Requirements

Our system will have two modules of mobile app one of which would be for user use and other one for driver secondly, we would develop the website to monitor the performance of our overall system. The whole system would be connected with the centralized database which would be connected by all this modules and website.


3.1.               Hardware Interfaces

This will be an Android phone application, so it will be designed to interface with the hardware present on the Android phone. The application will be able to run by other devices that can emulate the Android, but this will not be a consideration during design.  There are 4 physical buttons on the phone.

Application will be using the Android network to connect to the internet which will allow it to communicate with the server containing data. This means that it will be using the infrastructure, mostly wireless communication points of the network in order to perform properly.  There should be some sort of error checking for if the network is down or inaccessible.


3.2.               Software Interfaces


Our system will have two modules of mobile app one of which would be for user use and other one for driver secondly, we would develop the website to monitor the performance of our overall system. The whole system would be connected with the centralized database which would be connected by all this modules and website.



3.3.               Communications Interfaces

Our system will consist of two modules of mobile application which would communicate with each other. Secondly, we will make website that will communicate with both of the modules.

4.  Functional Requirements

4.1.      Functional Hierarchy

IEA provides the following functionalities to its respected users:



Call ambulance/police

The user can call ambulance/police via smartphone.


The user image is captured to validate request.

User’s Location information

If user captures the image through camera then he will also get the information about his present location.


Best nearest recommended hospital are shown based on user rating.

User’s feedback

Dataset can be updated according to user’s feedback.


4.2.        Use Cases

4.2.1.          It’s an Emergency

Use Case:



Use Case Specification:

Use case name

Gather Information

Participating actors

·      Caller
·      System


Driver collects details and location of the emergency case

Flow of events

1.   System displays address or area information if available 
3.   Caller provides driver with as much details as possible
4.   System enters emergency details into system
5.   System searches for location



Entry condition

·      System is logged on (see Logon use case)

Exit condition

·      Emergency location is identified

Quality requirements

·      Search for an address


Use case name


Participating actors

·      System


System has a mechanism to identify location of an ambulance

Flow of events

1.   System provides a transaction to search for ambulances
2.   System searches for an ambulance using its number or driver name
3.   System provides a list of matching ambulances
4    System selects an ambulance
5.   Ambulance location is identified on a map and physical address is written on the screen



Entry condition

·      User is logged on

Exit condition


Quality requirements




Use case name

Dispatch Nearest Ambulance


Participating actors

·      System
·      Ambulance Driver
·         User



System sends the ambulance nearest to the emergency location to handle the case


Flow of events

1.   System provides a transaction to dispatch ambulances
2.   User enters a case number
3.   System locates the nearest three ambulances to case location
4.   System suggest which ambulance to dispatch
5.   User gets an ambulance details.
6.   User contacts ambulance
7.   System transfers case & location information
8.   Driver acknowledges the case and moves





Entry condition

·      User is logged on (see Logon use case)
·      Ambulance driver is logged on (see Logon use case)
·      User is able to locate emergency site


Exit condition

·      An ambulance is successfully dispatched


Quality requirements

·      An ambulance must be dispatched in no more than 3 minutes
·      If 11 minutes pass by without dispatching an ambulance, the system raises an exception




Use case name

Locate CaseSite


Participating actors

·      System
·         User
·         Driver



User can identify the location of the emergency case on a map


Flow of events

1.   provides a transaction to search for a street address
2.   Driver gets available address information
3.   System highlights address on a map 
5.   System saves the address with the opened case





Entry condition

·      Driver is logged on (see Logon use case)
·      Driver collects enough address information to look for location on map


Exit condition



Quality requirements




Use case name

Locate Nearest Available Hospital

Participating actors

·      Driver
·      System


System locates nearest available hospital to emergency site

Flow of events

1.   Driver enters case number
2.   System retrieves case location
3.   System identifies nearest three hospitals to case
4.   System makes sure hospital can receive patient
5.   System contacts ambulance and recommends a hospital
6.   System transfers hospital location to ambulance



Entry condition

·      Driver is logged on (see Logon use case)
·      System is able to locate emergency site
·      Driver is not handling any other call

Exit condition


Quality requirements




Use case name


Participating actors

·      Driver
·      User


A user logs into the system

Flow of events

1.   User accesses the system via a terminal
2.   User enters username and password on welcome screen
3.   System verifies information
4.   System grants access to user


3.a  System does not recognize user
3.b  Access is not granted
3.c  System asks user to re-enter information (2)

Entry condition


Exit condition

User logs out

Quality requirements





5.  Non-functional Requirements

5.1.               Performance Requirements

The system requires only a camera and GPS supported android handset. The hardware should have enough memory and processor to support the application.

5.2.               Safety Requirements

The system is safe to use. It doesn’t affect any sort of physical or mental health problem.

5.3.               Security Requirements

The system doesn’t affect any user’s privacy or integrity. Infect no any personal factor, that can affect the user’s security, is involved in the system.

5.4.               User Documentation

User manual for using the system is provided below:


·         Open the installed application on his cell phone.

·         Click on emergency icon to call for services,


Note: If user clicks on emergency icon then it will ask mobile location services to send address of user.

·         Server dispatches emergency vehicles.

·         Click on view result button.


Note: This will take a few seconds until the processing is done and the information of that emergency service will be displayed on user’s mobile screen. In addition, the system will also provide the recommendation for nearest hospital/police available.


6.  References

This section should provide a complete list of all documents referenced at specific point in time. Each document should be identified by title, report number (if applicable), date, and publishing organization.  Specify the sources from which the references can be obtained. (This section is like the bibliography in a published book).



7.  Appendices




Short form for “Its  an emergency ”


Person managing and controlling all administrative sections of the application like posting, modifying and deleting news etc.


Person posting news or announcements. Faculty has less writes then an Admin.


Person who receives news and updates. Student can access to any section of the application and to the restricted sections also that are not be accessible by a general user, but required an identification by student id.


The general user, using the system. No log-in required.

Authorized User or User

Includes Admin, Student AND faculty.



I'm William!

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

Check it out