Keywords

1 Introduction

Information is considered as a key requirement for managing any kind of emergencies [1]. When an emergency happens, a complex network of emergency responders (ERs) from various emergency response organizations (EROs) such as police service, fire protection service, hospital service and municipality officials are involved in emergency response operations to alleviate both property and human losses. Furthermore, among these involved ERs, few ERs work on-site and others off-site (Control and Command Center). In addition, the involved ERs are often fragmented into different teams to carry out different tasks (such as evacuation, finding victims, firefighting, preventing property and so on) at different geo-locations [2]. Due to geographical dispersion, these fragmented teams must get access to relevant information such as location of the victim, location of the fire, location of the resources, location of the exits and so on to share within or among (intra-inter) teams to obtain or help to get the overview of the situation, to cooperate effectively and for decision-making [3].

When an emergency occurs, a lot of data is generated from various places. The volume and velocity of generated data tend to be extremely high, making it hard for ERs to process it [2, 4]. Without having enough and the right type of information, it is difficult to gain situational awareness [5,6,7]. Particularly, in dynamic and time critical situations, it becomes difficult for the first response teams to adequately decide which information might be relevant for other teams to support overall coordination. Despite the rapid development of ICT for emergency management [8, 9] information on-site is still typically collected manually.

In addition, each organization stores data in different formats in their own databases, making retrieval and sharing difficult. Consequently, the responders, both onsite and remotely face a lot of difficulties in getting an overview of the situation. The time pressure and the urge to respond worsen the problem and information may be ignored, even though it is available [10]. Therefore, to overcome these difficulties, the authors of this paper proposed and implemented a Model-driven data integration framework for emergency management. So, the research question that we want to answer is “Does the developed information system which can be used in any emergency response meet the user requirements of various ERs?”.

As this research question is generic and difficult to answer, we have formulated the above question to a specific case i.e., indoor fire emergency search and rescue operation. The goal of this paper is to address the following research question: “Does the developed information system (LifeRescue) which can be used during indoor fire emergency search and rescue operation meet the user requirements of different ERs?”.

To address the formulated research question, the authors of this paper developed a prototype named LifeRescue and conducted a workshop session by following a three-step process: (1) prototype demonstration and trail session, (2) semi-structured interview, and (3) individual questionnaire. The results presented in this paper were analyzed after the workshop session. The significance of this work lies on providing a holistic way to access information for supporting different ERs during indoor fire emergency search and rescue operation with a developed software prototype consisting of a GUI.

The remaining sections of this paper are organized as follows: we first begin with presenting the proposed data integration framework Sect. 2. Then, in Sect. 3, we describe the research methodology that was used for evaluating the user requirements and also describe the developed LifeRescue prototype. We then present our findings in the results part and the findings of the prototype evaluation are discussed in Sect. 4. Finally, contribution and conclusion of this research are discussed with directions for future research in Sect. 5.

2 Data Integration Framework for Emergency Management

To overcome the above-mentioned challenges, we proposed a framework for supporting different ERs. This proposed framework supports a holistic way of improving information availability and accessibility for sharing information among various ERs during emergency response by using Model-driven data integration approach which can be seen in the Fig. 1. In Fig. 1, the data integration framework consists of three components. The complete details of the proposed framework can be found in our previous research [11].

Fig. 1.
figure 1

A data integration framework for emergency management

Full size image

To develop an information system based on the proposed framework, the authors of this study could not get permission to access different EROs’ databases and applications. So, we used an indoor fire in educational building emergency scenario as a use-case and different university applications for data integration. This is because, to develop an effective Information System (IS), a detailed analysis of end-users’ information needs is required in order to make the system consistent [12]. In addition, the usability of such application is crucial for the continuous, efficient and satisfactory use of the system. In the system development, the approach of Human-Centered Design (HCD) involves end-users in each stage of the development cycle [13,14,15]. So, indoor fire emergency use-case scenario was used to capture the user requirements of different ERs. The details of user requirements elicitation can be found in our previous research [16].

3 Research Methodology

As mentioned in [17], evaluation of the system is necessary to analyze the user requirements and usability requirements. Therefore, in this section, we present the methods and material that were used to analyze the user requirements and usability requirements.

3.1 Emergency Scenario and Used User Requirements

The indoor fire emergency scenario which was used during workshop session was as follows.

