PIM VI - Análise e Desenvolvimento de Sitemas - Levantamento e Análise de Requisitos Sistema Venda Geek

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia 
 
 
 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E 
PRODUTOS GEEK 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIP EaD (XXXXXXXXXX) 
2022
UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E 
PRODUTOS GEEK 
 
 
 
 
 
 
 
Projeto Integrado Multidisciplinar para obtenção do 
título de graduação no Curso Superior de Tecnologia 
em Análise e Desenvolvimento de Sistemas 
apresentado à Universidade Paulista – UNIP EaD. 
 
Orientadora: Profa. XXXXXXXX 
 
 
 
 
 
 
 
UNIP EaD (XXXXXXXXXXXXX) 
2022
RESUMO 
Este projeto integrado multidisciplinar faz parte do programa pedagógico dos 
cursos superiores de tecnologia da Universidade Paulista e tem como objetivo 
fomentar a integração das disciplinas cursadas no 3º semestre deste curso de 
graduação. As disciplinas em questão são: Análise de Sistemas Orientadas a Objetos, 
Banco de Dados e Gestão Estratégica de RH. O projeto consiste em fazer 
levantamento e análise de requisitos de um sistema para controle de vendas de uma 
empresa de jogos eletrônicos, acessórios e produtos geek. Dentre as funcionalidades 
do sistema será considerado cadastro, alterações, consultas e exclusões relacionadas 
a produtos que serão vendidos na loja, bem como cadastro dos clientes. 
Neste estudo é apresentado o diagrama de classes de análise e o modelo de dados 
(MER), além de descrever os requisitos não funcionais e o contexto de uso do sistema. 
Todos esses fundamentos e conceitos serão utilizados no contexto do software em 
questão. O sistema será usado por atendentes, estoquistas e supervisores, sendo que 
os usuários terão níveis de acesso diferentes ao sistema dependendo qual deles fez 
o login. 
 
PALAVRAS CHAVE: Análise de Sistemas Orientadas a Objetos, Banco de Dados e 
Gestão Estratégica de RH. 
 
 
 
 
 
 
 
 
ABSTRACT 
This integrated multidisciplinary project is part of the pedagogical program of 
the higher education courses in technology at Universidade Paulista and aims to 
promote the integration of subjects taken in the 3rd semester of this undergraduate 
course. The subjects in question are: Object-Oriented Systems Analysis, Database 
and Strategic HR Management. The project consists of surveying and analyzing the 
requirements of a system to control the sales of a company of electronic games, 
accessories and geek products. Among the system's functionalities will be 
considered registration, changes, queries and exclusions related to products that will 
be sold in the store, as well as customer registration. 
In this study, the analysis class diagram and the data model (MER) are presented, in 
addition to describing the non-functional requirements and the context of use of the 
system. 
All these fundamentals and concepts will be used in the context of the software in 
question. The system will be used by attendants, stockists and supervisors, and 
users will have different levels of access to the system depending on which one has 
logged in. 
 
KEYWORDS: Analysis of Object Oriented Systems, Database and Strategic HR 
Management. 
 
 
 
 
 
 
 
