UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar

Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PROJETO DE UM LEVANTAMENTO E ANALISE DE REQUISITOS DE UM

SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS,
ACESSÓRIOS E PRODUTOS GEEK.

Campinas
2021
PROJETO DE UM LEVANTAMENTO E ANALISE DE REQUISITOS DE UM
SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS,
ACESSORIOS E PRODUTOS GEEK.

Projeto Integrado Multidisciplinar para a

obtenção do título de graduação em
Tecnologia em Análise e Desenvolvimento
de Sistemas, apresentado à Universidade
Paulista – UNIP EaD.

Campinas
2021
RESUMO
 O projeto visa realizar pesquisas, análises de demanda e modelagem para o
desenvolvimento de sistemas que contribuam com as vendas e controle de estoque
das lojas Geek.
O uso da tecnologia tornou-se um fator importante para o sucesso da
empresa, pois os clientes estão sempre correndo para sobreviver. Seu desejo é
atender os clientes com rapidez e qualidade. Quando alguma organização não tiver
equipamentos automatizados, eles se sentirão desconfortável com a eficiência do
sistema.
Palavras-chave: Software, Controle, Compras, Vendas, Estoque e Produto.

ABSTRACT
 The project aims to conduct research, demand analysis and modeling for the
development of systems that contribute to the sales and inventory control of Geek
stores.
The use of technology has become an important factor for the success of the
company, as customers are always running to survive. His desire is to serve
customers quickly and with quality. When an organization does not have automated
equipment, they will be uncomfortable with the efficiency of the system.
Keyword: Software, Control, Purchasing, Sales, Inventory and Product.

SUMÁRIO
1. INTRODUÇÃO……........………………………..………............….……..
……….........5
2. CASOS DE USO........................................................................………..............…..6
2.1 Requisitos..................................................................................................6
2.1.1 Casos de
Uso:.........................................................................................6
2.2 Modelagem de Casos de
Uso.....................................................................7
2.2.1 Cadastro Cliente.....................................................................................7
2.2.1.1 Fluxo do
Trabalho.................................................................................7
2.2.1.2 Requisitos
Relacionados......................................................................8
2.2.2 Cadastro de
Produtos..............................................................................8
2.2.2.1 Fluxo de
Trabalho.................................................................................9
2.2.2.2 Requisitos
Relacionados......................................................................9
2.2.3 Efetuar Vendas.....................................................................................10
2.2.3.1 Fluxo de
Trabalho...............................................................................10
2.2.3.2 Requisitos
Relacionados....................................................................11
2.3 Regras de
Uso..........................................................................................12
2.3.1 Login.....................................................................................................12
2.3.2 Cadastro de
Usuario..............................................................................12
2.3.3 Cadastro de Produto.............................................................................13
2.3.4 Cancelamento de
Vendas.....................................................................13
2.4 Contexto de
Uso.......................................................................................13
 2.4.1 Usuários e
Tarefas................................................................................13
2.4.2 Ambiente...............................................................................................14
3. REQUISITOS NÃO FUNCIONAIS E FUNCIONAIS...............................................14
4. DIAGRAMA DE CLASSES DE
ANALISES.............................................................15
4.1 Diagrama de
Classes...............................................................................15
4.2 Diagrama de
Objetos................................................................................15
4.3 Classes de
Analises.................................................................................15
4.4 Modelo de Entidade-Relacionamento
(MER)...........................................16
4.4.1 Entidades, Atributos e
Relacionamentos...............................................17
5. CONCLUSÃO.........................................................................................................19
6. REFERÊNCIAS......................................................................................................20
 5

1. INTRODUÇÃO

O Projeto Integrado Multidisciplinar trata-se da criação de um sistema de

gestão de estoque e vendas para uma loja de varejo voltada para jogos eletrônicos,
acessórios e produtos Geek. O trabalho visa descrever toda pratica que envolve os
processos de análise e desenvolvimento de sistemas dentro do projeto.
O desenvolvimento desse sistema surgiu a partir da necessidade da
empresa de atender melhor seus clientes e fazer um controle mais adequado de
toda a movimentação. Foi possível verificar que todo o procedimento de vendas e
controles realizado na empresa era feito manualmente por meio de planilhas,
dificultando manter uma organização interna do estoque e das vendas, sendo que
esses controles são fundamentais para uma empresa desse ramo.
O sistema será implementado, buscando atender todas as necessidades dos
clientes cadastrados na empresa.
Logo o objetivo desse projeto e realizar a análise de negócio, identificar
quais são as regras de negócios, os requisitos funcionais e não funcionais, criar os
cenários através de ferramentas de modelagem de dados, para o sistema a ser
desenvolvido.
 6

