MapDengue. Especificação de Requisitos UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA. Graduação em Ciência e Engenharia da Computação

(1)

Graduação em Ciência e Engenharia da Computação

MapDengue

Especificação de Requisitos

Professor: Jaelson Freire Brelaz de Castro Equipe: Andresson da Silva Firmino Arthur Felipe de Andrade Ferraz Humberto de Sousa Pachêco Rudiney Lacerda Barbosa {asf2, afaf, hsp, rlb} @cin.ufpe.br

(2)

asf2, afaf, hsp, rlb Página 2 24/11/2009

HISTÓRICO DE REVISÕES

Revisão Data Descrição Autor

01 07/11 Início do Documento de Requisitos. asf2. 02 10/11 Descrição das técnicas de coleta de dados; _{início das descrições dos requisitos funcionais.} asf2 e rlb.

03 11/11 Início das descrições dos requisitos não _funcionais. hsp.

04 12/11 Descrição dos casos de uso. asf2.

06 13/11 Início _{organizacionais e modelagem organizacional.}das descrições dos requisitos afaf.

07 14/11 Término da descrição dos requisitos não _funcionais. hsp.

08 16/11 Término _funcionais.da descrição dos requisitos asf2 e rlb.

09 16/11 Modelagem do diagrama do NFR. hsp.

10 18/11 Início da modelagem organizacional. afaf. 11 19/11 Continuação descrição casos de uso. asf2. 12 23/11 Finalização modelagem do diagrama do NFR. hsp. 13 24/08 Finalização modelagem organizacional. afaf.

14 25/08 Término Descrição dos Casos de uso. asf2, afaf, rlb.

(3)

Índice

1. INTRODUÇÃO ... 7 1.1 MOTIVAÇÃO ... 7 1.2 OPROBLEMA IDENTIFICADO ... 7 1.3 SOBRE A ORGANIZAÇÃO ... 7

1.4 CONVENÇÕES PARA IDENTIFICAÇÃO DOS REQUISITOS ... 8

1.5 CONVENÇÕES PARA IDENTIFICAÇÃO DOS CASOS DE USO... 8

1.5.1 Estrutura dos casos de uso ... 8

1.5.2 Prioridades dos casos de uso ... 8

2. REQUISITOS ORGANIZACIONAIS ... 9 3. REQUISITOS FUNCIONAIS ... 9 3.1 AUTENTICAÇÃO ... 9 3.1.1 [RF01] Efetuar login ... 9 3.1.2 [RF02] Efetuar logoff ... 9 3.1.3 [RF03] Mudar Senha ... 9

3.2 CADASTRO DE USUÁRIO –MEMBROS DO GCD ... 10

3.2.1 [RF04] Inserir Usuário ... 10 3.2.2 [RF05] Remover Usuário ... 10 3.2.3 [RF06] Atualizar Usuário ... 10 3.2.4 [RF07] Listar Usuários ... 10 3.3 AVISOS ... 11 3.3.1 [RF08] Escrever Aviso ... 11 3.3.2 [RF09] Remover Aviso ... 11

3.3.3 [RF10] Listar Avisos Enviados ... 11

3.3.4 [RF11] Listar Avisos Recebidos ... 12

3.4 FOCOS DE DENGUE ... 12

3.4.1 [RF12] Cadastro de Denúncias Foco ... 12

3.4.2 [RF13] Remover Denúncia de Foco ... 12

3.4.3 [RF14] Alterar Denúncia de Foco... 13

3.4.4 [RF15] Listar Denúncias de Foco ... 13

3.5 PLANO DE AÇÃO ... 13

3.5.1 [RF16] Inserir Plano de Ação ... 13

3.5.2 [RF17] Edição de Plano de Ação ... 14

3.5.3 [RF18] Retorno de Laboratório ... 14

3.6 GEORREFERENCIAMENTO E GEOCODIFICAÇÃO ... 14

3.6.1 [RF19] Obter Coordenadas Geográficas ... 14

3.6.2 [RF20] Aproximação de Coordenadas ... 14

3.7 RELATÓRIOS DOS DADOS ... 15

3.7.1 [RF21] Gerar Relatório ... 15

3.7.2 [RF22] Gerar Relatório com Mapa ... 15

4. REQUISITOS NÃO-FUNCIONAIS... 15

4.1 REQUISITOS DE PROCESSO ... 15

4.1.1 [NFR01] Utilizar Linguagem Java para Web (J2EE)... 15

4.1.2 [NFR02] Utilizar Hibernate ... 16

4.1.3 [NFR03] Utilizar Banco de Dados PostgreSQL ... 16

4.2 REQUISITOS DE PRODUTO ... 16

4.2.1 Usabilidade ... 16

4.2.1.1 - [NFR04] Mensagens de Erro ... 16

(4)

asf2, afaf, hsp, rlb Página 4 24/11/2009 4.2.1.3 - [NFR05] Manual do Usuário ... 17 4.2.2 Segurança ... 18 4.2.2.1 - [NFR06] Controle de Acesso ... 18 4.2.2.2 - [NFR07] Integridade ... 18 4.2.2.3 - [NFR08] Confidencialidade ... 18 4.2.2.4 - [NFR09] Auditoria ... 18 4.2.3 Desempenho ... 19 4.2.3.1 - [NFR10] Tempo de Resposta ... 19 4.3 REQUISITOS EXTERNOS ... 19 4.3.1 [NFR12] Orçamento ... 19 4.3.2 [NFR13] Tempo de desenvolvimento ... 19 5. MODELAGEM ORGANIZACIONAL ... 19

5.1 MODELAGEM DE DEPENDÊNCIA ESTRATÉGICA ... 20

5.2 MODELO ESTRATÉGICO DA RAZÃO ... 21

5.3 COMENTÁRIO SOBRE OS DIAGRAMAS ... 22

6. MODELAGEM DE REQUISITOS FUNCIONAIS (CASOS DE USO) ... 22

7. MODELAGEM DE REQUISITOS NÃO-FUNCIONAIS (NFR FRAMEWORK) ... 24

8. CONCLUSÃO ... 26

REFERÊNCIAS ... 27

RELATÓRIO DA EQUIPE ... 27

ANEXO A – TÉCNICAS UTILIZADAS NA COLETAS DE DADOS ... 28

REUSO DE REQUISITO ... 28

LEITURA ... 28

REUNIÕES ... 28

ANEXO E – DESCRIÇÃO DOS ATORES ... 28

ANEXO F – DESCRIÇÃO DOS CASOS DE USO ... 29

AUTENTICAÇÃO ... 29

[UC01] Efetuar logon ... 29

[UC02] Efetuar logoff ... 30

[UC03] Mudar Senha ... 30

CADASTRO DE USUÁRIO –MEMBROS DA GCD ... 31

[UC04] Inserir Usuário ... 31

[UC05] Remover Usuário ... 33

[UC06] Atualizar Usuário ... 34

[UC07] Listar Usuários ... 35

AVISOS ... 36

[UC08] Escrever Aviso ... 36

[UC09] Remover Aviso ... 37

[UC10] Listar Avisos Enviados ... 37

[UC11] Listar Avisos Recebidos ... 38

FOCOS DE DENGUE ... 39

[UC12] Inserir Denúncia de Foco de Dengue ... 39

