Mobile Computing for Disaster Emergency Management: Empirical Requirements Analysis for a Cooperative Crowdsourced System for Emergency Management Operation

: In large-scale civil emergencies such as ﬂoods, earthquakes, and extreme weather conditions, extended geographic areas and a great number of people may be a ﬀ ected by the unfortunate events. The wireless internet and the widespread di ﬀ usion of smart-phones and mobile devices make it possible to introduce new systems for emergency management. These systems could improve the e ﬃ ciency of the interventions by transferring information between a ﬀ ected areas and a central decision support system. Information on the state of the infrastructures, on people displacement, and on every other important and urgent issue can be gathered in the disaster area. The central system can manage all the received information and communicate decisions back to people and also facilitate the exchange of information for di ﬀ erent people that are still in the disaster area. This paper presents a requirement analysis for these kinds of systems. The presented analysis allows better tailoring of the features of these systems with the aim to meet the real need of emergency management operators and citizens.


Introduction
In the occurrence of a natural disaster of great proportions, administrations and citizens need to cooperate efficiently, to avoid waste of resources and also to exchange a lot of data and information with considerable speed. It is necessary to organize all resources to rescue victims and to deliver everything that is needed in the right place at the right time. All operations in the affected areas may have to be carried on a transportation network, which may have lost some of the relevant infrastructures. For this reason, knowledge of the current state of the transportation network in a disaster emergency is extremely important for better management of the emergency interventions.
Often, in a disaster emergency, some of the transportation infrastructures may be completely unusable or may present a partially reduced capacity. Some areas may be difficult to reach for these failures and severe congestion may set on the roads exiting the disaster area.
The management of a disaster emergency is strictly connected to the management of the transportation network. A good disaster emergency management should be able not only to make good use of the transportation network for logistics activities, but also convey important information to citizens to avoid the onset of severe traffic congestion on important roads.

•
Connectivity reliability is concerned with the probability that network nodes are connected. The network is considered successful when paths are operational. A path consists of a set of links, which are characterized by zero or one to denote the link's status (operating or failing). A special case of connectivity reliability is the terminal reliability, which concerns the existence of a path between a specific origin-destination (O-D) pair [19]. This binary approach has limited applications to everyday situations where roadway links are normally operating between the two extremes, but it may be suitable for abnormal situations such as earthquakes [19][20][21]. • Capacity reliability refers to the probability that the network capacity can accommodate a certain volume of traffic demand at a given service level when the link capacity is subject to random variations [22]. Lo and Tung [23] calculated the maximum flow a network can accommodate subject to the route choice principle of probabilistic user equilibrium under degradable link flow capacities (minor day-to-day events of stochastic link capacity variations). Connectivity reliability is a special case of capacity reliability where capacities are assumed to go to zero. • Travel time reliability is concerned with the probability that a trip between a given O-D pair can be made successfully within a given time interval and a specified level of service (LOS) [24,25]. Nevertheless, the subject of travel time reliability is challenging because there is no single agreed-upon travel time reliability measure. Different researchers have used different definitions of transportation network travel time reliability. Two of the most commonly used methods of travel time reliability in the U.S. are the Florida Reliability method and the California Buffer Time method.
The analysis of network reliability involves measuring the ability of the network to meet some expected functional criteria or "tolerance" set by its users, which in turn varies according to the severity and frequency of the underlying "non-recurrent" and "recurrent" causes.
Recently, the reliability of transportation networks has emerged as an important topic due to its critical status as the most important lifeline in the restoration process following the occurrence of a disaster. It has attracted many researchers to develop various indicators to assess the reliability of transport networks. The primary sources of unreliability include unpredictable demand-related traffic interactions between users (congestion) and unanticipated supply-related events (natural events, traffic incidents, network maintenance, mismanagement in infrastructure supply, etc.). Figure 1 provides a reminder of the relationship between the sources of unreliability. Moreover, it also illustrates the essential connection in network reliability between the provision and management of infrastructure (the supply) and its usage (the demand). Reliability can be different given the network operator perspective or the user perspective. Different methodologies can be applied to control and increase the reliability of the transport network. The OECD study reveals that four main instruments are available to optimize reliability on transport networks:

•
Physical expansion of capacity. This would require pre-disaster planning of the transportation network.

•
Better management of capacity. Capacity can be improved through better disaster management.

•
Pricing mechanisms to deliver a market for reliability. Where feasible, charging directly for reliability could be used to achieve more efficient levels of reliability.

•
Provision of information intended to mitigate the adverse consequences of unreliability, rather than to reduce the incidence of the unreliability.
As introduced above, an important tool in disaster emergency management is the distribution of information. Information can be of two different types: Pre-trip information and on-trip information.
Pre-trip information allows users to change the time of departure, the modal choice, or also to give up on the journey. Pre-trip information can be very useful in disaster management to avoid users to over saturate a single infrastructure. Pre-trip information can be broadcasted on tv or radio, that have always been used for broadcasting traffic information. But more efficiently, it can be broadcasted with internet-based services on mobile-phones. The use of on-trip information can also similarly reduce travel times. Given updated information or mandatory paths in case of disasters, network users can change their path. Even in the case there is no possibility to reduce travel times, just being fed information on the state of the network can help to keep rational decision making.
In this paper, we focus on an empirical analysis of functional requirements for emergency management system software based on new technologies, the application of which can bring significant advantages to the management of emergency situations especially in urban areas, in which Transportations and Telecommunications play a crucial role in disaster response and management. The main assumption is that telecommunication systems are connected to emergency generators which, in case of electricity breakdown, guarantee continuity of operation.
In the following Section 2 (Materials and Methods), the Section 2.1 presents the Mobile for Emergency (M4EM) software system, the Section 2.2 presents the methodology to obtain requirements for the software system, the Section 2.3 presents four scenarios that are used to derive requirements, an example of how requirements are obtained is presented in Section 2.4. Section 3 summarizes and describes all the 50 obtained requirements from the previous analyses. In Section 4, conclusions are presented and some recommendations for future studies are advised.

Materials and Methods
This section introduces the general operation of the M4EM system and the methodology underlying the definition of the system requirements and illustrates four possible application scenarios and the extraction method of selected requirements.

A Proposal for an Emergency Management Software
In a disaster emergency, different entities can be involved in the delivery of rescue services. Effective management of support and rescue activities necessitates the organization and coordination of all activities within a certain geographic area [26]. The adoption of Intelligent Transport Systems (ITS) can be useful for both creating new strategies for network operations and for enhancing the existing strategies. ITS also ensure the widespread propagation of information to the citizens, administrations, and the emergency management operators, thus allowing users to make informed travel decisions based on such factors that potentially impact their travel time and safety.
A specific system was introduced by the authors in a preceding conference work [27]. The system is designed to focus on current operation allowing the management and control of movements of materials, goods, and people in emergency zones. The system named Mobile for Emergency (M4EM) was designed to cover the whole crisis from before it happens to when it is completely resolved and to allow the management and control of movements of materials, goods, and people in emergency zones.
The operational improvement obtained with the system introduction can come from a more organized and better-structured flow of information and also from the vast quantity of localized information that can be gathered by transforming the mobile devices of the citizens into smart sensors that can gather data on the network condition.
The proposed mobile-phone-based system aims to increase the reliability of a transportation network in a disaster emergency by supporting emergency management and with a continuous exchange of information between citizens and emergency management operators.
The system is designed not only to help optimize the rescue activities in case of emergencies, but also as a support for the long-term post-disaster logistics activities.
The rescue activities are related to the short-term consequences of a disaster while post-disaster activities are oriented to bring back communities to pre-disaster conditions, involving long-term activities such as reconstruction [26].
The proposed system is proposed to support all emergency organization activities by managing the flow of information.
The system M4EM is composed of three main subsystems:
The mobile application; 3.
The Web Platform.
As shown in Figure 2, the system can gather information and data from various sources. Once information is collected, it is structured and elaborated to confirm the legitimacy, by checking the consistency, and it can be made available when it is necessary to citizens and management. With the aid of mobile devices connected to the central server, both emergency crew and common people are engaged both in the gathering and consuming information. The concept is that of cooperative crowdsourcing of information.
The system with the mobile application will gather information from users passively and actively. Citizens and emergency crew can actively input information adding photos and compiling automatic forms or can just keep the application working, passively allowing the application to extract localization information that can add knowledge on the transportation network in real time by using the Global Navigation Satellite System (GNSS) features of mobile devices. Some examples of data that can be gathered are the presence of dangers on the transportation network, specific help requests, georeferenced images and georeferenced information reports, vehicles and people real-time geolocalization, and the condition of the transportation network link by link.
Once information is gathered by the Decision Support System it becomes possible to share the information itself and optimize rescue services and the organization of assistance to the population in a dynamic way. The Decision Support System can provide a real-time exchange of information and data between the emergency crew and the citizens. The collaborative crowdsourced system would be able to connect operators, operating rooms, citizens, and brigade rescuers, in a structured and safe way.
The detail of what kind of services and the system is required to offer was analyzed with a dedicated requirement analysis.