SUMÁRIO 
INTRODUÇÃO ...................................................................................................................... 6 
1. O SISTEMA ................................................................................................................ 7 
1.1. Atores e Casos de Uso ...................................................................................... 7 
1.1.1. Atores .............................................................................................................. 7 
1.1.2. Atores do Sistema .......................................................................................... 8 
1.1.3. Casos de uso .................................................................................................. 8 
1.1.3.1. Login no Sistema ................................................................................................ 9 
1.1.3.2. Cadastrar Clientes ............................................................................................ 10 
1.1.3.3. Cadastrar Produto ............................................................................................ 11 
1.1.3.4. Consultar Produto ............................................................................................ 12 
1.1.3.5. Venda de Produtos........................................................................................... 12 
1.2. Requisitos funcionais e não funcionais ......................................................... 13 
2. BANCO DE DADOS ................................................................................................. 15 
2.1. Modelo de Entidade-Relacionamento (MER) ..................................................... 16 
2.2. Criação de Modelos Lógicos ............................................................................... 16 
CONCLUSÃO...................................................................................................................... 18 
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 19 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 
INTRODUÇÃO 
Este estudo refere-se a um levantamento e análise de requisitos de um sistema 
de controle de vendas de uma loja de jogos, acessórios e produtos geek. O objetivo 
central é aplicar os conhecimentos adquiridos com as disciplinas citadas acima para 
desenvolver um software de gerenciamento e controle de vendas exercitando as 
metodologias e técnicas de análise de sistemas orientada a objetos, explorando e 
utilizando ferramentas computacionais para modelagem de negócios, abordando as 
técnicas de artefatos UML e discutindo requisitos funcionais e não funcionais, 
usabilidade e aplicação de normas. Isso tudo fomenta o hábito de executar projetos 
envolvendo múltiplas disciplinas. 
Para contextualizar o caso vamos abordar as premissas. A empresa de produtos 
geek contratou a minha empresa para desenvolver um software de gerenciamento de 
vendas, atualmente esse meu cliente gerencia as vendas manipulando planilhas de 
excel e chegou o momento de darem um passo adiante para ter um controle mais 
assertivo e prático para as tarefas administrativas do negócio. O cliente me contratou 
para desenvolver um software para desktop para gerenciar as vendas incluindo um 
modulo de acessibilidade para que eventuais usuários portadores de deficiência 
possam utilizar o sistema normalmente. Algumas das solicitações são que o sistema 
deverá realizar os cadastros, alterações, consultas e exclusões relacionadas aos 
produtos que serão vendidos na loja, além de cadastro dos clientes, isso tudo com 
controle de acesso ao sistema com níveis de login. 
Dentre os aspectos a serem observados durante o estudo, temos que levar em 
conta o acesso ao sistema por meio de log in e senha, os produtos devem por serem 
divididos em três categorias (jogos, acessórios e produtos geek), o cadastro dos 
clientes devem possuir código, RG, CPF, nome, data do cadastro, endereço, telefone 
e e-mail. Outros requisitos no cadastro dos produtos como possuir código de barra, 
nome do produto, categoria, fabricante, quantidade e valor do produto e para jogos e 
acessórios, todos esses parâmetros deverão serem levados em conta. 
Neste estudo será apresentado o diagrama de classes de análise e o modelo de 
dados (MER), além de descrever os requisitos não funcionais e o contexto de uso do 
sistema. 
7 
 
1. O SISTEMA 
O sistema será desenvolvido para controlar o estoque e gerenciar as vendas 
de produtos da loja. O programa irá rodar em desktop e contará com um módulo de 
acessibilidade para que portadores de deficiênciaconsigam utiliza-lo. 
Dentre as funcionalidades do sistema podemos destacar: 
 Controle de acesso ao sistema com níveis de Login; 
 Cadastro de clientes; 
 Controle de estoque; 
 Cadastro de produtos por categoria 
 Alterações de produtos 
 Consultas de produtos 
 Exclusão de produtos 
 PDV para vendas dos produtos 
 
1.1. Atores e Casos de Uso 
1.1.1. Atores 
Ator é o agente que interage com o sistema, que executam o sistema. São 
usuários que utilizam o software ou até mesmo um hardware. 
Os atores têm um papel externo e são quem iniciam (e quem respondem) aos 
casos de uso, um ator representa o papel que de qualquer entidade externa, um 
indivíduo, um outro sistema, ou até um dispositivo de hardware, que interage com o 
sistema. O sistema nunca será um ator de si mesmo e também nunca é um 
componente interno do sistema ou componente de implementação dele. 
Cada ator corresponde a um papel específico: uma mesma pessoa que 
desempenha diferentes papéis nas interações com o sistema é representada por 
diferentes atores; por outro lado, diversas pessoas que desempenham o mesmo 
papel correspondem a um único ator. 
São os atores quem: 
8 
 Utilizam o sistema; 
 Inicializam o sistema; 
 Fornecem dados; 
 Usam informações do sistema; 
 
1.1.2. Atores do Sistema 
 
Os principais atores no caso do sistema em questão são: 
 Supervisor; 
 Atendente; 
 Estoquista; 
 Sistema de estoque; 
 Sistema de venda; 
 
Abaixo as interações entre os atores e o sistema: 
 Supervisor: 
-Exclui venda; 
-Cancela venda; 
-Exclui produto da venda; 
 Atendente; 
-Cadastra clientes; 
-Consulta de preços; 
-Realiza/Finaliza venda; 
 Estoquista; 
-Cadastra produto; 
 
1.1.3. Casos de uso 
 
Caso de uso é uma descrição de uma sequencia de atividades executadas por 
um agente externo ao sistema sem que sejam revelados detalhes do funcionamento 
interno ao sistema, por isso dizemos que o caso de uso mostra a visão 
comportamental externa ao sistema (BEZERRA, 2006). 
As descrições de casos de uso podem ser naturais ou numeradas, vou optar 
pela numerada, relatando o passo a passo para realização de cada atividade. 
9 
 