[UC13] Remover Denúncia de Foco ... 40

[UC14] Alterar Denúncia de Foco. ... 40

(5)

[UC16] Inserir Plano de Ação ... 42

[UC18] Retorno de Laboratório ... 43

[UC19] Obter Coordenadas Geográficas ... 44

[UC20] Aproximação de Coordenada ... 44

[UC21] Gerar relatório. ... 45

(6)

Índice de Figuras

Figura 1 Modelagem de Dependência Estratégica. ... 20

Figura 2 Modelo estratégico da razão com ator MapDengue expandido. ... 22

Figura 3 Modelagem de Requisitos Funcionais (Casos de Uso) ... 23

Figura 4 Modelagem de Requisitos Não Funcionais... 25

Índice de Tabelas

Tabela 1 Porcentagem de esforço dos membros da equipe. ... 27

(7)

1. Introdução

O objetivo desde documento é descrever o problema que foi identificado e especificar os requisitos para a solução encontrada durante a fase de estudo de viabilidade realizada previamente. Essa solução tem como centro um sistema de informação que deve ser construído a partir das informações capturadas pela utilização de algumas técnicas descritas adiante.

O nosso objeto de estudo é o grupo de combate a dengue da Secretaria Estadual de Saúde de Pernambuco (SESP). Este é formado por secretarias municipais (SMs), gerências regionais de saúde (GERES) e agentes de saúde. Este grupo tem como finalidade elaborar planos de ação, que são estratégias para o combate a focos de dengue. Os planos de ação são construídos através de estudos sobre informações coletadas, como regiões de maiores incidências, tipos de depósitos da larva do mosquito, quantidade de denúncia, número de casos da doença, fatores temporais (verão, inverno) e mais diversos outros fatores. Tendo em vista o grande número de tarefas e dados a serem manipulados e analisados pelo grupo de saúde, o projeto vem com o objetivo de ajudar o mesmo no gerenciamento das informações.

1.1 Motivação

Este projeto surge da necessidade de haver uma comunicação eficiente entre os membros do grupo de combate a dengue (GCD) da (SESP), através do processo de coleta e armazenamento de dados e informações. Ele fornecera um melhor processamento e estudo dos dados possibilitando o gerenciamento para tomada de decisões que serão acatadas pelos membros dos grupos na execução dos planos de ação.

1.2 O Problema Identificado

O processo de coleta de informações muitas vezes é lento por causa da pouca interatividade no repasse dos dados coletados entre os membros da (GCD), isso se deve a falta de material eletrônico para repasse dos dados da coleta que na maioria, é feita através de folhas de papel. E além do mais, esse volume imenso de documentos leva muito tempo para chegar à mão da secretaria estadual, devido ao tempo para se elaborar esses documentos e conjunto de protocolos no repasse de cada membro com sua respectiva coleta. O que acaba acarretando tardia na elaboração do plano de ação.

Outro problema é as dificuldades para fornecer e analisar as informações. Muitas informações fornecidas não são precisas e confiáveis sobre os focos de dengue, devido à falta de ferramenta para auxiliar esta tarefa. E ainda mesmo, após a coleta das informações os métodos de análise dos dados, presentes, apresentam-se pouco eficiente em vista a quantidade de aspectos que devem ser analisados e o volume de dados fornecidos para o estudo das informações. Isto dificulta e prejudica a elaboração de planos de ação eficientes.

1.3 Sobre a Organização

O público-alvo do sistema é constituído pelos membros (GERES e SMs) da (GCD) e os membros da população interessados em fornece informações sobre focos de dengue.

(8)

asf2, afaf, hsp, rlb Página 8 24/11/2009 O estudo de caso está embasado nas informações fornecidas pelos gerentes de projeto e professores do Centro de Informática (CIn): Valeria Times (vct@cin.ufpe.br) e Patrícia Tedesco (pcart@cin.ufpe.br). Tais professores foram alocados para o cargo de gerência, através da requisição do sistema MAPDENGUE, pelo secretário executivo da SESP em parceria com o CIn.

1.4 Convenções para Identificação dos Requisitos

Por convenção, os requisitos são indicados e referenciados por um indicador no formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os nomes dos casos de uso relacionados.

1.5 Convenções para Identificação dos Casos de Uso

Por convenção, os casos de uso são indicados e referenciados por um indicador no formato [UCxx], onde xx se refere ao número do caso de uso.

1.5.1 Estrutura dos casos de uso

Cada caso de uso terá o seguinte formato:

 Atores: Os modelos de usuário que utilizarão o caso de uso;

 Prioridade: Prioridade de implementação deste caso de uso;

 Entradas: Variáveis que serão passadas ao sistema;

 Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser

executado;

 Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso

seja concluído, podendo incluir fluxos de eventos secundários e/ou alternativos;

 Saídas: Saídas que devem ser fornecidas pelo sistema quando o caso de uso for

executado;

 Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser

finalizado.

1.5.2 Prioridades dos casos de uso

Os casos de uso são classificados como:

 Essencial: É o caso de uso indispensável ao funcionamento do sistema. Esse tipo

de caso de uso deve ser implementado impreterivelmente, caso contrário, o projeto perderá sua utilidade.

 Importante: Sem este caso de uso, o sistema ainda é capaz de ser utilizado.

Contudo, essa utilização se dá de forma não satisfatória pelo cliente.

 Desejável: Esse tipo de caso de uso poderá ser implementado em versões

posteriores do sistema, visto que, mesmo sem a sua implementação, o sistema atende as suas funcionalidades básicas.

(9)

2. Requisitos Organizacionais

Os requisitos organizacionais devem satisfazer os objetivos da organização e definir porque o sistema é necessário. Esses requisitos são:

 Facilitar comunicação membros da GCD – tornar a comunicação entre as partes mais ágil e tranqüila;

 Fornecer estudos eficientes de análise dos dados e informações; e prover suporte a decisão na construção de planos de ação de combate a foco de dengue.

 Melhorar a precisão e a confiança dos dados coletados – controle no cadastramento das denúncias, e melhorias na especificação da coordenadas geográficas do local do foco.

3. Requisitos Funcionais

Neste capítulo são definidas as funções que o sistema deve realizar. Os requisitos estão agrupados de acordo com suas características.

3.1 Autenticação

3.1.1 [RF01] Efetuar login

Identificação: [RF01] Efetuar login

Casos de Uso relacionados: _{[UC 01]}

Descrição:

Permite que um usuário tenha acesso a informações pertencentes ao Mapdengue. Para isso, o usuário deve informar login e senha. Não deve haver outra maneira de entrar no sistema diferente desta.

Prioridade:  Essencial  Importante  Desejável

3.1.2 [RF02] Efetuar logoff

Identificação: [RF02] Efetuar logoff

Descrição: Permite que o usuário saia do sistema.

3.1.3 [RF03] Mudar Senha

Identificação: [RF03] Mudar Senha

(10)

Prioridade:  Essencial  Importante  Desejável

3.2 Cadastro de Usuário – Membros do GCD

3.2.1 [RF04] Inserir Usuário

Identificação: [RF04] Inserir Usuário

Descrição:

Inserção de um novo usuário no banco de dados do sistema. Um usuário tem os dados: nome, CPF, email, login, senha, data de criação, criador do usuário, município do usuário, GERES do usuário, tipo do usuário (“Administrador Executivo”, “Administrador Local”, “Atendentes”) e o tipo membro (“Secretaria Municipal”, “GERES”).

Prioridade:  Essencial  Importante  Desejável 3.2.2 [RF05] Remover Usuário

Identificação: [RF05] Remover Usuário

Descrição:

Remoção um usuário no banco de dados do sistema. Ao realizar essa operação o sistema deve também remover todos os avisos desse usuário.

Um pedido de confirmação deve ser requerido ao administrador, juntamente com uma mensagem informando que o usuário e os avisos associados serão excluídos.

3.2.3 [RF06] Atualizar Usuário

Identificação: [RF06] Atualizar Usuário

Descrição: Permitir a atualização dos dados de um usuário.

3.2.4 [RF07] Listar Usuários

Identificação: [RF07] Listar Usuário

(11)

Descrição: Lista os usuários e possibilitar ordenação por nome, login,

tipo, município e GERES.

3.3 Avisos

3.3.1 [RF08] Escrever Aviso

Identificação: [RF08] Escrever Aviso

Descrição:

O usuário do sistema pode escrever notificações (avisos) para grupos de usuários, que será inserido no banco de dados do sistema. Um grupo de usuário é constituído pelo conjunto de usuários de mesmo tipo usuário e/ou tipo membro (GERES,SMs) e/ou do mesmo município.

O aviso tem os dados: usuário remetente, título, conteúdo, data de postagem e os destinatários (grupos de usuário).

3.3.2 [RF09] Remover Aviso

Identificação: [RF09] Remover Aviso

Descrição:

O usuário do sistema pode remover avisos no banco de dados do sistema, deste que o mesmo seja o remetente do aviso. Um pedido de confirmação deve ser requerido ao usuário, juntamente com uma mensagem informando que o aviso será excluído.

3.3.3 [RF10] Listar Avisos Enviados

Identificação: [RF10] Listar Avisos Enviados

Casos de Uso relacionados: _{[UC 10]} Descrição:

O usuário listará os avisos, no qual, este mesmo usuário é o remetente do aviso. Possibilitar ordenação por título, conteúdo, data de postagem.

(12)

asf2, afaf, hsp, rlb Página 12 24/11/2009 3.3.4 [RF11] Listar Avisos Recebidos

Identificação: [RF11] Listar Avisos Recebidos.

Descrição:

O usuário listará os avisos postados nos últimos 30 dias, no qual, este mesmo usuário faz parte do grupo de usuário contido como destinatários do aviso. Possibilitar ordenação por título, conteúdo, data de postagem, remetente.

3.4 Focos de Dengue

3.4.1 [RF12] Cadastro de Denúncias Foco

Identificação: [RF12] Cadastro de Denúncia Foco

Descrição:

Permitir a inserção de denúncias de possíveis focos de dengue no banco de dados do sistema. Os dados da denúncia são: código da denúncia, localização do foco (município, bairro, rua, cep, complemento, ponto de referência, coordenadas geográficas, coordenadas aproximadas ou não); o ambiente físico do foco que são: o tipo do local (Residência, Terreno Abandonado, Comércio, Indústria, Casa de Veraneio, Residência Abandonada ou Fechada, Cemitérios, Parque, Borracharia, Depósito de Material de Construção, Lixão, Edifício em Construção) e o tipo de depósito (Cacimbas, Poços e Cisterna; Depósitos Variados; Vasilhame para Água de Animais Domésticos; Bandeja Externa de Geladeiras; Lagos, Cascatas e Espelho D Água Decorativos; Cacos de Vidros nos Muros; Canteiro de Obras; Piscina ou tanque; Caixa d água e toneis; Ferro Velho; Laje com água e calhas; Cisterna à céu aberto; Pneus; Recipientes Naturais; Lixo Acumulado; Vasos de Flores; Carcaças de Automóveis; Entupimento em Ralos de Cozinha, Banheiro, Sauna e Ducha; Bromélias e Outras Plantas Parecidas; Urnas de Cemitério; Não Sabe Informar / Não Visualizado); dados do denunciante (Nome, Telefone, Celular, Email e Observações sobre a denúncia) .

3.4.2 [RF13] Remover Denúncia de Foco

(13)

Descrição:

Remoção de uma denúncia de foco no banco de dados do sistema. Ao realizar essa operação o sistema deve também remover o plano de ação associado a essa denúncia.

Um pedido de confirmação deve ser requerido ao usuário, juntamente com uma mensagem informando que a denúncia e o plano de ação associado serão excluídos.

3.4.3 [RF14] Alterar Denúncia de Foco

Identificação: [RF14] Alterar Denúncia de Foco

Descrição: Permitir a atualização dos dados de uma denúncia de foco.

Prioridade:  Essencial  Importante  Desejável 3.4.4 [RF15] Listar Denúncias de Foco

Identificação: [RF15] Listar Denúncias de Foco

Descrição: Lista as denúncias de foco e possibilitar ordenação por código,

município, bairro, rua, CEP e tipo do local.

3.5 Plano de Ação

3.5.1 [RF16] Inserir Plano de Ação

Identificação: [RF16] Inserir Plano de Ação

Descrição:

Permitir a inserção de planos de ação no banco de dados do sistema. Os dados da denúncia são: o código da denúncia associada; data do plano de ação; usuário que cadastrou o plano; ultimo usuário que atualizou o plano; foco positivo ou não; e uso ou não das seguintes atividades: “Eliminação de criadouros”, “Remoção de entulhos”, “Aplicação de larvicidas”, “Educação em saúde” (orientação sobre a doença e medidas preventivas), “Distribuição de material educativo”, “Inspeção de imóveis vizinhos”, “Identificação de caso suspeito na área” e

(14)

asf2, afaf, hsp, rlb Página 14 24/11/2009 “Bloqueio de transmissão viral com UBV leve”.

3.5.2 [RF17] Edição de Plano de Ação

Identificação: [RF17] Edição de Plano de Ação

Descrição: Permitir a atualização dos dados de um plano de ação.

3.5.3 [RF18] Retorno de Laboratório

Identificação: [RF18] Retorno de Laboratório

Permitir a atualização do plano de ação indicando se no local da denuncia de foco foi encontrado depósito com presença de larvas ou pupas de mosquitos.

3.6 Georreferenciamento e Geocodificação

3.6.1 [RF19] Obter Coordenadas Geográficas

Identificação: [RF19] Obter Coordenadas Geográficas

Descrição: Fornece coordenadas geográficas precisas, de um determinado

local através de endereço e visualização em mapa

Prioridade:  Essencial  Importante  Desejável 3.6.2 [RF20] Aproximação de Coordenadas

Identificação: [RF20] Aproximação de Coordenadas

Fornece coordenadas geográficas, aproximadas, a partir de endereços próximo ao fornecido, aproximação é feita com base em coordenadas precisas já cadastradas no sistema .

(15)

3.7 Relatórios dos Dados

3.7.1 [RF21] Gerar Relatório

Identificação: [RF21]

Permite a visualização e impressão de relatórios sobre os dados e informações de denúncias de foco e planos de ação cadastrados no banco de dados do sistema.

3.7.2 [RF22] Gerar Relatório com Mapa