“Fire accident happened inside the third floor of A’ block of the university building. The building consisted of many students (who might be normal, physically challenged, and sick), library, laboratories and storage rooms. Most of the students noticed smoke, flames, and screams inside the building. Some of the victims also report fire intensification. Due to the fire, the emergency site became rampageous and many students inside the building were wounded and traumatized. The number of people inside the building was unknown. But, the people who were running out of the building were giving information about the seen victims. To respond to the emergency, ERs did not know how many people are still inside the building and also their location [2]”. This emergency scenario was also used for user requirements elicitation, for convenience, these requirements are shown in the Table 1.

Table 1. Used user requirements of different emergency responders
Full size table

3.2 Developed LifeRescue Prototype

Based on the proposed data integration framework, we developed a prototype as a proof-of-concept. According to the suggestion given in [18] and described in our previous paper [19], we followed an HCD process for developing the LifeRescue system and it’s GUI. During entire software development process, different ERs from both police and fire protection services have been involved at several stages (for an example, indoor fire in a university building scenario creation, knowing user requirements for performing the search and rescue operations, mock-up GUI design and so on) to increase the usefulness and acceptance of the system, and to provide feedback and their requirements for the GUI features with us [20].

The GUI of the LifeRescue can be seen in Figs. 2 and 3. Figure 2 represents the login page for the developed application. Figure 3 presents relevant information to different ERs. However, to provide relevant data to different ERs for prior emergency scenario, the authors have used university systems’ applications for data integration. The prototype architecture, description of each data source, its metadata and implementation can be found in our previous research [19].

Fig. 2.
figure 2

Log-in page of LifeRescue prototype graphical user interface

Full size image
Fig. 3.
figure 3

Main page of the LifeRescue prototype graphical user interface [19] (Color figure online)

Full size image

The developed LifeRescue provides both static and dynamic information to the ERs. Here dynamic information means the information which gets changed over time during fire emergency and static information means the information which remains unchanged all the time during fire emergency. Both types of information are provided to the ERs with the following features which are listed below.

  • Pie - chart: In this chart, ERs can understand the total number of victims who are still inside the university building in a pie chart format. When the victims are rescued and out of the university building, then the count on the pie chart will be changed automatically (see Fig. 3). So, it is a dynamic information. This information can make the ERs get awareness of the situation and help them in making decisions.

  • Floor map: In GUI, the floor map represents each floor. The location of the victims’ is displayed on the map of each floor of each building block. The icons on the map (red and blue) represents location of the victim and their details (such as full name, age, gender and medical status) on a specific floor and the color of the icon helps the ERs to distinguish whether the victim is a normal or a physically challenged person. In this floor map, ERs can also see the fire related information with heat map (i.e., state of the fire in each room). The heat map is updated every second to consider the latest development of the fire. The colors on the floor map (in Fig. 3) go from green to red depending on the intensity of the fire. In the same floor map, ERs can also have a chance to see information related to the movement of the victims (i.e., moving from one location to other). So, this information is dynamic information. With this information, ERs get awareness of the victim location and can decide what should be done to rescue the victims.

  • Tabs: Tabs represent each block (such as A, B, C, D) which is located inside the university building. In each tab, the total number of floors can be seen. For an example, Block A has three floors (e.g., Floor 1, Floor 2, Floor 3) (see Fig. 3). In each floor, information related to the total number of victims can also be seen in the GUI. So, it is a dynamic information.

  • Building related information: This information is related to university building such as type of building, material used for constructing the building, number of floors and exits. This information can make ERs decide e.g., how fast the building-gets burned, which entrance is safe to enter and so on (see Fig. 3). So, it is a static information.

  • Hazardous Information: Information related to location of the hazardous goods inside the building. This information gives overview of the hazardous materials for the ERs (see Fig. 3). So, it is a static information.

  • Resource information: The location of the resources such as fire hoses and fire extinguisher which are needed for the fire extinguishing and its details such as coverage length of the fire hose, capacity of the fire extinguisher, model of the fire hose and fire extinguisher also provided to the ERs (see Fig. 3). So, it is static information.

3.3 Procedure and Participants

We first narrated the afore-mentioned scenario and demonstrated the prototype to different ERs. Then, we asked the participants to try the prototype. After that an individual SUS questionnaire was given to scale their opinion on the system usability and finally a post-test group interview was conducted with ERs to know whether the system fulfilled their information requirements.

