PIM VI - ADS

Prévia do material em texto

20
UNIVERSIDADE PAULISTA – UNIP EaD
Projeto Integrado Multidisciplinar – VI
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA PARA EMPRESA DESTINADA À VENDA DE JOGOS ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK
SÃO PAULO
2021
LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA PARA EMPRESA DESTINADA À VENDA DE JOGOS ELETRÔNICOS, ACESSÓRIOS E PRODUTOS GEEK
Trabalho para aprovação da disciplina Projeto Integrado Multidisciplinar – V do curso superior de tecnologia em Análise e Desenvolvimento de Sistemas, apresentado à Universidade Paulista – UNIP Ead.
SÃO PAULO
2021
RESUMO
Este projeto tem como objetivo realiza o levantamento de analises de requisitos de um sistema de controle de venda, para uma loja de jogos, acessórios e produtos geek. Levando como base as matérias de: analise de sistema e orientada a objeto, banco de dados e Gestão estratégica de Recursos Humanos. Com o avanço da tecnologia, o gerenciamento e a operação da loja deixou de ser apenas no papel e caneta ou até mesmo em planilha de excel, e começou a ser realizado todas as tarefas em um software. E não é só por conta da tecnologia, mas muitas vezes também por obrigações fiscais, onde é necessário enviar essas informações de vendas para o governo. A empresa fechou um contrato para desenvolvimento de um software de controle e gerenciamento de vendas, solicitando o Levantamento e a Análise de requisitos de um sistema, para que seja organizada nos cadastros, alterações, consultas e exclusões, o sistema será utilizado por atendentes, estoquistas e o supervisor da loja.
Palavras-chave – Loja, jogos, geek, desenvolvimento de software, análise de de requisitos.
ABSTRACT
This project aims to do a system documentation with requirements analysis of a sales control system, for a game store, accessories and geek products. Based on the subjects Object-Oriented System Analysis, Database and Human Resources Management. 
With the technological advances, the management and operation of the store is no longer done just with paper and pen or even on an Excel spreadsheet, and all tasks started to be performed using softwares. And it is not only due to technology, but often also due to tax obligations, where it is necessary to send this sales information to the government. The company signed a contract for the development of a software that manages and controls sales and stock also was requested a survey with system requirements analysis, such as registrations, changes, consultations and exclusions, considering that the system will be used for attendants, stockists and store supervisor.
Keywords - Shop, games, geek, software development, requirements analysis.
.
SUMÁRIO
SUMÁRIO	5
Índice de figuras	6
1	INTRODUÇÃO	7
2	MODELO ORGANIZACIONAL	8
3	CASOS DE USO	9
3.1	Modelos de casos de uso	10
4	REQUISITOS DO SISTEMA	17
4.1	Requisitos Funcionais	18
4.2	Requisitos Não-Funcionais	18
4.3	Permissões do Sistema	19
6	CONCEITUAÇÃO E MODELAGEM DO BANCO DE DADOS	20
6.1	Entidade	20
6.2	Atributos	21
6.3	Relacionamentos	21
7	CONCLUSÃO	21
8	REFERÊNCIAS BIBLIOGRÁFICAS	22
Índice de figuras
Figura 1. Diagrama de Caso de Uso.	8
Figura 2. Protótipo da tela de Login.	9
Figura 3. Protótipo da tela para cadastro de produtos.	10
Figura 4. Protótipo tela de controle de estoque	11
Figura 5. Protótipo da tela de Usuários	12
Figura 6. Protótipo da tela Consulta	13
Figura 7. Protóripo da tela Caixa.	15
Figura 8. Protótipo tela cadastro cliente.	15
1 INTRODUÇÃO
O presente trabalho pretende abordar as seguintes matérias abordadas no bimestre: Analise de Sistemas Orientada a Objeto, Banco de Dados, Gestão Estratégica de RH. E para exemplificar isso, foi feito o Levantamento de Analise de requisitos do sistema, para a loja de venda de jogos eletrônicos e produtos Geek. O sistema facilitará a interação dos atendentes e administradores com a ferramenta e consequentemente ajudando no controle de cadastros, produtos em estoques e venda, realizada por níveis de logins de atendentes, estoquistas e supervisor da loja, que através do controle de acesso permite ou não realizar determinada operação no sistema. Será abordado os casos de uso e seus relacionamentos de funcionamentos em detalhes e a justificativada escolha do sistema, o protótipo de telas com alta fidelidade para os requisitos funcionais, definido como funcionamento de cada tipo de entrada de dados, processamento ou saída de informação. Os dados construídos serão revisados conforme modelo (MER) para verificação das chaves primarias da tabela. 
2 MODELO ORGANIZACIONAL 
Independentemente do ramo de atividade, as organizações precisam ter bem estabelecido o modelo de organização. “A estrutura organizacional constitui uma cadeia de comando, ou seja, uma linha de autoridade que interliga as posições da organização e define quem se subordina a quem”. CHIAVENATO, 2004, p.85
Em nossa empresa utilizamos o modelo de organização funcional. Na equipe temos os profissionais com suas funções bem estabelecidas, as equipes são divididas por especialidades. A empresa conta com um gerente de projetos que é responsável por toda equipe de desenvolvedores e analistas. 
 A principal vantagem desse modelo é que a comunicação entre os setores é muito mais fluida e eficiente. E os colaboradores se tornam mais especializados. 
