POLITEHNICA UNIVERSITY OF BUCHAREST
SOFTWARE ENGINEERING
Senior Ambulance System
Software Requirements Specification
Team:
Coordinator: Date created:Wednesday, May 03, 2023
Delivery Report
Delivery Report(will be delivered along with the project)
Name Group Project implementation [%, reason] Signature
_______________ ______ ____________________________ _________ ____________________________ ____________________________
_______________ ______ ____________________________ _________ ____________________________ ____________________________
_______________ ______ ____________________________ _________ ____________________________ ____________________________
Delivery date:__________________________________
2
SDD
Table of Contents
1. Introduction.............................................................................................................51.1. Purpose..................................................................................................…. 51.2. Target Public................................................................................................51.3. Definitions, Acronyms and Abbreviations.................................................51.4. Document Structure....................................................................................5
2. References..............................................................................................................63. Decomposition Description...................................................................................7
3.1. Modules Description....................................................................................73.1.1. Description of Module 1...................................................................73.1.2. Description of Module 2...................................................................73.1.3. Description of Module 3...................................................................73.1.4. Description of Module 4...................................................................83.1.5. Description of Module 5...................................................................8
3.1.6. Description of Module 6.......................................................................8 3.1.7. Description of Module 7.......................................................................83.2. Description of Concurrent Processes.......................................................9
3.2.1. Description of Process 1 .................................................................93.2.2. Description of Process 2..................................................................93.2.3. Description of Process 3................................................................103.2.4. Description of Process 4................................................................103.2.5. Description of Process 5................................................................103.2.6. Description of Process 6................................................................103.2.7. Description of Process 7................................................................10
3.3. Description of Data Modules........................................................................113.3.1. Description of Data Module 1............................................................113.3.2. Description of Data Module 2............................................................123.3.3. Description of Data Module 3............................................................123.3.4. Description of Data Module 4............................................................12
4. Dependency Description......................................................................................134.1. Dependencies among modules................................................................134.2. Dependencies among processes.............................................................134.3. Dependencies among data modules...........................................................13
5. Interface Description............................................................................................155.1. Module Interfaces......................................................................................15
5.1.1. Module 1 Interface ..........................................................................155.1.2. Module 2 Interface ..........................................................................155.1.3. Module 3 Interface ..........................................................................155.1.4. Module 4 Interface ..........................................................................155.1.5. Module 5 Interface ..........................................................................165.1.6. Module 6 Interface ..........................................................................165.1.7. Module 7 Interface ..........................................................................16
5.2. Processes Interfaces.................................................................................175.2.1. Process 1 Interface.........................................................................175.2.2. Process 2 Interface.........................................................................17
3
SDD
5.2.3. Process 3 Interface.........................................................................175.2.3. Process 3 Interface.........................................................................175.2.4. Process 4 Interface.........................................................................175.2.5. Process 5 Interface.........................................................................175.2.6. Process 6 Interface.........................................................................175.2.7. Process 7 Interface.........................................................................175.2.8 . Process 8 Interface......................................................................17
6. Detailed Design......................................................................................................186.1. Modules detailed design..............................................................................18
6.1.1. Module 1...........................................................................................186.1.2. Module 3...........................................................................................186.1.3. Module 4...........................................................................................196.1.4. Module 5...........................................................................................196.1.5. Module 6...........................................................................................206.1.6. Module 7...........................................................................................206.1.7. Module 8...........................................................................................20
6.2. Data Modules Detailed Design....................................................................21A1. Use cases diagrams...........................................................................................22A2. Class diagrams...................................................................................................23A3. Sequence diagrams.............................................................................................24A4. Document evolution..............................................................................................26A5. Conclusions regarding the activity........................................................................26
4
SDD
System Design
According to the IEEE STD-1016-1998, IEEE Recommended Practice for Software Design Descriptions.
1. Introduction1.1. PurposeThe purpose of this document is to present the architectural design specification of the project “Senior Ambulance System”.
1.2. Target PublicThe audience for the SDD includes the project management, the system architects (i.e., the developers who participate in the system design), and the developers who design and implement each subsystem.
1.3. Definitions, Acronyms and AbbreviationsSAS = Senior Ambulance System
1.4. Document StructureBesides the introduction, the document contains five more chapters :
- References : list of the documents used in the paper- Decomposition Description : modules description, description of concurrent processes
and description of data modules- Dependency Description : dependencies among modules, dependencies among
processes and dependencies among data modules- Interface Description : module and processes interfaces- Detailed Design : modules and data modules detailed design
5
SDD
2. ReferencesList of references used in this paper, possible legislation that governs the application domain of the project/document. [1] IEEE STD-1016-1998, IEEE Recommended Practice for Software Design Descriptions
[2] Nicolae Goga, Software Engineering Lecture notes, Fils, 2014
[3] IEEE STD-830-1993, IEEE Recommended Practice for Software Requirements Specification.
6
SDD
3. Decomposition DescriptionThis article corresponds to chapter 6.2.1., Decomposition description, from [1].
3.1. Modules DescriptionModules description according to 5.3.1 -5.3.10, from [1]. The modules can be identified on the use case diagram(s) from the Software Requirements Specification.
3.1.1. Description of Module 1
Name LoginType SubprogramPurpose Allows users to log into the systemWay of operating In order to log into the system, a user must provide his username
and password. The module will take the information introduced by the user and verify its validity. After that it will grant access to the specific content according to the type of user or it will provide an error message.
Subordination Modules belonging to the operator (Operator Input, Uniqueness of Call);Modules belonging to the dispatcher (Locate Available Ambulances, Ambulances Status Update,Information Retrieval).
Dependencies -Resources The module needs to have access to the Internet and to the table
Users from the database.
3.1.2. Description of Module 2
Name Operator InputType SubprogramPurpose The system shall allow the operator who receives an incoming call to
input information, which is the beginning process of dispatching an ambulance
Way of operating The operator shall input the necessary information in the tab labeled “Log Calls” in the system’s user interface. The system shall have three 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 “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. - 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.
Subordination The Login moduleDependencies In order to have access to this module a user must log into the
system with an operator account. Resources The module needs to have access to the Internet and to the
database.
7
SDD3.1.3. Description of Module 3
Name Uniqueness of callType SubprogramPurpose The system shall help determine the uniqueness of each 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
Way of operating The operator has already input information about each incident in the system’s 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
Subordination The Login module.Dependencies In order to have access to this module a user must log into the
system using an operator account and access the Operator Input page (in order to verify the existing calls).
Resources The module needs to have access to the Internet and to the database.
3.1.4. Description of Module 4
Name Locate Available AmbulancesType SubprogramPurpose The system shall find the nearest ambulances and the dispatcher
shall choose the number needed to dispatch. The dispatcher can then select the appropriate number of ambulances to dispatch to the incident. (Each ambulance can carry two patients).
Way of operating The approximate amount of time for each ambulance to become available is the necessary input. This can be retrieved using Google Maps. Also, the system selects the ambulance to be associated 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.
Subordination The Operator Input module.Dependencies In order to have access to this module a user must log into the
system with an operator account. Resources The module needs to have access to the Internet and to the
database.
3.1.5. Description of Module 5
Name Ambulance Status UpdateType SubprogramPurpose The dispatcher shall be able to update the status of the ambulances..Way of operating 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.
Subordination The Locate Available Ambulances module.Dependencies In order to have access to this module a user must log into the
system with an operator account and access the Locate Available Ambulances page.
8
SDDResources The module needs to have access to the Internet and to the
database.
3.1.6. Description of Module 6
Name Information RetrievalType SubprogramPurpose The system shall provide an interface for viewing the information
about all previous calls for 6 months.Way of operating The user can search the system for incidents by inputting the caller’s
name, the caller’s address, or the date of the callSubordination -Dependencies In order to have access to this module a user must log into the
system using an administrator/manager account and access the Operator Input page.
Resources The module needs to have access to the Internet and to the database.
3.1.7. Description of Module 7
Name LogoutType SubprogramPurpose Allows users to log out from the systemWay of operating In order to log out from the system, a user must click on a link
available on each page. After that, the module will display the Login page.
Subordination The Login module.Dependencies A user can only log out from the system from a different page that the
one containing the Login module. Resources The module needs to have access to the Internet.
3.2. Description of Concurrent ProcessesDescription of concurrent processes according to 5.3.1 – 5.3.10, from [1]. The processes can be identified on the sequence diagram(s) from the Software Requirements Specification.
3.2.1. Description of Process 1
Name Login processType ProcessPurpose Log a user into the system, grant him information and permissions
according to roleWay of operating The user provides the login module with the user's credentials, the
login module then verifies the information and proceeds with granting access according to the user's role.
Subordination -Dependencies -Resources Internet access, access to the Users table of the DB
3.2.2. Description of Process 2
Name Operator Input processType ProcessPurpose Allows the operator to input information.Way of operating The operator must provide the Operator Input module with the
9
SDDnecessary information in the table labeled “Log Calls”
Subordination -Dependencies The process cannot be initiated from the Login pageResources Internet access, access to the Users table of the DB
3.2.3. Description of Process 3
Name Uniqueness of call processType ProcessPurpose Provides operator with information regarding the uniqueness of each
incident call.Way of operating If the operator believes the call 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. In the event that the operator believes that this call is unique, s/he shall click on the “Continue” button.
Subordination -Dependencies The user must be an operator (verified in the Login process)Resources Internet access, access to the DB
3.2.4. Description of Process 4
Name Locate Available Ambulances processType ProcessPurpose Provides dispatcher with the information regarding the nearest
ambulances.Way of operating Using Google Maps to determine the approximate amount of time for
each ambulance to become available the system selects the ambulance to be associated with the incident.
Subordination -Dependencies The user must be an operator (verified in the Login process)Resources Internet access, access to the DB
3.2.5. Description of Process 5
Name Ambulance Status UpdateType ProcessPurpose Enables the dispatcher to modify the status of the ambulances.Way of operating The dispatcher using the Locate Available Ambulances module
determines the available ambulances. Then, the module will update the database with the input provided by the dispatcher.
Subordination -Dependencies In order to go through this process a user must log into the system
using an operator account and go through the Locate Available Ambulances process.
Resources The module needs to have access to the Internet and to the database.
3.2.6. Description of Process 6
Name Information Retrieval processType ProcessPurpose Provides dispatcher with information regarding previous calls for 6
months..Way of operating The dispatcher is provided with information about the incident calls.
This is done using the search operation presented by the system.Subordination -
10
SDDDependencies In order to have access to this process a user must log into the
system using an operator account.Resources The process needs to have access to the Internet and to the
database.
3.2.7. Description of Process 7
Name Logout processType ProcessPurpose Logs a user out of the system, ending the user's session.Way of operating The user clicks a Logout link, available on every page except the
Login page.Subordination -Dependencies The process cannot be initiated from the Login pageResources Internet access, access to the Users table of the DB
3.3. Description of Data ModulesDescription of data modules according to 5.3.1 – 5.3.10, from [1]. The data modules can be identified on the use case diagram(s) from the Software Requirements Specification.
3.3.1. Description of Data Module 1
Name Equipment informationType Data modulePurpose Important information about the ambulances that are to be used for
this project.Way of operating Stored information in the database, that will be translated to the
users in different forms for the: -operator ask for data -> obtain it Can log new calls -dispatcher ask for data ->obtain it Is responsible for updating and dispatching the ambulances
Subordination -Dependencies -Resources Access to the database (SQL)
3.3.2. Description of Data Module 2
Name Login informationType Data modulePurpose It’s sent to a server and tested to see in the database if the user and
password are foundWay of operating Ambulance administration projectSubordination -Dependencies -Resources Temporary data stored for a brief period of time between the insertion
and validation (the application enter the running state)
3.3.3. Description of Data Module 3
Name User information
11
SDDType Data modulePurpose Important information about the user (team, position, username etc)Way of operating Stored information in the database will be used by the system in
order to display specific content for each userSubordination -Dependencies -Resources Access to the database (SQL)
3.3.4. Description of Data Module 4
Name Teams informationType Data modulePurpose This information is very important as it is important to know for each
location how many ambulances are available and how can they be found
Way of operating Stored information in the database will be used by the system in various reports
Subordination -Dependencies -Resources Access to the database (SQL)
12
SDD
4. Dependency DescriptionThis chapter corresponds to chapter 6.2.2, Dependency description, from [1].
4.1. Dependencies among modules
4.2. Dependencies among processesThe dependencies identified in chapter 3.2 are detailed. Detailed diagrams are recommended.
4.3. Dependencies among data modules
4.3.1. Login information <-> User informationThe first one is used to be stored locally for a brief period of time so it can be transmitted to
the system and then the system will test if the login information is found in the database; if the values are found, the user will get to the next phase in using the software. It affects all users.
4.3.2 User information <-> Dispatch informationAn dispatch will be seen different by the entities:
Dispatcher will be the only that locate the available ambulances, make the status update for the ambulance and then can retrieve information.
Operator can add his input and check for the uniqueness of the call.For administrators and managers the information from the orders are used for different reports, they can’t update or delete them.
4.3.3 Equipment information <-> Dispatch informationAn action consists of equipment that is being dispatched.
4.3.4 User information <-> Dispatch informationA dispatch will be seen by the following entities:
Dispatchers Operators
13
SDD
5. Interface DescriptionThis chapter corresponds to chapter 6.2.3, Interface description, from [1].
5.1. Module Interfaces
5.1.1. Module 1 Interface
Name LoginType (see 3.1.1)Purpose (see 3.1.1)Way of operating (see 3.1.1)Interface result: Login(username, password)Input username: String – the user name, read from the keyboard
password: string – user access password, read from the keyboardOutput result : String – OK or FAILED, depending on the search result of the
(username, password) pair in the Users database Description The registration operation is made by introducing a user name and a
password from the keyboard; the existence of this pair is verified in the Users data base; the data base search result will be returned as a string.
5.1.2. Module 2 Interface
Name Operator InputType (see 3.1.2)Purpose (see 3.1.2)Way of operating (see 3.1.2)Interface result: Operator Input (Name of Caller, Location of Incident, Priority)Input The three 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.
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. 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.
Description The system shall allow the operator who receives an incoming call to input information, which is the beginning process of dispatching an ambulance.
5.1.3. Module 3 Interface
Name Uniqueness of callType (see 3.1.3)Purpose (see 3.1.3)Way of operating (see 3.1.3)Interface result: Display (Uniqueness of call) Input The operator has already input information about each incident in the
system’s 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
14
SDDduplicate 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.
Output The system shall output a populated list of the currently pending incidents. 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.
Description The system shall help determine the uniqueness of each 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.
5.1.4. Module 4 Interface
Name Locate Available AmbulancesType (see 3.1.4)Purpose (see 3.1.4)Way of operating (see 3.1.4)Interface result: Display (Locate Available Ambulances)Input The approximate amount of time for each ambulance to become
available is the necessary input. This is retrieved using Google Maps. 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 using of course Google Maps.
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.
Description The system shall find the nearest ambulances and the dispatcher shall choose the number needed to dispatch. The dispatcher can then select the appropriate number of ambulances to dispatch to the incident. (Each ambulance can carry two patients).
5.1.5. Module 5 Interface
Name Ambulance Status UpdateType (see 3.1.5)Purpose (see 3.1.5)Way of operating (see 3.1.5)Interface result: Update(Ambulance Status)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.
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)
Description The dispatcher shall be able to update the status of the ambulances.
5.1.6. Module 6 Interface
Name Information Retrieval
15
SDDType (see 3.1.6)Purpose (see 3.1.6)Way of operating (see 3.1.6)Interface result: Display (Information)Input The user can search the system for incidents by inputting the caller’s
telephone number, the caller’s name, the caller’s address, or the date of the call
Output All output is directed to the system’s 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.
Description The system shall provide an interface for viewing the information about all previous calls for 6 months.
5.1.7. Module 7 Interface
Name LogoutType (see 3.1.7)Purpose (see 3.1.7)Way of operating (see 3.1.7)Interface result: the system displays the Login pageInput -Output the users is redirected to the Login pageDescription Each page of the application provides a Logout button which can be
clicked by the user anytime he wants to leave the application.
5.2. Processes Interfaces
5.2.1. Process 1 InterfaceSee 5.1.1
5.2.2. Process 2 InterfaceSee 5.1.2
5.2.3. Process 3 InterfaceSee 5.1.3
5.2.3. Process 3 InterfaceSee 5.1.3
5.2.4. Process 4 InterfaceSee 5.1.4
5.2.5. Process 5 InterfaceSee 5.1.5
5.2.6. Process 6 InterfaceSee 5.1.6
5.2.7. Process 7 InterfaceSee 5.1.7
16
SDD
17
SDD
AppendicesA1. Use cases diagrams
18
SDD
A2. Class diagrams
19
SDD
A3. Sequence diagrams
I
20
SDD
21
SDD
A4. Document evolution
A5. Conclusions regarding the activity
22
Top Related