The evaluation of the system was made with 6 ERs from fire protection and 3 ERs from police service departments in their respective organizations. The facilities had a meeting room with external screen and keyboard. In the meeting room, all the ERs gathered and the authors of this paper narrated an indoor fire in the university building scenario. After narrating the scenario, the developed prototype was demonstrated on the external large screen after connecting with a laptop where the prototype was running on. All features of the LifeRescue GUI were explained thoroughly to the ERs for 30 min. Then, participants tried the LifeRescue.

Among the participated 6 ERs of fire protection service, one works as fire chief (FC) who acts as an on-scene commander, 1 person as crew manager (CM), one as smoke diver leader (SDL), and three persons as smoke divers (SD). Whereas, 3 ERs from police service, 2 work as police chief (PC) at emergency site, and 1 as control room supervisor (CRS). The experience of the involved participants in responding to the emergency situations ranges from 4 to 20 years’ experience. The entire workshop session carried out for 2 h (120 min). During the session, participants were encouraged to ask questions and comment on the LifeRescue prototype.

3.4 Data Collection

The data collection was done by using audio recording of the post-test group interview and with SUS questionnaire.

Semi-Structured Interviews.

After the SUS questionnaire, a semi-structured interview session was held with all participants to obtain in-depth feedback in relation to the user requirement fulfilment and to get any suggestions for the system improvement. The whole interview session was audio recorded for the content analysis.

System Usability Scale Questionnaire.

After the prototype demonstration and trail, a System Usability Scale (SUS) questionnaire [21] which consists of 10 questions was given to each participant to evaluate the usability and performance of the system. The SUS questionnaire, is composed of 10 statements that are scored on a 5-point scale of strength of agreement.

The SUS was developed by Brooke [21] as a “quick and dirty” survey scale that would allow the usability practitioner to quickly and easily assess the usability of a given product or service [22].

Although there are a number of other excellent alternatives surveys available such as After Scenario Questionnaire (ASQ) [23], Computer System Usability (CSUQ) [23], Post-study System Usability (PSSUQ) [24], Software Usability Measurement Inventory (SUMI) [25], System Usability Scale (SUS) [21], Usefulness, Satisfaction and Ease of Use (USE) [26, 27] and Web Site Analysis and Measurement Inventory (WAMMI) [28], the SUS has become a good choice for general usability practitioners. The reason for this is the initial paper of Brooke [21] where the SUS questionnaire was first published has been cited over 3500 times, and studies have confirmed the reliability of the SUS with Cronbach’s alfa 0.91 [22] with the conclusion that SUS can positively supplement a usability test and evaluation program.

In the study [22], all the above mentioned surveys were compared and the results summarized that the SUS survey was the most reliable one. Therefore, in this paper, SUS survey has been used to evaluate the user satisfaction and usability of the system. In SUS, final scores range from 0 to 100, where higher scores indicate higher user satisfaction and better usability.

According to the researchers in [29, 30], the researchers used an adjective scale by dividing the SUS scores as follows: score of 0–25: worst, score of 25–39: poor, score of 39–52: OK, score of 52–85: excellent, and score of 85–100: best imaginable. So, in this paper we have adapted the same adjective scale in our study. The used SUS questionnaire format and questions can be seen in Fig. 4.

Fig. 4.
figure 4

(Source: [21])

System usability scale © digital equipment corporation, 1986

Full size image

3.5 Data Analysis

After the workshop session, all the data from SUS questionnaires and audio recordings of the group interview were transcribed into excel sheet. After transcribing, the scores of the each SUS questionnaire were calculated. The score calculation was based on the details of scoring the SUS which was explained in the article [21]. The recordings data were imported into QSR NVIVO 10 tool [31] for transcription and a qualitative content analysis.

4 Results

In this section, the results of the system evaluation are presented with the help of qualitative and quantitative analysis.

4.1 Qualitative Analysis

During workshop session, participants got access to the LifeRescue GUI. After getting access to the GUI, they went through the GUI features thoroughly. Then some questions were asked to the participants. Their answers were audio recorded and later encoded into Nvivo tool. The coded content organized into 4 groups: User Requirement Evaluation, GUI Placement, GUI Features Recommendations, and Existing Systems vs LifeRescue GUI.

User Requirement Evaluation.

During the interview, all the participants from fire and rescue service mentioned that “after reaching the emergency site, we have no idea how many people are still inside the building and their location. This information we generally collect manually from either security personnel or from floor responsible person”. With this statement, it is apparent that there is no ICT (decision-support) system used in Norway to support ERs’ information needs during an indoor fire emergency at university.