2. CASOS DE USO

2.1 Requisitos

O sistema irá controlar o estoque dos produtos e as vendas. O acesso ao

sistema será através de login e senha com 3 níveis de acesso, Estoquista,
Atendente e Supervisor.
O Estoquista terá acesso ao cadastro de produtos, onde será possível
salvar, alterar, excluir e consultar os dados dos produtos que terão as categorias de
jogos, acessórios e produtos geek.
O Atendente por sua vez terá acesso ao cadastro de clientes podendo
também salvar, alterar, excluir e consultar os dados dos clientes e é o atendente que
realiza as vendas da loja onde constarão os dados da venda como código único,
data, valores, formas de pagamento e status de pagamento e venda, constará os
dados do cliente e os dados dos produtos.
E o Supervisor tem acesso em todo o sistema, sendo responsável pela
exclusão de um produto na venda ou o cancelamento de toda a venda utilizando
usuário e senha válidos, no cancelamento da venda o código da venda é enviado
para o sistema financeiro.
Analisando os requisitos e em vista dos modelos de mercado chegamos aos
seguintes casos de uso:

2.1.1 Casos de uso:

 RF 01 - Cadastrar cliente;
 RF 02 - Alterar cliente;
 RF 03 - Excluir cliente;
 RF 04 - Consultar cliente;
 RF 05 - Cadastrar produto;
 RF 06 - Alterar produto;
 RF 07 - Excluir produto;
 RF 08 - Consultar produto;
 7

 RF 09 - Efetuar venda;
 RF 10 - Excluir produto;
 RF 11 - Cancelar venda;
 RF 12 - Buscar cliente;
 RF 13 - Consultar preço;
 RF 14 - Efetuar login com nível de acesso.

2.2 Modelagem de Casos de Uso

2.2.1 Cadastro Cliente

 Identificação: Cadastrar cliente;

 Escopo: Sistema de vendas e cadastros com controle de estoque;
 Descrição do propósito: Esse caso de uso permite ao atendente ou
supervisor realizar o cadastro de clientes no sistema da loja;
 Ator primário: Atendente e supervisor;
 Interessados: Loja e cliente;
 Pré-condições: O sistema da loja deve estar operacional;
 Pós-condições: O atendente ou supervisor pegam os dados do
cliente e salvam no sistema.

2.2.1.1 Fluxo do Trabalho

 O atendente ou supervisor clica em cadastrar cliente;

 Inclusão para validar nível de acesso;
o Caso nível de acesso seja incompatível, uma mensagem é exibida.
o Caso login e senha estejam incorretos, uma mensagem é exibida.
 Login e senha válidos são informados;
 O sistema exibe o formulário de cadastro de cliente com todas as
opções;
 Os dados do cliente são preenchidos;
 8

 Opção salvar, os dados são armazenados no sistema, uma

mensagem é exibida.
o Caso existam campos em branco, uma mensagem é exibida.
o Extensão para alterar dados do cliente.
o Extensão para excluir um cliente.
o Extensão para consultar um cliente.

2.2.1.2 Requisitos Relacionados

 RF 02 - Alterar cliente;
 RF 03 - Excluir cliente;
 RF 04 - Consultar cliente;
 RF 14 - Efetuar login com nível de acesso.

Figura 01: Sistema de Cadastro

2.2.2 Cadastro de Produto

 Identificação: Cadastrar Produto;

 Escopo: Sistema de vendas e cadastros com controle de estoque;
 9

 Descrição do propósito: Esse caso de uso permite ao estoquista ou

supervisor realizar o cadastro de produtos no sistema da loja;
 Ator primário: Estoquista e supervisor;
 Interessados: Loja e cliente;
 Pré-condições: O sistema da loja deve estar operacional;
 Pós-condições: O estoquista ou supervisor pegam os dados do
Produto e salvam no sistema;

2.2.2.1 Fluxo de Trabalho

 O estoquista ou supervisor clica em cadastrar produto.

 Inclusão para validar nível de acesso.