Requirements Analysis for the "Mobile for Emergencies" System
The present way in which emergency management is performed has some operational and coordination issues that severely limit the effectiveness and timeliness of response, thereby affecting the overall infrastructure system resilience.
These limitations can be traced to: • The complexity of the consequence scenarios prediction for every single event and the influence of these scenarios on risk, infrastructure damage, and modes of action aiming to prevent the occurrence of the event; • The difficulty of creating and updating the rescue situation due to poor and inadequate information flows to ensure continuity and timeliness.
A complex system such as a platform for emergency management requires an adequate model, which respects the basic objectives of different levels of emergency plans (regional or national).
According to the Transportation Safety Advancement Group (TSAG [28]): "the deployment and transition complexities of advanced communication technologies will present new interface and security challenges. Similarly, transitioning to interoperable networks presents complex interface requirements".
The technical difficulty of implementing a good user-friendly interface in M4EM is one aspect of the problem, but the main issue is that of establishing exactly what the system must do; for this reason, in this section, we present the results of a requirements analysis for a crowdsourced information system, which would provide users with a tool for optimizing the collective response in case of emergencies and for planning the post-disaster logistics activities. Firstly, an insight into the earlier technologies and tools, which can be used for easing the negative impacts of extreme events on transport networks, was performed, then the proposed information system requirements analysis was performed.
A requirement is something that the product should do or a quality that the product should have. A requirement exists because the specific product demands certain qualities or functions, or because the customer requests it. There are three types of requirements:

•
Functional requirements: Action that the product should be able to do in order to be useful to the user. Most actions fall within this requirement group; • Non-functional requirements: Properties or qualities the product must have. They can describe properties such as usability, appearance, safety, and legal issues; • Restrictions: The restrictions are global requirements. They can affect the product covered by the project as well as the same project.
A systematic approach that can be used to write requirements is the Volere method, one of the most complete and used in the field of software development.
"The Volere Requirements Process Model contains a detailed model of all of the activities and the connections between them. The model is very detailed [29], and a view of the overall process is shown in Figure 3.
In Figure 3, the Volere Requirements Process is presented with all of the main activities, the way they are connected, and the deliverables that can be produced.
The requirement process consists of 3 phases: 1.
Definition of the scope of the problem (work); (a) Project purposes; (b) Adjacent systems and domains; (c) Information flow.