We then asked the participants about their first impression after seeing our developed system. All participants stated and agreed that “the system is very well integrated and gives relevant information to us”. We then asked the participants whether the developed system fulfils the user requirements that they stated at the beginning of the system creation. Answer to this question was given by FC and PC1 that “it is easy to login to the GUI and the screen was useful to get overview of the inside situation i.e., victims and their location”.

Another four participants (1 SDL, 1 CM, 1 SD and PC2) positively commented on the pie chart feature of the GUI, “it helps to get the overview of the number of victims still inside the building”. Based on the responses to the questions, we have categorized the participants’ responses into YES or NO (i.e., if user requirements are met then answered as ‘YES’ and if user requirements are not met then answered as ‘NO’). The results of the user requirements evaluation are presented in Table 2.

Table 2. Results for the user requirements evaluation
Full size table

GUI Features.

All participants found that features that got incorporated in the GUI were very well integrated and useful for supporting their information needs to perform emergency response activities. They also mentioned that navigation was very easy and the information that was displayed on the GUI was with good visibility. However, they have provided some recommendations to improve the current GUI features by adding some extra information i.e., adding phone number to the victim details. With this information, either police or fire personnel can send mass messages to the trapped victims. Furthermore, the participants also mentioned that adding information related to room and corridor dimension (such as width, breadth and length size) will be helpful for the fire fighters.

Participants have also stated that displaying all information in a single browser with a single click was an outstanding idea, because, participants have lot of thing to perform at the same time at the emergency site. So, if they are given with multiple browser windows, that would be overloading for them to remember the information that they get from the LifeRescue GUI.

Participants have also commented that getting fire related information on the LifeRescue GUI was an excellent feature. However, they recommended that “coloring whole room would be better instead of showing this information in a dot form on the LifeRescue GUI”. All the firefighters agreed and specified that “instead of showing which room has hazardous materials in a list form, better to show them on the LifeRescue GUI with a symbol form”.

GUI Placement.

During the interview, the authors of this paper were interested to know answers to the following questions: “where can the system be placed during emergency and who should have access to the LifeRescue”.

All the participants responded to these questions as follows: “access to the GUI should be given to the ERs who are working at the emergency site”. The reason for this statement was given by the fire chief “he/she does not get orders from the support room (110 room). Fire chief just asks the support room to provide additional resources whenever he/she needs during emergency response”.

FC has also mentioned “he is the one who takes decisions at the emergency site. So, he is the one who is suitable for having the GUI access”. Furthermore, participants who work as CM and SDL mentioned “we would also like to get access to the GUI as they should also obtain the awareness of the situation to guide SDs”. However, SDs mentioned “if we carry small tablets with us, then we will get the information about the victims and their location. However, carrying the tablet would hinder our performances”.

When it comes to police service participants, the police chief mentioned that “access to the LifeRescue GUI should be given to both control room (112) and police chief who are at emergency site”. The reason for this statement was given by the police chief as “he/she get orders from the control room (112). Police chief informs the control room and wait for their decisions during emergency response process”. Police chief also mentioned that “he waits for the decisions that are taken by the superiors at the emergency site. However, having access to the GUI can make him to recognize the suspected person”.

Existing Systems vs LifeRescue GUI.

Firefighters do not use any kind of ICT system that can help them to acquire the needed/relevant information automatically from the emergency site. Usually, they take notes manually from the emergency site and later use the collected information to make reports in “Microsoft word document” after any kind of fire emergency. These reports are then sent to Directorate for Civil Protection and Emergency (DSB) [32]. All this process is done through electronic mail.

Whereas, police use lots of ICT (decision-support) systems during emergency response, but they also do not have any kind of ICT system that can help them to acquire the needed information automatically from the emergency site. However, social media like twitter, Instagram and so on are being used by the police department to help them getting the awareness of the situation. However, this channel does not completely give the awareness of the situation. Generally, they collect information either manually from the emergency site or get from the fire chief. This information is then used in emergency reports that are created in the “Microsoft word document”.

From our interview with the participants revealed that mainly 2 ICT systems in Norwegian crisis management have been used i.e., A crisis incident management (CIM) tool used by the police, and (2) LOCUS used by the fire and rescue service, and the health service.