Identificação: [RF22] Gerar Relatório com Mapa

Descrição:

Permite a visualização e impressão de relatórios sobre os dados e informações de denúncias de foco e planos de ação cadastrados no banco de dados do sistema. Este relatório deve ser acompanhado de imagens espaciais sobre os locais de denúncias de foco analisadas.

Prioridade:  Essencial  Importante  Desejável

4. Requisitos Não-Funcionais

Este capítulo descreve requisitos relacionados com restrições e aspectos de qualidade. A classificação desses requisitos segue o autor [Sommerville], que agrupa os mesmos em três grupos, a saber: requisitos de processo, requisitos de produto e requisitos externos.

4.1 Requisitos de Processo

4.1.1 [NFR01] Utilizar Linguagem Java para Web (J2EE)

Identificação: [NFR01] Utilizar Linguagem Java para Web (J2EE)

Casos de Uso relacionados: _Todos.

(16)

asf2, afaf, hsp, rlb Página 16 24/11/2009 necessários citados no estudo de viabilidade, a aplicação deverá ser toda desenvolvida em Java para Web.

4.1.2 [NFR02] Utilizar Hibernate

Identificação: [NFR02] Utilizar Hibernate

Descrição: Facilitar o desenvolvimento de consultas ao bando de dados e

permitir a independência do mesmo.

4.1.3 [NFR03] Utilizar Banco de Dados PostgreSQL

Identificação: [NFR03] Utilizar Banco de Dados PostgreSQL

Descrição: Esse sistema de banco de dados é gratuito e oferece recursos _{para analise de dados geográficos e os recursos básicos}

necessários à aplicação.

4.2 Requisitos de Produto

4.2.1 Usabilidade

4.2.1.1 - [NFR04] Mensagens de Erro

Identificação: [NFR04] Mensagens de Erro

Casos de Uso relacionados: _Todos. Descrição:

As mensagens de erro deverão ser objetivas, orientando o usuário a solucionar o problema e não impedindo o progresso dele no sistema. Elas serão exibidas com um mínimo de impacto no fluxo da aplicação.

4.2.1.2 - [NFR05] Interface do Sistema

(17)

Descrição:

A Interface Gráfica do Usuário (GUI) deverá prover a comunicação entre o usuário e o sistema para que ele tenha fácil acesso a todas as funcionalidades do sistema e de forma objetiva. A GUI deverá seguir regras de Usabilidade e as informações deverão estar bem intuitivas.

4.2.1.3 - [NFR05] Manual do Usuário

Identificação: [NFR05] Manual do Usuário.

Descrição: Apresentar de forma simples e objetiva todas as

funcionalidades do sistema.

(18)

asf2, afaf, hsp, rlb Página 18 24/11/2009 4.2.2 Segurança

4.2.2.1 - [NFR06] Controle de Acesso

Identificação: [NFR06] Controle de Acesso

Descrição: Cada usuário usufrui de funcionalidades que a eles são

permitidas.

4.2.2.2 - [NFR07] Integridade

Identificação: [NFR07] Integridade

Deve ser mantida a integridade dos dados em todas as ações de usuários, principalmente aquelas relacionadas a armazenamento e recuperação de dados do banco de dados.

4.2.2.3 - [NFR08] Confidencialidade

Identificação: [NFR08] Confidencialidade

Descrição: As senhas dos usuários são criptografadas para

armazenamento no banco de dados.

4.2.2.4 - [NFR09] Auditoria

Identificação: [NFR09] Auditoria

Descrição: Deve ser mantidas no banco de dados todas as ações

realizadas por cada usuário autenticado.

(19)

asf2, afaf, hsp, rlb Página 19 24/11/2009 4.2.3 Desempenho

4.2.3.1 - [NFR10] Tempo de Resposta

Identificação: [NFR10] Tempo de Resposta

Nenhuma das consultas feitas ao sistema deverá exceder 6 segundos, exceto as consultas de geração de relatório que pode atingir no máximo 20 segundos.

4.3 Requisitos Externos

4.3.1 [NFR12] Orçamento

Identificação: [NFR12] Orçamento

Descrição: O custo, com o desenvolvimento do sistema, não poderá

superar o estimado no Estudo de Viabilidade.

Prioridade:  Essencial  Importante  Desejável 4.3.2 [NFR13] Tempo de desenvolvimento

Identificação: [NFR13] Tempo de desenvolvimento

Descrição: O tempo com o desenvolvimento do sistema não poderá

superar mais de 10% do estimado no Estudo de Viabilidade.

5. Modelagem Organizacional

(20)

5.1 Modelagem de Dependência Estratégica

(21)

5.2 Modelo Estratégico da Razão

(22)

Figura 2 Modelo estratégico da razão com ator MapDengue expandido.

5.3 Comentário sobre os Modelos

Através do modelo de dependência estratégica mostramos o relacionamento de dependência entre os atores que fazem parte do sistema em relação a objetivos, softgoals, recursos e tarefas. Esse modelo mostra quem o ator é e quem depende do trabalho deste ator.

Através do modelo estratégico da razão mostramos como atores podem satisfazer os seus objetivos e softgoals. Este modelo inclui apenas elementos considerados importantes a ponto de impactar nos resultados de um objetivo.

O ator “administrador” no modelo faz menção aos dois administradores do sistema, administrador local e administrador executivo. Ambos possuem os mesmos privilégios no sistema, possuindo apenas uma distinção em relação aos mesmos. Administradores locais podem realizar as funcionalidades em relação as suas respectivas localidades, enquanto o administrador executivo pode realizá-las para todos os locais.

(23)

asf2, afaf, hsp, rlb Página 23 24/11/2009 Neste capítulo, os requisitos descritos anteriormente são modelados através de diagramas de caso de uso. O detalhamento dos casos de uso encontra-se no Anexo E deste documento.

Figura 3 Modelagem de Requisitos Funcionais (Casos de Uso)

A figura acima mostra o diagrama das funcionalidades do sistema, ele é composto pelas funcionalidades e pelos atores que usam as funcionalidades. Os cinco atores do sistema usam

(24)

asf2, afaf, hsp, rlb Página 24 24/11/2009 diversas funcionalidades, a interação de um ator com uma funcionalidade é representado por uma seta ligando os dois. Todos os usos que o ator atendente faz do sistema também pode ser feito pelo administrador local e tudo que o administrador local pode fazer, o administrador executivo também pode fazer. A diferença é que o administrador executivo gera relatórios de vários municípios e o administrador local gera apenas para o seu município. Quando uma funcionalidade depende de outra é representada por uma seta pontilhada de inclusão (<<include>>), por exemplo, para remover um aviso é necessário listar os avisos enviados. No caso do requisito obter coordenadas geográficas, no caso particular em que o servidor do Google não responder, estiver fora do ar, o sistema fará uma aproximação de coordenadas, por isso a seta pontilhada (<<extend>>).

7. Modelagem de Requisitos Não-Funcionais (NFR Framework)

Este capítulo contém os refinamentos dos requisitos não-funcionais, descreve suas interdependências e operacionalizações.

(25)

(26)