3 CASOS DE USO
Segundo Bezerra (2006, p. 45), “modelo de casos de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele”
Dessa forma, podemos imaginar que para todo sistema terá um autor, ou agentes externos, no qual ele se comunica e interage, seja um usuário ou outro sistema. Assim, se torna necessário realizar uma descrição do fluxo de atividades que seram executadas pelos agentes ao sistema.
No nosso caso, temos 4 autores definidos em nosso sistema, que são, nossos atendentes, estoquistas, supervisor e uma impressora que realizam interações para demonstração dessas interações.
Assim, foi desenhado um diagrama de caso de uso, com intuito de descrever o fluxo de atividades que cada autor executa, segue abaixo.
Figura 1. Diagrama de Caso de Uso.
No diagrama, podemos verificar cada utilidade do sistema em seu contexto e os processos que serão influenciados.
3.1 Modelos de casos de uso
Seguindo a criação dos modelos de casos, vamos aqui explicitar as principais funcionalidades e seus respectivos fluxo de atividades, bem como o protótipo da tela para maior compreensão da usabilidade do sistema. 
· Login
O detalhamento do caso de uso “Login”, descreve o fluxo de funções que o agente deve aplicar para efetua login no sistema. Nesse caso, ocorre a verificação da senha e usuário. Se algum dado estiver errado ele informa que não possível efetuar o login ao sistema.
	Descrição de caso de uso
	Identificação
	Login
	Escopo
	Efetuar login no sistema
	Propósito
	Descreve passa a passo para usuário efetuar login.
	Interessados
	Atendente, Estoquista, Supervisor
	Fluxo esperado
	1. Inicialização do sistema
	2. Usuário informa seus dados e seleciona a opção “Entrar”
	3. O sistema verifica se o nome de usuário e senha estão corretos
	4. Sistema é liberado
 
Abaixo podemos visualizar o protótipo da tela de Login.
Figura 2. Protótipo da tela de Login.
· Inserir Produto
O detalhamento do caso de uso “Inserir Produto”, descreve o fluxo de funções que o agente deve aplicar para cadastrar um produto no estoque. Nesse caso, ocorre a verificação se todos os dados necessários foram inseridos. Se algum campo obrigatório não for informado o sistema diz que não foi possível efetuar cadastro de produto.
	Descrição de caso de uso
	Identificação
	Inserir Produto
	Escopo
	Efetuar cadastro de novos produtos ou aumentar quantidade de produtos já existentes
	Propósito
	Descreve passa a passo para cadastro de produtos.
	Interessados
	Estoquista, Supervisor
	Fluxo esperado
	1. Uma vez na tela de estoque2. Usuário clica no botão Cadastrar no canto superior direito
	3. Nova tela Cadastro Produto irá abrir.
	4. O usuário preenche todos os campos com sinal de * para efetuar cadastrode novo produto ou entrada de produto já existente no estoque. 
	5. Usuário clica em salvar.
