SDD_SAS - 07.05

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.


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.


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.


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.


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.



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


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


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


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


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.



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.


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)


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)


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)


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.


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.


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.


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).


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.


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.


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








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

Documents

SDD_SAS - 07.05