asf2, afaf, hsp, rlb Página 26 24/11/2009 A figura acima mostra o diagrama dos requisitos não funcionais, as nuvens de borda mais escura são as operalizações, as demais, são os requisitos não funcionais do sistema. Foi analisado que para o nosso sistema ter segurança é necessário possuir integridade, confidencialidade e auditoria. O uso de triggers e chaves estrangeiras no banco de dados são operalizações necessárias para a integridade do sistema. Da mesma forma, o uso de senhas criptografas e o registro das operações no banco de dados fazem parte da confiabilidade e auditoria, repectivamente. Interface do sistema, manual do usuário e mensagens de erro são fundamentais para se ter uma boa usabilidade. O tempo de resposta ajuda na boa performance; a indexação de colunas no banco de dados e a normalização contribuem positivamente no tempo de resposta. Por fim, ter auditoria implica prejudicas a performance do sistema.

8. Conclusão

Através do documento de requisitos, foi possível entender, através de uma breve descrição nas seções 1 e 2, o problema a ser resolvido com o sistema MapDengue.

Em seguida foram apresentados todos os requisitos funcionais do sistema, isto é, todos os serviços que o MapDengue deve oferecer aos seus usuários, segundo a definição do cliente.

Seguindo os requisitos funcionais, no capítulo 4 foram apresentados os requisitos não-funcionais, que irão definir restrições de como o sistema irá funcionar baseado em seus requisitos funcionais.

No capítulo 5, foi abordada a modelagem organizacional do sistema usando a notação i*, em que foram incluídos os modelos de dependência estratégica (SD) e o modelo estratégico de razão (SR) com os atores MapDengue expandido.

No capítulo 6, dando continuidade à modelagem de requisitos funcionais, através do diagrama de casos de uso, foram descritos os casos de uso do sistema, incluindo seus fluxos de eventos e dependências entre si.

Finalmente, no capítulo 7, foi feita a modelagem dos requisitos não-funcionais utilizando a plataforma NFR, mostrando os refinamentos deles, explicitando operacionalizações e interdependências entre eles.

(27)

Referências

[Disciplina] Disciplina de Especificação de Requisitos e Validação de Sistemas. Disponível em: <http://www.cin.ufpe.br>. Acesso em: 14 Nov. 09.

[Hackos] Hackos, Joann T. and Redish, Janice, User and Task Analysis for Interface Design, John Wiley & Sons.

[i*] i* - An Agent-oriented Modelling Framework. Disponível em:

<http://www.cs.toronto.edu/km/istar/>. Acesso em: 16 Nov. 09.

[Projeto] Documento de Estudo de Viabilidade. Disponível em:

<http://www.cin.ufpe.br/~apba>. Acesso em: 01 Nov. 09.

[Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering : Processes and

Techniques , John Wiley & Sons, 1998.

[Wikipédia] Wikipédia. A enciclopédia livre. Disponível em: <http://www.wikipedia.org>. Acesso em: 14 Nov. 09.

Relatório da Equipe

Nesta última seção, segue a porcentagem de esforço de cada membro da equipe. As atividades realizadas por cada um estão descritas no Histórico de Revisões deste documento.

Nome Esforço da equipe (%) Assinatura

Andresson Firmino 25%

Arthur Ferraz 25%

Humberto Pachêco 25%

Rudiney Barbosa 25%

(28)

Anexo A – Técnicas Utilizadas na Coletas de Dados

Foram utilizadas três técnicas de coleta de dados: reuso de requisito, leitura e reuniões. As mesmas serão descritas a seguir.

Reuso de requisito

O projeto MapDengue possui uma implementação na linguagem de programação php. O mesmo foi utilizado para analisar vários requisitos que também serão implementados na nova aplicação, feita na linguagem Java.

Cada funcionalidade do antigo sistema foi analisada. Foram verificadas as seguintes características: sua real necessidade para os usuários e se a execução estava correta. Os casos considerados mais relevantes foram documentados neste novo documento.

Leitura

Técnica que permite o leitor capturar possíveis novas características através de artigos, revistas e livros, resumindo, leitura em geral. Essa leitura é investigativa, ou seja, tem o objetivo de encontrar novos casos de uso de acordo com as declarações de outras pessoas sobre o tema. Por exemplo, ao ler algum artigo sobre a concentração de casos de dengue em um determinado local com um determinado clima, o analista poderá identificar um novo requisito para o sistema, o qual seria buscar as informações e reuni-las por localidade e/ou por clima regional.

Reuniões

Nessa técnica o observador coleta artefatos que são mencionados durante as reuniões com clientes e com os chefes. Essas pessoas irão descrever o que querem, ou pretendem ter, como produto final. Enquanto isso, o analista faz suas anotações para poder incrementar o documento de requisitos.

Anexo E – Descrição dos Atores

Descreveremos os atores do sistema que estão associados aos casos de usos citados no “Anexo F”, explicitando que são as entidades associadas a cada ator descrito.

 Atendentes: são funcionários, atendentes e telefonistas que trabalham em

cada membro do GCD. É responsável por cadastrar denúncias de foco no sistema.

(29)

asf2, afaf, hsp, rlb Página 29 24/11/2009 membro do GCD. Responsável pelo gerenciamento local dos funcionários, o das denúncias e planos de ação.

 Administrador Executivo: formado pelo Secretário Executivo da SESP e seus

secretários. Responsável pelo gerenciamento global das denúncias, usuário e plano de ação.

 Servidor Google: responsável por executar o Georreferenciamento e a

Geocodificação dos endereços do sistema.

 Denunciante: cidadãos que fornece informações de locais onde há um indício

de possível foco de dengue, ou seja, ator responsável por fornecer os dados da denuncia.

Anexo F – Descrição dos Casos de Uso

Autenticação

[UC01] Efetuar logon

Identificador: [UC 01]

Descrição: Autentica o usuário no sistema.

Atores: Atendentes, Administrador Local, Administrador Executivo.

Prioridade: Essencial

Pré-condições: Não se aplica.

Pós-condições: O ator terá acesso às funcionalidades do sistema que lhe dizem respeito.

Fluxo de Eventos Principal

1. Estando na tela inicial do sistema, o ator deve preencher os campos “login” e “senha”;

2. O ator então clica no botão “OK”.

Fluxo Secundário 1

1. O ator fornece um login não cadastrado no sistema; 2. A mensagem “Usuário inexistente” é exibida.

1. O ator fornece um login e uma senha não correspondentes; 2. A mensagem “Senha incorreta” é exibida.

(30)

asf2, afaf, hsp, rlb Página 30 24/11/2009 Requisitos Não Funcionais Específicos -

[UC02] Efetuar logoff

Descrição: Finaliza o acesso ao sistema.

Atores: Atendentes, Administrador Local, Administrador Executivo.

Pré-condições: O ator deve estar logado no sistema no momento da execução dessa operação.

Pós-condições: O ator deixa de ter acesso às funcionalidades do sistema. O sistema retorna à tela inicial.

1. O ator clica na opção “Sair”;

2. O sistema finaliza todas as operações que estão em execução devido às requisições feitas por esse ator.

Requisitos Não Funcionais Específicos -

[UC03] Mudar Senha

Descrição: Alterar dados da senha do usuário.

Atores: Atendentes, Administrador Local, Administrador Executivo.

Prioridade: Importante

Pré-condições: O ator deve estar logado no sistema no momento da execução dessa operação.

Pós-condições: O ator terá os dados da senha alterados e uma mensagem informando alteração com sucesso.

1. O ator clica na opção “Mudar Senha”;

2. O sistema requisita o preenchimento dos seguintes campos: “Senha Atual”, “Nova Senha”, “Confirme Senha”.

3. Usuário preenche os campos e aberta no botão “Alterar Senha”.

(31)

asf2, afaf, hsp, rlb Página 31 24/11/2009 1. O conteúdo do campo “Nova senha” não é igual ao campo “Confirme Senha”; 2. Exibir Mensagem: “Nova Senha diferente de Confirme Senha”.

1. A senha atual informada não corresponde ao do banco de dados

2. Exibir Mensagem, “Senha Atual Incorreta!”. Requisitos Não Funcionais Específicos -

Cadastro de Usuário – Membros da GCD

[UC04] Inserir Usuário

Descrição: Insere um usuário no sistema.

Ator: Administrador Local, Administrador Executivo.

Pré-condições: O ator deve estar logado no sistema.

Pós-condições: Haverá um novo usuário inserido no sistema.

(32)

asf2, afaf, hsp, rlb Página 32 24/11/2009 1. O ator seleciona a opção inserir Usuário.

2. O sistema verifica o tipo do usuário (“Administrador Executivo”, “Administrador Local”);

3. Se “Administrador Local”:

a. O usuário escolhe o tipo do usuário a ser inserido (“Administrador Local”, “Atendente”);

b. O usuário informa os (*) campos do usuário. 4. Se “Administrador Executivo”:

a. O usuário escolhe o tipo do usuário a ser inserido (“Administrador Local”, “Administrador Executivo”);

b. Se o tipo for “Administrador Local”, o usuário deve informar o município do usuário e o tipo membro (GERES ou SM);

c. O usuário informa os (*) campos do usuário 5. O usuário clica no botão inserir.

i. Se realizou o passo 3: será inserido usuário do tipo membro do município do mesmo usuário cadastrante. Ex: se o usuário cadastrante é do tipo membro GERES e do município de Olinda, o usuário inserido será do tipo membro GERES e do município de Olinda.

ii. Se realizou o passo 4: os dados tipo membro e município do usuário serão os informados nos campos.

6. O sistema insere o usuário a partir dos campos e dos passos mencionadas e o usuário terá como atributo criador o id do usuário cadastrante.

(*) Os campos: nome, CPF, email, login, senha, data de criação.

1. Se existe um usuário com o mesmo CPF ou mesmo login, o sistema deve exibir uma mensagem de erro, “Usuário já existente”;

(33)

asf2, afaf, hsp, rlb Página 33 24/11/2009 [UC05] Remover Usuário

Descrição: Remove um usuário e avisos associados do sistema.

Pré-condições: Existe pelo menos usuário para remoção.

Pós-condições: O usuário e seus avisos removidos.

1. Incluir o fluxo de eventos do caso de uso “[UC07] Listar Usuários”;

2. O ator seleciona o ícone de remoção de uma das entradas presentes na lista de usuários;

3. O sistema exibe uma tela contendo um formulário com as informações do respectivo usuário e o botão “Excluir”;

4. O ator seleciona o botão “Excluir”;

5. O sistema exibe uma mensagem informando que o usuário, e seus avisos e outros registros relacionados a ela serão removidos do sistema e pede a confirmação do usuário;

6. O ator confirma a exclusão;

7. O sistema remove os devidos registros e retorna para a tela de listar usuários.

1. No passo quatro do fluxo principal, o ator seleciona o botão “Cancelar”; 2. O sistema retorna para a tela de listar usuários.

1. No passo seis do fluxo principal, o ator não confirma a exclusão; 2. O sistema retorna para a tela de listar usuários.

(34)

asf2, afaf, hsp, rlb Página 34 24/11/2009 [UC06] Atualizar Usuário

Descrição: Atualiza as informações do usuário.

Pré-condições: O usuário a ser alterado deve estar presente no sistema.

Pós-condições: Os dados do usuário informados na alteração serão persistidos no sistema.

1. Incluir o fluxo de eventos do caso de uso “[UC07] Listar Usuários”;

2. O ator seleciona o ícone de alteração de uma das entradas presentes na lista de usuários;

3. O sistema exibe uma tela contendo um formulário com as informações do respectivo usuário e o botão “Alterar”;

4. O ator altera as informações desejadas; 5. O ator seleciona o botão “Alterar”;

6. O sistema persiste os novos dados do usuário e volta para a tela de listar usuários.

1. No passo cinco do fluxo principal, o ator seleciona o botão “Cancelar”; 2. O sistema retorna para a tela de listar usuários.

1. No passo quatro do fluxo principal, o ator altera os dados do usuário deixando-os iguais ao de outra já cadastrada;

2. O sistema exibe uma mensagem avisando que já existe um usuário cadastrado com esses dados e permanece na mesma tela com os campos preenchidos.

(35)

asf2, afaf, hsp, rlb Página 35 24/11/2009 [UC07] Listar Usuários

Descrição: Lista os usuários que estão cadastrados no sistema.

Pré-condições: O usuário deve estar logado no sistema.

Pós-condições: Nenhum registro do sistema deve ser alterado pela realização dessa funcionalidade.

1. O ator seleciona a opção “Listar Usuários”;

2. O sistema identifica o tipo do usuário (“Administrador Local”, “Administrador Executivo”)

a. Se “Administrador Local”, será listado todos os usuários que possuam o mesmo município e o mesmo tipo membro do usuário logado.

b. Se “Administrador Executivo”, será listado todos os usuários do tipo “Administrador Local”

3. O sistema exibe uma tela com a lista com os usuários ordenada alfabeticamente pelo nome, e permitir a ordenação por nome, login, tipo usuário, município e

GERES.

1. No primeiro passo do fluxo principal, não há nenhuma usuário disponível cadastrado;

2. O sistema permanece na mesma tela e exibe uma mensagem informando que não existe nenhum usuário cadastrado.

(36)

Avisos

[UC08] Escrever Aviso

Descrição: Escreve um aviso no sistema.

Ator: Administrador Local, Administrador Executivo, Atendentes.

Pré-condições: O usuário deve estar logado no sistema.

Pós-condições: Haverá um novo escrito no sistema.

1. O ator seleciona a opção listar avisos;

2. O Sistema verifica o tipo do usuário, para geração das opções de destinatários do formulário de cadastro.

i. Se o tipo for “Atendentes”, não exibir a opção de destinatários e o (destinatário) grupo de usuário, para o aviso é formado por todos os usuários do mesmo município e do mesmo tipo membro do usuário logado.

ii. (Se for o tipo “Administrador Local”, exibir as opções “Atendentes” e “Outro Administrador Local”, sendo o grupo de usuário destinatário) será formado pelo mesmo município e do mesmo tipo membro do usuário logado e cujo tipo usuário seja uma das opções exibidas.

iii. Se for o tipo “Administrador Local”, exibir as opções de escolher o município e tipo membro, e o grupo de usuário (destinatário) é formado pelo município e tipo membro informado.

3. O sistema exibe o formulário de cadastro de um novo aviso; 4. O ator informa os dados do aviso a ser cadastrado;

5. O ator clica no botão “OK”;

6. O sistema cadastra as informações na base e retorna para o formulário de cadastro apresentando os campos limpos.

(37)

asf2, afaf, hsp, rlb Página 37 24/11/2009 [UC09] Remover Aviso

Descrição: Remove um aviso do sistema.

Pré-condições: Estar logado no sistema e o existe aviso disponível para remoção.

Pós-condições: O registro do aviso é removido do sistema.

1. Incluir o fluxo de eventos do caso de uso “[UC10] Listar Avisos Enviados”;

2. O ator seleciona o ícone de remoção de uma das entradas presentes na lista de avisos;

3. O sistema exibe uma tela contendo um formulário com as informações do respectivo aviso e o botão “Excluir”;

4. O ator seleciona o botão “Excluir”;

5. O sistema remove os devidos registros e retorna para a tela de listar avisos enviados.

1. No passo quatro do fluxo principal, o ator seleciona o botão “Cancelar”; 2. O sistema retorna para a tela de listar avisos enviados.

[UC10] Listar Avisos Enviados

Descrição: Lista os avisos enviados de determinado usuário.

Pré-condições: O ator deve estar logado no sistema.

Pós-condições: As informações consultadas devem permanecer inalteradas.

(38)

asf2, afaf, hsp, rlb Página 38 24/11/2009 1. O ator clica na opção “Listar Avisos Enviados”;

2. O sistema procura no banco os avisos com remetente igual ao id do ator;

3. O sistema exibe uma tela com a lista com os avisos ordenados por data de postagem e permitir a ordenação por título e conteúdo.

1. No primeiro passo do fluxo principal, não há nenhuma aviso disponível enviado; 2. O sistema permanece na mesma tela e exibe uma mensagem informando que não

existe nenhum aviso enviado.

[UC11] Listar Avisos Recebidos

Descrição: Lista os avisos recebidos de determinado usuário nos últimos 30 dias.

1. O ator clica na opção “Listar Avisos Recebidos”;

2. O sistema procura no banco os avisos cujo grupo de usuário (destinatários) contenha o ator e data de postagem do aviso seja superior a 30 dias posteriores a data atual;

3. O sistema exibe uma tela com a lista com os avisos ordenados por data de postagem e permitir a ordenação por título e conteúdo.

1. No primeiro passo do fluxo principal, não há nenhuma aviso disponível recebido; 2. O sistema permanece na mesma tela e exibe uma mensagem informando que não

existe nenhum aviso recebido.

(39)

Focos de Dengue

[UC12] Inserir Denúncia de Foco de Dengue

Descrição: Insere uma denúncia de foco no sistema.

Ator: Atendente, Denunciante.

Pré-condições: Atendente está logada ou o denunciante acessar a página de cadastro.

Pós-condições: Haverá uma denúncia de foco registrada no sistema.

1. O usuário clica na opção “Inserir Denúncia de Foco”

2. O sistema exibe o formulário de cadastro de uma nova denuncia;

3. O ator informa os dados de localização do foco (município, bairro, rua, cep, complemento, ponto de referência) .

4. Incluir o fluxo de eventos do caso de uso “*UC19] Obter Coordenadas Geográficas” e “*UC20] Aproximação de Coordenadas”.