CIMtool [33] is a software program for crisis management support, produced by One Voice AS, a company delivering crisis management solutions for a variety of organizations. It supports aspects of crisis management such as quality assurance, risk and vulnerability analyses, emergency planning, training, and evaluation. The purpose of this tool is to notify police personnel when major incidents occur. It supports notification and alerting of personnel through distribution lists for sending messages by email, SMS, and phone. The system provides the receiver with several response alternatives which are logged, so that the sender of a message can keep track on the status of each alerted individual [34]. It is currently used by many organizations that the police collaborate closely with, among others, the Directorate for Civil Protection and Emergency Planning (DSB), The Norwegian Civil Defense, and all Norwegian municipalities and county governors.

Whereas, LOCUS is a company delivering mission-critical solutions and products to the fire and rescue service as well as to the health service, among others (e.g. transport and logistics, security service companies). Its solutions are designed to reduce time constraints through being a tool for the emergency agencies to make the right decisions in relation to resource allocation. LOCUS’ solutions are used by the 110 and 113 emergency call centrals (TransFire for the fire and rescue service and TransMed for the health service) and mobile devices installed in vehicles for the tactical personnel (TransMobile 7). The detailed information about the solutions can be found in [34]. However, both ICT systems, do not provide the information requirements (see Table 1) of the different ERs automatically from the emergency site as LifeRescue provides.

When we asked the participants for their opinion on the LifeRescue system, one participant stated as “I like this new system and would find it helpful. In LifeRescue GUI, there are not many clicks and acquiring the relevant information is not complicated at all.” Another participant commented: “Anyhow, I think this system would be useful. Usually, I should search a lot for information during emergency response. But, in this LifeRescue, I like the visibility of the key information”.

4.2 Quantitative Analysis

During workshop session, a SUS questionnaire has been used to document the participants’ opinion on system usability. The results of the SUS responses are presented in Table 3.

Table 3. SUS scores (higher score implies better performance)
Full size table

The SUS responses in Table 3 are described as follows. If the mean agreement scores are ≥4 out of 5, that means the participants Strongly Agreed that they felt confident using the LifeRescue prototype, it was easy to use and ERs would like to use. If the mean agreement scores are <3 out of 5, then the participants generally Disagreed with statements that the LifeRescue prototype was: unnecessarily complex or cumbersome (or required technical assistance), or inconsistent in format (i.e., the mean of the dissatisfaction ratings were on the range of Agree, Strongly Agree or Neutral for most answers to the positively enunciated questions and in the range of Disagree, Strongly Disagree or Neutral for most of the answers for the negatively enunciated questions).

Adjective Rating.

The researchers in [29, 30] used an adjective scale by dividing the SUS scores as follows: score of 0–25: worst, score of 25–39: poor, score of 39–52: OK, score of 52–85: excellent, and score of 85–100: best imaginable. Authors of this paper also adapted the same adjective scale in our study. The results of the overall SUS scores of each participant response are presented in the Fig. 5. Based on the responses given to the SUS questionnaire, the results show that all the participants have given rating above 60%. Therefore, the LifeRescue achieved “Excellent and Best imaginable” SUS rating. However, the SUS scores calculation can be found in [21]. From the Fig. 6, it is observed that SDL, FC1, PC1 and PC2 rated that the LifeRescue is “best acceptable” system which can be used to support their work during the indoor fire emergency search and rescue operation. The other participants also rated the system as “excellent” to be used to support their work during the indoor fire emergency search and rescue operation.

Fig. 5.
figure 5

SUS scores based on each participant’s response

Full size image
Fig. 6.
figure 6

Responsesto learnability dimension

Full size image

Learnability and Usability Dimensions.

In the seminal work of [35], the researcher conducted factor analysis on the SUS statement and then defined two dimensions, i.e., learnability and usability. As per their analysis, the learnability dimension includes the statement 4 and 10, while the usability dimension includes the statements 1, 2, 3, 5, 6, 7, 8, and 9 of the SUS questionnaire (see Fig. 4). The detailed explanation of these dimensions can be seen in the work [21, 35]. In this paper, the authors have also used learnability and usability dimensions to understand the user views on the developed LifeRescue.

For learnability dimension, responses to the questions 4 and 10 are considered and calculated. The results of the responses to the questions 4 and 10 to understand the learnability dimension can be seen in the Fig. 6.