Abaixo podemos visualizar o protótipo da tela de Cadastro Produto.
Figura 3. Protótipo da tela para cadastro de produtos.
· Excluir Produto
O detalhamento do caso de uso “Excluir Produto”, descreve o fluxo de funções que o agente deve aplicar para subtrair o item do estoque
	Descrição de caso de uso
	Identificação
	Excluir Produto 
	Escopo
	Efetuar subtração de produto
	Propósito
	Descreve passa a passo para diminuir quantidade de um produto no estoque.
	Interessados
	Estoquista, Supervisor
	Fluxo esperado
	1. Uma vez na tela de estoque
	2. Usuário clica no botão editar no canto superior direito
	3. O usuário seleciona a quantidade de itens que deseja subtrair do estoque. 
	4. Sistema verificar se quantidade solicitada não deixará o estoque com saldo negativo
	5. Edição de estoque é autorizada.
Abaixo podemos visualizar o protótipo da tela Estoque.
Figura 4. Protótipo tela de controle de estoque
· Cadastro Funcionário
O detalhamento do caso de uso “Cadastro Funcionário”, descreve o fluxo de funções que o agente deve aplicar para cadastrar um no funcionário no sistema.
	Descrição de caso de uso
	Identificação
	Cadastro Funcionário
	Escopo
	Cadastrar novo usuário ao sistema
	Propósito
	Descreve passa a passo para cadastrar novo usuário.
	Interessados
	Supervisor
	Fluxo esperado
	1. Uma vez na tela de Usuários
	2. Usuário deve inserir todos os dados nos campos com o sinal *
	3. Usuário tbm seleciona campo “Status” e “Tipo” 
	4. Clica em salvar
	5. Cadastra efetuado.
Abaixo podemos visualizar o protótipo da tela Usuários para realizar cadastro de novos funcionários.
Figura 5. Protótipo da tela de Usuários
· Consultar Produto Info 
O detalhamento do caso de uso “Consultar Produto Info”, descreve o fluxo de funções que o agente deve aplicar para consultar informação de um produto.
	Descrição de caso de uso
	Identificação
	Consultar Produto Info
	Escopo
	Consultar Informação de um produto
	Propósito
	Descreve passa a passo para consulta de produto
	Interessados
	Atendente, Supervisor
	Fluxo esperado
	1. Uma vez na tela Consulta
	2. Usuário deve entrar nome ou código do produto
	3. Clicar em Buscar 
	4. Visualização de informações sobre produto requerido
Abaixo podemos visualizar o protótipo da tela Consulta.
Figura 6. Protótipo da tela Consulta
· Caixa
O detalhamento do caso de uso “Caixa”, descreve o fluxo de funções que o agente deve aplicar para realizar uma venda.
	Descrição de caso de uso
	Identificação
	Caixa
	Escopo
	Realizar Venda
	Propósito
	Descreve passa a passo para realização de venda
	Interessados
	Atendente, Supervisor
	Fluxo esperado
	1. Uma vez na tela Caixa
	2. Usuário deve entrar código de barras de produto que será vendido
	3. Uma vez que produtos forem inseridos, atendente deve conferir se produtos e quantidades inseridos estão corretas. 
	4. Uma vez com itens conferidos, clicar em Finalizar
	5. Selecionar forma de pagamento
	6. Selecionar cliente (pode buscar por nome, rg, ou telefone)
	7. Clicar em Finalizar
	8. Venda realizada com sucesso.
	Fluxo alternativo (Cliente ainda não tem cadastro)
	1. Quando cliente não tem cadastro na loja, ao clicar em Finalizar sem cliente selecionado, uma nova janela de Cadastro de Cliente abrirá.
	2. Usuário deve inserir todos os dados nos campos com o sinal * 
	3. Clica em salvar
	4. Cadastro efetuado com sucesso. Somente prosseguir com venda a partir do item 4 do fluxo esperado.
	Fluxo alternativo (Exclusão de produto ou modificação de qtd)
	1. Caso algum item tenha sido inserido erroneamente, deve-se clicar em excluir e solicitar auxilio da supervisão para ação ser aprovado
	2. Supervisor de inserir senha para aprovação de ação
	3. Remover produtos e quantidades
	4. Clicar em Finalizar
	5. Venda Realizada com sucesso
	Fluxo alternativo (Cancelamento de venda)
	1. Usuário deverá clicar em Cancelar venda e solicitar auxílio da supervisão para aprovação;
	2. Supervisor de inserir senha para aprovação de ação
	3. Venda cancelada.