1.1.3.1. Login no Sistema 
A rotina Login foi desenvolvida para permitir acesso dos usuários ao 
sistema. 
Tabela 1 – Login no Sistema 
Caso de uso: Login no Sistema 
Identificação Acesso ao sistema 
Escopo Aplicativo Desktop 
Descrição do propósito Permite que o usuário acesse o sistema 
Ator primário Usuário 
Pré-condições O sistema deve estar aberto na tela de login 
Pós -condições O usuário acessa o sistema 
Fluxo normal 1- O Sistema exibe a tela solicitando o login e a senha. 
 
2- Usuário preenche os campos "Usuário" e "Senha" e pressiona "ok" 
 3- O acesso do usuário é autenticado. 
Fluxo alternativo 1- Login e senha inválido, o sistema exibe mensagem de senha inválida e volta para o passo 2 do fluxo normal. 
 
2- Esqueceu sua senha, usuário clica em "esqueceu sua 
senha?" e o sistema envia uma nova senha para o e-mail cadastrado. 
Fonte: próprio autor 
 
Figura 1 – Tela Login no sistema 
 
Fonte: próprio autor 
 
 
 
 
10 
1.1.3.2. Cadastrar Clientes 
A rotina Cadastrar Cliente foi desenvolvida para permitir a interação de 
inclusão de clientes na base de dados do sistema. 
Tabela 2 – Cadastrar Clientes 
Caso de uso: Cadastrar Clientes 
Identificação Efetuar cadastro de clientes 
Escopo Aplicativo Desktop 
Descrição do propósito Permite ao atendente cadastrar cliente no sistema 
Ator primário Atendente 
Pré-condições O sistema deve estar aberto na tela de cadastro de cliente e o atendente deve ter a senha de acesso ao sistema 
Pós -condições O sistema inclui o cliente na base de dados do sistema 
Fluxo normal 1- Será exibida pelo sistema a tela de Cadastro de Clientes. 
 
2- O atendente cadastra o cliente, nome, RG, CPF, endereço, e-mail e telefone. 
 3- O sistema exibe o aviso para salvar a inclusão. 
Fluxo alternativo 1- Cliente já cadastrado, o sistema retorna para tela principal. 
 2- Somente usuários "Atendentes" podem cadastrar clientes, o sistema volta para tela principal. 
Fonte: próprio autor 
 
Figura 2 – Tela Cadastrar Cliente 
 
Fonte: próprio autor 
 
 
 
11 
1.1.3.3. Cadastrar Produto 
A rotina Cadastrar Produto foi desenvolvida para permitir a interação de 
inclusão de produtos na base de dados do sistema. 
Tabela 3 – Cadastrar Produto 
Caso de uso: Cadastrar Produtos 
Identificação Efetuar cadastro de produtos 
Escopo Aplicativo Desktop 
Descrição do propósito Permite ao estoquista cadastrar produtos no sistema 
Ator primário Estoquista 
Pré-condições O sistema deve estar aberto na tela de cadastro de produtos e o estoquista deve ter a senha de acesso ao sistema 
Pós -condições O sistema inclui o produto na base de dados do sistema 
Fluxo normal 1- Será exibida pelo sistema a tela de Cadastro de Produtos. 
 
2- O estoquista cadastra o produto, informando o código de barras, nome do produto, categoria, fabricante, quantidade, preço do produto. 
 3- O sistema exibe o aviso para salvar a inclusão. 
Fluxo alternativo 1- Produto já cadastrado, o sistema retorna para tela principal. 
 2- Somente usuários "Estoquistas" podem cadastrar produtos, o sistema volta para tela principal. 
Fonte: próprio autor 
 
Figura 3 – Tela Cadastrar Produto 
 
Fonte: próprio autor 
 
 
 
12 
1.1.3.4. Consultar Produto 
A rotina Consultar Produto foi desenvolvida para permitir a interação de 
consulta de produtos na base de dados do sistema. 
Tabela 4 – Consultar Produto 
Caso de uso: Consultar Produtos 
Identificação Efetuar consulta de produtos 
Escopo Aplicativo Desktop 
Descrição do propósito Permite ao atendente consultar produtos no sistema 
Ator primário Atendente 
Pré-condições O sistema deve estar aberto na tela de consulta de produtos e o atendente deve ter a senha de acesso ao sistema 
Pós -condições O sistema consulta o produto na base de dados do sistema e retorna a busca na tel apara o usuário. 
Fluxo normal 1- Será exibida pelo sistema a tela de consulta de produtos. 
 