2.
Investigation of potential sources of requirements; Others.
3. Writing requirements. The Volere method is based on the definition of scenarios. Scenarios are like stories. It is possible to use them in a process where the developers work with stakeholders to reach a better knowledge of the functionality to be implemented. The scenario can help, with a step by step reasoning path, to define how a product can be used and what operations it can perform. With this method, the developers can use a simple neutral language and communicate efficiently with the appropriate stakeholders about the different features of a software product. The scenarios, with this methodology, become the base for the definition of needed product requirements.
In [13], the wrong definition of requirements is indicated as the main problem that can be caused because the actual utilization of the product has not been well clarified between the developers and the final users. The developers have to avoid this by writing the requirements in a readable and shareable way so as to ensure that the functional requirements are in line with the adjectives of the development.
The proposed system aims to respond to the reliability of transportation networks and emergency management issues by means of modern communication technology equipment and data transmission in the network.

The Four Macro Scenarios
The investigation of potential sources of additional requirements has been conducted using the Volere method. Four macro scenarios have been proposed. The four macro scenarios are: Raffaele, a university student at the University of Calabria, is driving along the A3 motorway when an earthquake occurs. He notices, 200 meters ahead, the flyover has collapsed. As quickly as possible, he moves to the side of the road, keeping his mind totally focused on safety. He turns off the engine and puts his handbrake on. He is not hurt but he is obligated to remain stopped on the verge of the road due to the blockage of the route. He takes his smartphone and turns on the M4EM_app by means of appeals for help. The distress signal is immediately sent to the public-safety answering point (PSAP) where Anna, a trained operator, manages his request. She is responsible for dispatching emergency services (police, fire-fighting, and ambulance services, etc.). Meanwhile, the system checks the Raffaele's request and asks M4EM_app users for information. After many calls, signals, and requests, the affected area has increased considerably. An event has been created and now Raffaele display updates, warning, and advice while he waits for the emergency services.

Scenario 2
It is 1.00 am when Giuseppe and Martina, a Genovese married couple, hear the M4EM_app alarm. They wake up but do not know what it is about. The entire city has been hit by bad weather conditions. When lightning struck a nearby power line, their neighbourhood suffered a blackout. Hundreds of homes are without electricity after the storm took down power lines. Giuseppe takes his smartphone and turns on the M4EM_app. There are already updates available and he realizes that a flood is threatening their district. Several roads are flooded, and many cars got swallowed. He just learned about current events by reading into the M4EM_app. There is a large pool of rainwater blocking the entrance to their building and the street next to the building is collapsing, leaving a massive crater. The basements and the ground floor are completely flooded. Residents are forced to evacuate due to severe flooding. Giuseppe and Martina decide to appeal for help through the M4EM_app. They try to be detailed and to attach photos in order to provide information for the rescuers. The distress signal is immediately sent to the public-safety answering point (PSAP) where Lorenzo, a trained operator, manages their request. He notices that another request from the same building has not been managed yet and the emergency services have been already warned. Lorenzo gets in touch with Giovanni, the rescuer team leader, and transmit him the detailed information provided by Giuseppe and Martina.

Scenario 3
Gino, an 82-year-old retired employee, flies to Lamezia Terme this afternoon and starts to drive to Cosenza in a rented car. He is driving along the A3 motorway when he hears the M4EM_app alarm. The M4EM_app displays: "Heavy rains have caused landslides throughout the area; temporary interruption of the A3 motorway, both directions, next to Torrente Stupino Viaduct". He hears this text through his car Bluetooth stereo system. This allows him to be aware of current road conditions without disconnecting his focus from driving safely. Gino leaves the A3 motorway at Falerna and takes the state road (SS18).

