FUNCIONALIDADES DE UM SOFTWARE APLICADO AO GERENCIAMENTO DE

DESASTRES – UM MAPEAMENTO SISTEMÁTICO

FUNCTIONALITIES OF A DISASTER MANAGEMENT SOFTWARE - A

SYSTEMATIC MAPPING

Roberto Salviano da Silva*

Resumo

Desastres têm sido cada vez mais frequentes no mundo, atingindo populações residentes de
áreas urbanas e rurais e provocando danos de ordem material e imaterial. Com isso, conseguir
identificar requisitos no tempo certo para gerenciar tais desastres tem sido uma tarefa cada
vez mais difícil e complicada. Como não existe muita informação sobre características dos
requisitos aplicados à gestão de desastres, foi proposto um mapeamento sistemático da
literatura para encontrar maneiras de identificar os requisitos. Esse mapeamento visa
responder essas questões com base na literatura atual, onde percebeu-se que é preciso
verificar abordagens para facilitar a comunicação em todas as diferentes etapas do desastre e
como é importante que um sistema de apoio à gestão de desastres seja confiável e que as
informações disponibilizadas sejam precisas, em suma, os resultados não fornecem
características especiais, mas mostram o quão confiável e preciso ela tenha que ser.

Palavras-chave: gestão de desastres, requisitos e mapeamento sistemático.

Abstract

Disasters have been often happening in the world, thus affecting urban and agricultural
residents and causing material and immaterial damages. Therefore, identifying requirements
for managing such disasters has been an increasingly complicated task. As there is not much
information about characteristics of the requirements applied to disaster management, a
systematic literature mapping was proposed to find ways to identify these requirements. This
literature mapping aims to answer these questions based on current literature, where it has
been realized that approaches need to be verified to facilitate communication at all different
stages of the disaster and how important it is for a disaster management support system to be
reliable and to the information provided is accurate, in short, the results do not provide special
characteristics, but show how reliable and accurate it has to be.

Keywords: disaster management, requirement and systematic mapping.

Aprovado em: 19/12/2019 Versão Final em: 08/01/2020*

*Trabalho de conclusão de curso apresentado ao curso de Bacharelado em Sistemas de Informação da

Universidade Federal Fluminense como requisito parcial para conclusão do curso.
Graduando do Curso de Sistemas de Informação-UFF; <robertosalviano@id.uff.br>

1
1 INTRODUÇÃO

A intensidade de ocorrência de desastres naturais no mundo tem aumentado nas

últimas décadas e tende a continuar aumentando de forma considerável, como consequência
de fatores como o aumento populacional e a ocupação do solo, associados ao processo de
urbanização e industrialização. Nas áreas rurais, esses fatores se devem a desmatamentos,
queimadas, compactação dos solos e assoreamento dos rios. Nas áreas urbanas, se devem à
impermeabilização dos solos, adensamento das construções, conservação de calor e poluição
do ar (KOBIYAMA et al., 2006).
Segundo Natarajarathinam et al. (2009), os desastres são eventos súbitos e inesperados
ou lentos, caracterizados por atingir uma determinada região causando danos econômicos,
sociais e ambientais e podendo resultar em mortos e feridos. Por tratar-se de eventos não
facilmente administráveis por procedimentos rotineiros, verifica-se a necessidade de atuação
conjunta de entidades como, órgãos governamentais, setores privados, agências humanitárias
e comunidades, em ações preventivas de regiões vulneráveis a desastres. Os desastres podem
ser derivados de causas naturais (inundações, secas, terremotos, furacões e fome) ou podem
ser provocados pelo homem (como guerras, conflitos e crise de refugiados), impactando
comunidades e nações ao redor do mundo (EM-DAT, 2012).
Nos últimos anos, as organizações voltadas ao desenvolvimento de software têm
procurado por melhores práticas em engenharia de requisitos (YOUNG, 2004; WIEGERS,
2006; ROBERTSON; ROBERTSON, 2006; DAVEY; COPE, 2008; TAMAI; KAMATA,
2009; LIU et al., 2010). Essa busca por novas práticas ocorreu porque as organizações
perceberam que o êxito no projeto está cada vez mais relacionado a um melhor entendimento
dos requisitos (WIEGERS, 2006; ROBERTSON; ROBERTSON, 2006).
Neste sentido, a definição correta dos requisitos é um fator crucial para reduzir custos
e riscos no projeto de software (GOTTESDIENER, 2008), pois a falta de um bom trabalho na
atividade de elicitação de requisitos leva ao insucesso ou abandono de projetos (DAVEY;
COPE, 2008). Problemas na elicitação de requisitos estão relacionados a escopo,
compreensão e volatilidade (CHISTEL; KANG, 1992), esses problemas são decorrentes da
dificuldade em se extrair ou identificar as necessidades de seus usuários (HOOD et al., 2008).
Nesse contexto, o presente artigo apresenta um mapeamento sistemático de literatura
(MSL) sobre como identificar requisitos aplicados a gestão de desastre, buscando na base
IEEE Xplore, estudos que respondessem três questões de pesquisas: “Como identificar os
requisitos aplicados à gestão de desastres/emergências?”, “Quais são as características dos

2
requisitos aplicados à gestão de desastres?” e “Quais funcionalidades os softwares sobre
gestão de desastres precisam ter?”. Essas análises obtidas a partir do mapeamento podem ser
usadas como parâmetro para identificação de oportunidades de estudos e pesquisas,
contribuindo para trabalhos futuros.
Este trabalho está dividido da seguinte maneira: No capítulo 2, está a fundamentação
teórica sobre a gestão de desastres e a engenharia de requisitos. No capítulo 3, estão os
detalhes de como o mapeamento sistemático foi usado neste estudo. O capítulo 4, apresenta os
resultados e discussões provenientes do MSL e no capítulo 5, apresenta as conclusões do
trabalho e possíveis recomendações para estudos futuros.

2 REFERENCIAL TEÓRICO

Nesta seção falaremos sobre a gestão de desastres, seus conceitos e todo o seu
processo e a engenharia de requisitos, o que é a engenharia de requisitos e suas definições.

2.1 GESTÃO DE DESASTRES

Os desastres podem ser classificados em naturais ou causados pelo homem e podem

