Software de Controle de Acesso

Preparado por: Tiago Mateus Belarmino Cardoso

Aracaju, 03 de setembro de 2021

 Sistema de Controle de Acesso Projeto Integrador II

Documentação de Software Versão 2.0

Histórico de Alteração
Versão Data Autor Nota de Revisão
1.0 03/09/2021 Tiago Mateus Introdução do Projeto Descrição
1.1 04/09/2021 Tiago Mateus Descrição do Produto
1.2 05/09/2021 Tiago Mateus Requisitos Específicos
1.3 06/09/20121 Tiago Mateus Matriz da
1.4 07/09/2021 Tiago Mateus Relação dos stakeholders
1.5 08/09/2021 Tiago Mateus Gerente de projeto
2.0 09/09/20121 Tiago Mateus Analista de sistema
2.1 10/09/2021 Tiago Mateus Programador

Aracaju, 03 de setembro de 2021

 Sistema de Controle de Acesso Projeto Integrador II
Documentação de Software Versão 2.0

Sumário

1. INTRODUÇÃO.................................................................................................................................. 4
1.1 OBJETIVO DO DOCUMENTO................................................................................... ........4
1.2 VISÃO GERAL DO DOCUMENTO......................................................................................4
1.3 CONVENÇÕES, TERMOS E ABREVIAÇÕES....................................................................4
1.4 ESCOPO DO PRODUTO DE SOFTWARE.........................................................................4
2. DESCRIÇÃO GERAL........................................................................................................................4
2.1 PERSPECTIVA DO PRODUTO..........................................................................................4
2.2 FUNÇÕES DO PRODUTO..................................................................................................4
2.3 CARACTERÍSTICAS DO USUÁRIO...................................................................................5
2.4 RESTRIÇÕES.....................................................................................................................5
2.5 PRESSUPOSTOS E DEPENDÊNCIAS..............................................................................5
2.6 POSTERGAR REQUISITOS...............................................................................................5
3. REQUISITOS ESPECÍFICOS...........................................................................................................5
3.1 INTERFACES EXTERNAS..................................................................................................5
3.2 REQUISITOS FUNCIONAIS................................................................................................5
3.3 REQUISITOS NÃO FUNCIONAIS.......................................................................................6
3.4 REQUISITOS DE DOMÍNIO................................................................................................6
4. MATRIZ DE RASTREABILIDADE.................................................................................................6
5. CASOS DE USO.................................................................................................................................. 6
5.1 UC01 - NOME DO CASO DE USO......................................................................................6
6. DEMAIS DIAGRAMAS .....................................................................................................................7
7. PLANEJAMENTO DO PROJETO...................................................................................................7
8. REFERÊNCIAS.................................................................................................................................. 7
 Sistema de Controle de Acesso Projeto Integrador II
Documentação de Software Versão 2.0

1 Introdução

1.1 Objetivo do Documento

Este documento fornece uma visão abrangente do projeto sem se aprofundar nos
detalhes das iterações, que serão melhor definidas ao longo do processo de desenvolvimento.
Nele são apresentados: a metodologia de desenvolvimento, a descrição e os objetivos do
projeto, os objetivos das iterações, o cronograma e os produtos do desenvolvimento, a equipe
de desenvolvimento e o processo de homologação

1.2 Visão geral do documento

A visão geral do documento, tem por objetivo compreender o sistema que será
desenvolvido ao cliente e a todas as partes interessadas no projeto, tendo como
problema apresentado pelo cliente, a necessidade de controle de quem adentra a
empresa ou instituição, estaremos descrevendo o projeto do software através de
casos de uso, informando os colaboradores que vão interagir com sistema, para
melhor compreender o projeto que vai ser desenvolvido, estaremos também
utilizando diagrama de classe e tudo que seja necessário para melhor compreender o
projeto e por fim que o projeto atenda a necessidade do cliente, que é obter um
software de controle e informação de quem adentra a empresa ou instituição.

1.3 Convenções, termo e abreviações

RF – Requisitos Funcionais

RNF- Requisitos Não Funcionais

1.4 Escopo do produto de software

 Realização de cadastro de visitantes, com os seguintes dados; Nome, CPF, telefone e

Endereço.

 Após o cadastrado, ao consultar o sistema haverá um campo observação, onde será

informando o setor ou departamento de destino do visitante.
  Opção de relatório de busca por data, por nome e CPF, sendo ao colocar o nome ou
CPF, sistema deve informa todo o histórico do visitante.

Stakeholder Responsabilidade

– Assegurar a implantação e o alcance dos resultados do Projeto

Financiador do – Intermediar as interações com as partes envolvidas no projeto.

Projeto
– Acompanhar periodicamente o andamento do Projeto.

– Intermediar as interações para formação dos Grupos Técnicos

Coordenador do – Acompanhar periodicamente o andamento das fases do Projeto

Projeto
– Atestar a conclusão dos produtos do Projeto.

Gestor de TI. Deliberar acerca de políticas de uso e segurança dos recursos de

