Software Requirement Specifications It’s an Emergency Version: 1.1 Project Code CS491 Supervisor Dr Farooque Hassan Kumbhar Co Supervisor Ms. Mehwish Amjad Project Team Syed Arsalan Hussian(k132133) Syed Muhammad Ifrahim (k132216) Ayaz Latif(k132409) Submission Date 14/12/2017 Instructions- 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 HistoryRevision history will be maintained to keep a track of changes done by anyone in the document. Version Name of Person Date Description of change 1.0f Ayaz Latif 28/10/2017 Initial Creation 1.1 Ayaz Latif 14/12/2017 Solved error and used research Distribution ListFollowing table will contain list of people whom the document will be distributed after every sign-off Name Role Dr Farooque Hassan Kumbhar Supervisor Ms Mehwish Amjad Co- Supervisor Document Sign-OffFollowing 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. Version Sign-off Authority Sign-off Date Table of Contents 1. Introduction. 71.
1. Purpose of Document 71.2. Intended Audience.
71.3 Abbreviations …………………………………………………………………………………………71.4. Document Convention.
72. Overall System Description. 82.1. Project Background. 82.2. Project Scope.
82.3. Not In Scope. 82.4. Project Objectives 82.5.
Stakeholders 82.6. Operating Environment 82.7. System Constraints 82.8. Assumptions & Dependencies 83.
External Interface Requirements 93.1. Hardware Interfaces 93.2. Software Interfaces 93.3. Communications Interfaces 94.
Functional Requirements 104.1. Functional Hierarchy. 104.2. Use Cases 104.2.1.
Title of use case 105. Non-functional Requirements. 115.1. Performance Requirements 115.2.
Safety Requirements 115.3. Security Requirements 115.4. User Documentation. 116.
References. 127. 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 AudienceThe 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 Term Description IAE It’s an Emergency RS Requirements Specifications GPS The Global Positioning System 1.4 Document ConventionSeveral 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 Description2.1. Project BackgroundThe 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 ScopeThe 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 constraintsMobile 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 constraintsWrong 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 & DependenciesThe 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 RequirementsOur 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 InterfacesThis 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 InterfacesOur 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 Requirements4.1. Functional HierarchyIEA provides the following functionalities to its respected users: Functionality Description Call ambulance/police The user can call ambulance/police via smartphone. Images 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. Recommendations 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 Cases4.
2.1. It’s an EmergencyUse Case: Use Case Specification: Use case name Gather Information Participating actors · Caller · System Description 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 Variations None 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 TrackAmbulance Participating actors · System Description 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 Variations None Entry condition · User is logged on Exit condition N/A Quality requirements N/A Use case name Dispatch Nearest Ambulance Participating actors · System · Ambulance Driver · User Description 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 Variations None 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 Description 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 Variations None Entry condition · Driver is logged on (see Logon use case) · Driver collects enough address information to look for location on map Exit condition N/A Quality requirements N/A Use case name Locate Nearest Available Hospital Participating actors · Driver · System Description 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 Variations None 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 N/A Quality requirements N/A Use case name Logon Participating actors · Driver · User Description 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 Variations 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 N/A Exit condition User logs out Quality requirements N/A 5. Non-functional Requirements5.
1. Performance RequirementsThe 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 RequirementsThe system is safe to use. It doesn’t affect any sort of physical or mental health problem.5.3.
Security RequirementsThe 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 DocumentationUser 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. ReferencesThis 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 Term Definition IEA Short form for “Its an emergency ” Admin Person managing and controlling all administrative sections of the application like posting, modifying and deleting news etc. Faculty Person posting news or announcements.
Faculty has less writes then an Admin. Student 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. Visitor The general user, using the system.
No log-in required. Authorized User or User Includes Admin, Student AND faculty.