a. O sistema obtém as coordenadas geográficas, coordenadas aproximadas ou não; 5. O ator informa os dados do ambiente físico do foco que são: o tipo do local

(Residência, Terreno Abandonado, Comércio, Indústria, Casa de Veraneio, Residência Abandonada ou Fechada, Cemitérios, Parque, Borracharia, Depósito de Material de Construção, Lixão, Edifício em Construção) e o tipo de depósito (Cacimbas, Poços e Cisterna; Depósitos Variados; Vasilhame para Água de Animais Domésticos; Bandeja Externa de Geladeiras; Lagos, Cascatas e Espelho D Água Decorativos; Cacos de Vidros nos Muros; Canteiro de Obras; Piscina ou tanque; Caixa d água e toneis; Ferro Velho; Laje com água e calhas; Cisterna à céu aberto; Pneus; Recipientes Naturais; Lixo Acumulado; Vasos de Flores; Carcaças de Automóveis; Entupimento em Ralos de Cozinha, Banheiro, Sauna e Ducha; Bromélias e Outras Plantas Parecidas; Urnas de Cemitério; Não Sabe Informar / Não Visualizado);

6. O ator informa os dados do denunciante: (Nome, Telefone, Celular, Email e Observações sobre a denúncia)

7. O ator clica no botão “OK”;

8. O sistema cadastra as informações na base e retorna para o formulário de cadastro apresentando os campos limpos.

(40)

asf2, afaf, hsp, rlb Página 40 24/11/2009 [UC13] Remover Denúncia de Foco

Descrição: Remove uma denúncia de foco do sistema e o plano de ação associado.

Pré-condições: Estar logado no sistema e a denúncia a ser removido deve constar no sistema.

Pós-condições: O registro da denúncia e seu plano de ação associado são removidos do sistema.

1. Incluir o fluxo de eventos do caso de uso “*UC15] Listar Denúncias de Foco”; 2. O ator seleciona o ícone de remover da denúncia de uma das entradas presentes na

lista de denúncias;

3. O sistema exibe uma mensagem informando que a denúncia selecionada será excluída juntamente com sue plano de ação e pede confirmação;

4. O ator confirma a operação;

5. O sistema permanece na mesma tela.

1. No passo quatro do fluxo principal, o ator não confirma operação; 2. O sistema permanece na mesma tela.

[UC14] Alterar Denúncia de Foco.

Descrição: Alterar os dados de Denúncia de Foco.

Ator: Administrador Local, Administrador Executivo

Pós-condições: Os dados da denúncia informados na alteração serão persistidos no sistema.

(41)

asf2, afaf, hsp, rlb Página 41 24/11/2009 1. Incluir o fluxo de eventos do caso de uso “*UC15] Listar Denúncias de Foco”; 2. O ator seleciona o ícone de alteração de uma das entradas presentes na lista

denúncias;

3. O sistema exibe uma tela contendo um formulário com as informações da respectiva denuncia e o botão “Alterar”;

6. O sistema persiste os novos dados da denúncia e volta para a tela de listar denúncias.

1. No passo cinco do fluxo principal, o ator seleciona o botão “Cancelar”; 2. O sistema retorna para a tela de listar denúncias.

[UC15] Listar Denúncias de Foco

Descrição: Lista as denúncias de foco.

Ator: Administrador Local, Administrador Executivo

1. O ator clica na opção “Listar Denúncia de Foco”;

2. O sistema identifica o usuário (“Administrador Local”, “Administrador Executivo”)

a. Se “Administrador Local”, exibir apenas as denúncias registradas apenas por usuários que são do mesmo município e tipo membro do ator.

b. Se “Administrador Executivo”, exibir todas as denúncias.

3. O sistema exibe uma tela com a lista com as denúncias ordenadas por código e permitir a ordenação por código, município, bairro, rua, CEP e tipo do local.

(42)

asf2, afaf, hsp, rlb Página 42 24/11/2009 1. No primeiro passo do fluxo principal, não há nenhuma denúncia disponível; 2. O sistema permanece na mesma tela e exibe uma mensagem informando que não

existe nenhum denúncia.

[UC16] Inserir Plano de Ação

Descrição: Insere os dados de um plano de ação.