Scenario 4
An unusual heavy precipitation event is sweeping over Calabria, with a total amount that exceeded 100 mm locally and snowfall of more than 20 cm near the coast. This event affects mainly the coastal region and is accompanied by thunderstorms and strong wind gusts in some areas. Giuseppe, a bank employee, walks along Corso Roma in Paola when the high wind tore up a tree, blocking travel lanes physically. He takes his smartphone and turns on the M4EM_app by means of raises alert over segment blockage. It is immediately sent to the public-safety answering point (PSAP) where Emanuele, a trained operator, manages his request. He is responsible for dispatching emergency services. According to standard procedure, Emanuele warns all the required emergency services. After many calls, signals, and requests, the catchment area has increased considerably. A man and a woman died when parts of a factory wall in the north-eastern town of Fuscaldo fell on them in the storm. A rail crewman was also injured when a train partially derailed after running into a fallen tree. The storm leaves 40,000 customers without power in the Cosenza area. The Calabrian government advised people to stay away from insecure structures through the media and M4EM_app.

The Extraction of Requirements
From each scenario, many requirements have been derived. As an example of how requirements are derived, from this part: "It's 1.00 am when Giuseppe and Martina, a Genovese married couple, hear the Mobile phone app alarm. Hundreds of homes are without electricity after the storm took down power lines", the following requirement is derived and presented in Table 1: Fifty requirements have been derived from all four different scenarios.
The following diagram summarizes the adopted strategy ( Figure 4).

Requirements of the System
The requirements that have been obtained are divided in: -22 requirements for the Decision Support System (DSS): Decision context (14), central database (4), and user interface (4); -25 requirements for the Mobile application: Different information flows [from citizens to operators (5), from operators to citizens (1), and from citizens to citizens (1)], features for citizens (11), features for operators (6), and constraint requirements (1); -3 Web platform requirements. The requirements for the DSS are listed in Tables 2-4.    The requirements for the Mobile application are listed in the following Tables 5-10:      The requirements for the web platform are listed in the following Table 11. All the above requirements have been defined according the Volere Requirements Process, as introduced in Section 2.2. They have been derived from all four different scenarios presented and described in Section 2.3.
It is important to underline that the process of definition and extraction of the requirements follow the exposed methodology, but it should be highlighted that the number and characteristics of the requirements themselves are strictly dependent on the reference scenarios. It is therefore appropriate to rely on case studies to define which requirements to analyze in relation to the emergency to be addressed.

Conclusions
In this paper, the authors analyzed the fundamental requirements of an informatics system platform useful to organize and coordinate all human activities in emergency conditions. In these circumstances, the transportation network used by citizens to reach all types of services and logistic nodes may be compromised or completely unusable and may present a partially reduced capacity.
The advent of new technologies and new communication protocols for the acquisition and transmission of data in real-time (i.e., the fifth-generation wireless technology for digital cellular, 5G) makes the systems for emergency management perform better and better.
The solution examined by the authors is oriented to the development of a mobile phone-based platform to acquire, analyze, and disseminate useful information on the conditions of transport infrastructures and on the management of rescue operations. This solution guarantees a continuous exchange of information between citizens and the emergency management operators, optimizing not only the rescue activities in case of emergency, but also long-term post-disaster activities.
The system platform is composed of a Decision Support System, a Mobile Application, and a Web Platform. The main functional requirements, non-functional requirements, and restrictions are determined using the "Volere" method, based on the definition of scenarios.
This methodology ensures better knowledge of all functionalities to be implemented, how a specific platform's module can be used, and what operations it can perform.
The authors intend to spend more effort to test the proposed system in a simulation environment and verify the functionality of the M4EM architecture, in order to demonstrate that the proposed approach can be adopted as a standard coherent procedure across city departments to facilitate the introduction of innovations in developing smart cities.
Author Contributions: V.A. was responsible for conceptualization and methodology; V.P.G. carried out all the software development; G.G. and A.V. performed supervision, review, and editing; V.P.G. and G.S. carried out the data curation. All authors have read and agreed to the published version of the manuscript.
Funding: This research received no external funding.

Conflicts of Interest:
The authors declare no conflict of interest.