tecnologia da informação e da priorização das demandas efetuadas.

- Acompanhar a execução das atividades do projeto relacionadas à TI e

reportar seu andamento para o financiador do projeto.
Coordenador de TI
- Resolver junto ao Gestor do sistema os problemas que extrapolem a
responsabilidade do Gerente do projeto.

- Acompanhar a execução do projeto e reportar seu andamento para o

Coordenador do departamento de TI.
Gerente de TI
- Resolver junto ao Coordenador do TI ou ao Gestor do sistema os
problemas que extrapolem a responsabilidade do Gerente do projeto.
 Sistema de Controle de Acesso Projeto Integrador II
Documentação de Software Versão 2.0

2 Descrição Geral

2.1 Perspectiva do Produto

 O sistema deverá ser desenvolvido em módulo único;

 Geração de relatório por data, com as respectivas bases de consulta, nome e
CPF.

2.2 Funções do Produto

 Gestão de questionário individual
 Gestão de relatório de acesso
 Menu Cadastro, Consulta e relatório

2.3 Características do Usuário

Usuário Características

O sistema deve permitir ao usuário administrador, cadastrar visitante,

alterar, excluir e bloquear visitante no sistema. Criar os usuários Operador
Administrador com permissão de alterar, excluir, bloquear o mesmo.

Operador O sistema deve permitir ao usuário Operador, cadastrar visitante, alterar,

excluir e bloquear visitante no sistema.

2.4 Restrições

O sistema deverá possuir uma política de segurança para garantir que não haja acessos
sem autorização e que os dados trafeguem pela rede de maneira segura, que deverá ser
garantida através da criptografia do banco de dados.
2.5 Postergar Requisitos

Até o momento, não foram postergados requisitos. Se houver a postergação de algum

requisito, deverá ser incluída nessa seção uma explicação sobre este adiamento.
 Sistema de Controle de Acesso Projeto Integrador II
Documentação de Software Versão 2.0

3. Requisitos Específicos

Requisito Funcional 1: O sistema deve permitir ao usuário administrador a inclusão,

alteração, consulta e exclusão dos dados do usuário operador.
3.1 Requisitos Funcionais

Requisito Funcional 1: O sistema deve permitir ao usuário administrador a inclusão,

alteração, bloqueio, consulta e exclusão dos dados do usuário operador.

RF1: Perfis de usuários Estado: Proposto

Prioridade: Alta Estabilidade: Alta

Descrição: O sistema deve permitir as devidas opções dos perfis de usuário, como
descrito no item 2.3 (Característica do usuário). Para iniciar a utilização do software, o
mesmo deve ter a tela com o campo usuário e login.

Requisito Funcional 2: O sistema deve permitir ao usuário operador a consulta de

cadastro de visitante, a inclusão, alteração, consulta e exclusão dos dados do visitante.

RF2: Cadastro de Visitante Estado: Proposto

Prioridade: Alta Estabilidade: Alta

Descrição: O sistema deve permitir a manutenção dos dados do cadastro. Para o
preenchimento do cadastro é necessário que haja o cadastro de um visitante

Requisito Funcional 3: O sistema deve permitir ao usuário administrador a inclusão,

alteração, consulta e exclusão dos dados da conta usuário Operador.
RF3:Usuário Administrador Estado: Proposto

Prioridade: Alta Estabilidade: Alta

Descrição: O sistema deve permitir ao usuário administrador, a manutenção dos
dados Operador. Para o preenchimento de novos operadores.
Requisito Funcional 4: O sistema deve permitir a qualquer usuário do sistema a
visualização da origem da pesquisa que formulou o cadastramento do visitante.

RF4: Pesquisa Estado: Proposto

Prioridade: Alta Estabilidade: Alta

Descrição: O sistema deve permitir a visualização da origem da pesquisa.

Requisito Funcional 5: O sistema deve permitir a qualquer usuário do sistema a

finalização do aplicativo.
RF5: Menu Estado: Proposto

Prioridade: Alta Estabilidade: Alta

Descrição: O sistema deve permitir a finalização do aplicativo através do acionamento
de um botão.

3.2 Requisitos Não Funcionais

Requisito Não Funcional 1: O sistema deve utilizar um sistema gerenciador de bancos

de dados que possibilite a integração ao sistema a ser desenvolvido (banco de dados
interno).

RNF1: Banco de Dados Estado: Proposto

Prioridade: Alta Estabilidade: Alta

Descrição: O sistema deve utilizar um sistema gerenciador de bancos de dados que
possibilite a integração ao sistema a ser desenvolvido.

Requisito Não Funcional 2: O sistema deve possibilitar que todos os relatórios sejam
pré-visualizados antes do envio para a impressora, caso existam.
RNF2: Pré-Visualização Estado: Proposto

Prioridade: Baixa Estabilidade: Alta Desejável

Descrição: O sistema deve possibilitar que todos os relatórios sejam pré-visualizados
antes do envio para a impressora.