Abaixo podemos visualizar o protótipo da tela Caixa, onde se inicia o processo de venda e tela de Cadastro Clientes
Figura 7. Protóripo da tela Caixa.
Figura 8. Protótipo tela cadastro cliente.
4 REQUISITOS DO SISTEMA
Os requisitos do sistema são declarações articuladas de forma clara sobre o que um sistema deve ser capaz de fazer para satisfazer as necessidades e requisitos. São definidos de duas formas bem claras, requisitos funcionais e não funcionais, os requisitos funcionais descrevem o comportamento exigido e as funções do sistema. Os requisitos não funcionais descrevem os critérios específicos que podem ser usados para avaliar o funcionamento de um Sistema. 
DESCRIÇÃO DOS REQUISITOS DO SISTEMA 
Permissões do Sistema 
Foi solicitado como requisitos do sistema permissões diferenciadas para supervisores, estoquistas e vendedores.
4.1 Requisitos Funcionais 
Cadastro de Informações
· O sistema permitirá cadastro de produtos, clientes e usuários.
Cadastro de Clientes 
· No cadastro de cliente serão os seguintes campos: RG, CPF, nome, data do cadastro, endereço, telefone, e-mail do cliente.
Cadastro de Produtos
· No cadastro de produtos serão fornecidos os seguintes campos: código de barras, nome do produto, categoria, fabricante, quantidade, valor do produto. Para os jogos e acessórios deve ser informado em qual plataforma serão utilizados e também qual o prazo de garantia do produto. O campo empresa será preenchido de acordo a filial logada, portando não é necessário informar.
Realização de Vendas 
· O sistema permitirá fazer vendas condicionais gerando código para os mesmos. 
· Em qualquer tipo de venda será obrigatório o preenchimento do cliente que está realizando a compra, e o tipo de pagamento.
· No momento de efetuar alguma venda será necessário selecionar produtos. O sistema permitirá selecionar somente produtos que estejam em estoque e disponíveis para venda e a quantidade disponível em estoque. 
· O sistema irá gerenciar o pagamento das vendas atualizando o status do pagamento e venda automaticamente, na confirmação.
· Ao ser finalizada uma venda, o(s) produto(s) vendido(s) deverá(ão) ficar indisponível para a venda e o mesmo será decrementado do valor total de unidades disponíveis. 
 
4.2 Requisitos Não-Funcionais 
· O sistema deve ter uma interface simples e com soluções intuitivas. 
As informações serão armazenadas em um Banco de Dados. 
· O sistema poderá ser acessado somente pelo supervisor do sistema, estoquista e pelos vendedores devidamente cadastradas no sistema; 
· O acesso ao sistema se dará pela informação de usuário e senha; 
· O sistema deverá ser desenvolvido na linguagem C#. 
· O sistema deverá utilizar banco de dados MySQL. 
· O acesso ao sistema deverá ser permitido apenas na rede da escola.
· O sistema deverá ser executado em S.O Windows 7, 8 e 10.
· Memória RAM, mínimo exigido 4GB.
4.3 Permissões do Sistema 
Supervisor
· Terá acesso à todas as áreas do sistema, com permissão de leitura, exclusão, inclusão e alteração. 
Vendedores
· Permissão para realizar todos os tipos de cadastros e inclusões.
· Permissão para realizar vendas.
· Permissão para consultar produtos e seu estoque; 
· Permissão para concluir vendas no sistema. 
Estoquista
· Permissão para cadastrar produto.
· Permissão para incluir e reduzir estoque do produto.
· Permissão par excluir produto.
· Permissão para alterar o produto.
 