ser repentinos (como terremotos, tsunamis, ataques terroristas e vazamentos de óleo) ou
perenes (como fome, estiagem, pobreza ou crises políticas e de refugiados) (VAN
WASSENHOVE, 2006).
Segundo o Escritório das Nações Unidas para a Redução de Desastres (UNISDR) e o
Centro de Pesquisas de Epidemiologia em Desastres (CRED), o Brasil é o único país das
Américas que está na lista dos 10 países com maior número de pessoas afetadas entre os anos
de 1995 e 2015 (ONU, 2015). Nas últimas duas décadas, 51 milhões de brasileiros foram
impactados por catástrofes. Estados Unidos, China, Índia, Filipinas e Indonésia aparecem
como os cinco países com maior número de desastres relacionados ao clima durante esse
período (ONU, 2015).
Em uma escala global, cerca de três quartos da população do planeta vivem em áreas
afetadas por desastres (terremotos, ciclones tropicais, inundações, seca, dentre outros). Dessa
fração, 85% das pessoas expostas a desastres de origem natural vivem em países de médio a
baixo desenvolvimento. Por tratar-se de fenômenos complexos, muitas vezes imprevisíveis e
não antecipados, torna-se mais desafiador e complicado conseguir efetuar a redução de seus
danos (HUALOU, 2011). Assim, apesar de não podermos prevenir os seus impactos de forma

3
precisa, gerenciando seu processo poderemos minimizar o impacto negativo causado em meio
ao desastre (DIIRR, 2016).
O desastre afeta negativamente o desenvolvimento e consequentemente o crescimento
econômico, na medida em que causa perda de vidas humanas, danos às pessoas, destruição
total ou parcial a moradias, fontes de sustento, de subsistência, a infraestrutura produtiva e de
serviços, e meio ambiente, entre outros (LOPES, 2017).
Podemos considerar as seguintes fases (Figura 2.1.1) para gerenciamento de desastre:

Figura 2.1.1: Fases para gerenciamento de desastres (DIIRR, 2016)

 Pré-desastre: Inicia antes da ocorrência de um desastre. São desenvolvidas

ações a fim de contribuir para as reduções dos riscos. As equipes de
planejamento começam a criar ações de longo prazo, de forma a evitar a
ocorrência de grandes desastres, e a obtenção de equipamentos e recursos
financeiros necessários para o seu desenvolvimento. Essas equipes são
responsáveis por identificar e priorizar os riscos evidenciados. Como os
recursos disponibilizados para o desastre são limitados, surge daí a necessidade
de filtrar e priorizar os riscos identificados. (HADDOW et al., 2011; KHAN et
al., 2008; PENADÉS et al., 2011).
 Resposta: Esta fase compreende atividades de treinamento, que tem como
objetivo avaliar como os recursos, procedimentos e equipes planejados devem
responder às situações de desastre. São tomadas medidas para reduzir os
efeitos negativos a fim de não evoluir para uma fase crítica. Também
compreende uma fase de alerta com ações preventivas como, por exemplo,
cobertura de janela em furacões, ativações de sirenes em áreas de risco durante
tempestade, interdição de estradas em caso de chuva de tempestade, etc. E

4
 quando a emergência evolui para uma situação mais crítica, a resposta vem de
imediato. Há o envolvimento de organizações governamentais, organizações
não-governamentais, setor privado e sociedade. (HADDOW et al., 2011;
PADILHA et al., 2010).
 Pós-desastre: Inicia quando a equipe de resposta se propõe a recuperar o que
foi afetado, analisando as condições que possuía antes da ocorrência do
desastre e avaliar as ações tomadas durante a resposta, tomando ações para a
recuperação e o replanejamento. (HADDOW et al., 2011; KHAN et al., 2008;
PENADÉS et al., 2011). Não é possível afirmar o tempo necessário para a
recuperação de um desastre, vide que pode levar apenas semanas, ou perdurar
por diversos meses e até anos, como podemos observar no exemplo de
Mariana, o maior desastre natural do Brasil, que ocorreu em 2011 e, até hoje,
podemos verificar seus danos e seu processo de recuperação. Ao término do
desastre é efetuado o replanejamento onde a equipe tem o objetivo de
identificar as possibilidades de melhoria em emergências semelhantes futuras.

2.2 ENGENHARIA DE REQUISITOS

De acordo com Sommerville (2007), a engenharia de requisitos tem como objetivo

definir o que o sistema deve fazer, quais as necessidades reais do usuário e identificar quais
são limitações que existem para que o software seja desenvolvido. Ela engloba todas as
atividades relacionadas à descoberta, documentação e manutenção do conjunto de requisitos
de um sistema (KOTONIA e SOMMERVILLE, 1998).
A norma IEEE 24765(IEEE, 1990), define os requisitos como:
1) Uma condição ou capacidade necessária por um usuário para resolver um
problema ou atingir objetivos;
2) Uma condição ou capacidade que deve ser atingida ou possuída por um sistema
ou componente de um sistema para satisfazer um contrato, padrão,
especificação ou outro documento formalmente imposto;
3) Uma documentação que represente uma condição ou capacidade como em (1)
ou (2).
Os requisitos de software são classificados em funcionais, não funcionais e de
domínio. Os requisitos funcionais descrevem o que o software deve fazer, quais serviços
devem fornecer ao usuário e como deve reagir a entradas específicas (SOMMERVILLE,
2007). Qualquer ação ou verbo ativo são considerados requisitos funcionais, como por

5
exemplo, calcular, inspecionar, publicar, processar, imprimir, listar e etc. (ROBERTSON e
ROBERTSON, 2006)
Já os requisitos não funcionais não estão ligados diretamente às funcionalidades do
software e sim às restrições sobre os serviços e funções oferecidas por ele. Eles especificam o
comportamento do produto, são derivados de políticas e procedimentos da organização do
cliente e do desenvolvedor e também são derivados de fatores externos ao software e seu
processo de desenvolvimento (SOMMERVILLE, 2007). Ou seja, são descrições ou
atribuições de qualidade que o sistema deve possuir (ROBERTSON e ROBERTSON, 2006).
São exemplos requisitos ligados à segurança, desempenho, usabilidade, portabilidade e etc.
Os requisitos de domínio são derivados do domínio da aplicação e usam terminologia
específica. Podem ser novos requisitos funcionais, podem restringir os requisitos funcionais
existentes ou estabelecer como cálculos específicos devem ser realizados. Esses requisitos são
muito importantes por refletirem os fundamentos do domínio da aplicação (SOMMERVILLE,
2007). A diferença entre esse tipo de requisito e os requisitos funcionais e os não funcionais, é
que requisitos de domínio normalmente têm uma existência fora dos limites de qualquer
sistema de software (WIEGERS, 2006). Isso quer dizer que, uma regra de negócio não é
propriamente um requisito de domínio, ela existe independentemente de um sistema
computacional, e muitas vezes ela será aplicada para garantir que o sistema imponha esta
regra.

