TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE...
Transcript of TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE...
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
Luana Jacinto de Oliveira
Maycon Rocha da Cunha
MINHA IGREJA
BRASÍLIA
2015
Luana Jacinto de Oliveira
Maycon Rocha da Cunha
MINHA IGREJA
Trabalho de Conclusão de Curso apresentado às Faculdades Integradas Promove de Brasília como requisito parcial para obtenção do título de tecnólogo em Análise e Desenvolvimento de Sistemas
Orientador: Prof.Cid Cintra
BRASÍLIA
2015
Luana Jacinto de Oliveira
Maycon Rocha da Cunha
MINHA IGREJA
Trabalho de Conclusão de Curso apresentado às Faculdades Integradas Promove de Brasília como requisito parcial para a obtenção do título de tecnólogo em Análise e Desenvolvimento de Sistemas
Aprovado em ___/___/____________:
______________________________________
Orientador:
______________________________________
Avaliador:
_______________________________________
Avaliador:
RESUMO
O objetivo deste projeto é desenvolver um software que seja capaz de solucionar os
problemas de gestão enfrentados pela instituição religiosa Primeira Igreja Batista
Independente de Samambaia. A metodologia utilizada para levantar os requisitos
necessários para o desenvolvimento do sistema foi uma pesquisa realizada com os
responsáveis pela administração da instituição, através de perguntas e observações
diárias de como os membros eram cadastrados como era realizados o controle de
receitas a forma em que o patrimônio era controlado na instituição. Chegou-se a
conclusão de que os dados eram armazenados em fichas de papel ou em planilhas
Excel. Ao levantar essas informações, o Software minha igreja foi desenvolvido e o
problema de gestão da IBIS foi sanado após a implantação deste.
Palavras-chaves: software gestão, metodologia, implantação.
ABSTRACT
The objective of this project is to develop a software that is able to solve the
management problems faced by the religious institution First Baptist Church
Independent Fern. The methodology used to raise the necessary requirements for the
development of the system was a survey of those responsible for the administration of
the institution, through questions and daily observations of how members were
registered as was made the recipes control the way the patrimony It was controlled in
the institution. We came to the conclusion that the data were stored in paper records
or Excel spreadsheets. By raising this information, the software was developed my
church and the IBIS management problem was remedied after the implementation of
this.
Keywords: management software, methodology, implementation.
SUMÁRIO
CAPITULO I - APRESENTAÇÃO ............................................................................... 1
1.1 - Introdução .......................................................................................................... 1
1.2 - Justificativa ....................................................................................................... 1
1.3 - OBJETIVO .......................................................................................................... 2
1.3.1 - OBJETIVO GERAL .......................................................................................... 2
1.3.2 - OBJETIVOS ESPECÍFICOS ............................................................................ 2
1.3.3 - METODOLOGIA .............................................................................................. 2
CAPÍTULO II- REFERENCIAL TEÓRICO .................................................................. 3
2.1 - PROGRAMAÇAO ORIENTADA A OBJETOS. .................................................. 3
2.1.1 - INTRODUÇÃO ................................................................................................. 3
2.1.2 - DEFINIÇÕES ................................................................................................... 3
2.2 - UNIFIED MODELING LANGUAGE (UML) ......................................................... 5
2.2.1 - DIAGRAMA DE CASOS DE USO .................................................................... 5
2.2.1.1 - CASO DE USO ............................................................................................. 6
2.2.1.2 - ATOR ............................................................................................................ 7
2.2.1.3 - DIAGRAMA DE CLASSE .............................................................................. 7
2.3 - Rational Unified Process RUP ....................................................................... 11
2.3.1 - Fase de Concepção / Iniciação ...................................................................... 12
2.3.2 - Fase de Elaboração ....................................................................................... 12
2.3.3 - Fase de Construção ....................................................................................... 13
2.3.4 - Fase de Transição.......................................................................................... 13
2.4 - Ferramentas Utilizadas ................................................................................... 15
2.4.1 - Hypertext Preprocessor ( PHP) ...................................................................... 15
2.4.2 - Angular JS ...................................................................................................... 15
2.4.3 - Atributos ......................................................................................................... 15
2.4.4 - Objetivos ........................................................................................................ 15
2.4.5 - Mysql .............................................................................................................. 16
2.4.6 - Apache cordova ............................................................................................. 16
2.4.7 - JAVA SCRIPT ................................................................................................ 16
CAPITULO III – ANÁLISE E DOCUMENTAÇÃO DO SISTEMA .............................. 17
3 - DOCUMENTO DE VISÃO .................................................................................... 17
3.1 - INTRODUÇÃO .................................................................................................. 17
3.1.1 - Finalidade ....................................................................................................... 17
3.1.2 - Escopo do documento.................................................................................... 17
3.1.3 - Visão Geral .................................................................................................... 17
3.2 - Posicionamento .............................................................................................. 17
3.2.1 - Descrição da Empresa ................................................................................... 17
3.3 - Oportunidade de Negócios ............................................................................ 18
3.3.1 - Descrição do Problema .................................................................................. 18
3.3.2 - Sentença de Posição do Produto ................................................................... 19
3.3.3 - Escopo do Produto ......................................................................................... 19
3.4 - Descrições dos Envolvidos e dos Clientes .................................................. 19
3.4.1 - Demografias do Mercado ............................................................................... 19
3.4.2 - Resumo dos Envolvidos ................................................................................. 20
3.4.3 - Resumo dos Clientes ..................................................................................... 20
3.4.4 - Ambiente dos Clientes ................................................................................... 21
3.4.5 - Perfis dos Envolvidos ..................................................................................... 21
3.5 - Alternativas e Concorrência ........................................................................... 24
3.6 - Restrições ........................................................................................................ 24
3.7 - Especificações de Requisitos ........................................................................ 25
3.7.1. - ERaF MI.001 ................................................................................................. 25
3.7.2 - ER aD MI.001 ................................................................................................. 25
3.7.2 - ER aF MI.002 ................................................................................................. 25
3.7.3 - ER aD MI.002 ................................................................................................. 26
3.7.4 - ER aF MI.003 ................................................................................................. 26
3.7.5 - ER aD MI.003 ................................................................................................. 26
3.7.6 - ERaF MI.004 ................................................................................................. 27
3.7.7 - ERaD MI.004 .................................................................................................. 27
3.7.8 - ERaF MI.005 .................................................................................................. 27
3.7.9 - ERaD MI. 005 ................................................................................................. 27
3.7.10 - ERaF MI.006 ................................................................................................ 28
3.7.11 - ERaD MI.006 ................................................................................................ 28
3.7.1.2 - ERaF MI.007 ............................................................................................... 28
3.7.13 - ERaD MI.007 ................................................................................................ 28
3.7.14 - ERaF MI.008 ................................................................................................ 29
3.7.15 - ERaF MI.008 ................................................................................................ 29
3.7.16 - ERaF MI.009 ................................................................................................ 29
3.7.17 - ERaD MI.009 ................................................................................................ 29
3.7.18 - ERaF MI.010 ................................................................................................ 30
3.7.19 - ERaD MI.010 ................................................................................................ 30
3.7.20 - ERaF MI.011 ................................................................................................ 30
3.7.21 - ERaD MI.011 ................................................................................................ 30
3.7.22 - ERaF MI.012 ................................................................................................ 31
3.7.23 - ERaD MI.012 ................................................................................................ 31
3.7.24 - ERaF MI.013 ................................................................................................ 31
3.7.25 - ERaD MI.013 ................................................................................................ 31
3.7.26 - ERaF MI.014 ............................................................................................... 32
3.7.27 - ERaD MI.014 ................................................................................................ 32
3.7.28 - ERaF MI.015 ................................................................................................ 32
3.7.29 - ERaD MI.015 ................................................................................................ 32
3.7.30 - ERaF MI.016 ................................................................................................ 33
3.7.31 - ERaD MI.016 ................................................................................................ 33
3.7.32 - ERaF MI.017 ................................................................................................ 33
3.7.33 - ERaD MI.017 ................................................................................................ 33
3.7.34 - ERaF MI.018 ................................................................................................ 33
3.7.35 - ERaD MI.018 ................................................................................................ 34
3.7.36 - ERaF MI.019 ................................................................................................ 34
3.7.37 - ERaD MI.019 ................................................................................................ 34
3.7.38 - ERaF MI.020 ................................................................................................ 34
3.7.39 - ERaD MI.020 ................................................................................................ 35
3.7.40 - ERaF MI.021 ................................................................................................ 35
3.7.41 - ERaD MI.021 ................................................................................................ 35
3.7.42 - ERaF MI.022 ............................................................................................... 35
3.7.43 - ERaD MI.022 ................................................................................................ 36
3.7.44 - ERaD MI.023 ................................................................................................ 36
3.7.45 - ERaD MI.023 ................................................................................................ 36
3.7.46 - ERaF MI.024 ................................................................................................ 37
3.7.-47 - ERaD MI.024 .............................................................................................. 37
3.7.48 - ERaF MI.025 ................................................................................................ 37
3.7.49 - ERaD MI.025 ................................................................................................ 37
3.7.50 - ERaF MI.026 ................................................................................................ 38
3.7.51 - ERaD MI.026 ............................................................................................... 38
3.7.52 - ERaF MI.027 ............................................................................................... 38
3.7.53 - ERaD MI.027 ................................................................................................ 38
3.7.54 - ERaF MI.028 ................................................................................................ 39
3.7.55 - ERaD MI.028 ................................................................................................ 39
3.7.56 - ERaF MI.029 ............................................................................................... 39
3.7.57 - ERaD MI.029 ................................................................................................ 39
3.7.58 - ERaF MI.030 ................................................................................................ 40
3.7.59 - ERaD MI.030 ................................................................................................ 40
3.7.60 - ERaF MI.031 ................................................................................................ 40
3.7.61 - ERaD MI.031 ................................................................................................ 40
3.7.62 - ERaF MI.032 ................................................................................................ 41
3.7.63 - ERaD MI.032 ................................................................................................ 41
3.7.64 - ERaF MI.033 ................................................................................................ 41
3.7.65 - ERaD MI.033 ................................................................................................ 41
3.7.66 - ERaF MI.034 ................................................................................................ 42
3.7.67 - ERaD MI.034 ................................................................................................ 42
3.7.68 - ERaF MI.035 ................................................................................................ 42
3.7.69 - ERaD MI.035 ................................................................................................ 42
3.7.70 - ERaF MI.036 ................................................................................................ 43
3.7.71 - ERaD MI.036 ................................................................................................ 43
3.7.72 - ERaF MI.037 ................................................................................................ 43
3.7.73 - ERaD MI.037 ................................................................................................ 43
3.7.74 - ERaF MI.038 ................................................................................................ 44
3.7.75 - ERaD MI.038 ................................................................................................ 44
3.7.76 - ERaF MI.039 ................................................................................................ 44
3.7.77 - ERaF MI.039 ................................................................................................ 44
3.7.78 - ERaF MI.40 .................................................................................................. 45
3.7.79 - ERaD MI.40 .................................................................................................. 45
3.8 - DESCRIÇÕES DOS CASOS DE USO E ATORES .......................................... 45
3.8.1 - Caso de uso ................................................................................................... 45
3.9 - Descrições dos Atores ................................................................................... 46
3.9.1 - Pastores presidentes...................................................................................... 46
3.9.2 - Vice-presidente .............................................................................................. 46
3.9.3 - Secretarias ..................................................................................................... 46
3.9.4 - Tesoureiros .................................................................................................... 47
3.9.5 - Presidente patrimonial.................................................................................... 47
3.9.6 - Administradores do sistema ........................................................................... 47
3.10 - DIAGRAMA GERAL DE CASO DE USO ....................................................... 47
3.10.1 - DETALHAMENTO DOS CASOS DE USO ................................................... 48
3.10.1.2 - UC 001 – Manter Membro ......................................................................... 48
3.10.1.3 - UC 002 – Manter Sede .............................................................................. 51
3.10.1.4 - UC 009 – Manter classe escola bíblica dominical ..................................... 53
3.10.1.5 - UC14–Manter Relatório ............................................................................. 56
3.10.1.6 - UC 015– Manter Caixa .............................................................................. 57
3.10.1.7 - UC 016 – Manter Departamento ................................................................ 60
3.10.1.8 - UC 017 - Manter cargos eclesiásticos ....................................................... 64
3.10.1.9 - UC 020–Manter contas a pagar ................................................................ 67
3.10.1.10 - UC 021–Manter fornecedor ..................................................................... 70
3.10.1.11 - UC 020–Manter culto .............................................................................. 73
3.10.1.12 - UC 020–Manter bens .............................................................................. 76
3.11 - Diagrama de Classe ...................................................................................... 80
3.12 - Diagrama de Entidade Relacional ................................................................ 81
3.13 - Diagrama de sequência ................................................................................ 82
3.13.1 - Diagrama de sequência autenticação .......................................................... 82
3.13.2 Diagrama de Sequência Manter Membro ....................................................... 83
3.13.3 - Diagrama de Sequência Manter Bens .......................................................... 84
3.13.4 - Diagrama de Sequência Manter Caixa......................................................... 85
3.13.5 - Diagrama de Sequência Manter Cargos ...................................................... 86
3.13.6 - Diagrama de Sequencia Manter Classe ....................................................... 87
3.13.7 - Diagrama de Sequencia Manter conta ......................................................... 88
3.13.8 - Diagrama de Sequência Manter Culto ......................................................... 89
3.13.9 - Diagrama de Sequência Manter Departamento ........................................... 90
3.13.10 - Diagrama de Sequencia manter formas de pagamento ............................. 91
3.13.11 - Diagrama de sequencia manter fornecedor ............................................... 92
3.13.12 - Diagrama de Sequência Manter Funcionário ............................................. 93
CAPITULO IV – CONCLUSÃO ................................................................................. 94
4.1 - REFERÊNCIA ................................................................................................... 95
4.2 - APÊNDICE ........................................................................................................ 96
4.2.1 - Telas do Sistema ........................................................................................... 96
4.2.1.1 - Tela de Autenticação ................................................................................... 96
4.2.1.2 - Tela Inicial ...................................................................................................97
4.2.1.3 - Tela Cadastrar Membro .............................................................................. 98
4.2.1.4 - Tela Cadastrar Cultos ................................................................................. 99
4.2.1.5 - Menu de Navegação ................................................................................. 100
4.2.1.6 - Tela de Login Mobile ................................................................................. 101
4.2.1.7 - Tela de Mensagens Aplicativo Mobile ....................................................... 102
4.2.1.8 - Tela Feed de Notícias Mobile .................................................................... 103
1
CAPITULO I - APRESENTAÇÃO
1.1 - Introdução
A informação é o ativo de maior valor que uma empresa possui.
A era das informações guardadas em papeis ficou pra trás, Na atualidade, as
empresas utilizam os meios digitais para manipular suas informações. Tendo em vista
proteger seu bem mais valioso, a informação, as instituições adotam as boas práticas
da segurança da informação, seu principal objetivo é preservar a integridade da
informação. A segurança da informação preserva a confidencialidade, integridade,
disponibilidade e autenticidade das informações.
Atualmente, é impossível se imaginar uma empresa que não possua um
software para auxiliar o gerenciamento de suas informações. Ao aderir um sistema de
gerenciamento, são muitas as vantagens para a empresa. Um software garante a
integridade das informações e economiza tempo na administração de uma empresa.
O objetivo da elaboração deste projeto é expor o passo a passo do
desenvolvimento do software Minha Igreja, que foi desenvolvido, no primeiro
momento, para a Primeira Igreja Batista Independente de Samambaia, e será
disponibilizado para as demais igrejas do seguimento protestante.
São apresentadas as regra de negócio e as informações levantadas durante o
processo de análise e planejamento do sistema, diagramas, requisitos e descrições
do projeto.
1.2 - Justificativa
Atualmente a Primeira Igreja Batista Independente de Samambaia manipula
suas informações de forma manual, por meio de fichas e planilhas do aplicativo Excel.
Essa forma de manipular suas informações ocasiona muitos transtornos. Informações
importantes são perdidas. Para recuperá-las e preciso abordar cada membro para que
novas fichas sejam preenchidas.
O objetivo ao desenvolver esse software é facilitar o gerenciamento das
informações. A implantação do software Minha igreja é de grande importância para a
instituição. Após a instituição adotar o software para gerenciar suas informações, o
2
processo de administração será facilitado, tendo em vista que as igrejas também são
empresas que lidam com informações. As mesmas precisam do auxílio de um
software para automatizar seu gerenciamento.
1.3 - OBJETIVO
1.3.1 - OBJETIVO GERAL
Desenvolver um software para gerenciamento de informações da instituição
religiosa Primeira Igreja Batista Independente de Samambaia.
1.3.2 - OBJETIVOS ESPECÍFICOS
Produzir a documentação do sistema.
Automatizar o processo de gerenciamento das informações de
secretariado, manter membro.
Automatizar o processo do financeiro.
Automatizar o processo de recursos humanos.
Automatizar o controle de entrada e saída de patrimônio.
Automatizar a gestão da Escola Bíblica Dominical.
1.3.3 - METODOLOGIA
O Minha Igreja foi desenvolvido utilizando as fases do RUP, concepção,
elaboração, construção e transição. Primeiro foi levantado os requisitos junto ao
cliente (concepção), logo após os resultados foram utilizados para desenvolver o
software(elaboração).
O desenvolvimento da documentação, teve como base o RUP e o UML. Na
fase de construção foi feita a codificação do sistema na linguagem java script e
angular JS, logo após o sistema foi implantado na instituição.
3
CAPÍTULO II- REFERENCIAL TEÓRICO
2.1 - PROGRAMAÇAO ORIENTADA A OBJETOS.
2.1.1 - INTRODUÇÃO
De acordo com o site devmedia (sem data), o termo orientação a
objetos pressupõe uma organização de software em termos de coleção de objetos
discretos, incorporando estrutura e comportamento próprios. Esta abordagem de
organização é essencialmente diferente do desenvolvimento tradicional de software,
onde estruturas de dados e rotinas são desenvolvidas de forma apenas fracamente
acopladas.
Segundo Ricarte(2001), Programação Orientada a Objetos (POO) diz respeito
a um padrão de desenvolvimento que é seguido por muitas linguagens, como C#
e Java. Esse padrão se baseia em quatro pilares, abstração, encapsulamento,
herança e polimorfismo.
Figura 1- POO
Fonte: labdegaragem.com
2.1.2 - DEFINIÇÕES
2.1.2.1 - OBJETO
Para Ricarte (2001), um objeto é uma entidade do mundo real que tem
uma identidade. Objetos podem representar entidades concretas (um arquivo no
computador, uma bicicleta) ou entidades conceituais (uma estratégia de jogo, uma
4
política de escalonamento em um sistema operacional). Cada objeto ter sua
identidade significa que dois objetos são distintos mesmo que eles apresentem
exatamente as mesmas características. Embora objetos tenham existência própria no
mundo real, em termos de linguagem de programação, um objeto necessita de um
mecanismo de identificação. Esta identificação do objeto deve ser única, uniforme e
independente do conteúdo do objeto. Este é um dos mecanismos que permite a
criação de coleções de objetos, as quais são também objetos em si.
2.1.2.2 - POLIMORFISMO
De acordo com Ricarte (2001), Polimorfismo significa que a mesma operação
pode se comportar de forma diferente em classes diferentes. Por exemplo, a
operação move quando aplicada a uma janela de um sistema de interfaces tem um
comportamento distinto do que quando aplicada a uma peça de um jogo de xadrez.
Um método é uma implementação específica de uma operação para certa classe.
Polimorfismo também implica que uma operação de uma mesma classe pode ser
implementada por mais de um método. O usuário não precisa saber quantas
implementações existem para uma operação, ou explicitar qual método deve ser
utilizado: a linguagem de programação deve ser capaz de selecionar o método correto
a partir do nome da operação, classe do objeto e argumentos para a operação. Desta
forma, novas classes podem ser adicionadas sem necessidade de modificação de
código já existente, pois cada classe apenas define os seus métodos e atributos. No
mundo real, alguns objetos e classes podem ser descritos como casos especiais,
ou especializações, de outros objetos e classes. Por exemplo, a classe de
computadores pessoais com processador da linha 80x86 é uma especialização de
computadores pessoais, que por sua vez é uma especialização de computadores. Não
é desejável que tudo que já foi descrito para computadores tenha de ser repetido para
computadores pessoais ou para computadores pessoais com processador da linha
80x86.
5
2.2 - UNIFIED MODELING LANGUAGE (UML)
Segundo Gama (2013), UML é uma linguagem ou notação de diagramas para
especificar, visualizar e documentar modelos de 'software' orientados por objetos.
O UML não é um método de desenvolvimento, o que significa que não lhe diz o que
fazer primeiro ou o que fazer depois ou como desenhar o seu sistema, mas ajuda-o a
visualizar o seu desenho e a comunicar com os outros. A UML é controlada pelo
Object Management Group (OMG) e é a norma da indústria para descrever
graficamente o 'software'.
2.2.1 - DIAGRAMA DE CASOS DE USO
Para Gama (2013), diagramas de Caso de Uso descrevem relacionamentos e
dependências entre um grupo de Caso de Uso e os Atores participantes no processo.
É importante observar que Diagramas de Caso de Uso não são adequados para
representar o desenho, e não podem descrever os mecanismos internos de um
sistema. Diagramas de Caso de Uso são feitos para facilitar a comunicação com os
futuros usuários do sistema, e com o cliente, e são especialmente úteis para
determinar os recursos necessários que o sistema deve ter. Diagramas de Caso de
Uso dizem o quê o sistema deve fazer, mas não fazem — e não podem —
especificar como isto será conseguido. Veja na figura 2
Figura 2 – Diagrama de Caso de Uso
Fonte:http://imasters.com.br
6
2.2.1.1 - CASO DE USO
Segundo Gama (2013), um Caso de Uso descreve — do ponto de vista dos
atores — um grupo de atividades num sistema que produz um resultado concreto e
tangível.
Ainda, segundo Gama (2013), casos de Uso são descrições de interações
típicas entre os usuários de um sistema e o sistema propriamente dito. Eles
representam a interface externa do sistema e especificam um conjunto de exigências
do que o sistema deve fazer (lembre-se: somente o quê, não como). Quando trabalhar
com Casos de Uso, é importante lembrar-se de algumas regras simples:
Cada Caso de Uso está relacionado com no mínimo um ator.
Cada Caso de Uso possui um iniciador (isto é um ator).
Cada Caso de Uso liga-se a um resultado relevante (um resultado com “valor
de negócio”).
Segundo Gama (2013), Casos de Uso também podem ter relacionamentos com
outros Casos de Uso. Os três tipos mais comuns de relacionamento entre Casos de
Uso são:
<<inclui-se>> que especifica que um Caso de Uso toma lugar dentro de outro
Caso de Uso
<<estende>> que especifica que em determinadas situações, ou em algum
ponto (chamado um ponto de extensão) um Caso de Uso será estendido por
outro.
Generalização especifica que um Caso de Uso herda as características
do “Super” Caso de Uso, e pode sobrepor algumas delas ou adicionar novas
de maneira semelhante a herança entre classes.Descrição do Caso de Uso são
narrativas de texto do Caso de Uso. Elas usualmente tomam a forma de uma
nota ou um documento que é de alguma maneira ligada ao Caso de Uso, e
explana o processo ou atividades que tomarão lugar no Caso de Uso.
7
2.2.1.2 - ATOR
Segundo Cardoso (2013),
Um ator é qualquer pessoa ou sistema externo (SE) que tenha interação com o sistema que está em desenvolvimento; o nome ideal seria papel e não autor, pois isto tem confundido alguns projetistas que acabam identificando somente as pessoas que acessam o sistema e não levam em consideração que outros SEs podem e devem ser representados como ator. Além do nome, foi definido para a UML um símbolo que ajuda nesta associação com pessoas interagindo com o sistema.(CARDOSO, 2003, P.19).
Para Gama (2013), um ator é uma entidade externa (fora do sistema) que
interage com o sistema participando (e frequentemente iniciando) um Caso de Uso.
Atores podem ser pessoas reais (por exemplo, usuários do sistema), outro sistema de
computador ou eventos externos.
Segundo Gama (2013), atores não representam a pessoa física ou sistemas,
mas sua regra. Isto significa que quando uma pessoa interage com o sistema de
diferentes maneiras (assumindo diferentes regras) ela será representada por diversos
atores. Por exemplo, uma pessoa que fornece suporte ao cliente por telefone e recebe
ordens do cliente para o sistema pode ser representado por um ator da “Equipe de
Suporte” e um ator “Representante de Vendas”. Veja a figura abaixo.
Figura 3 – Representação de um ator
Fonte: Autores
2.2.1.3 - DIAGRAMA DE CLASSE
De acordo com Gama (2013), diagramas de Classe mostram as diferentes
classes que fazem um sistema e como elas se relacionam. Os Diagramas de Classe
são chamados diagramas “estáticos” porque mostram as classes, com seus métodos
e atributos bem como os relacionamentos estáticos entre elas: quais
8
classes “conhecem” quais classes ou quais classes “é parte” de outras classes, mas
não mostram a troca de mensagens entre elas.
2.2.1.4 - CLASSE
Segundo Gama (2013), uma Classe define os atributos e os métodos de um
conjunto de objetos. Todos os objetos desta classe (instâncias desta classe)
compartilham o mesmo comportamento, e possuem o mesmo conjunto de atributos
(cada objeto possui seu próprio conjunto). O termo “Tipo” é algumas vezes usado ao
invés de Classe, mas é importante mencionar que estes dois termos não são a mesma
coisa, e Tipo é um termo mais genérico.
Ainda, segundo Gama (2013), em UML Classes são representadas por
retângulos, com o nome da classe, e podem também mostrar os atributos e operações
da classe em dois outros “compartimentos” dentro do retângulo. Veja figura abaixo
(Figura 04).
Figura 4 – Diagrama de Classe
Fonte:http://www.linhadecodigo.com.br
9
.2.1.5 - ATRIBUTOS
Segundo CARDOSO (2003), os atributos possuem uma determinada por um
nome, um tipo e um valor padrão (default) que é opcional. É importante na
representação dos atributos seguir normas que facilitem a identificação.
Hensgen (2001), na UML, atributos são mostrados com pelo menos seu nome,
e podem também mostrar seu tipo, valor inicial e outras propriedades. Atributos podem
também ser exibidos com sua visibilidade:
+ indica atributos públicos
# indica atributos protegidos
- indica atributos privados
Figura 5- Atributos
Fonte:www.guiadophp.yoonix.com.br
2.2.1.6 - OPERAÇÕES
Segundo Hensgen (2001), métodos também são exibidos com pelo menos seu
nome, e podem também mostrar seus parâmetros e valores de retorno. Operações
podem, como os Atributos, mostras sua visibilidade:
+ indica operações públicas
# indica operações protegidas
- indica operações privadas
10
2.2.1.7 HERANÇA
Hensgen (2001), a herança é um dos conceitos fundamentais da programação
orientada por objetos, nos quais uma classe “ganha” todos os atributos e operações
da classe que herda, podendo sobrepor ou modificar algumas delas, assim como
adicionar mais atributos ou operações próprias.
De acordo com Hensgen (2001), UML é uma associação Generalização entre
duas classes coloca-as numa hierarquia representando o conceito de herança de uma
classe derivada de uma classe base. Em UML, Generalizações são representadas por
uma linha conectando duas classes, com uma seta no lado da classe base.
Figura 06 - Herança
Fonte:http://www.hardware.com.br
2.2.1.8 - DIAGRAMAS DE SEQUENCIA
Segundo Hensgen (2001), diagramas de sequência mostram a troca de
mensagens (isto é chamada de método) entre diversos Objetos, numa situação
específica e delimitada no tempo. Objetos são instâncias de classes. Diagramas de
Sequência colocam ênfase especial na ordem e nos momentos nos quais mensagens
para os objetos são enviadas.
Hensgen (2001), em diagramas de sequência de objetos são representados
através de linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo
é também vertical, aumentando para baixo, de modo que as mensagens são enviadas
de um Objeto para outro na forma de setas com a operação e os nomes dos
parâmetros.
11
Hensgen (2001), mensagens podem ser síncronas, o tipo normal de mensagem
de chamada onde o controle é passado para o objeto chamado até o método ter
terminado sua execução, ou assíncronas onde o controle é passado diretamente para
o objeto chamado. Mensagens síncronas possuem uma caixa vertical no lado do
objeto chamado para mostrar o controle do fluxo do programa.
Figura07- Diagrama de Sequência
Fonte: www.profissionaisti.com.br
2.3 - Rational Unified Process RUP
Segundo Martinez, RUP organiza o desenvolvimento de software em quatro fases,
onde são tratadas questões sobre planejamento, levantamento de requisitos, análise,
implementação, teste e implantação do software. Cada fase tem um papel
fundamental para que o objetivo seja cumprido, distribuídos entre vários profissionais
como o Analista de sistema, Projetista, Projetista de testes, entre outros. Veja na figura
08.
12
Figura 08 – Fases do RUP
Fonte: RUP
2.3.1 - Fase de Concepção / Iniciação
De acordo com Martinez, Esta fase do RUP abrange as tarefas
de comunicação com o cliente e planejamento. São feito um plano de projeto
avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as
prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo.
Assim, haverá uma anuência das partes interessadas na definição do escopo do
projeto, onde são examinados os objetivos para se decidir sobre a continuidade do
desenvolvimento.
2.3.2 - Fase de Elaboração
Martinez afirma que a fase de elaboração Abrange a Modelagem do modelo
genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a
análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a
arquitetura do projeto começa a ter sua forma básica. Indagações como "O plano do
projeto é confiável?", "Os custos são admissíveis?" são esclarecidas nesta etapa.
13
2.3.3 - Fase de Construção
Segundo Martinez, Desenvolve ou Adquire os componentes de Software. O
principal objetivo desta fase é a construção do sistema de software, com foco no
desenvolvimento de componentes e outros recursos do sistema. É na fase de
Construção que a maior parte de codificação ocorre.
2.3.4 - Fase de Transição
Martinez afirma que a fase de transição abrange a entrega do software ao
usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-
o disponível e compreendido pelo usuário final. As atividades desta fase incluem o
treinamento dos usuários finais e também a realização de testes da versão beta do
sistema visando garantir que o mesmo possua o nível adequado de qualidade. Veja a
baixo na figura .
Figura 09 - fases do RUP
Fonte: RUP
Sene (2011), Rational Unified Process (RUP) é um processo de engenharia de
software que fornece uma abordagem disciplinada para assumir tarefas e
responsabilidades dentro de uma organização de desenvolvimento, cujo objetivo é
assegurar a produção de software de alta qualidade dentro de prazos e orçamentos
previsíveis (Kruchten 2003, pág. 14).
14
Sene (2011), derivado dos trabalhos sobre UML e do Processo Unificado
de Desenvolvimento de Software, ele traz elementos de todos os modelos genéricos
de processo, apoia a iteração e ilustra boas práticas de especificação e projeto
(Sommervillie 2007, pág. 54).
Para Sene (2011), ele captura seis das melhores práticas no desenvolvimento
de software de forma satisfatória para uma grande faixa de projetos e organizações
(Krutchten 2003, pág. 14). As melhores práticas abordadas são as seguintes
(Sommerville 2007, pág. 56):
1. Desenvolver o software iterativamente: planejar os incrementos de software com
base nas prioridades do cliente e desenvolver e entregar o mais cedo possível às
características de sistema de maior prioridade no processo de desenvolvimento.
2. Gerenciar Requisitos: documentar explicitamente os requisitos do cliente e manter
acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças
no sistema antes de aceitá-las.
3. Usar arquiteturas baseadas em componentes: Estruturar a arquitetura do
sistema com componentes, reduzindo a quantidade de software a ser desenvolvido e,
consequentemente, reduzir custos e riscos.
4. Modelar software visualmente: usar modelos gráficos de UML para apresentar as
visões estáticas e dinâmicas do software.
5. Verificar a qualidade do software: garantir que o software atenda aos padrões de
qualidade da organização.
6. Controlar as mudanças do software: gerenciar as mudanças do software, usando
um sistema de gerenciamento de mudanças, procedimentos e ferramentas de
gerenciamento de configuração.
Para Cardoso (2003), o PRISM facilita o trabalho de arquitetura e engenharia
de software, uma vez que mostra o caminho e permite o acompanhamento do projeto
em cada fase.
15
2.4 - Ferramentas Utilizadas
2.4.1 - Hypertext Preprocessor ( PHP)
Segundo php group, php é uma linguagem de programação de ampla
utilização, interpretada, que é especialmente interessante para desenvolvimento para
a Web e pode ser mesclada dentro do código HTML. A sintaxe da linguagem lembra
C, Java e Perl, e é fácil de aprender. O objetivo principal da linguagem é permitir a
desenvolvedores escreverem páginas que serão geradas dinamicamente.
2.4.2 - Angular JS
Segundo Oliveira (Sem data), é um framework open source desenvolvido pela
Google, que liga seu HTML (views) com objetos JavaScript (models). Quando seus
modelos mudam, a página é atualizada automaticamente. Seu objetivo é aumentar
aplicativos que podem ser acessados por um navegador web, sob o padrão model–
view–controller (MVC), em um esforço para facilitar tanto o desenvolvimento quanto o
teste dos aplicativos.
2.4.3 - Atributos
De acordo com Oliveira o AngularJS lhe dá um grande número de Diretivas que
permitem a associação de elementos HTML com os Modelos. Elas são atributos que
iniciam com ng- e podem ser adicionadas a qualquer elemento. O mais importante
atributo deve incluir em qualquer página é o ng-app.
2.4.4 - Objetivos
Oliveira diz que o objetivo do AnjularJS é abstrair a manipulação
do DOM ( Document Object Model ) da lógica do aplicativo. Isto melhora os testes do
código. Considera os testes do aplicativo tão importantes quanto seu
desenvolvimento. A dificuldade do teste é diretamente afetada pela maneira como o
código é estruturado. Abstrai o acoplamento entre o lado cliente e o lado servidor da
aplicação. Isto permite que o desenvolvimento do aplicativo evolua em ambos os
lados, de forma paralela, e permite o reuso de código. Guia os desenvolvedores
16
através da construção de todo o aplicativo: desde o design de Interface, passando
pela escrita das regras de negócio, até chegar aos testes da aplicação.
2.4.5 - Mysql
Para Pacievitch, o MySQL foi criado na Suécia, por David Axmark, Allan
Larsson e o finlandês Michael Widenius. Eles começaram o projeto em 1980. O
MySQL é um SGBD, um Sistema de gerenciamento de banco de dados, que usa a
linguagem SQL como interface. É um sistema de gerenciamento de banco de
dados(SGBD), que utiliza a linguagem SQL(Structured Query Language) como
interface.
2.4.6 - Apache cordova
Segundo Costa, é um navegador sem barras de navegador e outros adereços
que permite criar apps com tecnologias web usando apenas HTML, Java script e CSS.
2.4.7 - JAVA SCRIPT
De acordo com o site Darifo (sem data), é uma linguagem de
programação interpretada. Foi originalmente implementada como parte
dos navegadores web para que scripts pudessem ser executados do lado do cliente e
interagisse com o usuário sem a necessidade de este script passar pelo servidor,
controlando o navegador, realizando comunicação assíncrona e alterando o conteúdo
do documento exibido. É atualmente a principal linguagem para programação client-
side em navegadores web. Começa também a ser bastante utilizada do lado do
servidor através de ambientes como o node.js. Foi concebida para ser uma linguagem
script com orientação a objetos baseada em protótipos, tipagem fraca e dinâmica e
funções de primeira classe. Possui suporte à programação funcional e apresenta
recursos como fechamentos e funções de alta ordem comumente indisponíveis em
linguagens populares como Java e C++.
17
CAPITULO III – ANÁLISE E DOCUMENTAÇÃO DO SISTEMA
3 - DOCUMENTO DE VISÃO
3.1 - INTRODUÇÃO
Esse documento tem como objetivo fornecer uma visão geral do sistema Minha
Igreja, detalhando como serão suas funcionalidades.
3.1.1 - Finalidade
A finalidade deste documento é coletar, analisar e definir as características e
necessidades de alto nível do Sistema Minha Igreja. Ele se concentra nos recursos
necessários aos envolvidos e aos usuários-alvo e nas razões que levam a essas
necessidades. O detalhe de como o Minha Igreja atinge essas necessidades são
descritos no caso de uso e nas especificações suplementares.
3.1.2 - Escopo do documento
Esse documento de visão faz referência ao Sistema de Gerenciamento de
Igrejas Minha Igreja. A função do Minha Igreja é automatizar o processo de
administração da empresa.
3.1.3 - Visão Geral
Nas próximas seções será apresentado o escopo da empresa e produto em
desenvolvimento.
3.2 - Posicionamento
3.2.1 - Descrição da Empresa
A instituição Primeira Igreja Batista Independente de Samambaia é uma
instituição religiosa que segue o protestantismo. É ligada à convenção das Igrejas
Batista Independente do Brasil- CIBI, está sediada na QN 504 conjunto 06, lote 02,
Samambaia-Sul, Brasília Distrito Federal, desde o ano de 1991. É composta por,
aproximadamente, 150 membros. O corpo administrativo da instituição é formado por
presidente e vice-presidente, tesoureiro e vice-tesoureiro, presidente de patrimônio,
secretaria, e lideres de departamentos. O corpo administrativo tem a função de manter
a igreja funcionando, pois mesmo se tratando de uma instituição religiosa, a mesma
possui entrada, controle de receitas e despesas e controle de membros controle de
departamentos. A instituição é dividida em nove departamentos:
18
I. Jovens
II. Senhoras
III. Crianças
IV. Louvor
V. Diáconos
VI. Adolescentes
VII. Adultos
VIII. EBD
IX. Missões
Cada departamento possui seu líder, que tem a responsabilidade de
administrar as informações administrativas, finanças, recursos humanos e patrimônios
do seu departamento.
3.3 - Oportunidade de Negócios
A instituição religiosa descrita ainda não possui um sistema automatizado para
gerenciar suas informações. O controle é feito por fichas e tabelas no Excel que
contém: dados cadastrais, eclesiásticos de membros congregados e obreiros,
visitantes. A automatização desses processos por meio do Minha Igreja trará
praticidade para a empresa, e facilitara o processo administrativo dos líderes que
poderão, através do sistema, fazer todo o controle de seu departamento.
3.3.1 - Descrição do Problema
Quadro 1 – Descrição do Problema
O problema de Perda de dados, dificuldade em encontrar fichas
cadastrais.
Afeta Líderes e liderados
Cujo impacto é Dificuldade no processo de gestão da instituição
Uma boa solução seria Implantação de um sistema que gerencie a
instituição, visando facilitar a gestão da empresa.
19
3.3.2 - Sentença de Posição do Produto
Quadro 2 – Sentença de Posição do Produto
Para Pastores e líderes da instituição
Quem Primeira Igreja Batista Independente
O Minha Igreja É um software
Que Agiliza e automatiza a administração.
Diferente do Estado atual que o controle é feito através de planilha e
fichas.
Nosso produto Automatiza a gestão da instituição.
3.3.3 - Escopo do Produto
O sistema será interligados nos ambientes web e Mobile. O sistema tem como
objetivo o gerenciamento de instituições religiosas nas áreas administrativa,
financeira, recursos humanos, patrimonial e atividades internas. Será disponibilizado
para os usuários uma aplicação mobile, possibilitando o acesso a informações tais
como: relatórios, eventos, avisos alteração de dados cadastrais, envio de mensagem
para outros membros e para a própria igreja. O aplicativo MI (Minha Igreja) é uma
aplicação gratuita e completa para o gerenciamento de instituições religiosas.
3.4 - Descrições dos Envolvidos e dos Clientes
3.4.1 - Demografias do Mercado
O mercado-alvo desse sistema compreende um segmento de instituições
religiosas que adotam o protestantismo como religião. O mercado a ser atendidos é
composto de administradores da instituição que serão os usuários do sistema (líderes,
pastor, secretarias, tesoureiros e presidente de patrimônio).
20
3.4.2 - Resumo dos Envolvidos
Quadro 03 – Resumo dos Envolvidos
Nome Descrição Responsabilidades
Pastor presidente Principal usuário do
sistema. Tem acesso a
todos os níveis
Controlar dados cadastrais de
membros, controle de receitas
e despesas.
Vice-presidente Usuário secundário do
sistema tem acesso a
todos os níveis do sistema
Controlar dados cadastrais de
membros, controle de receitas
e despesas.
Tesoureiro e vice-
Tesoureiro
Usuário do nível de
tesouraria
Controlar as receitas e
despesas da instituição.
Presidente de
patrimônio
Usuário do nível de
patrimônio
Controlar entradas e saídas de
patrimônios da instituição
Secretaria e vice-
Secretaria
Usuário do nível
administrativo
Administrar a parte de
secretariado, controlar o
cadastro de membros.
3.4.3 - Resumo dos Clientes
Quadro 4 – Resumo dos Clientes
Nome Descrição Responsabilidades Envolvido
Pastor presidente
É o responsável geral do sistema
Cadastrar novos membros, alterar nível de acesso de usuários.
Auto-representado
Vice-presidente Responsável secundário do sistema
Cadastrar novos membros, alterar nível de acesso de usuários na ausência do presidente.
Auto-representado
Presidente de patrimônio
Responsável por zelar por todo patrimônio da instituição
Cadastro de patrimônios da instituição, controle
Pastor presidente ou vice-presidente
21
de entrada e saída de patrimônio.
Secretaria e vice- secretaria
Responsável por todos os dados cadastrais de membros congregados e corpo administrativo.
Incluir, excluir e alterar dados cadastrais de membros e congregados. Atualizar ata da instituição.
Pastor presidente ou vice-presidente
Tesoureiro e vice- tesoureiro
Responsável pela parte financeira da instituição
Gerar relatórios de entradas e saída de receitas da instituição.
Pastor presidente ou vice- presidente
3.4.4 - Ambiente dos Clientes
O software Minha Igreja será desenvolvido em plataforma Web e Mobile. O
controle de acesso do software será dividido em níveis de acesso. Possibilitará que a
diretoria da instituição faça o controle de cadastro, alteração, pesquisas e exclusão de
dados de membros congregados, controle de receitas, controle de patrimônio, gerar
relatórios de controle de receitas.
3.4.5 - Perfis dos Envolvidos
3.4.5.1 - Pastor Presidente
Quadro 5 – Pastor Presidente
Descrição É o responsável pela instituição com um todo.
Tipo Usuário primário
Responsabilidades É o usuário que tem a responsabilidade de controlar
todos os níveis de acessos ao sistema.
Critérios de Sucesso Capacidade de alterar níveis de acesso. Controlar
dados que entram e saem do sistema.
Envolvimento Revisor de requisitos.
Produtos Liberados Nenhum.
Comentários/Problemas Nenhum.
22
3.4.5.2 - Vice Presidente
Quadro 6 – Vice Presidente
Descrição Assume a responsabilidade da instituição na ausência
do Presidente.
Tipo Usuário primário
Responsabilidades É o usuário que tem a responsabilidade de controlar
todos os níveis de acessos ao sistema na ausência do
Presidente.
Critérios de Sucesso Capacidade de alterar níveis de acesso. Controlar
dados que entram e saem do sistema.
Envolvimento Revisor de requisitos na ausência do Presidente
Produtos Liberados Nenhum
Comentários/Problemas Nenhum
3.4.5.3 - Presidente de patrimônio
Quadro 7 – Presidente de Patrimônio
Descrição É o responsável por todo o patrimônio da instituição.
Tipo Usuário secundário
Responsabilidades É o usuário que tem a responsabilidade de controlar
entradas e saídas de patrimônio da instituição.
Critérios de Sucesso Capacidade de realizar cadastro alterar e excluir dados
de patrimônio da instituição.
Envolvimento Inserir dados no sistema
Produtos Liberados Nenhum
Comentários/Problemas Nenhum
23
3.4.5.4 - Líder de Departamento
Quadro 8 – Líder de Departamento
Descrição É o responsável pelos dados do seu departamento
Tipo Usuário secundário
Responsabilidades É o usuário que tem a responsabilidade de controlar
entrada e saída de dados de seus liderados no sistema.
Critérios de Sucesso Capacidade de realizar cadastro alterar e excluir dados
de seus liderados no sistema.
Envolvimento Inserir dados no sistema
Produtos Liberados Nenhum
Comentários/Problemas Nenhum
3.4.5.5 - Secretaria e vice
Quadro 9 – Secretaria e Vice
Descrição É o responsável pelos dados de membros da instituição
Tipo Usuário secundário.
Responsabilidades É o usuário que tem a responsabilidade de controlar
entrada e saída de dados de membros no sistema.
Critérios de Sucesso Capacidade de realizar cadastro alterar e excluir dados
de membros no sistema
Envolvimento Inserir dados no sistema
Produtos Liberados Nenhum
Comentários/Problemas Nenhum
24
3.4.5.6 - Principais Necessidades dos Envolvidos ou dos Clientes.
Quadro 10 – Necessidades dos Envolvidos ou dos Clientes
Necessidade Prioridade Preocupações Solução Atual
Soluções Propostas
Cadastrar dados
Alta Níveis de volume e tempo de resposta
Fichas de papel ou planilha Excel
Impantação de um módulo que automatize o processo de gestão.
Alterar dados Alta Níveis de volume e tempo de resposta
Fichas de papel ou planilha Excel
Impantação de um módulo que automatize o processo de gestão.
Pesquisar dados
Alta Níveis de volume e tempo de resposta
Fichas de papel ou planilha Excel
Impantação de um módulo que automatize o processo de gestão.
Excluir dados Alta Níveis de volume e tempo de resposta
Fichas de papel ou planilha Excel
Impantação de um módulo que automatize o processo de gestão.
3.5 - Alternativas e Concorrência
No Mercado existem vários sistemas que atual no seguimento do software
minha igreja, mas o MI será adaptado para a Primeira Igreja Batista Independente de
Samambaia.
3.6 - Restrições
O sistema deverá estar disponível até junho de 2015
A versão Web e a Mobile deveram compartilhar a mesma base de dados.
Usuários cadastrados no nível de acesso membro não terão acesso à versão
web, serão direcionados a página para baixar o aplicativo móbile.
A versão móbile permitirá o acesso apenas a alguns modulos da aplicação.
25
3.7 - Especificações de Requisitos
3.7.1. - ERaF MI.001
Quadro 11 – Quadro de Especificação do Requisito ER aF.001
ER aF.001 Cadastrar membro
Descrição Esse requisito tem a função de cadastrar os membros no sistema
Descrição do risco Risco Prioridade
Os dados não serem gravados no banco. Alto Alta
Usuário Envolvido Pastor presidente, vice-presidente, secretária
3.7.2 - ER aD MI.001
Quadro 12 – Quadro de Especificação do Requisito ER aD.001
3.7.2 - ER aF MI.002
Quadro 13 – Quadro de Especificação do Requisito ER aF. 002
ER aF. 002 Alterar membro
Descrição Esse requisito tem a função de alterar dados de membros da igreja.
Descrição do risco Risco Prioridade
Os dados não serem alterados com sucesso. Alto Media
Usuário Envolvido
Pastor presidente, vice-presidente e secretária.
ER aD.001 Dados cadastrar membro
Descrição Esse requisito tem a função de cadastrar nome e sobrenome, data de nascimento, nacionalidade, naturalidade, RG, CPF, endereço, telefone,sexo, estado civil, grau de escolaridade, status, e-mail, senha, e Nível de acesso , data da conversão, data do batismo dos membros, inserir foto no sistema.
Descrição do risco Risco Prioridade
Os dados não serem gravados no banco. Alto Alta
Usuário Envolvido Pastor presidente, vice-presidente, secretária.
26
3.7.3 - ER aD MI.002
Quadro 14– Quadro de Especificação do Requisito ER aD. 002
ER aD. 002 Dados alterar membro
Descrição Esse requisito tem a função de alterar nome e sobrenome, data de nascimento, nacionalidade, naturalidade, RG, CPF, endereço, telefone,sexo, estado civil, grau de escolaridade, status, e-mail, senha, e nível de acesso, data da conversão, data do batismo dos membros, alterar foto, gerar extrato de dizimo no sistema.
Descrição do risco Risco Prioridade
Os dados não serem alterados com sucesso. Baixo Alta
Usuário Envolvido Pastor presidente, vice-presidente e secretaria.
3.7.4 - ER aF MI.003
Quadro 15 – Quadro de Especificação do Requisito ER aF.003
ER aF.003 Pesquisar membro
Descrição Esse requisito tem a função pesquisar dados dos membros no sistema.
Descrição do risco Risco Prioridade
O dado pesquisado não ser encontrado Médio Médio
Usuário Envolvido Pastor presidente, vice-presidente e secretaria.
3.7.5 - ER aD MI.003
Quadro 16 – Quadro de Especificação do Requisito ER aD.003
ER aD.003 Dados pesquisar membro
Descrição Esse requisito tem a função de pesquisar nome e sobrenome, data de nascimento, nacionalidade, naturalidade, RG, CPF, endereço, telefone, sexo, estado civil, grau de escolaridade, status, e-mail, senha, e nível de acesso, data da conversão, data do batismo dos membros, pesquisar foto, gerar extrato de dizimo no sistema.
Descrição do risco Risco Prioridade
O dado pesquisado não ser encontrado Médio Médio
Usuário Envolvido Pastor presidente, vice-presidente e secretaria
27
3.7.6 - ERaF MI.004
Quadro 17 – Quadro de Especificação do Requisito ER aF.004
ER aF.004 Cadastrar sede
Descrição Esse requisito tem a função de cadastrar a sede no sistema.
Descrição do risco Risco Prioridade
Os dados não serem salvos Médio Alta
Usuário Envolvido Pastor presidente ou vice-presidente
3.7.7 - ERaD MI.004
Quadro 18 – Quadro de Especificação do Requisito ER aD. 004
ER aD.004 Cadastrar sede
Descrição Dados da sede: denominação, nome da sede, CNPJ, data fundação da congregação, endereço e telefone.
Descrição do risco Risco Prioridade
Os dados não serem salvos Alto Alta
Usuário Envolvido Pastor presidente ou vice-presidente
3.7.8 - ERaF MI.005
Quadro 19– Quadro de Especificação do Requisito ER aF. 005
ER aF.005 Cadastrar Classes da Escola Bíblica Dominical
Descrição Esse requisito tem a função de cadastrar as classes da escola bíblica dominical
Descrição do risco Risco Prioridade
Os dados não serem gravados. Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
3.7.9 - ERaD MI. 005
Quadro 20– Quadro de Especificação do Requisito ER aD. 005
ER aD.005 Cadastrar Classes da Escola Bíblica Dominical
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem gravados. Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
28
3.7.10 - ERaF MI.006
Quadro 21– Quadro de Especificação do Requisito ER aF. 006
ER aF.006 Alterar Classes da Escola Bíblica Dominical
Descrição Esse requisito tem a função de alterar o grau de instrução dos membros
Descrição do risco Risco Prioridade
Os dados não serem alterados Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
3.7.11 - ERaD MI.006
Quadro 22– Quadro de Especificação do Requisito ER aD. 006
ER aD.006 Dados Alterar Classes da Escola Bíblica Dominical
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem alterados Baixo Alto
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
3.7.1.2 - ERaF MI.007
Quadro 23– Quadro de Especificação do Requisito ER aF. 007
ER aF.007 Pesquisar Classes da Escola Bíblica Dominical
Descrição Esse requisito tem a função de pesquisar as classes da escola Bíblica dominical
Descrição do risco Risco Prioridade
A classe da escola bíblica dominical não ser encontrada
Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
3.7.13 - ERaD MI.007
Quadro 24– Quadro de Especificação do Requisito ER aD. 007
ER aD.007 Dados Pesquisar Classes da Escola Bíblica Dominical
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
A classe da escola bíblica dominical não ser encontrada
Médio Médio
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
29
3.7.14 - ERaF MI.008
Quadro 25– Quadro de Especificação do Requisito ER aF. 008
ER aF.008 Excluir Classes da Escola Bíblica Dominical
Descrição Esse requisito tem a função de excluir as class da escola bíblica dominical.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
3.7.15 - ERaF MI.008
Quadro 26– Quadro de Especificação do Requisito ER aD. 008
ER aD.008 Dados Excluir Classes da Escola Bíblica Dominical
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e secretária.
3.7.16 - ERaF MI.009
Quadro 27– Quadro de Especificação do Requisito ER aF. 009
ER aF.009 Gerar Relatório
Descrição Esse requisito tem a função de gerar relatórios financeiros.
Descrição do risco Risco Prioridade
Não encontrar nem um dado financeiro Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
3.7.17 - ERaD MI.009
Quadro 28– Quadro de Especificação do Requisito ER aD. 009
ER aD.009 Dados Gerar Relatório
Descrição Por data, por período, por data de inicio e final, por tipo.
Descrição do risco Risco Prioridade
Não encontrar nem um congregado Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
30
3.7.18 - ERaF MI.010
Quadro 29– Quadro de Especificação do Requisito ER aF. 010
ER aF.010 Cadastrar Caixa
Descrição Esse requisito tem a função de cadastrar os caixas da igreja
Descrição do risco Risco Prioridade
Os dados não serem gravados. Alto Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Tesoureiro.
3.7.19 - ERaD MI.010
Quadro 30 – Quadro de Especificação do Requisito ER aD. 010
ER aD.010 Dados Cadastrar caixa
Descrição Nome, Descrição, lançamento de entradas e lançamento de saídas
Descrição do risco Risco Prioridade
Os dados não serem gravados. Alto Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Tesoureiro.
3.7.20 - ERaF MI.011
Quadro 31– Quadro de Especificação do Requisito ER aF. 011
ER aF.011 Alterar Caixa
Descrição Esse requisito tem a função de alterar os caixas
Descrição do risco Risco Prioridade
Os dados serem alterados de forma indevida. Toda alteração o sistema deve ser registrada a data e qual usuário realizou a atualização
Alto Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Tesoureiro.
3.7.21 - ERaD MI.011
Quadro 32– Quadro de Especificação do Requisito ER aD. 011
ER aD.011 Alterar Caixa
Descrição Nome, Descrição, lançamento de entrada, lançamento de saída data da alteração.
Descrição do risco Risco Prioridade
Os dados serem alterados de forma indevida. Toda alteração o sistema deve ser registrada a data e qual usuário realizou a atualização
Alto Alto
Usuário Envolvido Pastor Presidente, Vice-Presidente e Tesoureiro.
31
3.7.22 - ERaF MI.012
Quadro 33– Quadro de Especificação do Requisito ER aF. 012
ER aF.012 Pesquisar Caixa
Descrição Esse requisito tem a função de pesquisar os dados dos caixas
Descrição do risco Risco Prioridade
Os dados não serem encontrados Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Tesoureiro.
3.7.23 - ERaD MI.012
Quadro 34 – Quadro de Especificação do Requisito ER aD. 012
ER aD.012 Pesquisar Caixa
Descrição Nome, Descrição, lançamento de entrada, lançamento de saída.
Descrição do risco Risco Prioridade
Os dados não serem encontrados Médio Médio
Usuário Envolvido Pastor Presidente, Vice-Presidente e Tesoureiro.
3.7.24 - ERaF MI.013
Quadro 35 – Quadro de Especificação do Requisito ER aF. 013
ER aF.013 Cadastrar Departamentos
Descrição Esse requisito tem a função de cadastrar os departamentos da igreja
Descrição do risco Risco Prioridade
Os dados não serem gravados. Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.25 - ERaD MI.013
Quadro 36 – Quadro de Especificação do Requisito ER aD. 013
ER aD.013 Dados Departamentos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem gravados. Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
32
3.7.26 - ERaF MI.014
Quadro 37 – Quadro de Especificação do Requisito ER aF. 14
ER aF.014 Alterar Departamentos
Descrição Esse requisito tem a função de alterar os departamentos da igreja
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.27 - ERaD MI.014
Quadro 38– Quadro de Especificação do Requisito ER aD. 014
ER aD.014 Alterar Departamentos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alto
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.28 - ERaF MI.015
Quadro 39– Quadro de Especificação do Requisito ER aF. 015
ER aF.015 Pesquisar Departamentos
Descrição Esse requisito tem a função de pesquisar os departamentos
Descrição do risco Risco Prioridade
O departamento não ser encontrada Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
3.7.29 - ERaD MI.015
Quadro 40 – Quadro de Especificação do Requisito ER aD. 015
ER aD.015 Pesquisar Departamentos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
O departamento não ser encontrada Médio Médio
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
33
3.7.30 - ERaF MI.016
Quadro 41– Quadro de Especificação do Requisito ER aF. 016
ER aF.016 Excluir Departamento
Descrição Esse requisito tem a função de excluir os caixas
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.31 - ERaD MI.016
Quadro 42– Quadro de Especificação do Requisito ER aD. 016
ER aD.016 Excluir Departamento
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.32 - ERaF MI.017
Quadro 43– Quadro de Especificação do Requisito ER aF. 017
ER aF.017 Cadastrar Cargos Eclesiásticos
Descrição Esse requisito tem a função de cadastrar os cargos eclesiásticos.
Descrição do risco Risco Prioridade
Os dados não serem gravados. Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.33 - ERaD MI.017
Quadro 44 – Quadro de Especificação do Requisito ER aD. 017
ER aD.017 Cadastrar Cargos Eclesiásticos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem gravados. Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.34 - ERaF MI.018
Quadro 45 – Quadro de Especificação do Requisito ER aF. 018
ER aF.018 Alterar Cargos Eclesiásticos
Descrição Esse requisito tem a função de alterar os cargos eclesiásticos
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
34
3.7.35 - ERaD MI.018
Quadro 46– Quadro de Especificação do Requisito ER aD. 018
ER aD.018 Alterar Cargos Eclesiásticos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alto
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.36 - ERaF MI.019
Quadro 47– Quadro de Especificação do Requisito ER aF. 019
ER aF.019 Pesquisar Cargos Eclesiásticos
Descrição Esse requisito tem a função de pesquisar os cargos eclesiásticos
Descrição do risco Risco Prioridade
O cargo eclesiástico não ser encontrado Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
3.7.37 - ERaD MI.019
Quadro 48 – Quadro de Especificação do Requisito ER aD. 019
ER aD.019 Pesquisar Cargos Eclesiásticos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
O cargo eclesiástico não ser encontrada Médio Médio
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
3.7.38 - ERaF MI.020
Quadro 49– Quadro de Especificação do Requisito ER aF. 020
ER aF.020 Excluir Cargos Eclesiásticos
Descrição Esse requisito tem a função de excluir os cargos eclesiásticos
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
35
3.7.39 - ERaD MI.020
Quadro 50 – Quadro de Especificação do Requisito ER aD. 020
ER aD.020 Excluir Cargos Eclesiásticos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.40 - ERaF MI.021
Quadro 51 – Quadro de Especificação do Requisito ER aF. 021
ER aF.021 Cadastrar contas a pagar
Descrição Esse requisito tem a função de cadastrar as contas a serem pagas.
Descrição do risco Risco Prioridade
As contas não serem cadastradas Alto Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente, Tesoureiro.
3.7.41 - ERaD MI.021
Quadro 52 – Quadro de Especificação do Requisito ER aD. 021
ER aD.021 Cadastrar contas a pagar
Descrição Numero contas a pagar, número do documento, caixa, conta, fornecedor, data do documento, histórico, forma de pagamento, departamento, congregação, período de vencimento, quantidade de parcelas, data de vencimento inicial, valor da parcela, data de pagamento da última parcela, valor total.
Descrição do risco Risco Prioridade
As contas não serem cadastradas Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e Secretária.
3.7.42 - ERaF MI.022
Quadro 53 – Quadro de Especificação do Requisito ER aF. 022
ER aF.022 Alterar contas a pagar
Descrição Esse requisito tem a função de alterar as contas a serem pagas.
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e tesoureiro.
36
3.7.43 - ERaD MI.022
Quadro 54 – Quadro de Especificação do Requisito ER aD. 022
ER aD.022 Alterar contas a pagar
Descrição Numero contas a pagar, número do documento, caixa, conta, fornecedor, data do documento, histórico, forma de pagamento, departamento, congregação, período de vencimento, quantidade de parcelas, data de vencimento inicial, valor da parcela, data de pagamento da última parcela, valor total.
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e tesoureiro.
3.7.44 - ERaD MI.023
Quadro 55 – Quadro de Especificação do Requisito ER aD. 023
ER aD.023 Pesquisar contas a pagar
Descrição Esse requisito tem a função de pesquisar as contas a serem pagas.
Descrição do risco Risco Prioridade
Os dados pesquisados não serem encontrados
Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e tesoureiro,
3.7.45 - ERaD MI.023
Quadro 56– Quadro de Especificação do Requisito ER aD. 023
ER aD.023 Pesquisar contas a pagar
Descrição Numero contas a pagar, número do documento, caixa, conta, fornecedor, data do documento, histórico, forma de pagamento, departamento, congregação, período de vencimento, quantidade de parcelas, data de vencimento inicial, valor da parcela, data de pagamento da última parcela, valor total.
Descrição do risco Risco Prioridade
Os dados não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e tesoureiro.
37
3.7.46 - ERaF MI.024
Quadro 57 – Quadro de Especificação do Requisito ER aF. 024
ER aF.024 Excluir contas a pagar
Descrição Esse requisito tem a função de excluir as contas a serem pagas.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e tesoureiro.
3.7.-47 - ERaD MI.024
Quadro 58 – Quadro de Especificação do Requisito ER aD. 024
ER aD.024 Excluir contas a pagar
Descrição Numero contas a pagar, número do documento, caixa, conta, fornecedor, data do documento, histórico, forma de pagamento, departamento, congregação, período de vencimento, quantidade de parcelas, data de vencimento inicial, valor da parcela, data de pagamento da última parcela, valor total.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e tesoureiro.
3.7.48 - ERaF MI.025
Quadro 59– Quadro de Especificação do Requisito ER aF. 025
ER aF.025 Cadastrar fornecedor
Descrição Esse requisito tem a função de cadastrar os fornecedores das receitas a serem pagas.
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária.
3.7.49 - ERaD MI.025
Quadro 60 – Quadro de Especificação do Requisito ER aD. 025
ER aD.025 Cadastrar fornecedor
Descrição Nome, descrição.
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e secretária.
38
3.7.50 - ERaF MI.026
Quadro 61 – Quadro de Especificação do Requisito ER aF. 026
ER aF.026 Alterar fornecedor
Descrição Esse requisito tem a função de alterar os fornecedores.
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e secretária.
3.7.51 - ERaD MI.026
Quadro 62 – Quadro de Especificação do Requisito ER aD. 026
ER aD.026 Alterar fornecedor
Descrição Nome, descrição
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e secretária.
3.7.52 - ERaF MI.027
Quadro 63– Quadro de Especificação do Requisito ER aF. 027
ER aF.027 Pesquisar fornecedor
Descrição Esse requisito tem a função de pesquisar os fornecedores.
Descrição do risco Risco Prioridade
Os dados não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e secretária.
3.7.53 - ERaD MI.027
Quadro 64 – Quadro de Especificação do Requisito ER aD. 027
ER aD.027 Pesquisar fornecedor
Descrição Nome, descrição
Descrição do risco Risco Prioridade
Os dados não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária.
39
3.7.54 - ERaF MI.028
Quadro 65 – Quadro de Especificação do Requisito ER aF. 028
ER aF.028 Excluir fornecedor
Descrição Esse requisito tem a função de excluir os fornecedores.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e secretária.
3.7.55 - ERaD MI.028
Quadro 66 – Quadro de Especificação do Requisito ER aD. 028
ER aD.028 Excluir fornecedor
Descrição Nome, descrição.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária.
3.7.56 - ERaF MI.029
Quadro 67 – Quadro de Especificação do Requisito ER aF. 029
ER aF.029 Cadastrar Formas de Pagamentos
Descrição Esse requisito tem a função de cadastrar as formas de pagamentos
Descrição do risco Risco Prioridade
Os dados não serem gravados. Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.57 - ERaD MI.029
Quadro 68 – Quadro de Especificação do Requisito ER aD. 029
ER aD.029 Cadastrar Formas de Pagamentos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem gravados. Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
40
3.7.58 - ERaF MI.030
Quadro 69– Quadro de Especificação do Requisito ER aF. 030
ER aF.030 Alterar Formas de Pagamentos
Descrição Esse requisito tem a função de alterar as formas de pagamentos
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.59 - ERaD MI.030
Quadro 70 – Quadro de Especificação do Requisito ER aD. 030
ER aD.030 Alterar Formas de Pagamentos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alto
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.60 - ERaF MI.031
Quadro 71– Quadro de Especificação do Requisito ER aF. 031
ER aF.031 Pesquisar Formas de Pagamentos
Descrição Esse requisito tem a função de pesquisar as formas de pagamentos
Descrição do risco Risco Prioridade
A forma de pagamento não ser encontrada Baixo Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
3.7.61 - ERaD MI.031
Quadro 72 – Quadro de Especificação do Requisito ER aD. 031
ER aD.031 Pesquisar Formas de Pagamentos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
A forma de pagamento não ser encontrada Médio Médio
Usuário Envolvido Pastor Presidente, Vice-Presidente e Secretária.
41
3.7.62 - ERaF MI.032
Quadro 73– Quadro de Especificação do Requisito ER aF. 032
ER aF.032 Excluir formas de pagamentos
Descrição Esse requisito tem a função de excluir os cargos eclesiásticos
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.63 - ERaD MI.032
Quadro 74 – Quadro de Especificação do Requisito ER aD. 032
ER aD.032 Excluir formas de pagamentos
Descrição Nome, Descrição.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor Presidente, Vice-Presidente.
3.7.64 - ERaF MI.033
Quadro 75 – Quadro de Especificação do Requisito ER aF. 033
ER aF.033 Cadastrar culto
Descrição Esse requisito tem a função de cadastrar os cultos
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente e secretaria.
3.7.65 - ERaD MI.033
Quadro 76– Quadro de Especificação do Requisito ER aD. 033
ER aD.033 Cadastrar culto
Descrição Nome descrição, hora, responsável pelo culto
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente secretaria.
42
3.7.66 - ERaF MI.034
Quadro 77 – Quadro de Especificação do Requisito ER aF. 034
ER aF.034 Alterar culto
Descrição Esse requisito tem a função de alterar os cultos.
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária,
3.7.67 - ERaD MI.034
Quadro 78 – Quadro de Especificação do Requisito ER aD. 034
ER aD.034 Alterar culto
Descrição Nome descrição, hora, responsável pelo culto
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária.
3.7.68 - ERaF MI.035
Quadro 79– Quadro de Especificação do Requisito ER aF. 035
ER aF.035 Pesquisar culto
Descrição Esse requisito tem a função de pesquisar os cultos.
Descrição do risco Risco Prioridade
Os dados não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária,
3.7.69 - ERaD MI.035
Quadro 80 – Quadro de Especificação do Requisito ER aD. 035
ER aD.035 Pesquisar culto
Descrição Nome descrição, hora, responsável pelo culto
Descrição do risco Risco Prioridade
Os dados não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária.
43
3.7.70 - ERaF MI.036
Quadro 81– Quadro de Especificação do Requisito ER aF. 036
ER aF.036 Excluir culto
Descrição Esse requisito tem a função de excluir os cultos.
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária,
3.7.71 - ERaD MI.036
Quadro 82– Quadro de Especificação do Requisito ER aF. 036
ER aD.036 Excluir culto
Descrição Nome descrição, hora, responsável pelo culto
Descrição do risco Risco Prioridade
Os dados não serem excluídos Médio Alta
Usuário Envolvido Pastor presidente, vice presidente e secretária.
3.7.72 - ERaF MI.037
Quadro 83– Quadro de Especificação do Requisito ER aF. 037
ER aF.037 Cadastrar Bens
Descrição Esse requisito tem a função de cadastrar os bens
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente, Presidente patrimonial.
3.7.73 - ERaD MI.037
Quadro 84– Quadro de Especificação do Requisito ER aD. 037
ER aD.037 Dados Bens
Descrição Nome, descrição, tipo de bens, tipo de entrada de bens, tipo de saída de bens, Número Patrimonial, Tipo, Data da aquisição
Descrição do risco Risco Prioridade
Os dados não serem alterados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente, Presidente patrimonial.
44
3.7.74 - ERaF MI.038
Quadro 85– Quadro de Especificação do Requisito ER aF. 038
ER aF.038 Pesquisar Bens
Descrição Esse requisito tem a função de pesquisar os bens.
Descrição do risco Risco Prioridade
Os bens não serem encontrados Médio Alta
UsuárioEnvolvido Pastor presidente, vice-presidente, Presidente patrimonial.
3.7.75 - ERaD MI.038
Quadro 86– Quadro de Especificação do Requisito ER aD. 038
ER aD.038 Dados Bens
Descrição Nome, descrição, tipo de bens, tipo de entrada de bens, tipo de saída de bens, Número Patrimonial, Tipo, Data da aquisição.
Descrição do risco Risco Prioridade
Os bens não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente, Presidente patrimonial.
3.7.76 - ERaF MI.039
Quadro 87– Quadro de Especificação do Requisito ER aF. 039
ER aF.039 Alterar bens
Descrição Esse requisito tem a função de alterar os bens.
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente, Secretária.
3.7.77 - ERaF MI.039
Quadro 88– Quadro de Especificação do Requisito ER aF. 039
ER aD.039 Dados Bens
Descrição Nome, descrição, tipo de bens, tipo de entrada de bens, tipo de saída de bens, Número Patrimonial, Tipo, Data da aquisição.
Descrição do risco Risco Prioridade
Os bens não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente, Presidente patrimonial.
45
3.7.78 - ERaF MI.40
Quadro 89– Quadro de Especificação do Requisito ER aF. 040
ER aF.040 Excluir bens
Descrição Esse requisito tem a função de alterar os bens.
Descrição do risco Risco Prioridade
Os dados não serem cadastrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente, Secretária.
3.7.79 - ERaD MI.40
Quadro 89– Quadro de Especificação do Requisito ER aF. 040
ER aD.040 Dados Bens
Descrição Nome, descrição, tipo de bens, tipo de entrada de bens, tipo de saída de bens, Número Patrimonial, Tipo, Data da aquisição.
Descrição do risco Risco Prioridade
Os bens não serem encontrados Médio Alta
Usuário Envolvido Pastor presidente, vice-presidente, Presidente patrimonial.
3.8 - DESCRIÇÕES DOS CASOS DE USO E ATORES
3.8.1 - Caso de uso
3.8.1.1 - Manter Membro
A função de cadastrar, pesquisar e alterar dados dos membros no sistema.
3.8.1.2 - Manter Sede
Tem a função de cadastrar a sede no sistema.
3.8.1.3 - Manter classe escola bíblica dominical
Tem a função de cadastrar, pesquisar, alterar e excluir dados da classe escola bíblica dominical no sistema.
3.8.1.4 - Manter relatório
Tem a função de gerar relatórios dados da sede no sistema.
3.8.1.5 - Manter caixa
46
Tem a função de cadastrar, pesquisar e alterar dados dos caixas no sistema.
3.8.1.6 - Manter departamento
Tem a função de cadastrar, pesquisar, alterar e excluir dados do departamento no sistema.
3.8.1.7 - Manter cargos eclesiásticos
Tem a função de cadastrar, pesquisar, alterar e excluir os dados eclesiásticos no sistema.
3.8.1.8 - Manter contas a pagar
Tem a função de cadastrar, pesquisar, alterar e excluir dados de contas no sistema.
3.8.1.9 - Manter fornecedor
Tem a função de cadastrar, pesquisar, alterar e excluir dados do fornecedor no sistema.
3.8.1.10 - Manter formas de pagamento
Tem a função de cadastrar, pesquisar, alterar e excluir dados de formas de pagamento no sistema.
3.8.1.11 - Manter culto
Tem a função de cadastrar, pesquisar, alterar e excluir dados do culto no sistema.
3.8.1.12 - Manter bens
Tem a função de cadastrar, pesquisar, alterar e excluir dados dos bens no sistema.
3.9 - Descrições dos Atores
3.9.1 - Pastores presidentes
Este ator é uma pessoa que atua no sistema como ator primário, ele pode
cadastrar, pesquisar, alterar e excluir dados do sistema em qualquer nível de acesso.
3.9.2 - Vice-presidente
Este ator é uma pessoa que atua no sistema como ator secundário, ele pode
cadastrar, pesquisar, alterar e excluir dados do sistema.
3.9.3 - Secretarias
47
Este ator é uma pessoa que atua no sistema como ator secundário, ele pode
cadastrar, pesquisar, alterar e excluir dados do sistema no nível de recursos humanos.
3.9.4 - Tesoureiros
Ator é uma pessoa que atua no sistema como ator secundário, ele pode
cadastrar, pesquisar, alterar e excluir dados do sistema no nível de finanças.
3.9.5 - Presidente patrimonial
Este ator é uma pessoa que atua no sistema como ator secundário, ele pode
cadastrar, pesquisar, alterar e excluir dados do sistema no nível de patrimônio.
3.9.6 - Administradores do sistema
Este ator é uma pessoa que atua no sistema como ator primário, ele pode cadastrar,
pesquisar, alterar e excluir dados do sistema, e tem acesso e permissão para alterar
o código do sistema.
3.10 - DIAGRAMA GERAL DE CASO DE USO
Figura 01 – Diagrama de Casos de Uso geral
48
3.10.1 - DETALHAMENTO DOS CASOS DE USO
3.10.1.2 - UC 001 – Manter Membro
Figura 10 – Diagrama de Casos de Uso manter membro
Quadro 90- Fluxo de Eventos do manter membro
Nome da Use Case Manter membro
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir
membros no sistema.
Requisitos
Associados
ER aF.001, ER aD.001, ER aF.002, ER aD.002, ER
aF.003, ER aD.003.
Pré Condições O pastor presidente, vice-presidente ou secretaria está
autenticado no sistema.
Pós Condições A tela principal estar aberta, e a sede ter sido cadastrada.
Atores Pastor presidente, vice-presidente, secretária
49
Fluxo Principal
Ações Recebidas (Ator) Ações Realizadas (Sistema)
1) O ator seleciona no menu
a opção membros;
3) O ator clica na opção
cadastrar novo membro;
5) O ator insere os dados do
membro e clicar no botão
cadastrar;
7) O ator espera a resposta
do sistema de (Success ou
Error), e trata ela como o
sistema pede.
2) O sistema abre a tela membro
com a opção novo membro.
4) O sistema abre a tela que
contém os campos para inserir
os dados do Membro, nome,
sobrenome, sexo, data de
nascimento, nacionalidade,
naturalidade, estado civil, grau
de escolaridade, CPF, RG,
email, senha, status, nivel de
acesso, data conversão e data
de batismo.
6) O sistema valida os campos
obrigatórios;
6.1 Se algum campo obrigatório
não foi prenchido, o sistema
retorna uma mensagem de
error(todos os campos com “*”
são obrigatórios.);
6.2 Se todos os dados estiverem
corretos o sistema salva os
dados e retorna uma
mensagem(Cadastro realizado
com sucesso);
Fluxo Alternativo Alterar membro
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu
edição;
2) O sistema abre a drop down
com as opções de edição, Editar
Dados Pessoas.
50
3) O ator clica na opção editar
Dados Pessoas.
5) O ator altera os dados e
clica no botão Alterar Dados.
4) O sistema abre a tela com os
dados a serem alterados.
6) O sistema efetua a requisição.
6.1 Se a requisição for bem
sucedida, o sistema apresenta a
mensagem(Dados alterados
com sucesso);
6.2 Caso a requisição falhe, o
sistema apresenta a mensagem
(Não foi possivel alterar este
registro no momento).
Fluxo Alternativo pesquisar membro
Ações Recebidas Ações Realizadas
1) O ator digita o nome do
membro no campo “Buscar
Membro”
2) O sistema começa a procurar
referencia no banco de dados de
acordo com os dados que o usuario
esta digitando.
2.1 Caso encontre alguma
referência ele exibe na tabela o
usuário procurado.
Fluxo Alternativo excluir membro
Ações recebidas Ações realizadas
1) O ator clica no menu
Edição e escolhe a opção
deletar usuário.
2) O sistema pega o id do
usuário e faz um requisição
passando o id a ser deletado.
2.1 caso de erro, o sistema
exibe uma mensagem (Não
foi possivel deletar este
usuário no momento);
51
2.2 se a requisição for bem
sucedida, o sistema exibe a
mensagem(Usuário deletado
com sucesso).
3.10.1.3 - UC 002 – Manter Sede
Figura 11 – Diagrama de Casos de Uso manter sede
Quadro 91- Fluxo de Eventos do manter Sede
52
Nome da Use Case Manter sede
Descrição Tem a função de cadastrar a sede no sistema.
Requisitos
Associados
ER aF.004, ER aD.004.
Pré Condições O pastor presidente, vice presidente ou secretaria estar
autenticado no sistema
Pós Condições A tela principal está aberta
Atores Pastor presidente, vice-presidente, secretária
Fluxo Principal
Ações Recebidas (Ator) Ações Realizadas (Sistema)
1) O ator acessa o sistema.
3) O ator insere os dados da sede e clica em cadastrar sede.
2) Se o email não possuir
nenhuma sede associada, o
sistema apresenta uma
mensagem “Não existe nenhuma
sede cadastrada” O sistema abre
a tela cadastrar sede, com os
dados nome da igreja, CNPJ,
denominação, data da fundação.
4) O sistema salva os dados e
apresenta a mensagem “sede
cadastrada com sucesso!”.
4.1 – Caso a requisição não seja
bem sucedida, o sistema retorna
a mensagem(não foi possivel
cadastrar sede).
53
3.10.1.4 - UC 009 – Manter classe escola bíblica dominical
Figura 12 – Diagrama de casos de uso manter escola bíblica dominical.
Quadro 92- Fluxo de Eventos do manter E.B.D
Nome da Use Case Manter E.B.D
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir
E.B.D no sistema.
Requisitos
Associados
ER aF.005, ER aD.05, ER aF.006, ER aD.006, ER aF.007,
ER aD.007, ER aF.008, ER aD.008.
Pré Condições O pastor presidente, vice presidente ou secretaria estar
autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Pastor presidente, vice presidente, secretária
Fluxo Principal
54
Ações Recebidas (Ator) Ações Realizadas (Sistema)
1) O ator seleciona no menu a
opção escola bíblica;
3) O ator escolhe a opção
classes.
5) O ator insere os dados da
classe e clica em salvar.
2) O menu abre a opção classe.
4) O sistema abre a tela que
contém os campos contendo os
dados do Cadastro de Classe.
6) O sistema grava os dados e
apresenta a mensagem “Classe
cadastrada com sucesso.
6.1 - Caso a requisição não seja
bem sucedida, o sistema retorna
a mensagem(Não foi possivel
cadastrar classe).
Fluxo Alternativo Alterar Classe
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu
a opção escola bíblica;
3) O ator escolhe a opção
classes;
5) O ator seleciona a opção
alterar dados e clica em
alterar;
2) O menu abre a opção classe.
4) O sistema abre uma tela que
contém uma tabela com os
dados das classes e um drop
down com a opção alterar
classe.
6) o sistema grava os dados e
apresenta a mensagem “Classe
alterada com sucesso!”.
6.1 - Caso a requisição não seja
bem sucedida, o sistema retorna
a mensagem(não foi possivel
alterar dados).
Fluxo Alternativo pesquisar Classe
Ações Recebidas Ações Realizadas
55
1) O menu escola bíblica
dominical é selecionado
3) O ator insere o nome do da
classe a ser pesquisada
2) O sistema abre a tela membro
com as opção de classe e uma
caixa de texto para pesquisa
4) O sistema busca a classe e
exibe os dados da classe
pesquisada.
4.1 - Caso a requisição não seja
bem sucedida, o sistema retorna
a mensagem(Não foi possivel
encontar classe).
Fluxo Alternativo excluir classe
Ações recebidas Ações realizadas
1) O ator clica no menu
escola bíblica é
selecionado a opção
classes.
3) O ator selecionar o botão
edição e seleciona a
opção apagar esse
registro.
2) O sistema abre a tela classe.
4) O sistema abre um alert contendo a
mensagem ”Você está preste a
apagar esta classe, deseja
continuar?”
5) O ator escolhe a opção que
deseja e clica em (ok ou
cancelar)
6) O sistema apaga o registro e
exibe a mensagem”registro
apagado com sucesso!”.
6.1 - Caso a requisição não seja
bem sucedida, o sistema retorna
a mensagem(Não foi possivel
excluir registro).
56
3.10.1.5 - UC14–Manter Relatório
Figura 13 – Diagrama de Caso de Uso Manter Relatório
Quadro 93 – Fluxo de Eventos Manter Relatório
Nome da Use Case Manter relatório
Descrição Tem a função de gerar relatório.
Requisitos Associados ER aF.009 ER aD.009
Pré Condições O pastor presidente, vice presidente ou secretaria estar autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Pastor presidente, vice presidente, secretária
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas(Sistema)
1) O ator seleciona o menu
recursos central de
relatórios.
3) O ator escolhe a opção de
relatório que deseja e clica
no botão gerar relatório.
2) O sistema abre a tela da
central de relatórios.
4) O sistema gera e exibe o relatório.
4.1 Caso a requisição não seja bem sucedida, o sistema retorna a mensagem(Não foi possivel gerar relatório).
57
3.10.1.6 - UC 015– Manter Caixa
Figura 14 – Diagrama de Classe Manter Caixa
Quadro 94- Fluxo de Eventos Manter Caixa
UC 016 - Manter Departamento
Nome da Use Case Manter Caixa
Descrição Tem a função de manter caixa.
Requisitos Associados ER aF.009 ER aD.009
Pré Condições O pastor presidente, vice presidente ou tesoureiro estar autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Pastor presidente, vice presidente, tesoureiro
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas(Sistema)
1 ) O ator seleciona o menu
recursos humanos
2) O sistema abre a tela com
uma tabela listando os
caixas cadastrdos e um
58
3) O ator clica no botão “Novo
Caixa”.
5) O ator insere os dados e
clica no botão “cadastrar”.
botão no topo da “Novo
Caixa”.
4) O sistema abre a tela com as
opções para serem
preenchidas.
6) Os dados são gravados.
6.1 Caso a requisição não seja
bem suceidida, o sistema exibe
a mensagem(não foi possivel
cadastrar este caixa no
momento).
6.2 Caso a requisição tenha
sucesso, o sistema exibe a
mensagem(dados cadastrado
com sucesso).
Fluxo Alternativo Alterar caixa
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção financeiros;
2) O sistema abre a tela
financeiro
3) O ator clica em caixa. 4) o sistema exibe a tela com
os caixas já cadastrados e
uma drop down edição com
os dados alterar caixa
5) O ator clica na drop down
edição e escolhe a opção
alterar caixa.
6) O sistema exibe uma tela
com os dados a serem.
59
7) O ator insere os dados e
clica em alterar caixa.
8) O sistema salva os dados e
apresenta a mensagem
“dados alterados com
sucesso”.
8.1 Caso a requisição não
seja bem sucedida, o
sistema exibe a
mensagem(Não foi possivel
alterar este registro).
Fluxo Alternativo pesquisar caixa
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção financeiros.
2) O sistema abre a tela
financeiro com os dados já
cadastrados e uma caixa de
texto para inserir o cadastro
a ser pesquisado
3) O ator insere o nome do
caixa a ser pesquisado
4) O sistema busca o dado
procurado, e exibe os dados
do pesquisado.
4.1 - Caso a requisição não seja
bem sucedida, o sistema
retorna a mensagem(Não foi
possive encontrar registros).
60
3.10.1.7 - UC 016 – Manter Departamento
Figura 15– Diagrama de classe Manter Departamento
Quadro 95- Fluxo de Eventos Manter Departamento
Nome da Use Case Manter departamento
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir
departamentos no sistema.
Requisitos Associados ER aF.013, ER aD.013, ER aF.014, ER aD.014, ER
aF.014, ER aD.014, ER aF.015, ER aD.015.
Pré Condições O pastor presidente, vice presidente e secretaria estar
autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Pastor presidente, vice presidente, secretária
61
Fluxo Principal
Ações Recebidas (Ator) Ações Realizadas (Sistema)
1) O ator seleciona no menu a
opção financeiros;
3) O ator clica em departamento.
5)O ator clica no botão novo
departamento.
7) O ator insere os dados e clica em
cadastrar departamento.
2) O sistema abre a tela
financeiro com a opção
departamento, fornecedores,
caixa, conta, formas de
pagamento.
4) O sistema exibe a tela com
os departamentos já
cadastrados e um botão novo
departamento.
6) O sistema exibe uma tela
com os dados a serem
cadastrados nome e
descrição
8) O sistema salva os dados
e apresenta a mensagem
“dados alterados com
sucesso”.
8.1 caso a requisição não
seja bem sucedida, o sistema
exibe a mensagem(Não foi
possivel cadastrar
departamento).
Fluxo Alternativo Alterar departamento
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção financeiros;
3) O ator clica em departamento.
2) O sistema abre a tela
financeiro com a opção
departamento, fornecedores,
62
5) O ator clica na drop down edição
e escolhe a opção alterar
departamento
7) O ator insere os dados e clica em
alterar departamento.
caixa, conta, formas de
pagamento.
4) O sistema exibe a tela com
os departamento já
cadastrados e uma drop
down edição com os dados
alterar departamento apagar
registro.
6) O sistema exibe uma tela
com os dados a serem
alterados nome e descrição
8) O sistema salva os dados
e apresenta a mensagem
“dados alterados com
sucesso”.
8.1 Caso a requisição não
seja bem sucedida, o
sistema exibe a
mensagem(Não foi possivel
alterar dados).
Fluxo Alternativo pesquisar departamento
Ações Recebidas Ações Realizadas
1) O ator clica na opção financeiros;
3) O ator insere o nome do
departamento a ser pesquisado
2) O sistema abre a tela
financeiro com os dados já
cadastrados e uma
departamentos de texto para
inserir o cadastro a ser
pesquisado.
63
4) O sistema busca o dado
procurado, e exibe os dados
do pesquisado.
4.1 - Caso a requisição não
seja bem sucedida, o sistema
exibe a mensagem(Não foi
possivel encontrar
departamento).
Fluxo Alternativo excluir departamento
Ações recebidas Ações realizadas
1) O ator seleciona no menu a opção
financeiros.
3) O ator clica em departamento.
5) O ator clica na drop down edição e escolhe
a opção apagar registro.
7) O ator clica em ok.
9) Caso o ator clique em cancelar
2) O sistema abre a tela financeiro com a opção departamento, fornecedores, caixa, conta, formas de pagamento.
4) O sistema exibe a tela com os departamento já cadastrados e uma drop down edição com os dados alterar departamento apagar registro.
6) O sistema exibe uma tela com um alert “Você deseja a pagar esse registro?”
8) O sistema apresenta a mensagem
“dados excluído com sucesso”.
8.1 Caso a requisição não seja bem
sucedida, o sistema exibe a
mensagem(Não foi possivel exluir
registro).
10) O sistema retorna a pagina inicial.
64
3.10.1.8 - UC 017 - Manter cargos eclesiásticos
Figura 16 – Diagrama de Classe Manter Cargos Eclesiásticos
Quadro 96- Fluxo de Eventos cargos eclesiásticos
Nome da Use Case Manter cargos eclesiásticos
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir cargos eclesiásticos no sistema.
Requisitos Associados ER aF.017, ER aD.017, ER aF.018, ER aD.018, ER aF.019, ER aD.019, ER aF.020, ER aD.020.
Pré Condições O pastor presidente, vice presidente estar autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Pastor presidente, vice presidente
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas(Sistema)
1 ) O ator seleciona no menu a
opção financeiros;
2) O sistema abre a tela financeiro com a opção departamento, fornecedores, caixa, conta, formas de pagamento.
65
3) O ator clica em departamento.
5) O ator clica no botão novo departamento.
7) O ator insere os dados e clica em cadastrar cargos eclesiásticos.
4) O sistema exibe a tela com os departamentos já cadastrados e um botão novo departamento.
6) O sistema exibe uma tela com os dados a serem cadastrados nome e descrição
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
8.1- Caso a requisição não seja bem sucedida, o sistema exibe a mensagem(Não foi possivel cadastrar cargos eclesiásticos).
Fluxo Alternativo Alterar departamento
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu
a opção financeiros.
3) O ator clica em
departamento.
5) O ator clica na drop down
edição e escolhe a opção
alterar departamento.
7) O ator insere os dados e clica em alterar
cargos eclesiásticos.
2) O sistema abre a tela
financeiro com a opção
departamento, fornecedores,
caixa, conta, formas de
pagamento.
4) o sistema exibe a tela com os
departamento já cadastrados e
uma drop down edição com os
dados alterar departamento
apagar registro.
6) O sistema exibe uma tela com
os dados a serem alterados
nome e descrição
8) O sistema salva os dados e
apresenta a mensagem “dados
alterados com sucesso”.
8.1 – Caso a requisição não seja bem sucedida, o sistema exibe a mensagem(Não foi possivel alterar departamentos.
Fluxo Alternativo pesquisar departamento
66
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção financeiros.
3) O ator insere o nome do cargo eclesiásticos a ser pesquisado .
2) O sistema abre a tela
financeiro com os dados já
cadastrados e uma
departamentos de texto para
inserir o cadastro a ser
pesquisado.
4) O sistema busca o dado
procurado, e exibe os dados do
pesquisado.
4.1 – Caso a requisição não seja
bem sucedida, o sistema exibe a
mensagem(Não foi possivel
encontrar cargo eclesiástico).
Fluxo Alternativo excluir departamento
Ações recebidas Ações realizadas
1) O ator seleciona no menu a
opção financeiros.
3) O ator clica em departamento.
5) O ator clica na drop down edição
e escolhe a opção apagar registro
7) O ator clica em ok
9) Caso o ator clique em cancelar
2) O sistema abre a tela financeiro com a opção cargos eclesiásticos, fornecedores, caixa, conta, formas de pagamento.
4) O sistema exibe a tela com os departamento já cadastrados e uma drop down edição com os dados alterar departamento apagar registro.
6) O sistema exibe uma tela com um alert “Você deseja a pagar esse registro?”
8) O sistema apresenta a mensagem
“dados excluído com sucesso”.
8.1 – Caso a requisição não seja bem
sucedida, o sistema exibe uma
mensagem(Não foi possivel excluir
registro).
10) o sistema retorna a pagina inicial
67
Quadro17 - Fluxo de Eventos do manter cargos eclesiásticos
3.10.1.9 - UC 020–Manter contas a pagar
Figura 17 – Diagrama de caso de Uso Manter Contas a Pagar
Quadro 97 - Fluxo de Eventos do manter contas a pagar
Nome da Use Case Manter contas a pagar
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir
contas a pagar no sistema.
Requisitos Associados ER aF.021, ER aD.021, ER aF.022, ER aD.022, ER
aF.023, ER aD.023, ER aF.024, ER aD.024.
Pré Condições O pastor presidente, vice presidente ou tesoureiro estar
autenticado no sistema
Pós Condições A tela principal estar aberta
68
Atores Pastor presidente, vice presidente, tesoureiro
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas (Sistema)
1) O ator seleciona no menu a
opção financeiros;
3) O ator clica em contas.
5) O ator clica no botão nova conta.
7) O ator insere os dados e clica em cadastrar contas.
2) O sistema abre a tela financeiro com a opção departamento, fornecedores, caixa, conta, formas de pagamento.
4) o sistema exibe a tela com as contas já cadastradas e um botão nova conta.
6) O sistema exibe uma tela com os dados a serem cadastrados nome, saldo da conta e descrição
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
8.1 - Caso a requisição não seja bem sucedida, o sistema exibe a mensagem(Não foi possivel cadastrar esta conta).
Fluxo Alternativo Alterar contas
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção financeiros;
3) O ator clica em contas.
5) O ator clica na drop down
edição e escolhe a opção alterar
conta
7) O ator insere os dados e clica
em alterar conta.
2) O sistema abre a tela
financeiro com a opção
departamento, fornecedores,
caixa, conta, formas de
pagamento.
4) o sistema exibe a tela com
as contas já cadastradas e uma
drop down edição com os
dados alterar conta e apagar
registro.
6) O sistema exibe uma tela
com os dados a serem
69
alterados nome, saldo em
conta e descrição
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
8.1 – Caso a requisição não seja bem sucedida, o sistema exibe a mensagem(Não foi possivel alterar Registro).
Fluxo Alternativo pesquisar conta
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a opção
financeiros;
3) O ator insere o nome da
conta a ser pesquisada
2) O sistema abre a tela
financeiro com os dados já
cadastrados e uma caixa de
texto para inserir o cadastro a
ser pesquisado.
4) O sistema busca o dado
procurado, e exibe os dados
pesquisados.
Fluxo Alternativo excluir conta
Ações recebidas Ações realizadas
1) O pastor presidente, vice
presidente ou secretária seleciona
no menu a opção financeiros;
3) O pastor presidente, vice presidente ou
secretária clica em conta.
5) O pastor ou secretaria clica na drop
down edição e escolhe a opção apagar
registro
7) O pastor ou secretaria clica em ok
9) Caso o pastor ou secretaria
clique em cancelar
2) O sistema abre a tela financeiro com a opção departamento, fornecedores, caixa, conta, formas de pagamento.
4) o sistema exibe a tela com as contas já cadastradas e uma drop down edição com os dados alterar conta e apagar registro.
6) O sistema exibe uma tela com um alert “Você deseja a pagar esse registro?”
8) O sistema apresenta a mensagem
“dados excluído com sucesso”
10) O sistema retorna a pagina inicial
70
3.10.1.10 - UC 021–Manter fornecedor
Figura 18 – Diagrama de Caso de Uso Manter Fornecedor
Quadro 98 - Fluxo de Eventos do manter Fornecedor
Nome da Use Case Manter fornecedor
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir
contas a pagar no sistema.
Requisitos
Associados
ER aF.025, ER aD.025, ER aF.026, ER aD.026, ER
aF.027, ER aD.027, ER aF.028, ER aD.028.
Pré Condições O pastor presidente, vice presidente ou tesoureiro estar
autenticado no sistema
Pós Condições A tela principal estar aberta
71
Atores Pastor presidente, vice presidente, tesoureiro
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas (Sistema)
1)O pastor presidente, vice
presidente ou secretária
seleciona no menu a opção
financeiros;
3) o pastor presidente, vice presidente ou secretária clica em fornecedor.
5)O pastor ou secretaria clica no botão novo fornecedor.
7) o pastor ou secretaria insere os dados e clica em cadastrar fornecedor.
2) O sistema abre a tela financeiro com a opção departamento, fornecedores, caixa, conta, formas de pagamento.
4) o sistema exibe a tela com os departamentos já cadastrados e um botão novo fornecedor.
6) O sistema exibe uma tela com os dados a serem cadastrados nome razão social CNPJ e descrição
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
Fluxo Alternativo Alterar fornecedor
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção financeiros;
3) O ator clica em fornecedor.
5) O pastor ou secretaria clica
na drop down edição e
escolhe a opção alterar
fornecedor
7) O ator insere os dados e
clica em alterar fornecedor.
2) O sistema abre a tela
financeiro com a opção
departamento, fornecedores,
caixa, conta, formas de
pagamento.
4) O sistema exibe a tela com os
departamento já cadastrados e
uma drop down edição com os
dados alterar fornecedor apagar
registro.
6) O sistema exibe uma tela com
os dados a serem alterados
nome e descrição
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
8.1 - Caso a requisição não seja bem sucedida, o sistema exibe a
72
mensagem(Não foi possivel alterar Registro).
Fluxo Alternativo pesquisar fornecedor
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção financeiros;
3) O ator insere o nome do
fornecedor a ser pesquisado
2) O sistema abre a tela
financeiro com os dados já
cadastrados e uma fornecedor
de texto para inserir o cadastro
a ser pesquisado.
4) O sistema busca o dado
procurado, e exibe os dados do
pesquisado.
4.1 - Caso a requisição não seja
bem sucedida, o sistema exibe a
mensagem(Não foi possivel
encontrar fornecedor).
Fluxo Alternativo excluir fornecedor
Ações recebidas Ações realizadas
1) O ator seleciona no menu a
opção financeiros.
3) O ator clica em fornecedor.
5)O ator clica na drop down edição e
escolhe a opção apagar registro
7) O ator clica em ok.
9) Caso o pastor ou secretaria
clique em cancelar.
2) O sistema abre a tela financeiro com a opção departamento, fornecedores, caixa, conta, formas de pagamento.
4) o sistema exibe a tela com os departamento já cadastrados e uma drop down edição com os dados alterar fornecedor apagar registro.
6) O sistema exibe uma tela com um alert “Você deseja a pagar esse registro?”.
8) O sistema apresenta a mensagem
“dados excluído com sucesso”.
8.1 - Caso a requisição não seja bem
sucedida, o sistema exibe a
73
mensagem(Não foi possivel excluir
Registro).
10) o sistema retorna a pagina inicial.
3.10.1.11 - UC 020–Manter culto
Figura 19- Diagrama de Classe Manter Culto
Quadro 99 - Fluxo de Eventos do manter culto
Nome da Use Case Manter culto
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir
culto no sistema.
74
Requisitos Associados ER aF.033, ER aD.033, ER aF.034, ER aD.034, ER
aF.035, ER aD.035, ER aF.036, ER aD.036.
Pré Condições O pastor presidente, vice presidente ou secretária
estar autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Pastor presidente, vice presidente, secretária
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas (Sistema)
1) O ator seleciona no menu a
opção secretaria.
3) O ator clica em culto.
5)O ator clica no botão novo culto.
7) o pastor ou secretaria insere os dados e clica em cadastrar culto.
2) O sistema abre a tela secretaria com a opções membro e culto.
4) o sistema exibe a tela com os culto já cadastrados e um botão novo culto.
6) O sistema exibe uma tela com os dados a serem cadastrados nome, dia, horário e descrição
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”
Fluxo Alternativo Alterar culto
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção secretaria;
3) O pastor presidente, vice
presidente ou secretária clica em
culto.
5) O ator clica na drop down
edição e escolhe a opção alterar
culto
7) O ator insere os dados e clica
em alterar culto.
2) O sistema abre a tela
financeiro com as opções
membro e culto
4) o sistema exibe a tela com
os departamento já
cadastrados e uma drop
down edição com os dados
alterar culto apagar registro.
6) O sistema exibe uma tela
com os dados a serem
alterados nome, dia, horário
e descrição
75
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
8.1- Caso a requisição não seja bem sucedida, o sistema exibe a mensagem(Não foi possivel alterar Registro).
Fluxo Alternativo pesquisar culto
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a opção
secretaria.
3) O ator insere o nome do culto
a ser pesquisado.
2) O sistema abre a tela
financeiro com os dados já
cadastrados e uma caixa de
texto para inserir o cadastro
a ser pesquisado.
4) O sistema busca o dado
procurado, e exibe os dados
do pesquisado.
4.1 - Caso a requisição não
seja bem sucedida, o sistema
exibe a mensagem(Não foi
possivel encontrar culto).
Fluxo Alternativo excluir culto
Ações recebidas Ações realizadas
1) O ator seleciona no menu a
opção secretaria.
3) O ator clica em culto.
5) O ator clica na drop down edição e
escolhe a opção apagar registro.
7) O pastor ou secretaria clica em ok.
9) Caso o ator clique em cancelar.
2) O sistema abre a tela financeiro com as opções membro e culto.
4) O sistema exibe a tela com os cultos já cadastrados e uma drop down edição com os dados alterar culto apagar registro.
6) O sistema exibe uma tela com um alert “Você deseja a pagar esse registro?”.
8) O sistema apresenta a mensagem
“dados excluído com sucesso”.
76
8.1 - Caso a requisição não seja bem
sucedida, o sistema exibe a
mensagem(Não foi possivel excluir
Registro).
10) O sistema retorna a pagina inicial.
3.10.1.12 - UC 020–Manter bens
Figura 20 – Diagrama de Caso de uso Manter Bens
Quadro 100 - Fluxo de Eventos do manter culto
77
Nome da Use Case Manter bens
Descrição Tem a função de cadastrar, pesquisar, alterar e excluir
bens no sistema.
Requisitos Associados ER aF.037, ER aD.037, ER aF.038, ER aD.038, ER
aF.039, ER aD.039, ER aF.040, ER aD.040.
Pré Condições O pastor presidente, vice presidente ou presidente de
patrimônio estar autenticado no sistema
Pós Condições A tela principal estar aberta
Atores Pastor presidente, vice presidente, presidente de
patrimônio
Fluxo Principal
Ações Recebidas(Ator) Ações Realizadas (Sistema)
1) O ator seleciona no menu a
opção patrimonial.
3) O ator clica em bens.
5) O ator clica no botão novos bens.
7) O ator insere os dados e clica em cadastrar bens.
2) O sistema abre a tela secretaria com a opção bens.
4) o sistema exibe a tela com os bens já cadastrados e um botão novo bem.
6) O sistema exibe uma tela com os dados a serem cadastrados bens, imóveis, tipo de entrada, tipo de saída,tipo de bem.
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
8.1 - Caso a requisição não seja bem sucedida, o sistema exibe a mensagem(Não foi possivel cadastrar bem).
Fluxo Alternativo Alterar bens
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a
opção patrimonial;
3) O ator clica em bens.
2) O sistema abre a tela
financeiro com a opção bens.
4) O sistema exibe a tela
com os bens já cadastrados
e uma drop down edição com
78
5) O ator clica na drop down
edição e escolhe a opção alterar
bens.
7) O ator insere os dados e clica
em alterar bens.
os dados alterar bens,
apagar registro.
6) O sistema exibe uma tela
com os dados a serem
alterados bens, imóveis, tipo
de entrada, tipo de saída,tipo
de bem.
8) O sistema salva os dados e apresenta a mensagem “dados alterados com sucesso”.
8.1 - Caso a requisição não seja bem sucedida, o sistema exibe a mensagem(Não foi possivel alterar Registro).
Fluxo Alternativo pesquisar bens
Ações Recebidas Ações Realizadas
1) O ator seleciona no menu a opção
patrimonial;
3) O ator insere o nome do bem
a ser pesquisado
2) O sistema abre a tela
patrimonial com os dados já
cadastrados e uma caixa de
texto para inserir o cadastro
a ser pesquisado.
4) O sistema busca o dado
procurado, e exibe os dados
do pesquisado.
4.1 - Caso a requisição não
seja bem sucedida, o sistema
exibe a mensagem(Não foi
possivel encontrar bem).
Fluxo Alternativo excluir bens
Ações recebidas Ações realizadas
79
1) O ator seleciona no menu a
opção patrimonial.
3) O ator clica em bens.
5) O ator clica na drop down edição e
escolhe a opção apagar registro
7) O ator clica em ok ou em cancelar.
2) O sistema abre a tela financeiro com a opção bens
4) o sistema exibe a tela com os cultos já cadastrados e uma drop down edição com os dados alterar bens e apagar registro.
6) O sistema exibe uma tela com um alert “Você deseja a pagar esse registro?”
8) O sistema apresenta a mensagem
“dados excluído com sucesso”.
8.1 - Caso a opção escolhida seja
cancelar, o sistema retorna a
mensagem(Operação cancelada).
9) O sistema retorna a página inicial.
80
3.11 - Diagrama de Classe
Figura 21- Diagrama de Classe
81
3.12 - Diagrama de Entidade Relacional
Figura 22 – Diagrama de Entidade Relacional
82
3.13 - Diagrama de sequência
3.13.1 - Diagrama de sequência autenticação
Figura 23 – Diagrama de sequência autenticação
83
3.13.2 Diagrama de Sequência Manter Membro
Figura 24- Diagrama de Sequência Manter Membro
84
3.13.3 - Diagrama de Sequência Manter Bens
Figura 25 – Diagrama de Sequência Manter Bens
85
3.13.4 - Diagrama de Sequência Manter Caixa
Figura 26 – Diagrama de Sequência Manter Caixa
86
3.13.5 - Diagrama de Sequência Manter Cargos
Figura 27 – Diagrama de Sequência Manter Cargos
87
3.13.6 - Diagrama de Sequencia Manter Classe
Figura 28– Diagrama de Sequêcia Manter Classe
88
3.13.7 - Diagrama de Sequencia Manter conta
Figura 29- Diagrama de Sequência Manter Conta
89
3.13.8 - Diagrama de Sequência Manter Culto
Figura 30– Diagrama de Sequencia Manter Culto
90
3.13.9 - Diagrama de Sequência Manter Departamento
Figura 31 - Diagrama de Sequencia Manter Departamento
91
3.13.10 - Diagrama de Sequencia manter formas de pagamento
Figura 32 - Diagrama de Sequencia Manter Formas de Pagamento
92
3.13.11 - Diagrama de sequencia manter fornecedor
Figura 33– Diagrama de sequencia manter fornecedor
93
3.13.12 - Diagrama de SequÊncia Manter Funcionário
Figura 34 – Diagrama de Sequencia Manter Funcionário
94
CAPITULO IV – CONCLUSÃO
Para que uma empresa tenha um bom funcionamento é necessário que haja uma boa gestão. O sucesso de uma empresa está diretamente ligado a forma de como ela é administrada.
Uma boa alternativa para a melhoria da gestão de uma empresa é a automatização desse processo. Os programas de computadores são facilitadores de processos.
Para desenvolver um Software, existem processos a serem seguidos, não há como desenvolver um sistema de qualquer forma.
Todo o desenvolvimento do sistema foi desenvolvido baseado na tecnologia RUP, que deu o direcionamento de como o Software deveria ser desenvolvido e o UML foi quem deu o direcionamento de como modelar o sistema.
Em seguida foi a hora de escolher a melhor linguagem, a que melhor solucionasse nosso problema, escolhemos trabalhar com um Framework que nos últimos tempos vem ganhando espaço entre os desenvolvedores. O angularJS foi responsável pela construção do front-end da versão web e a mobile.
O Software Minha Igreja, foi desenvolvido visando facilitar o process de gestão da empresa Primeira Igreja Batista Independente de Samambaia, antes da implantação do Software, todas as informações eram armazenada em fichas de cadastro ou em planilhas do Excel, dessa forma varias vezes as mesmas eram perdidas.
A implantação do sistema Minha Igreja visa sanar os problemas enfrentados atualmente pela instituição, possibilitando que as informações sejam feitas de forma mais rápidas e seguras, minimizando assim os transtornos enfrentados por lideres e liderados da instituição.
95
4.1 - REFERÊNCIA
CARDOSO, Caíque. UML na prática: do problema ao sistema. Rio de Janeiro: Ciência Moderna, 2003.
COSTA, Igor. Apache Cordova: Mantendo a Sanidade. Disponível em:< http://www.igorcosta.com/palestras/cpbr6/phgap/#/ >Acesso em: 25 de maio de 2015.
DARINFO. Linguagem Java Script.Disponível em:< http://darinfo.com.br/linguagem-javascript/ > Acesso em: 25 de maio de 2015.
DEVMEDIA. Os 4 pilares da Programação Orientada a Objetos. Disponível em
<http://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-
objetos/9264>. Acessado em: 20 de maio de 2015.
GAMA, Marcus (2013) apud HENSGEN, PAUL, 2001:Fundamentos do UML.
Disponível em: <https://docs.kde.org/stable4/pt_BR/kdesdk/umbrello/uml-
basics.html>. Acesso em: 21 maio de 2015.
GROUP, Php. PHP. Disponível em:< http://php.net/manual/pt_BR/preface.php > Acesso em: 25 de maio de 2015.
MARTINEZ, Marina. RUP. Disponível em: < http://www.infoescola.com/engenharia-de-software/rup/ > Acesso em: 25 de maio de 2015.
OLIVEIRA, Eric. Aprenda AngularJS com estes 5 Exemplos Práticos. Disponível em:< http://javascriptbrasil.com/2013/10/23/aprenda-angularjs-com-estes-5-exemplos-praticos/ > Acesso em: 25 de maio de 2015.
RICARTE, Ivan Luiz Marques. Introdução a Orientação a objeto. Disponível em:
<http://www.dca.fee.unicamp.br/cursos/POOCPP/node4.html>. Acesso em: 20 maio
de 2015.
PACIEVITCH, Yuri. Mysql. Disponível em:http://www.infoescola.com/informatica/mysql Acesso em: 25 de maio de 2015.
SENE, Rafael Peria de. RUP – Primeiros Passos. Disponível em:
http://www.tiespecialistas.com.br/2011/02/rup-primeiros-passos Acesso em: 25 de
maio de 2015.
96
4.2 - APÊNDICE
4.2.1 - Telas do Sistema
4.2.1.1 - Tela de Autenticação
Figura 35- Tela de Autenticação
Tela exibida quando o usuário acessa a pagina web.
97
4.2.1.2 - Tela Inicial
Figura 36 – Tela Inicial
Após o usuário ser autenticado o sistema exibe essa tela com os menus de acesso e
os gráficos.
98
4.2.1.3 - Tela Cadastrar Membro
Figura 37 – Tela Cadastrar Membro
Formulário de cadastro de membros.
99
4.2.1.4 - Tela Cadastrar Cultos
Figura 38 – Cadastrar Cultos
Formulário de cadastro de Cultos.
100
4.2.1.5 - Menu de Navegação
Figura 39- Menu de Navegação
Ao ser autenticado no sistema o usuário tem acesso ao menu de navegação no
sistema.
101
4.2.1.6 - Tela de Login Mobile
Figura 40- Tela Login Mobile
Tela de acesso ao aplicativo mobile.
102
4.2.1.7 - Tela de Mensagens Aplicativo Mobile
Figura 41- Tela de Mensagem Aplicativo Mobile
Tela de visualização e envio de mensagem entre membros da instituição.
103
4.2.1.8 - Tela Feed de Notícias Mobile
Figura 42- Tela Feed de Notícias Mobile
Tela de visualisação de noticias recentes da instituição.