2- O atendente informa um parametro de busca (codigo de barra, categoria ou nome do produto) e clica em "buscar". 
 
3- O sistema exibe a tela de busca com o cadastro do 
produto 
Fluxo alternativo 1- Produto não encontrado, o sistema retorna para tela principal. 
Fonte: próprio autor 
 
Figura 4 – Tela Consultar Produto 
 
Fonte: próprio autor 
1.1.3.5. Venda de Produtos 
A rotina Venda de produto foi desenvolvida para permitir a interação de 
venda de produtos no sistema. 
13 
Tabela 5 – Venda de Produto 
Caso de uso: Venda de Produtos 
Identificação Realizar venda de produtos 
Escopo Aplicativo Desktop 
Descrição do propósito Permite ao atendente vender produtos no sistema 
Ator primário Atendente 
Pré-condições O sistema deve estar aberto na tela de venda de produtos e o atendente deve ter a senha de acesso ao sistema 
Pós -condições O sistema realiza a venda de um produto no sistema 
Fluxo normal 1- Será exibida pelo sistema a tela de venda de produtos. 
 
2- O atendente insere ou escaneia os produtos, e o sistema inclui no pedido de venda e finaliza a venda 
 
3- O sistema exibe a tela de perguntando a forma de 
pagamento 
 4- O cliente realiza o pagamento e é impressa a NF 
Fluxo alternativo 1- O sistema não encontra o produto e retorna a tela para inserir novo produto. 
 2- O cliente desiste da compra e o sistema solicita a senha do supervisor para efetuar o cancelamento 
 3- O supervisor insere a senha e cancela a venda 
Fonte: próprio autor 
 
Figura 5 – Tela Venda de Produto 
 
Fonte: próprio autor 
 
 
1.2. Requisitos funcionais e não funcionais 
14 
Os conceitos de requisitos funcionais e não funcionais são essenciais para o 
sucesso do software, eles representam as funções, propriedades e as possíveis 
restrições que o software precisa ter para atingir os objetivos. 
Conceitos de Requisitos Funcionais e não Funcionais: 
 Requisitos Funcionais – este requisito refere-se ao comportamento do 
software,diz respeito as entradas, processamentos e saídas que o sistema vai 
desempenhar. Os requisitos funcionais podem ser divididos em requisitos de 
negócio (requisitos referentes ao negócio/atividade em que o software será 
usado), requisitos de usuário (este diz respeito às necessidades do usuário ao 
utilizar o sistema) e requisitos técnicos (sobre as necessidades ou restrições 
técnicas). 
 Requisitos não funcionais – são os critérios que qualificam os requisitos 
funcionais, estão diretamente ligadas as restrições e qualidades especificas. 
Requisitos Funcionais do Sistema 
 O acesso ao sistema é feito na loja por meio de login e senha; 
 O estoquista cadastra os produtos que serão vendidos na loja por categorias 
(jogos, acessórios e produtos geek); 
 Os cadastros dos clientes devem possuir: código, RG, CPF, nome, data do 
cadastro, endereço, telefone e e-mail do cliente; 
 Todos os produtos devem possuir: código de barras, nome do produto, 
categoria, fabricante, quantidade e valor do produto. Para os jogos e os 
acessórios, devem ser informados em qual plataforma serão utilizados e qual o 
prazo de garantia que o produto possui; 
 A venda deverá possuir os dados do cliente e todos os produtos adquiridos e 
ser gerado um código único da venda, com a data da venda, o valor da venda, 
opções para pagamento (dinheiro/cartão), o status de pagamento e o status da 
venda; 
 O atendente poderá excluir produtos da venda caso o cliente não queira mais 
adquiri-los. Apenas o supervisor da loja poderá excluir o produto da venda, 
devendo informar um usuário e senha válidos; 
 O atendente poderá consultar os preços dos produtos caso o cliente solicite; 
15 
 A venda pode ser cancelada apenas pelo supervisor da loja, que deve 
informar usuário e senha válidos. No momento do cancelamento, o código da 
venda deve ser enviado para o sistema financeiro; 
 Deve possuir módulos de acessibilidade para que eventuais usuários 
portadores e deficiência consigam utiliza-lo; 
Requisitos Não Funcionais do Sistema 
 Funcionalidade 
 Confiabilidade 
 Usabilidade 
 Eficiência 
 Manutenibilidade 
 