In Fig. 6, it is seen that the response for the question 4 was given 56% as SD and 44% as D. For the question 10, all participants responded 78% as SD and 22% as NAND. It is because the LifeRescue was very easy to use and no technical person is needed to setup the system. The ERs are usually need to login to the LifeRescue web application (see Fig. 2) with given username and password to acquire the emergency related information on the main screen (see Fig. 3). Therefore, with the responses, it is perceived that the LifeRescue was not much difficult to learn.

Whereas, for the usability dimension, the other 8 questions are considered. The responses to these 8 questions can be seen in the Fig. 7. Results reveal that all the participants responded as either SA or A or NAND for positive questions and SD, D or NAND for negative questions. From the results, it is again perceived as LifeRescue was easy to use. In an overall view, participants mentioned “the system is easy to learn, use and support them to achieve their goals during search and rescue operation”. The participants also commented that the colors which are being used in the GUI are good enough to differentiate the different kind of victims and fire related information (see Fig. 3). Participants did not face any kind of usability problems.

Fig. 7.
figure 7

Responses to usability dimension

Full size image

5 Discussion and Conclusions

Emergency response operations demand well information access to support search and rescue tasks and decision-making at the emergency site and at the command and control center, because, the availability of the needed information is one of the bottlenecks [36]. However, in any kind of emergency response, upon arrival at an emergency location, first responders usually use lot of time gathering information to obtain an overview of the situation. The time for which first responders spend on gathering static and volatile situational information from affected people as well as from responsible persons at the emergency site can be reduced if they are given with accessibility or availability of the needed information [16]. Therefore, an approach was proposed which is a holistic way to access information during emergency search and rescue operations. Based on the approach, a LifeRescue information management system was developed to support different ERs for enhancing their response activities during fire emergency in a university building.

When a software system’s development is complete, it is necessary to ensure that the outcome is successful. To check that, the design team must check whether the system satisfies the needs and wants of the user. To achieve this, user needs should not only be elicited by techniques such as surveys, focus groups, interviews etc., but they should also be reflected back to users via simulations in order to prototype the user requirements [37]. Therefore, in this paper, we present an evaluation of a developed LifeRescue information management system to ensure that user requirements (of different ERs in case of a fire emergency in the educational building) are met. In addition, we present the usability of the developed prototype.

To evaluate the user and usability requirements of the system, a workshop session was being held with 6 participants from fire and 3 from police departments for testing the developed LifeRescue. The workshop session was incorporated with a prototype demonstration and trail, semi-structured interview and a SUS questionnaire. The findings show that the participants felt that the developed system fits to their purposes and showed their satisfaction that the system fulfils the requirements. All participants mentioned that accessing diverse information from diverse sources was very easy. This information accessibility and availability can make them achieving the situational awareness. The participants also acknowledged that “they prefer to use this system during any kind of fire emergency response”.

Furthermore, the SUS questionnaire results reveal that all participant gave rating above 60%. That means that the LifeRescue achieved “Excellent and Best imaginable” SUS rating. The results show that participants SDL, FC1, PC rated that the LifeRescue is “best acceptable” system which can be used to support their work during the indoor fire emergency search and rescue operation. The other participants rated the system as “excellent” to be used to support their work during the indoor fire emergency search and rescue operation. When it comes to learnability and usability dimensions, results of the responses to the SUS questionnaire concludes that LifeRescue that the system is easy to use and learn. So, with this obtained results, answer the sub question which was mentioned at the beginning of the paper.

Based on the results of our study, it is anticipated that our methodology can be used for all types of emergencies and fulfils user requirements. Moreover, the lessons learned from this study are two-fold: Firstly, any emergency information system should be easy to use and fast enough to provide relevant/needed information to the involved ERs upon arrival at the emergency site. Another lesson is that ERs information requirements should be met with the support of ICT i.e., integrating diverse data sources, presenting, and sharing the right information to the right people in the right format at the right time which is critical in any emergency response situation.

There were some limitations associated to this study, such as the use of a simulated test environment and a reduced number of end-users. Firstly, the workshop session was carried out with a prototype demonstration and trail in a simulated setting instead of a real emergency response environment. So, testing the system in a real emergency settings through a field trial would be recommended. Secondly, the reduced number of participants in the user requirement and usability evaluation can be seen as an impediment of the applicability of the findings in a larger scale. However, the participants meaningfully represented the end-users of the system and in qualitative usability studies, a small number of participants can be sufficient for having valid results [38].

Our potential future research directions will be to develop the LifeRescue by adding the features that are recommended by the participants and test the implemented prototype in a realistic fire emergency response setting for making further improvements of the system.