o Caso nível de acesso seja incompatível, uma mensagem é exibida.
o Caso login e senha estejam incorretos, uma mensagem é exibida.
 Login e senha válidos são informados.
 O sistema exibe o formulário de cadastro de produto com todas as
opções.
 Os dados do produto são preenchidos.
 Opção salvar, os dados são armazenados no sistema, uma
mensagem é exibida.
o Caso existam campos em branco, uma mensagem é exibida.
o Extensão para alterar dados produto.
o Extensão para excluir um produto.
o Extensão para consultar um produto.

2.2.2.2 Requisitos Relacionados

 RF 06 - Alterar produto;
 RF 07 - Excluir produto;
 RF 08 - Consultar produto;
 RF 14 - Efetuar login com nível de acesso.
 10

Figura 02: Sistema de Cadastro

2.2.3 Efetuar Vendas

 Identificação: Efetuar venda;

 Escopo: Sistema de vendas e cadastros com controle de estoque;
 Descrição do propósito: Esse caso de uso permite ao atendente ou
supervisor efetuar a venda de produtos no sistema da loja;
 Ator primário: Atendente e supervisor;
 Interessados: Loja e cliente;
 Pré-condições: O sistema da loja deve estar operacional;
 Pós-condições: os produtos são adicionados, á venda é efetuada o
pagamento realizado e a venda concluída.

2.2.3.1 Fluxo de Trabalho

 11

 O atendente ou supervisor seleciona efetuar venda;

 Inclusão para validar nível de acesso;
o Caso nível de acesso seja incompatível, uma mensagem é exibida;
o Caso login e senha estejam incorretos, uma mensagem é exibida.
 Login e senha válidos são informados;
 O sistema exibe a tela de vendas com todas as opções;
 Os produtos são adicionados através do código de barras, valor total
é atualizado;
o Caso produto não esteja cadastrado, uma mensagem é exibida;
o Caso produto não esteja cadastrado, digitar código manualmente;
o Extensão para buscar dados do cliente;
o Extensão para excluir produto da venda;
o Extensão para cancelar a venda;
o Extensão para consultar preço.
 A forma de pagamento é selecionada;
 Opção efetuar venda, pagamento é realizado;
 Inclusão para atualizar o estoque;
 Inclusão para finalizar a venda.

2.2.3.2 Requisitos Relacionados

 RF 10 - Excluir produto;
 RF 11 - Cancelar venda;
 RF 12 - Buscar cliente;
 RF 13 - Consultar preço;
 RF 14 - Efetuar login com nível de acesso.
 12

Figura 03: Sistema de Vendas

2.3 Regras de Uso

2.3.1 Login
 Só usuários pré-cadastrados poderão ter acesso ao sistema;
 Somente funcionários terão acesso direto ao sistema;
 13

 Somente usuários com função de Administrador poderão cadastrar e

excluir usuários.

2.3.2 Cadastro de Usuário

 Deve ser feito o cadastro de todos os clientes para efetuar a compra;
 Somente usuários com função de Atendente/Administrador poderão
cadastrar clientes;
 Somente usuários com função de Administrador poderão alterar e
excluir cadastro de clientes.

2.3.3 Cadastro de Produto

 Somente usuários com função de Estoquista/Administrador poderão
cadastrar os produtos;
 Todos os produtos devem ser cadastrados para possibilitar a venda e
o controle de movimento;
 Todos os dados devem ser preenchidos para efetuar o cadastro do
produto.

2.3.4 Cancelamento de Vendas

 Somente usuários com função de administrador poderão cancelar
uma venda.

2.4 Contexto de Uso

2.4.1 Usuários e Tarefas

Os usuários que utilizam o sistema são separados por setores/funções, uma

forma separada e organizada de interação perante o software. Dentre os usuários,
temos os atendentes, que necessitam ter um fácil acesso e ao mesmo tempo
detalhado sobre todos os produtos para que possa ser repassado ao cliente e ao
final a geração da compra.
Os Estoquistas, que necessitam fazer a verificação, validação e
cadastramento de todos os produtos do estoque. Tudo de forma clara e ágil.
 14

Os Supervisores/Administradores, que por segurança tem acesso a todo o

sistema, garantindo uma segurança e total gerenciamento sobre o sistema.

2.4.2 Ambiente