3 MATERIAS E MÉTODOS

Para poder responder as questões de pesquisas levantadas é necessário fazer um

levantamento bibliográfico. Pode-se fazer um levantamento de forma ad hoc, onde não se
segue nenhum processo prévio ou um processo formal e sistemático, onde temos todo um
processo a ser seguindo, como a definição de um protocolo, definição de questões de
pesquisa, etc.
O principal método de síntese é uma revisão sistemática da literatura (RSL). Em
contraste com uma revisão especializada usando seleção ad hoc da literatura, uma RSL é uma
revisão metodologicamente rigorosa dos resultados da pesquisa. O objetivo de uma RSL não é
apenas agregar todas as evidências existentes em uma questão de pesquisa mas também se
destinar a apoiar o desenvolvimento de diretrizes baseadas em evidências para os
profissionais (KITCHENHAM; CHARTERS, 2007; PETERSEN et al., 2015).

6
 O Mapeamento Sistemático da Literatura (MSL) e a Revisão Sistemática da Literatura
(RSL) são tipos de estudos secundários que seguem um processo de pesquisa
metodologicamente bem definido para identificar, analisar e interpretar as evidências
disponíveis relacionadas a um conjunto de questões de pesquisa, tópico ou fenômeno de
interesse, de uma maneira não tendenciosa e, até certo grau, repetível (KITCHENHAM;
CHARTERS, 2007; PETERSEN et al., 2015).
Optamos pelo mapeamento sistemático, que é um procedimento formal para revisão da
literatura, por prover uma visão mais ampla do tópico de pesquisa e por ajudar a identificar
lacunas na presente pesquisa e que são capazes de sugerir pesquisas futuras e prover um guia
para posicionar adequadamente novas atividades de pesquisa
Nesta seção falaremos sobre o processo usado para o Mapeamento Sistemático da
Literatura (MSL) proposta e apresentar a MSL executada para a presente pesquisa.

3.1 MAPEAMENTO SISTEMÁTICO DA LITERATURA (MSL)

Um Mapeamento Sistemático da Literatura (MSL) tem como objetivo identificar e

classificar, com uma visão mais ampla, dado tópico de pesquisa de modo a estabelecer se há
evidência de pesquisa nesse tópico (KITCHENHAM; CHARTERS, 2007; PETERSEN et al.,
2015). Já, uma Revisão Sistemática da Literatura (RSL) tem como objetivo identificar,
selecionar, avaliar, interpretar e sumarizar estudos disponíveis considerados relevantes para
um tópico de pesquisa ou fenômeno de interesse, fazendo uso de uma metodologia de revisão
que seja confiável, rigorosa e que permita auditagem (KITCHENHAM et al., 2004;
BIOLCHINI et al., 2005).
Uma das principais diferenças entre MSL e RSL está no escopo e nos procedimentos
de análise. O escopo de uma MSL é geralmente mais amplo e a análise e síntese mais
superficiais do que em uma RSL (WHOLIN et al., 2013). Com isso, a estratégia de busca
deve ser menos restritiva, de modo permitir recuperar mais estudos (KITCHENHAM et al.,
2011; PETERSEN et al., 2015). Assim, de maneira geral, MSLs envolvem mais trabalhos, a
serem analisados mais superficialmente, enquanto RSLs envolvem menos trabalhos, mas que
devem ser analisados com maior profundidade.
Vale a pena destacar que MSLs e RSLs são abordagens complementares. Primeiro, um
MSL pode ser conduzido, visando prover uma visão geral de um tópico de pesquisa. Ele pode
identificar grupos (clusters) de estudos que são adequados para estudos mais detalhados e
aprofundados, os quais podem ser feitos por meio de RSLs (KITCHENHAM et al., 2011;
PETERSEN et al., 2015).

7
 O processo de condução da RSL/MSL é realizado por meio de um processo composto
por uma sequência de fases bem definidas, envolvendo três etapas: o Planejamento, a
Execução e a Análise dos Resultados (BIOLCHINI et al. 2005), apresentando desta forma
uma avaliação justa e rigorosa sobre um determinado tópico de pesquisa, conforme figura
3.1.1.

Figura 3.1.1-Processo do Mapeamento Sistemático

Durante a etapa de Planejamento, os objetivos da pesquisa são definidos e é criado o

protocolo, que é o elemento essencial para sua execução e tem como objetivo reduzir a
possibilidade da ocorrência de vieses (KITCHENHAM et al., 2004). Esta fase contém itens
como a seleção de fontes, métodos de busca e palavras-chave, critérios de inclusão, exclusão,
qualidade dos estudos primários e como serão sintetizados (BIOLCHINI et al. 2005), de
forma que outros pesquisadores possam reproduzir a RSL/MSL usando tal protocolo.
A etapa de Execução tem como objetivo a obtenção e análise dos estudos primários, os
estudos são identificados, coletados e organizados em uma lista. Então os critérios de inclusão
e exclusão definidos no protocolo são aplicados nos estudos da lista em duas etapas,
inicialmente por meio da leitura do título, resumo e conclusões, seguido pela leitura do texto
completo. Ao final dessa atividade, as informações são extraídas dos estudos identificados
como incluídos (FELIZARDO et al., 2003; LIMA et al., 2012).
A última fase do processo, que é a etapa de Análise dos Resultados, os resultados dos
estudos primários que atendem ao propósito da revisão são sintetizados. Essa síntese pode ser
descritiva, mas um sumário quantitativo obtido por meio de um cálculo estatístico pode
complementar a descrição (SANTOS et al., 2018).

3.2 MSL SOBRE AS CARACTERÍSTICAS EM GESTÃO DE DESASTRES