Pré-condições: O plano de ação a ser criado não deve existir no sistema.

Pós-condições: Os dados do plano de ação informados na inserção serão persistidos no sistema.

1. O ator seleciona o botão “plano de ação” e informa o código da denúncia de foco;

2. O sistema exibe uma tela contendo um novo formulário e o botão “Cadastrar”; 3. O ator insere as informações desejadas;

4. O ator seleciona o botão “Cadastrar”;

5. O sistema persiste os dados do plano de ação, retorna uma mensagem de sucesso e retorna para a tela inicial .

1. No passo um do fluxo principal, o ator informa um código inexistente;

2. O sistema informa que o código da denuncia não existe e retorna á tela principal.

[UC17] Edição de Plano de Ação

Descrição: Atualiza os dados de um plano de ação.

(43)

Pré-condições: O plano de ação a ser alterado deve estar presente no sistema.

Pós-condições: Os dados do plano de ação informados na alteração serão persistidos no sistema.

1. O ator seleciona o botão “plano de ação” e informa o código da denúncia de foco;

2. O sistema exibe uma tela contendo um formulário com as informações do respectivo plano de ação e o botão “Alterar”;

5. O sistema persiste os novos dados do plano de ação, retorna uma mensagem de sucesso e retorna para a tela inicial .

1. No passo um do fluxo principal, o ator informa um código inexistente;

2. O sistema informa que o código da denuncia não existe e retorna á tela principal.

[UC18] Retorno de Laboratório

Descrição: O plano de ação contra um foco é atualizado indicando se o local da ocorrência é um foco positivo (existência de ovos) ou não.

Ator: Administrador Local e Administrador Executivo.

Prioridade: Essencial

Pré-condições: Administrador deve estar logado.

Pós-condições: Plano de ação atualizado.

1. Administrador seleciona um plano de ação;

2. Altera a informação de foco para positivo (quando há ovos) ou negativo (caso contrário).

(44)

asf2, afaf, hsp, rlb Página 44 24/11/2009 [UC19] Obter Coordenadas Geográficas

Descrição: Usuário fornece um endereço e a aplicação apresenta o endereço referenciado no mapa

Ator: Usuário.

Pré-condições: O subsistema GoogleMaps deve estar em execução.

Pós-condições: Obter novas coordenadas geográficas.

1. Usuário acessa a tela de georreferenciamento e fornece dados de endereço como o Município, bairro, rua, cep, complemento e ponto de referência.

2. O sistema se comunica com o subsistema Googlemaps, o qual apresenta o endereço georreferenciado.

3. O usuário tem acesso visível aos pontos geográficos do endereço informado no passo 1.

1. Após passo 3 do fluxo principal, o usuário poderá movimentar o ponto do mapa fornecido pelo GoogleMaps.

2. O subsistema GoogleMaps informa as novas coordenadas geográficas.

[UC20] Aproximação de Coordenada

Descrição: Obter coordenadas geográficas, aproximadas, utilizando outros endereços já cadastrados no sistema através do caso de uso 19 que são próximos ao endereço fornecido.

Ator: Usuário.

Prioridade: Importante.

Pré-condições: O subsistema GoogleMaps deve estar em execução.

Pós-condições: Obter novas coordenadas geográficas.

(45)

asf2, afaf, hsp, rlb Página 45 24/11/2009 1. O ator seleciona no menu “Fórum” a opção “Postar Notícia”;

2. O sistema exibe uma tela contendo o campo para as informações; 3. O ator preenche o campo;

4. O ator seleciona o botão “Postar”;

5. O sistema adiciona a informação ao fórum de notícias e permanece na mesma tela.

[UC21] Gerar relatório.

Identificador: [UC 21]

Descrição: Visualizar relatórios, informações sobre denúncias de foco e planos de ações cadastrados para as denúncias.

Prioridade: Essencial.

Pós-condições: Nenhum registro do sistema deverá ser alterado pela realização dessa operação.

1. O atendente seleciona a opção ver relatório na tela de opções; 2. O usuário terá acesso a informações e terá opção para imprimi-lo;

3. No passo 1, o atendente poderá escolher a opção de ver denúncias de focos e também planos de ações contra tais denúncias.

[UC22] Gerar Relatório com Mapa

Identificador: [UC 22]

Descrição: Visualizar relatórios com dados visíveis em mapas.

Prioridade: Desejável

Pós-condições: Nenhum registro do sistema deverá ser alterado pela realização dessa operação.

(46)

asf2, afaf, hsp, rlb Página 46 24/11/2009 1. O atendente seleciona a opção ver relatório com mapa na tela de opções; 2. O usuário terá acesso a informações e a visualização de um mapa com

dados sobre os focos;

Anexo G – Glossário

 SESP: Secretária Estadual de Saúde de Pernambuco.

 GERES: Gerência Estadual de Saúde.

 SMs: Secretárias Municipais.

 GCD: Grupo de Combate a Dengue.

 CIn: Centro de Informática da Universidade da Federal de Pernambuco.

 Plano de Ação: Atividade esquematizada pelo GCD, formadas por várias etapas:

o Análise do Local: consiste da averiguação do local da denúncia de foco, se existe algum indicador de um possível foco de dengue. Caso não possua indicado a denuncia é descartada, caso sim e feita coleta de materiais do ambiente para checagem em laboratório.

o Laboratório: O material recolhido é analisado para detecção de ovos e restígios do mosquito. Após a análise é declarado se o local da denuncia é ou não, um foco positivo.

o Tratamento: Após a confirmação do foco positivo, são elaboradas e registradas as atividades, para o combate ao loco do foco, tais como: "Eliminação e remoção de criadouros", "Aplicação de Larvicidas"; "Distribuiçaõ de Material Educativo".

 UBV: Um importante instrumento para o combate à dengue no Estado é o Ultra

Baixo Volume (UBV), popularmente conhecido como fumacê. Há dois tipos do aparelho: UBV leve e UBV pesado. O primeiro deles é o chamado UBV Costal. Este é um aparelho portátil, que pode ser utilizado durante todo o ano e tem o objetivo de conter uma possível disseminação da doença.

 Georreferenciamento: Obtenção de coordenadas geográficas, a partir de um ponto

em um mapa.

 Geocodificação: Conversão de endereço em coordenadas geográficas.

 PostgreSQL: O PostgreSQL é um sistema de banco de dados objeto-relacional que

tem as características de sistemas de bancos de dados comerciais tradicionais com melhoramentos encontrados nos sistemas SGBDs(Sistemas de Gerenciamento de Banco de Dados) de próxima geração. PostgreSQL é livre e o código-fonte completo

(47)

asf2, afaf, hsp, rlb Página 47 24/11/2009 está disponível.

 Hibernate: Framework para o mapeamento objeto-relacional escrito na linguagem

Java. Este programa facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicação, mediante o uso de arquivos (XML) para estabelecer esta relação.

 Login: Trata-se de uma seqüência de caracteres utilizada para identificar um usuário

de forma única.

 Log on: Termo utilizado para demonstrar a ação de um usuário quando entra no

sistema dom login e senha.

 Log off: Termo utilizado para demonstrar a ação de um usuário quando este sai do

sistema.

 Notação i*: Abordagem criada por John Mylopoulos e EricYu, na Universidade de