Requisito Não Funcional 3: O sistema deve possuir alta usabilidade, constituindo

facilidade para que os usuários aprendam a operá-lo, tempo e esforço mínimos para
que os usuários atinjam um nível aceitável de desempenho, mínimo esforço físico e
cognitivo dos usuários durante o processo de interação, disponibilização de help e
interfaces autoexplicativas e satisfação dos usuários.

RNF3: Pré-Visualização Estado: Proposto

Prioridade: Baixa Estabilidade: Alta Desejável

Descrição: O sistema deve possibilitar que todos os relatórios sejam pré-visualizados
antes do envio para a impressora.

Requisito Não Funcional 4: O sistema deve ser desenvolvido utilizando a linguagem

Java.

RNF4: Linguagem Estado: Proposto

Prioridade: Alta Estabilidade: Alta Obrigatório

Descrição: O sistema deve ser desenvolvido utilizando a linguagem Java.

Requisito Não Funcional 5: Descrição: O sistema deve ser desenvolvido utilizando

uma interface condizente com os navegadores disponíveis atualmente no mercado de
modo a facilitar a operação do aplicativo.
RNF5: Estado: Proposto

Prioridade: Alta Estabilidade: Alta Obrigatório

Descrição: O sistema deve ser desenvolvido utilizando uma interface condizente com
os navegadores disponíveis atualmente no mercado de modo a facilitar a operação do
aplicativo.

3.3 Requisitos de Domínio

Os requisitos de domínio já estão descritos, nas páginas anteriores, a descrição dos

requisitos .
 Sistema de Controle de Acesso Projeto Integrador II
Documentação de Software Versão 2.0

4. Matriz de Rastreabilidade

Requisito Funcionais X Requisitos Funcionais

RF1 RF2 RF3 RF4 RF5

RF1
RF2 X
RF3 X
RF4
RF5

Requisitos Funcionais X Requisitos Não Funcionais

RF1 RF2 RF3 RF4 RF5

RF1 X X X X X
RF2
RF3 X X X X X
RF4 X X X X X
RF5 X X X X X
 Sistema de Controle de Acesso Projeto Integrador II
Documentação de Software Versão 2.0

5. Casos de Uso

Objetivo:O caso de uso é utilizado para descrever a primeira ação do Administrador

que é a de incluir os dados dos Operadores no qual irá trabalhar. O objetivo deste caso
de uso é possibilitar o cadastramento dos visitantes, pois sem o cadastramento dos
visitantes impossibilita o acesso aos questionários gerencial e Individual.

Requisitos:
Atores (Primário e Secundário): Administrador, Operador e Desenvolvedor.

Prioridade:

Pré-condições: O usuário necessita estar logado no sistema com o perfil de operador ou

administrador e deve existir uma manifestação para a atividade ser relacionada.

Frequência de Uso:

Criticalidade:
 Visualizar a lista para questões críticas, observando suas características. Deverá
haver um filtro para que esta visualização se adeque às expectativas do usuário.

 Características da função

 A lista de questões críticas padrão que será exibida, mostrará todas as que estiverem
em aberto.

 O filtro poderá ser composto com os seguintes campos:



CPF

NOME

Usuário
Fluxo Principal: O usuário insere as informações relativas a nova atividade, O usuário
confirma o cadastro da nova atividade, a atividade é cadastrada.

Fluxo Alternativo: Não aplicável

Regras de Negócio: Os campos obrigatórios são: uma ou mais respostas de acordo

com a pergunta.
 Sistema de Controle de Acesso Projeto Integrador II
Documentação de Software Versão 2.0

6. Demais Diagrama

A figura a seguir representa os atores e os casos de uso e diagrama de classes

relacionados com cada um destes.
7. Planejamento

Este trabalho apresenta uma abordagem que apoia a definição de

objetivos do software, alinhado ao negócio da organização e a gerência desses
objetivos. A abordagem promove a monitoração contínua dos objetivos
definidos e a execução de ações apropriadas para tratar os desvios detectados,
considerando, inclusive o cenário das organizações de software de alta
maturidade. Essa abordagem contém três componentes principais: um Método
para Planejamento Estratégico, Operacional da organização de um software;
uma Infraestrutura para Monitoração dos Objetivos definidos; e uma Estratégia
para Recomendação de Ações Corretivas. O desenvolvimento da abordagem,
sua avaliação e os principais resultados obtidos são descritos.
8. Referência

SOARES, L. S. (2007). Obtenção de Requisitos para Customização de

Processo de Desenvolvimento de Software. Master’s Thesis. Universidade
Federal de Viçosa. CCE/DPI. Dissertação de Mestrado. WAZLAWICK, R. S.
Análise e Projeto de Sistemas de Informação Orientados a Objetos. Editora
Campus. Rio de Janeiro: Elsevier, 2004. PRESSMAN, R. S. (2005). Software
Engineering: A Practitioner’s Approach, volume 6. McGraw-Hill.