O aumento do número de desastres que estão acontecendo nos últimos anos e as

dificuldades que se enfrenta para fazer o levantamento de requisitos de forma precisa e
assertiva, mostra a necessidade de investigar e entender as características dos requisitos

8
aplicados em gestão de desastres. Além disso, os requisitos precisam ser definidos de maneira
rápida e, como não há muito tempo para escrevê-los de maneira estruturada, existe a
necessidade de se realizar um estudo para entender essas características e como colaborar na
construção de um sistema que seja útil, confiável e que possa, de alguma forma, prevenir e
minimizar o impacto negativo causado em meio aos desastres.
Assim, o primeiro passo foi a definição do protocolo da revisão, bem como a
elaboração das questões de pesquisas relacionadas ao objetivo deste MSL. Levantamos três
questões de pesquisa:
 QP1: Como identificar os requisitos aplicados à gestão de
desastres/emergências?
 QP2: Quais são as características dos requisitos aplicados à gestão de
desastres?
 QP3: Quais funcionalidades os softwares sobre gestão de desastres precisam
ter?

A abordagem PICO (Population, Intervention, Comparison, Outcome) foi utilizada

para derivar os termos para a busca nas bases de dados (FELIZARDO et al, 2003). Além da
Medicina, esta abordagem também é muito utilizada pela Engenharia de Software. A
abordagem PICO é considerada adequada se a mesma pode ser estruturada em:
 População (P): grupo da população que será observada pela intervenção;
 Intervenção (I): Normalmente, na medicina, é uma comparação entre
tratamentos alternativos, pode indicar qual o fator prognóstico e o que se
pretende fazer parta o paciente. No caso da Engenharia de Software, seriam os
métodos, procedimentos ou tecnologias que serão estudados;
 Comparação (C): Procura mencionar as principais alternativas para comparar
com a intervenção. Em alguns casos, esse critério pode ser omitido, pois nem
sempre é necessário haver uma comparação específica.
 Resultados (O): Fatores considerados importantes para caracterizar o que está
sendo investigado.

Assim, para o presente MSL, como população foram utilizados: gestão de desastres
(disaster management) e gestão de emergências (emergency management). Como intervenção
foram utilizados: requisitos (requirement) e funcionalidades (functionalities). Comparação
não foi utilizado na busca, por não ser necessário neste cenário. E como resultados, foi

9
utilizado características (characteristics), elementos (elements), particularidades
(particularities), demanda (demands), exigência (exigency) e desafios (challenges).
Dessa forma, com o uso de conectores OR e AND, foi definida a string de busca para
ser usada nas pesquisas junto às bases de dados:

(("disaster management" OR "emergency management") AND (requirement OR

functionalities) AND (characteristics OR elements OR particularity OR demand OR
exigency OR challenges))