Dentro do ambiente, temos um sistema de banco de dados, que ficam em

um servidor separado dos computadores de atendimento, utilizando um maior
processamento e acesso ao disco rígido.
Propriamente instalado em uma sala com ar condicionado e acesso restrito.
Os servidores estão diretamente conectados ao sistema base, onde é agrupado e
alocado todos os dados do sistema, como (Dados de usuários, senhas, produtos,
etc.).
Os softwares de cadastro serão instalados em computadores desktops, que
servirão de base para a comunicação e registro com o banco de dados.
Com acesso aberto a usuários que tem registro sobre o sistema, é possível
acessar de diferentes máquinas sem interferir nas configurações pré-estabelecidas
em cada usuário.

3. REQUISITOS NÃO FUNCIONAIS E FUNCIONAIS

Requisitos são serviços que um sistema deve prestar e suas restrições de

funcionamento. Eles devem necessariamente refletir as necessidades do cliente e
são classificados em dois níveis: requisitos de usuário e requisitos de sistema.
Os requisitos de sistema são descrições mais detalhadas das funções,
serviços e restrições operacionais do sistema de software. Eles devem ser
direcionados a usuários, arquitetos de sistema e desenvolvedores, pois podem
definir uma sequência de implementação, o que influencia diretamente na solução
dada.
 15

Os requisitos funcionais (RF) descrevem o comportamento esperado de um

sistema de software, explicita o que o sistema deve fazer e idealmente o que o
sistema não deve fazer
Os requisitos não funcionais (RNF) descrevem restrições sobre os serviços
oferecidos pelo sistema de software.
Os requisitos funcionais são insuficientes para descrever o sistema de
software, pois é necessário descrever outros aspectos: atributos do sistema e
atributos do ambiente do sistema, normalmente classificados como requisitos não
funcionais.

4. DIAGRAMA DE CLASSES DE ANALISE

4.1 Diagrama de Classes

Diagrama de classes é um diagrama UML que tem como objetivo

representar a estrutura estática das classes de um sistema de software

4.2 Diagrama de Objetos

Diagrama de objetos é um diagrama que tem como objetivo representar

instâncias de classes, ou seja, objetos e suas respectivas ligações ou associações.
Logo, podemos dizer que a base do diagrama de objetos é o diagrama de classes.
Por meio do diagrama de objetos tem-se uma visão dos objetos, suas informações e
seus relacionamentos em um determinado cenário em determinado momento de
execução desse cenário.

4.3 Classes de Análises

Os objetos são divididos e categorizados em três grupos de acordo com seu

tipo de responsabilidade: classe entidade, classe de fronteira e classe de controle,
também chamadas de classes de análise.
A classe entidade é o objeto mais próximo do mundo real que o sistema
representa e tem como objetivo principal manter informações referentes ao domínio
de problema que queremos resolver.
 16

A classe de fronteira tem como responsabilidade dividir o ambiente interno

do sistema e suas interações externas.
A classe de controle tem como objetivo realizar o sequenciamento da
execução de um caso de uso na estrutura de objetos do sistema, fazer a
coordenação entre camadas internas do sistema, representadas pelas classes de
entidade, com as camadas externas do sistema, representadas pelas camadas de
fronteira.

Figura 04: Diagrama de Classes de Análises

 17

4.4 Modelo de Entidade-Relacionamento (MER)

O Modelo Entidade-Relacionamento (MER) é um tipo de modelo conceitual

que descreve os objetos (entidades), suas características (atributos) e como se
relacionam (relacionamento).
Considerado um modelo de alto-nível, tem como objetivo representar um
arranjo de dados mais perto do mundo real, é um modelo abstrato desenvolvido pelo
fim de representar as estruturas de dados de forma mais natural e mais próxima do
mundo real dos negócios.
Partindo desta afirmativa, podemos entender que o modelo reproduz
aspectos abstratos que a estrutura possuirá no banco de dados da aplicação.
4.4.1 Entidades, Atributos e relacionamentos

Partindo dessa conjectura podemos classificar as entidades como: fortes,