5 MODELO ENTIDADE-RELACIONAMENTO 
O modelo ER deste sistema é formado por 19 tabelas, sendo que uma delas, a tabela de validação de usuário, que realizará a validação do tipo de usuário com os acessos permitidos no sistema. Contamos no sistema de Entidade-Relacionamento com cinco tabelas correspondes a cadastros, sendoelas: Vendedores, Clientes, e Produtos, onde cada uma possui os atributos correspondentes as informações exigidas para o seu cadastro. 
Cada uma das tabelas, com exclusão das tabelas de cadastro já mencionadas, está vinculada por chave-estrangeira a outra tabela e cada uma possui os atributos que lhe são necessários, podendo estes serem visualizados de melhor forma na imagem do modelo Entidade-Relacionamento que veremos abaixo. 
Na figura abaixo é possível observar a estrutura do modelo ER (EntidadeRelacionamento): 
Modelo Entidade-Relacionamento 
6 CONCEITUAÇÃO E MODELAGEM DO BANCO DE DADOS
Modelo de Entidade e Relacionamento (ou MER), é um modelo conceitual utilizado na Engenharia de Software para descrever objetos (entidades) dentro de um domínio de negócio. Os objetos (entidades) possuem atributos e se relacionam entre si.
Em geral este modelo representa de forma abstrata como se dará a aplicação de um banco de dados, contendo várias outras entidades e atributos fazem sentido apenas no contexto de banco de dados relacional.
6.1 Entidade
Representação de um objeto físico ou lógico dentro de um domínio. Entidades físicas são objetos tangíveis, visíveis e que de fato existem no mundo real, como produtos (mercadorias, automóveis, roupas), clientes (pessoas físicas ou empresas), etc. Entidades lógicas são objetos que se conectam às entidades físicas, porém são conceitos mais abstratos, não sendo tangíveis no mundo real, como representação de cargos e funções dentro de uma empresa, por exemplo.
6.2 Atributos
Características que descrevem as particularidades de cada entidade dentro do domínio. Podem ser categorizadas em 3 tipos. Características que descrevem a entidade de maneira intrínseca. Nominativos, como o nome sugere, têm a função de definir ou nomear aquele objeto. Por fim referencial, representa a ligação do relacionamento da entidade com outro objeto.
6.3 Relacionamentos
Relacionamentos é como se dá a ligação entre entidades, suas classificações dependem da quantidade de entidades em ambos os lados do relacionamento. Temos relacionamento “um para um” que infere que para cada entidade de um lado do relacionamento existe apenas um correspondente do outro lado. Relacionamento “um para muitos” que para cada entidade de um lado do relacionamento pode haver duas ou mais entidades que se relacionam com esta. Por fim, relacionamento “muitos para muitos” que para vários objetos podem possuir várias outras entidades que se relacionam com estes.
6.4 DER(Diagrama Entidade Relacionamento)
7 CONCLUSÃO 
Este projeto procurou atender as solicitações estabelecidas pela loja de jogos eletrônicos e produtos geek. Afim de agilizar o processo de cadastro, consulta e vendas dos produtos em sua loja. O principal foco foi desenvolver um software que seja funcional e ao mesmo tempo pratico de se usar. Partiu-se de um cenário inicial apontado pela necessidade do cliente que, pode ser interpretado como uma primeira entrevista, para posteriores elaborações de casos de uso, regras de negócio e representações em Diagramas de Classe de Domínio e Entidade e relacionamento.
8 REFERÊNCIAS BIBLIOGRÁFICAS
MANZALLI, H.F. e DITTICIO, C.. Economia e Mercado. São Paulo: Sol, 2020.
RIBEIRO, A.L..Engenharia de Software ll.São Paulo, Sol, 2015.
LOPES, H.F. e ITO, O.T..Programação Orientada a Objetos l São Paulo, Sol, 2015.
FERREIRA C.C.R, HAZAN C Uma Aplicação da Análise de Pontos de Função no Planejamento e Auditoria de Custos de Projetos de Desenvolvimento de Sistemas Rio de Janeiro, 2010
SOUZA, L.S.Projeto de Interface com o Usuário. São Paulo: Sol, 2015.
ORTH, A. I. Interface homem-máquina. Porto Alegre: AIO, 2005.
PRESSMAN, ROGER S. Engenharia de Software. McGraw-Hill, 2006. 
 5 tipos de organizações empresariais: como escolher o modelo de negócio https://www.simeon.com.br/tipos-de-organizacao-empresarial-como-escolher-o-modelo-de-negocio/ Acesso em: 29 de maio. de 2021. 
Entenda a especificação de requisitos de software em projetos. https://www.monitoratec.com.br/blog/especificacao-de-requisitos-de-software/#:~:text=A%20especifica%C3%A7%C3%A3o%20de%20requisitos%20de%20software%20%C3%A9%20a%20etapa%20do,n%C3%A3o%20pode%20ter%20(restri%C3%A7%C3%B5es). Acesso em: 29 de maio. de 2021 
Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER)
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332. Acesso em: 29 de maio. de 2021