A base escolhida para realizar as buscas foi a IEEEXplore (http://ieeexplore.ieee.org),

por se tratar de um poderoso recurso para acesso de conteúdos científicos e de autores
relevantes para fim de estudos.
Os critérios utilizados para a inclusão dos estudos (CI) foram:
 CI1: Podem ser selecionadas publicações que tratem das características dos
requisitos em gestão de desastres/emergências;
 CI2: Podem ser selecionados publicações que tragam os desafios de requisitos
em gestão de desastres/emergências;
 CI3: Podem ser selecionados publicações que descrevam abordagens,
estratégias, práticas que possam auxiliar na obtenção de requisitos;
 CI4: Podem ser selecionados publicações que descrevam requisitos de um
sistema de desastres específico.

Os critérios para exclusão de estudos (CE) foram:

 CE1: Não serão selecionadas publicações em que as palavras-chave da busca
não apareçam no título, resumo e/ou texto da publicação (exclui-se daí o
campo “palavra-chave”, as seções agradecimentos, biografia dos autores,
referências bibliográficas e anexos) e não há variações destas palavras-chave
(exceto plural).
 CE2: Não serão selecionadas publicações em que o contexto não trate de
desastres;
 CE3: Não serão selecionadas publicações em que o contexto não trate de
requisitos de software;
 CE4: Não serão selecionados artigos similares (mesmo autor e temática
semelhante) a outros artigos encontrados.

10
 O processo de seleção dos estudos primários teve como passo inicial a busca na base
selecionada. Os resultados dessas buscas foram importados e trabalhados na StArt†,
ferramenta desenvolvida pelo Laboratório de Pesquisa em Engenharia de Software (LAPES)
da Universidade Federal de São Carlos (UFSCar), que visa apoiar o planejamento e execução
de MSLs/RSLs. Após as buscas, o próximo passo foi a primeira seleção dos estudos,
realizado através da leitura dos títulos, resumos e palavras-chave, conforme figura 3.2.1,
sendo sinalizados na ferramenta StArt* quais são os estudos não relevantes após cada fase.
Esses estudos foram lidos por todos os envolvidos no MSL e, quando conflitos foram
identificados (selecionado por uma pessoa e rejeitado por outra), relemos o abstract e, se o
conflito se mantivesse, foi necessário ler a introdução e conclusão do artigo para a tomada da
decisão. Os estudos que passaram pela primeira seleção foram submetidos a uma nova
seleção, onde foram lidos na íntegra, conforme figura 3.2.2. A Tabela 3.1 resume os
quantitativos de estudos resultantes após cada uma das fases:

Figura 3.2.2-Quantidade de artigos aceitos e

Figura 3.2.1-Quantidade de artigos aceitos e
rejeitados, após a leitura completa dos estudos
rejeitados, após a extração dos estudos

Tabela 3.1: Retorno das buscas e análises dos estudos.

DADOS DO RETORNO DAS BUSCAS E ANÁLISES DOS RESULTADOS
Retorno das Buscas 257 estudos
Após a remoção dos duplicados 255 estudos
Lidos títulos, resumos e palavras chaves 255 estudos
Estudos selecionados por meio da leitura dos títulos, 23 estudos
resumos e palavras-chave
Leitura completa dos estudos 23 estudos
Estudos aceitos após leitura completa 9 estudos
Estudos rejeitados após leitura completa 14

Os Apêndices A e B trazem a lista dos estudos aceitos após leitura completa e

rejeitados após leitura completa, respectivamente.

†
Disponível em: http://lapes.dc.ufscar.br/tools/start_tool

11
4 RESULTADOS E DISCUSSÕES

Nesta seção apresentaremos os resultados obtidos da análise de 23 artigos

selecionados. A pesquisa foi realizada em novembro de 2019, obtendo estudos compreendidos
entre 2002 e 2018, conforme gráfico 4.1.

Gráfico 4.1: Frequência de estudos por ano de publicação

Como não era previsto filtrar os estudos por ano de publicação, foram obtidos estudos
dentro de um período de aproximadamente 17 anos, o que, em termos de tecnologia, é um
tempo considerável para mudanças e aprendizados. Para as respostas às questões de pesquisa,
somente foram considerados 9 estudos, nos quais foi exposto pelos autores sobre o
conhecimento e as características sobre a gestão de desastre, os demais estudos foram
excluídos pelos critérios de exclusão, conforme gráfico 4.2.

Gráfico 4.2: Quantidade dos estudos incluídos e excluídos

12
4.1 RESPOSTAS ÀS QUESTÕES DE PESQUISA

QP1: Como identificar os requisitos aplicados à gestão de desastres/emergências?

Com base nos estudos, não conseguimos encontrar maneiras específicas de como
identificar os requisitos aplicados à gestão de desastres. Entretanto os estudos relatam que é
necessário verificar abordagens para facilitar o intercâmbio de informações e comunicações
em todas as diferentes etapas e operações e que é preciso verificar que tipos de informações e
parâmetros estão constantemente sendo monitorados, bem como a frequência que são
atualizados investigar a importância de fatores como confiabilidade, taxa de
confidencialidade, natureza atualizada e a extensão das informações disponíveis.

QP2: Quais são as características dos requisitos aplicados à gestão de desastres?

Com base nos estudos selecionados, não foi identificado nenhuma característica que
fosse específica para um sistema de gestão de desastres, pois geração de relatórios,
comunicação entre usuários, alertas, etc., são características aplicadas em qualquer tipo de
sistema, não sendo apenas sobre desastre.

QP3: Quais funcionalidades o software sobre gestão de desastres precisa ter?

RF1. Emitir Alerta – Permite emitir alertas para a população sobre perigos e
potenciais eventos indesejáveis através de servidores SMS ou meios de comunicação
(BENSSAM et al., 2014; LEPPÄNIEMI et al., 2009).
RF2. Analisar Riscos – Permite analisar violações de atualizações periódicas de
dados relacionados a diferentes riscos, como riscos de cartografia de cada localidade,
atividades de preparação sazonal (BENSSAM et al., 2014).
RF3. Verificar Riscos - Permite verificar violações de atualizações periódicas de
dados relacionados a diferentes riscos, como riscos de cartografia de cada localidade,
atividades de preparação sazonal (BENSSAM et al., 2014).
RF4. Realizar backup de dados – Permite realizar um backup contra a perda de
dados do processo de desastre (BENSSAM et al., 2014).
RF5. Coletar Informações sobre o desastre – Permite coletar informações entre
comunidades e organizações envolvidas no processo de desastre (BENSSAM et al., 2014).
RF6. Processar Informações sobre o desastre – Permite processar informações entre
comunidades e organizações envolvidas no processo de desastre (BENSSAM et al., 2014).

13
 RF7. Compartilhar informações sobre o desastre – Permite compartilhar
informações entre comunidades e organizações envolvidas no processo de desastre
(BENSSAM et al., 2014).
RF8. Realizar fusão de dados – Permite apoiar o processo na recuperação de
desastre, utilizando os dados antes da ocorrência, junto com os dados após a ocorrência do
desastre.
RF9. Consultar fusão de dados – Permite consultar as informações após a fusão dos
dados (SINGH, V. K.; 2011).

Os requisitos RF1, RF2 e RF3 correspondem as funcionalidades necessárias para a

fase de preparação. Para a fase de resposta são necessários os requisitos RF4, RF5, RF6 e
RF7. E para a fase de recuperação de desastres, o software precisa ter as funcionalidades
descritas nos requisitos RF8 e RF9.

4.2 DISCUSSÃO

Os estudos não foram claros e objetivos no sentido de responderem as questões

solicitadas. Não foram encontrados trabalhos que discutam de maneira clara quais são as
funcionalidades que o software aplicado a gestão de desastre precisa ter.
A comunicação entre os envolvidos foi a principal característica encontrada na maioria
dos estudos selecionados. Eles dissertam que para conseguir gerir um desastre, saber do
ocorrido, dos fatos verídicos, saber onde as pessoas que se encontram na situação do desastre
se encontram, conseguir se comunicar com as pessoas que estejam apoiando ao resgate,
enfim, todo o tipo de comunicação é primordial para poder conseguir gerir um desastre.
Muitos estudos também falaram sobre as características dos requisitos não funcionais
de um software aplicado a gestão de desastres. Um dos requisitos mais citados foram:
interoperabilidade, disponibilidade e escalabilidade. Segundo alguns estudos, esses três
requisitos não funcionais são primordiais para facilitar o planejamento estratégico,
operacional e tático do software.
Alguns estudos abordados sugeriam o uso de softwares próprios e como esses
softwares foram criados. Alguns deles dissertavam sobre a abordagem arquitetônica para
integrar sistemas do tipo SOA e muitos deles falavam sobre tecnologias que eles mesmos
criaram, apresentando conceitos, a estratégia de design e testes relacionados.

14
 Com isso se chegou à conclusão que identificar requisitos aplicados à desastre não é
uma tarefa fácil, muito pelo contrário, conseguir identificar quais são estes requisitos é uma
tarefa difícil e complexa.

5 CONCLUSÃO

O principal objetivo desse trabalho foi compreender, através de um Mapeamento

Sistemático da Literatura, as características dos requisitos aplicados à gestão de desastres e
maneiras de realizar a identificação destas características.
O mapeamento foi feito dentro dos parâmetros do protocolo (tratado no capítulo 3),
obtendo um total de nove estudos relevantes ao tema da pesquisa. A extração dos dados foi
feita visando responder às questões de pesquisas propostas, porém, nem todos os estudos
conseguiam respondê-las de maneira clara.
É possível perceber, com esse mapeamento, que ainda não foram abordadas maneiras
de se identificar requisitos aplicados à gestão de desastres de forma clara e assertiva, pois não
foi possível responder de forma clara duas das questões propostas mas foi possível perceber
que o quão é importante a disseminação de informações precisas em todo o processo de
gerenciamento de desastres e como o software precisa ser preciso e confiável em toda sua
informação. Com isso, se chega à conclusão de que ainda há muito que se explorar no
contexto de identificação e levantamento de requisitos aplicados a gestão de desastres, pois
como se trata de um meio complexo e como não há muito tempo para se fazer esse
levantamento, necessita-se cada vez mais de recursos para poder facilitar a identificação
destes requisitos.
Uma ameaça a validade é o uso de apenas uma base, por isso, como sugestão para
trabalho futuro, pesquisas em outras bases, realização de snowballing, que consiste na análise
das referências contidas em cada estudo selecionado, bem como na análise dos estudos que
citam os mesmos. Esse processo é usado, recursivamente, a fim de obter novos estudos que,
por algum motivo, possam não ter sido retornados pelas buscas (WHOLIN, 2014),
automatizar a identificação dos requisitos relacionados à comunicação e confidencialidade,
reuso de requisitos, dariam respostas mais precisas acerca da identificação e características
aplicadas a gestão de desastres.

15
 REFERÊNCIAS

BENSSAM, A.; NOUALI-TABOUDJEMAT, N.; NOUALI, O. Requirements for an IT

Based Platform for Disaster Management, 1st International Conference on Information and
Communication Technologies for Disaster Management (ICT-DM), 2014

BIOLCHINI, J.; MIAN, P.G.; NATALI, A.C.C.; TRAVASSOS, G.H. Systematic Review in
Software Engineering, Programa de Engenharia de Sistemas e Computação, Universidade
Federal do Rio de Janeiro, Rio de Janeiro, 2005

CHRISTEL, M. G., KANG, K. C. Issues in Requirements Elicitation, Technical Report

Software Engineering Institute CMU/SEI-92-TR-12.7, September 1992. Disponível
em:http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf. Acessado em 15 de
dez. de 2019.

DAVEY, B; COPE, C. Requirements Elicitation – What’s Missing?, Issues in Informing

Science and Information Technology, Issues in Informing Science and Information
Technology Volume 5, 2008

DIMITROV, V.; VAZQUEZ, J.; PADIR, T. LocATER: Localization and Accountability

Technologies for Emergency Responders, IEEE International Symposium on Technologies
for Homeland Security (HST), 2017

DIIRR, B. G. S. Support for Plan Adaptation in Unforeseen Complex Situations,

Programa de Pós Graduação em Informática – Universidade Federal do Rio de Janeiro, 2016

EM-DAT - Emergency Events Database. What’s new. Disponível em:<www.emdat.be/>.

Acesso em 16 de dez. de 2019.

FELIZARDO, K. R.; NAKAGAWA, E. Y.; FABBRI, S. C. P. F.; FERRARI, F. C. Revisão

Sistemática da Literatura em Engenharia De Software - Teoria e Prática, 1ª Edição. Rio
de Janeiro: Elsevier, 2003

GOTTESDIENER, E. Good Practices for Developing User Requirements, Crosstalk - The

Journal of Defense Software Engineering, March, 2008

HADDOW, G.; BULLOCK, J.; COPPOLA, D. Introduction to Emergency Management.

4. ed. Burlington: Butterworth Heinemann, 2011.

HOOD, C., WIEDEMANN, S., FICHTINGER, S., PAUTZ, U. Requirements Management:

The Interface Between Requirements Development and All Other Systems Engineering
Processes. Springer-Verlag Berlin Heidelberg, 2008. ISBN 978-3-540-47689-4

HUALOU, L. Disaster Prevention and Management: A Geographical Perspective, Our

editor from Institute of Geographic Sciences and Natural Resources Research, Chinese
Academy of Sciences, Beijing 100101, CHINA, 2011

16
HUANG, Y.; HE, W.; NAHRSTEDT, K.; LEE, W. C. Requirements and System
Architecture Design Consideration for First Responder Systems, IEEE Conference on
Technologies for Homeland Security, 2007

IEEE, IEEE standard Glossary of Software Engineering Terminology. IEE Standard,

New York, 1990

KHAN, H.; VASILESCU, L.; KHAN, A. Disaster Management Cycle: A Theoretical

Approach. Management and Marketing Journal, [S.l.], v. 6, n. 1, p. 43-50, 2008.

KITCHENHAM, B.A., BRERETON, O.P., BUDGEN, D., Using Mapping Studies as the
Basis for Further Research – A Participant-Observer Case Study. Information and
Software Technology, vol. 53, 2011.

KITCHENHAM, B.A., CHARTERS, S., Guidelines for Performing Systematic Literature

Reviews in Software Engineering, EBSE 2007-001. Keele University and Durham
University Joint Report, 2007.

KOBIYAMA, M. M., M. D. A. MORENO e PENA, I., Prevenção de desastres naturais:

conceitos básicos, Florianópolis: Ed. Organic Trading. 109p., 2006

KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and

Techniques, Editora John Wiley and Sons, 1998

LEPPÄNIEMI, J.; LINNA, P.; SOINI, J.; JAAKKOLA, H. Toward a Flexible Service-
Oriented Reference Architecture for Situational Awareness Systems in Distributed
Disaster Knowledge Management, PICMET '09 - 2009 Portland International Conference
on Management of Engineering Technology, 2009

LICHTENEGGER, G.; VORRABER, W.; GOJMERAC, I.; SPORER, A.; BRUGGER, J.;
EXNER, E.; ASCHBACHER, H.; CHRISTIAN, M.; VOESSNER, S. Identification of
Information Gaps in Civil-Military Cooperation in Disaster Management, 2nd
International Conference on Information and Communication Technologies for Disaster
Management (ICT-DM), 2015

LIMA, M. M.; LIMA, A. R.; MONTEIRO, A. C. C.; JUNIOR, E. H. C.; GOMES, L. Q. L.

Uma Revisão Sistemática da Literatura dos Processos de Desenvolvimento de Software
Educativo, 2012

LOPES, I. T. P., Gestâo de Riscos de Desastres: Integrando os Riscos de Acidentes

Industriais à Gestão Territorial, Dissertação (Mestrado) – UFRJ/ COPPE/ Programa de
Planejamento Energético, 2017

LYNHAM, T. J.; DULL, C. W.; SINGH, A. Requirements for Space-based Observations

in Fire Management: A report by the Wildland Fire Hazard Team, Committee on Earth
Observation Satellites (CEOS) Disaster Management Support Group (DMSG), IEEE
International Geoscience and Remote Sensing Symposium, 2002

LIU, L., LI, T., PENG, F. Why Requirements Engineering Fails: A Survey Report from
China, Requirements Engineering Conference (RE), 2010 18th IEEE International, 2010

17
NATARAJARATHINAM, M., CAPAR, I., NARAYANAN. A., Managing Supply Chains
in Times of Crisis: A Review of Literature and Insights, 2009. International Journal of
Physical Distribution and Logistics Management. p. 535–573. DOI:
10.1108/09600030910996251.

ONU: Brasil está entre os 10 países com maior número de afetados por desastres nos
últimos 20 anos. Nações Unidas Brasil, Brasil, 25 de jun. de 2015. Disponível em:
<https://nacoesunidas.org/onu-brasil-esta-entre-os-10-paises-com-maior-numero-de-afetados-
por-desastres-nos-ultimos-20-anos/>. Acesso em 14 de nov. de 2019.

PADILHA, R.; BORGES, M.; GOMES, J. O.; CANÓS, J. The Design of Collaboration
Support Between Command and Operation Teams During Emergency Response. In:
INTERNATIONAL CONFERENCE ON COMPUTER SUPPORTED COOPERATIVE
WORK IN DESIGN, 14., 2010, Shanghai. Proceedings... New York: IEEE, 2010. p. 759-763.

PENADÉS, M. C.; BORGES, M.; VIVACQUA, A.; CANÓS, J.; SOLIS, C. Collaborative
refinement of emergency plans through public engagement. In: INTERNATIONAL
CONFERENCE ON COLLABORATIVE COMPUTING: NETWORKING,
APPLICATIONS AND WORKSHARING, 7., 2011, Orlando. Proceedings... New York:
IEEE, 2011. p. 524-527.

PETERSEN, K.; VAKKALANKA, S.; KUZNIARZ, L. Guidelines for Conducting

Systematic Mapping Studies in Software Engineering: An Update, Elsevier Volume
64, August 2015, Pages 1-18, 2015

ROBERTSON, S. ROBERTSON, J. Mastering the Requirements Process, Second Edition.

Addision Wesley Professional, 2006

SANTOS, L. C.; LUGÃO, M. L. S. Levantamento sobre o Apoio das Ferramentas de

Colaboração em Equipes que Adotam Métodos Ágeis – Uma Revisão Sistemática da
Literatura – Monografia – Universidade Federal Fluminense, 2018

SIMONETTE, M. J.; Engenharia de Sistemas em Sistemas Sociotécnicos, Dissertação

(Mestrado) - Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia
de Computação e Sistemas Digitais, 2010

SINGH, V. K.; MODANWAL, N.; BASAK, S. MAS Coordination Strategies and their
Application in Disaster Management Domain, 2nd International Conference on Intelligent
Agent Multi-Agent Systems, 2011

SOMMERVILLE, I. Software Engineering, 8ª edição. São Paulo: Pearson Addison Wesley,

2007

SURI, N.; ZIELINSKI, Z.; TORTONESI, M.; FUCHS, C.; PRADHAN, M.; WRONA, K.;
FURTAK, J.; VASILACHE, D. B.; STREET, M.; PELLEGRINI, V.; BENINCASA, G.;
MORELLI, A.; STEFANELLI, C.; CASINI, E.; DYK, M. Exploiting Smart City IoT for
Disaster Recovery Operations, IEEE 4th World Forum on Internet of Things (WF-IoT),
2018

18
TAMAI, T., KAMATA, M. L. Impact of Requirements Quality on Project Success or
Failure, Design Requirements Engineering: A Ten-Year Persperctive, Lecture Notes in
Business Information Processing, 14, 258-275, 2009

VAN WASSENHOVE, L.V., Blackett Memorial Lecture Humanitarian aid logistics:

supply chain management in high gear, Journal of the Operational Research Society (2006)
57, 475–48, 2006

WIEGERS, K. E. More About Software Requirements: Thorny Issues and Practical

Advice, Microsoft Press, ISBN: 0735622671, 2006

WHOLIN, C. Guidelines for Snowballing in Sistematic Literature Studies and a

Replication in Software Engineering. 18th International Conference on Evaluation and
Assessment in Software Engineering (EASE 2014) – London, England, 2014.

WOHLIN, C., RUNESON, P., SILVEIRA NETO, P.A.M., ENGSTRÖM, E., MACHADO,
I.C., ALMEIDA, E.A., On the Reliability of Mapping Studies in Software Engineering,
Journal of Systems and Software, 2013

YOUNG, R. R. The Requirements Engineering Handbook. Artech House, 2004

19
 APÊNDICE A – Estudos Selecionados Incluídos

ESI01 - BENSSAM, A.; NOUALI-TABOUDJEMAT, N.; NOUALI, O. Requirements for

an IT Based Platform for Disaster Management, 1st International Conference on
Information and Communication Technologies for Disaster Management (ICT-DM), 2014

ESI02 - DIMITROV, V.; VAZQUEZ, J.; PADIR, T. LocATER: Localization and

Accountability Technologies for Emergency Responders, IEEE International Symposium
on Technologies for Homeland Security (HST), 2017

ESI03 - HUANG, Y.; HE, W.; NAHRSTEDT, K.; LEE, W. C. Requirements and System
Architecture Design Consideration for First Responder Systems, IEEE Conference on
Technologies for Homeland Security, 2007

ESI04 - LEPPÄNIEMI, J.; LINNA, P.; SOINI, J.; JAAKKOLA, H. Toward a Flexible
Service-Oriented Reference Architecture for Situational Awareness Systems in
Distributed Disaster Knowledge Management, PICMET '09 - 2009 Portland International
Conference on Management of Engineering Technology, 2009

ESI05 - LICHTENEGGER, G.; VORRABER, W.; GOJMERAC, I.; SPORER, A.;

BRUGGER, J.; EXNER, E.; ASCHBACHER, H.; CHRISTIAN, M.; VOESSNER, S.
Identification of Information Gaps in Civil-Military Cooperation in Disaster
Management, 2nd International Conference on Information and Communication
Technologies for Disaster Management (ICT-DM), 2015

ESI06 - LYNHAM, T. J.; DULL, C. W.; SINGH, A. Requirements for Space-based

Observations in Fire Management: A Report by the Wildland Fire Hazard Team,
Committee on Earth Observation Satellites (CEOS) Disaster Management Support
Group (DMSG), IEEE International Geoscience and Remote Sensing Symposium, 2002

ESI07 - SINGH, V. K.; MODANWAL, N.; BASAK, S. MAS Coordination Strategies and
their Application in Disaster Management Domain, 2nd International Conference on
Intelligent Agent Multi-Agent Systems, 2011

ESI08 - SURI, N.; ZIELINSKI, Z.; TORTONESI, M.; FUCHS, C.; PRADHAN, M.;
WRONA, K.; FURTAK, J.; VASILACHE, D. B.; STREET, M.; PELLEGRINI, V.;
BENINCASA, G.; MORELLI, A.; STEFANELLI, C.; CASINI, E.; DYK, M. Exploiting
Smart City IoT for Disaster Recovery Operations, IEEE 4th World Forum on Internet of
Things (WF-IoT), 2018

ESI09 - WANG, F.; WEN, R.; ZHONG, S. Key Issues in Mapping Technologies for
Disaster Management, 2nd International Conference on Information Engineering and
Computer Science, 2010

20
 APÊNDICE B – Estudos Selecionados Excluídos

ESE01 - BALOGH, Z.; GATIAL, E.; HLUCHY, L. Use of Polls to Seamlessly Collect and
Aggregate Semi-Structured Information For Crisis Response, IEEE 13th International
Symposium on Intelligent Systems and Informatics (SISY), 2015

ESE02 - BASAK, S.; MAZUMDAR, D. On Agent Mediated Coordination Strategies and

its Application in Disaster Management System, 1st International Conference on Recent
Advances in Information Technology (RAIT), 2012

ESE03 - CHAVES, J. M.; DONNER, A.; TANG, C.; ADLER, C.; KRUSMANN, M.; VIA
ESTREAM, À.; GREINER-MAI, T. An Interdisciplinary Approach to Designing a Mass
Casualty Incident Management System, The 14th International Symposium on Wireless
Personal Multimedia Communications (WPMC), 2011

ESE04 - CHENG, Z.; WANG, J.; YEN, N.; WU, Y. Allocation of Resources after Disaster
Based on Big Data from SNS and Spatial Scan, International Conference on Advanced
Cloud and Big Data (CBD), 2016

ESE05 - DOMDOUZIS, K.; ANDREWS, S.; GIBSON, H.; AKHGAR, B.; HIRSCH, L.
Service-Oriented Design of a Command and Control Intelligence Dashboard for Crisis
Management, IEEE/ACM 7th International Conference on Utility and Cloud Computing,
2014

EES06 - DOMINICI, F.; MARUCCO, G.; MULASSANO, P.; DEFINA, A.; CHARQANE,
K. Navigation in Case of Emergency (NICE): An Integrated NAV/COM Technology for
Emergency Management, 5th IEEE Consumer Communications and Networking
Conference, 2008

ESE07 - GOJMERAC, I.; RUGGENTHALER, C.; EGLY, M.; VORRABER, W.;

BRUGGER, J.; ASCHBACHER, H.; PANZENBOCK, K.; CHRISTIAN, M. Advanced
Information Systems for Enhanced Civil-Military Interoperability in Austria, 3rd
International Conference on Information and Communication Technologies for Disaster
Management (ICT-DM), 2016

ESE08 - MEISSEN, U.; VOISARD, A. Towards a Reference Architecture for Early

Warning Systems, International Conference on Intelligent Networking and Collaborative
Systems, 2010

ESE09 - MENDES, C. C. S.; DE ALMEIDA, L. B.; MORO, C.; QUISEN, R. Parana Fire
Department System - Mobile Application for Agile Communication with the Seaside
Vacationers, XLIV Latin American Computer Conference (CLEI), 2018

ESE10 ROSSI, C.; STEMBERGER, W.; BIELSKI, C.; ZEUG, G.; COSTA, N.; POLETTO,
D.; SPALTRO, E.; DOMINICI, F. Coupling Crowdsourcing, Earth Observations, and E-
GNSS in a Novel Flood Emergency Service in the Cloud, IEEE International Geoscience
and Remote Sensing Symposium (IGARSS), 2015

21
ESE11 - SOJEVA, B.; XIE, J. Spatial-Aware Iterative Integration of Crisis Management
Information Systems, 3rd International Conference on Information and Communication
Technologies for Disaster Management (ICT-DM), 2016

ESE12 - TAN, X.; REN, Y. Study on the Emergency Rescue VRP Based on Ant Colony
Optimization and Generalized Distance, Fourth Global Congress on Intelligent Systems,
2013

ESE13 - YANG, Y.; PRASANNA, R.; YANG, L.; MAY, A. Opportunities for WSN for
Facilitating Fire Emergency Response, Fifth International Conference on Information and
Automation for Sustainability, 2010

ESE14 - ZHAO, Q.; ZHENG, X.; LI, W.; WANG, C.; ZHANG, X. Framework Design of
Natural Disasters and Emergency Management System Oriented to Region, Fifth
International Conference on Geo-Information Technologies for Natural Disaster Management,
2013

22
 APÊNDICE C – Lista de Ilustrações

Figura 2.1.1 Fases para gerenciamento de desastres – DIIRR (2016) ........................... 04

Figura 3.1.1 Processo do Mapeamento Sistemático ....................................................... 08

Figura 3.2.1 Quantidade de artigos aceitos após extração dos estudos .......................... 11

Figura 3.2.2 Quantidade de artigos aceitos após a leitura completa dos estudos ........... 11

Gráfico 4.1 Estudos selecionados por ano de publicação ............................................. 12

Gráfico 4.2 Quantidade dos estudos incluídos e excluídos .......................................... 12

23
 APÊNDICE D – Lista de Tabelas

Tabela 3.1 Retorno das buscas e análises dos estudos ................................................. 11

24