fracas e associativa.
Entidades fortes: são aquelas que existem independentemente de outras
entidades. Ela possui total sentido para existir. Em nosso sistema de vendas por
exemplo, a entidade produto existe sem que outra entidade exista.
Entidades fracas: diferente das entidades fortes, as fracas dependem que
outras entidades existam, pois ela só não faz sentido. A exemplo, a entidade do
nosso sistema de vendas depende da entidade produto, sendo assim uma venda
sem itens não faz sentido.
Entidades associativas: surgem quando há a necessidade de associar uma
entidade a um relacionamento existente. Na modelagem Entidade-Relacionamento
não é possível que um relacionamento seja associado a uma entidade. Então
tornamos esse relacionamento uma entidade associativa, que a partir daí poderá se
relacionar com outras entidades, conforme descrito no sítio Devmedia.
Atributos são a representação de uma propriedade de uma entidade ou de
um relacionamento, ou seja, são as características usadas para descrever cada
entidade dentro do domínio, podendo ser descritivo os quais representam
características particular (ex.: nome, cor), nominativos além de descritos tem a
função de identificar e definir o objeto (ex.: número, código) e referenciais que é a
ligação de uma entidade a outra em um relacionamento (ex.: CPF relaciona com a
entidade vendas).
 18

Relacionamento é a representação das associações entre entidades

indicadas através das cardinalidades que é o número de ocorrências de uma
entidade que se relaciona com uma outra.
Relacionamentos um para um (1-1) - nesse tipo de relacionamento cada
uma das entidades se referência obrigatoriamente apenas uma unidade da outra.
Relacionamentos um para muitos (1-n ou 1..*) - nesse tipo de
relacionamento uma das entidades pode referenciar várias unidades da outra.
Relacionamentos muitos para muitos (n-n ou *..*) - neste tipo de
relacionamento cada entidade, de ambos os lados, podem referenciar múltiplas
unidades da outra.

Figura 05: Modelo de Entidade-Relacionamento (MER)

Figura 06: Diagrama Entidade-Relacionamento (DER)

 19

5. CONCLUSÃO

Esse projeto teve como objetivo realizar o desenvolvimento de um sistema a

partir de métodos, técnicas e ferramentas de engenharia de software.
O sistema desenvolvido nesse projeto atende todos requisitos propostos,
visto que ele engloba os setores de vendas, compras e estoque, tornando o sistema
funcional e prático para gerar informações necessárias para tomadas de decisões.
Ao desenvolver esse trabalho, permitiu uma grande contribuição para o
crescimento profissional e pessoal.
 20

6. REFERÊNCIAS

https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-
diagrama-entidade-relacionamento-der/14332
https://aws.amazon.com/pt/rds/?
trk=ps_a131L0000083bBMQAY&trkCampaign=pac_ps_Q1_120_RDS_PDP_P_NBra
nd_BR&sc_channel=ps&sc_campaign=pac_q1-1-
2020_paidsearch_RDS_OpenSource_BR&sc_outcome=PaaS_Digital_Marketing&sc
_geo=LATAM&sc_country=BR&sc_publisher=Google&sc_category=Database&sc_d
etail=%2Bbancos%20%2Bde
%20%2Bdados&sc_content=database_bmm&sc_matchtype=b&sc_segment=436567
689819&sc_medium=PAC-PaaS-P|PS-GO|Non-Brand|Desktop|PA|Database|RDS|
BR|PT|Text&s_kwcid=AL!4422!3!436567689819!b!!g!!%2Bbancos%20%2Bde
%20%2Bdados&ef_id=Cj0KCQjw7pKFBhDUARIsAFUoMDb-KhLNQJ__VE-
RKbSALBOs6lgPSppKjoWFWyWSP97RZ5lLRgT-
MkoaAiopEALw_wcB:G:s&s_kwcid=AL!4422!3!436567689819!b!!g!!%2Bbancos
%20%2Bde%20%2Bdados
 21

https://www.dbsi.com.br/analise-de-desempenho-e-performance?
keyword=administrador%20banco%20de
%20dados&matchtype=b&adposition=&device=c&gclid=Cj0KCQjw7pKFBhDUARIsA
FUoMDYbbzfLu4B2I3DbuXMRsJqopnxRuKQU_c_2SsVrAr3hlPwbCkqkZmsaAgrgEA
Lw_wcB
https://pt.wikipedia.org/wiki/Modelo_entidade_relacionamento
https://pt.stackoverflow.com/questions/328342/qual-a-diferen%C3%A7a-
entre-mer-modelo-de-entidade-relacionamento-e-der-diagrama-d