2. BANCO DE DADOS 
Segundo Elmasri e Navathe (2011) um Banco de Dados é uma coleção de 
dados relacionados. Os dados são traduzidos em fatos conhecidos que podem ser 
registrados e possuem significado implícito. 
O SGBD é um fator fundamental para o sucesso do gerenciamento dos dados 
de uma empresa e deve ser considerado para o sucesso de uma organização. O 
gerenciamento do banco de dados é o bem maior no meio corporativo. Todos devem 
compreender o valor das informações e dos dados processados. 
Os dados são utilizados por pessoas diferentes, em departamentos diferente e 
por diversos motivos, sendo assim, os agentes de integração de gerenciamento se 
enquadram nos seguintes itens: 
 A interpretação e a apresentação de dados em formatos uteis, 
transformando os dados brutos em informação. 
 A distribuição de dados e informações para as pessoas certas no 
momento certo. 
 A preservação dos dados e o monitoramento de sua utilização por 
períodos adequados. 
16 
 O controle da duplicação e da utilização de dados, tanto interna como 
externa. 
 
2.1. Modelo de Entidade-Relacionamento (MER) 
Idealizado por Peter P. Chen em meados de 1976 o modelo MER foi definido 
como um processo de modelagem de dados. As técnicas de diagramação e um 
conjunto de conceitos devem ser bem entendidos para que se respeite a simbologia 
e não se cometa erros. Baseado na simplicidade e na técnica de diagramação o 
MER serve como meio de representação dos próprios conceitos de manipulação de 
dados. 
Algumas formas geométricas são utilizadas para representar as entidades, por 
exemplo, losango para representar relacionamentos, retângulo para representar 
entidades e pequenos balões para indicar os atributos que cada entidade possui. 
Abaixo segue um exemplo de modelo MER 
Figura 6 – Modelo MER 
 
Fonte: próprio autor 
2.2. Criação de Modelos Lógicos 
Para criar a sintaxe de SQL é necessário primeiro criar o modelo de banco de 
dados e as tabelas que formarão a base de dados, é importante ressaltar que com 
17 
exceção da criação de banco de dados, a maioria dos SGBDs utiliza uma SQL que 
desvia pouco do SQL padrão. A linguagem SQL padrão frequentemente é utilizada 
para representar as mais diversas funções relacionadas a banco de dados e 
programação. 
Utilizando um SGBD empresarial, antes de começar a criar tabelas, é 
necessário ser autenticado por esse sistema, isso garante que somente usuários 
registrados possam acessar o banco de dados. 
Abaixo um modelo de script SQL baseado no modelo MER. 
 
 
 
 
 
 
 
 
 
 
18 
 
 
CONCLUSÃO 
Ao apresentar este estudo e trabalhar na solução dos problemas propostos no 
PIM VI, foi possível entender melhor a maneira como as disciplinas estudadas no 
último bimestre se integram e em alguns momentos até se fundem no mesmo sentido. 
Neste trabalho foi utilizado os conhecimentos com as disciplinas de Análise de 
Sistemas Orientadas a Objetos, Banco de Dados e Gestão Estratégica de RH. 
Na disciplina de Banco de Dados foi possível passar por todas as fases do 
projeto de levantamento de necessidades, modelagem lógica e física, até a parte de 
implementação. 
Neste projeto fica claro como é importante a automatização de algumas 
ferramentas nas empresas para que se possa melhorar o atendimento aos clientes, 
agilizar o trabalho dos colaboradores e gerenciar de maneira mais assertiva os 
recursos de uma empresa. Organizando o estoque da empresa e propiciando um 
cadastro de cliente atualizado, podendo assim ser usado para múltiplos fins, desde 
um contato de pós venda até para mailing de divulgação de promoções e pesquisas 
de mercado. 
 
 
 
 
 
 
 
 
 
19 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
BEZERRA, E. Princípio de análise e projeto de sistemas com UML: um guia prático 
para modelagem de sistemas orientados a objetos através da linguagem de 
modelagem unificada. Rio de Janeiro: Campus, 2006. 
ESMARI, R; NAVATHE, S. B. Sistemas de bancos de dados: fundamentos e 
aplicações.4. ed. São Paulo: Pearson, 2011. 
Rocha, H.V.; BARANAUSKAS, M. C. C. Design e avaliação de interfaces humano-
computador. Campinas: Nied/Unicamp,2003. 
Sommerville, I. Engenharia de Software. 9 ed. São Paulo: Pearson, 2011. 
 
Figuras e Ilustrações 
As figuras e ilustração são de fonte do próprio autor.