pim IV - sistema de loja geek

Prévia do material em texto

UNIVERSIDADE PAULISTA – EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistema
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS
GEEK. 
CAMPINAS POLO TAQUARAL
2022
UNIVERSIDADE PAULISTA – EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistema
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS
GEEK.
Nome : Leandro Alves de Sousa
RA: 2177053
Curso: Análise e Desenvolvimento de Sistema
Semestre: 3° Semestre
CAMPINAS POLO TAQUARAL
2022
RESUMO
O Desenvolvimento desse PIM (Projeto Integrado Multidiciplinar) tem como sua base
a matérias ministradas no atual bimestre, que são as matérias de banco de dados, análise de
sistema orientado a objeto e gestão estratégicas de recursos humanos, e teve como objetivo
fazer o levantamento de requisitos sistema para uma loja de produtos geeks.
A loja buscando a melhoria de atendimento ao cliente e buscando um melhor controle
de seu estoque, contratou a empresa para desenvolver um sistema de desktop para manter o
controle e o gerenciamento das suas vendas, sendo necessário o levantamento de requisitos e
funcionalidades, o sistema deve contar com acesso por login e senha e vários níveis de acesso,
cadastro de clientes, inclusão, alteração, consulta e exclusão de produtos para um melhor
controle de seu estoque.
Palavras chaves: loja, geek, jogos, controle de estoque, sistema, requisitos, cliente, login
ABSTRACT
The Integrated Multidisciplinary Development (PIM) is based on projects Projected in
the present bi-star, which are the subjects of database, object-oriented system analysis and
strategic human resources management, and aimed to develop a system for a geek products
store.
The store, seeking to improve customer service and seeking better control of its stock,
hired the company to develop a desktop system to maintain control and management of its
sales, being necessary to survey requirements and functionalities, the system must have access
by login and password and several levels of access, customer registration, inclusion,
alteration, consultation and exclusion of products for a better control of your stock.
Keywords: store, geek, games, inventory control, system, requirements, customer, login
Sumário
1 INTRODUÇÃO.......................................................................................................................6
2 CONTEXTUALIZAÇÃO........................................................................................................7
3 FUNÇÕES DE NEGÓCIO......................................................................................................7
4 SOLUÇÕES DISPONÍVEIS NO MERCADO........................................................................8
5 AUTOMATIZAÇÃO DE OPERAÇÕES.................................................................................9
6 CASO DE USO........................................................................................................................9
6.1 Atores................................................................................................................................9
6.2 Diagrama de caso de uso................................................................................................10
7 ANALISE DE REQUISITOS................................................................................................17
7.1 Requisitos funcionais.....................................................................................................17
8 CONTEXTO DE USO...........................................................................................................19
9 REGRAS DE NEGÓCIO.......................................................................................................19
10 GLOSSÁRIO DO SISTEMA..............................................................................................20
11 ORIENTAÇÃO OBJETO....................................................................................................21
11.1 Classes..........................................................................................................................22
11.2 Diagrama de classes......................................................................................................22
12 MODELO (MER)................................................................................................................23
13 CONCLUSÃO.....................................................................................................................24
14 REFERÊNCIAS...................................................................................................................26
1 INTRODUÇÃO
O objetivo do projeto integrado multidisciplinar o PIM VI, é baseado na necessidade
de uma loja que trabalha com o ramo de vendas de jogos eletrônicos e produto geek, para
construir um sistema para controlar estoque dos produtos e as vendas realizadas. O sistema
deverá realizar todos os cadastros, alterações, consultas e exclusões relacionados ao produto
que serão vendidos na loja, também serão permitidos cadastro de clientes e ainda o controle
de acesso com níveis de login. O sistema será utilizado por atendentes, estoquista e supervisor
de loja.
O PIM VI tem como objetivo principal descrever como será realizado o levantamento
e análise de requisitos que serão necessários para a elaboração do sistema, serão necessário
colocar em prática todo conhecimento adquirido nas matérias realizadas nesse bimestre, as
matérias em questão são análise de sistema orientado objeto, banco de dados, gestões
estratégicas de rh.
 
2 CONTEXTUALIZAÇÃO
Uma loja de venda de jogos eletrônicos, acessórios e produtos geek fechou um
contrato com uma empresa para o desenvolvimento de um software de controle e
gerenciamento de vendas de produtos e acessórios na área de jogos e cultura geek.
Atualmente, as pequenas tarefas gerenciadas para controlar vendas são manipuladas
utilizando planilhas em Excel.
 Para atender o cliente será desenvolvido um sistema desktop, e por isso, contratou-se
uma fábrica de software (grupo PIM) para o desenvolvimento. Nessa fase foi solicitada a
elaboração do levantamento de requisitos do sistema e pede-se que: o sistema deve ser
desenvolvido para plataforma desktop, deve possuir módulos de acessibilidade para que
eventuais portadores de deficiência consigam utilizá-lo. 
A empresa possui alguns produtos em estoque que, eventualmente por grau de raridade
e disponibilidade na plataforma de desenvolvimento dos jogos, não podem ser mais
adquiridos pelo cliente, tornando seu controle de venda um pouco mais rigoroso, pois alguns
produtos, após serem baixados do estoque, dificilmente poderão ser adquiridos por
encomenda devido seu grau de raridade (item exclusivo/colecionador). No entanto, o foco é
gerenciar as vendas efetuadas ao cliente. (Manual PIM VI, 2022, p. 24). 
3 FUNÇÕES DE NEGÓCIO
Funções de Negócio são estruturas
conceituais idealizadas que servem para descrever a
missão de uma Organização. Uma vez que tenham sido
definidas e decompostas adequadamente, elas se
mantêm estáveis ao longo do tempo, mesmo diante de
reorganizações da empresa. 
Fonte: Wikipédia
As funções de negócios do projeto em questão tem a finalidade de realizar o controle
de vendas dos produtos da empresa, através do gerenciamento, monitoramento e controle de
atividades, gerando assim um resultado financeiro que servirá as necessidades do contratante.
4 SOLUÇÕES DISPONÍVEIS NO MERCADO
Conforme o crescimento da empresa é de extrema importância contar com um sistema
que fará todo o gerenciamento controle e monitoramento de seus e estoque e suasvendas,
facilitando assim o dia a dia da empresa. Os sistemas de gerenciamento tem um papel
fundamental, são eles que são responsáveis por controlar o fluxo financeiro através da entrada
e saída de recursos, gerenciar o estoque, através do controle das mercadorias que se
encontram disponíveis.
Hoje em dia existem diversas ferramentas disponíveis no mercado, o valor de cada
uma varia de acordo com a necessidade de cada cliente, logo abaixo segue algumas
ferramentas que foram pesquisadas durante o desenvolvimento desse projeto.
 Lexos erp – é uma ferramenta de controle de estoque que permite o controle de
entrada e saída de produtos dos estoque, possibilita cadastro manual de produto de
forma rápida, gerando código de barra dos produtos, exibindo relatórios de seu
estoque que permitirá a empresa maior controle do seu estoque, ele possui vários tipos
de assinatura indo de 169 por mês, até valor sobre consulta para corporações.
 NEX – Nex é um sistema de gestão comercial que permite controlar o estoque,
registrar vendas, controle de caixa, emitir notas fiscais e muitas outras
funcionalidades, ele também conta com vários níveis de plano e seu preço varia de
49,00 a 119 reais por mês.
O sistema que será desenvolvido será capaz de atender todas as necessidades do
cliente, atendendo todos requisitos funcionais e não funcionais, a vantagem desse sistema
sobre outras opções do mercado é que será desenvolvido um sistema sobre medida, que trará
muitas vantagens ao nosso cliente, pois vai atender de forma específica todas as necessidades
de nosso contratante, algumas das vantagens de nosso sistema desenvolvido será de fácil
implementação, ótimo custo beneficio, boa flexibilidade e suporte exclusivo.
5 AUTOMATIZAÇÃO DE OPERAÇÕES
A automatização de operações é fundamental nos dias de hoje, graças a elas foi
reduzido o tempo de realizações de tarefa com isso foi gerado uma grande economia de
tempo, dinheiro e redução de mão de obra, em nosso sistema algumas operações foram
automatizadas garantindo assim um sistema mais eficiente e seguro.
 Emissão de nota fiscais sendo impressa de forma automatizada.
 Controle de estoque automatizado, o operador recebera informação quando precisar
repor o estoque.
 E-mail marketing será enviado a clientes, informando promoções.
 Sac automatizado pelo sistema
6 CASO DE USO
 Um modelo de caso de uso é um modelo que descreve como os usuários interagem
com o sistema para resolver um problema, ele descreve as metas dos usuários, as interações
entre o usuário e o sistema, assim como o comportamento necessário do sistema para atingir
essas metas
6.1 Atores
Atores são agentes externos ao sistema que executam ações e que esperam algum
resultado, ou seja, interagem diretamente com o sistema a partir de caso de uso, um exemplo
de autores são usuários que interagem com o sistema, ou outro sistema de software ou até
mesmos dispositivos de hardware. Em nosso caso os autores serão clientes, e funcionário que
será uma generalização de atendentes, estoquista e supervisor de loja e os cenários serão
sequencia específica de ações e interações entre os atores e o sistema.
 
6.2 Diagrama de caso de uso
O diagrama de caso de uso representa de forma gráfica, os elementos fundamentais da
modelagem de caso de uso.
Abaixo segue o modelo de caso de uso
Figura01 – Cadastro de funcionário
Fonte: autoria propiá
Nome do caso de uso: Cadastrar Funcionário
Escopo: Cadastro
Ator: Supervisor de loja/funcionário
Interessados: Funcionário/supervisor de loja
Pré-condição: Só supervisor de loja pode cadastrar funcionários
Pós condição: Funcionário cadastrado
Fluxo Básico: – Os dados do cliente são colocados
 – Cliente Cadastrado com sucesso
Fluxo alternativo: – Caso o ator cadastrado não seja funcionário uma mensagem é 
apresentado.
 – Caso for inserido algum dado o sistema apresentará uma 
mensagem
Cadastrar produtos no estoque:
Figura02-Cadastro de produtos
Fonte: autoria propiá
Nome do caso de uso: Cadastro no estoque
Escopo: Cadastro de produtos
Ator: Funcionário/sistema
Interessados: Funcionário/loja
Pré-condição: -Estoquista e supervisor podem cadastrar produto.
-Somente supervisor pode excluir um produto do estoque
-todos produtos devem ter nota do fornecedor.
Pós condição: Produto cadastrado no estoque, jogos informados qual a 
plataforma
Fluxo Básico: -Produto com nota de fornecedor 
-funcionário cadastra o produto
-jogos cadastrado em sua devida plataforma
-gerado um código de barra para o produto
-etiquetas são geradas para o produto
-produto cadastrado no estoque
Fluxo alternativo: – Caso não contenha nota fiscal uma mensagem aparecerá 
pedindo a regularização
 – Caso for informado algum dado o sistema informa dados que 
estão faltando.
 – Caso não seja estoquista ou supervisor de loja o sistema 
informará que não poderá cadastrar o produto.
Escolha do produto:
Figura03-Escolha de produto
Fonte: autoria propiá
Nome do caso de uso: Escolher produto
Escopo: Escolha do produto
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja
Pré-condição: O Atendente deve estar autenticado no sistema
Pós condição: O cliente escolhe o produto
Fluxo Básico: – O sistema busca no estoque o produto desejado
 – O sistema mostra na tela o produto desejado
Fluxo alternativo: – O Sistema está fora do ar
Nome do caso de uso: Filtrar produto
Escopo: Escolha do produto
Ator: Cliente/atendente/sistema
Interessados: Cliente/atendente/loja
Pré-condição: O Atendente deve estar autenticado no sistema
Pós condição: O sistema encontra o produto
Fluxo Básico: – O atendente fornece ao sistema os dados do produto a ser 
cadastrado
– O sistema busca em sua base de dados o produto com a 
característica buscada.
 – O sistema encontra o produto e exibe o resultado na tela.
Fluxo alternativo: – O sistema informa que o produto pesquisado não foi 
encontrado em sua base de dados.
 – O atendente erra o nome e o sistema busca em sua base de 
dados nomes parecido com o descrito
Nome do caso de uso: Leitura do produto
Escopo: Escolha do produto
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja
Pré-condição: O Atendente deve estar com o produto em mãos com etiqueta de
código de barras, o código de barras deve estar cadastrado.
Pós condição: – produto lido e encaminhado para o carrinho de compras
Fluxo Básico: – O sistema leu o código e buscou em banco de dados um 
código similar
 – Código encontrado e produto adicionado no carrinho de 
compras
Fluxo alternativo: – O Sistema não encontra o código de barras e mostra uma 
mensagem ao atendente.
-Código de barras rasurado, o sistema informa que o código de 
barra não pode ser lido.
Nome do caso de uso: Adicionar ao carrinho
Escopo: Escolha do produto
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja
Pré-condição: O Atendente deve estar autenticado no sistema
Pós condição: O produto encaminhado para o carrinho
Fluxo Básico: – O atendente lê o produto 
 – O sistema armazena o produto em uma tabela
Fluxo alternativo: – produto não está cadastrado no sistema 
Nome do caso de uso: Remover do carrinho
Escopo: Escolha do produto
Ator: Cliente/supervisor
Interessados: Cliente/atendente/supervisor/loja
Pré-condição: Apenas supervisor pode remover do carrinho
Pós condição: O produto retirado do carrinho
Fluxo Básico: – Supervisor coloca login e senha
 – remove produto do carrinho
Fluxo alternativo: – atendente tenta remover produto do carrinho, sistema informa 
que apenas supervisor pode remover produto.
 – O produto não está no carrinho
Finalizar venda:
Figura04-Finalizar Compra
Fonte: autoria propiá
Nome do caso de uso: Finalizar compra
Escopo: Finalização de compra
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja/operadora
Pré-condição: O Atendente deve estar autenticado no sistema, deveter compra 
no carrinho para a finalização.
Pós condição: O produto é enviado para registrar a venda
Fluxo Básico: – O atendente lê todos os produtos e finaliza a compra
Fluxo alternativo: – Carrinho vazio 
Nome do caso de uso: Registrar venda
Escopo: Escolha do produto
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja/operadora
Pré-condição: O Atendente deve estar autenticado no sistema
Pós condição: O produto automaticamente será dado baixa no estoque
Fluxo Básico: – O sistema envia para o estoque para ser dado baixa no 
produto
Nome do caso de uso: Efetuar pagamento
Escopo: Finalização de compra
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja/operadora
Pré-condição: O Atendente deve estar autenticado no sistema, deve ter compra 
no carrinho para a finalização.
Pós condição: Venda registrada
Fluxo Básico: – O sistema calcula o valor total da compra
 – O atende informa o valor da compra ao cliente
 – É informado a foma de pagamento dinheiro ou cartão
Fluxo alternativo: – O cliente pede para adicionar mais produtos 
 – O cliente não conta com nenhuma forma de pagamento que é 
aceita na loja, a compra tem que ser cancelada 
Nome do caso de uso: Pagamento em dinheiro
Escopo: Finalização de compra
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja/operadora
Pré-condição: O Atendente deve estar autenticado no sistema
Pós condição: Pagamento efetuado
Fluxo Básico: – O atendente registra o valor recebido.
 – O sistema mostra o troco e emite a nota fiscal ao cliente.
 – O sistema envia a compra para o sistema financeiro
Fluxo alternativo: – O valor recebido não é suficiente e mostra o valor que falta.
Nome do caso de uso: Pagamento em cartão
Escopo: Finalização de compra
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja/operadora
Pré-condição: Operadora de cartão disponível
Pós condição: Pagamento efetuado
Fluxo Básico: – A operadora de cartões valida os dados do cliente.
 – Autoriza a compra dos clientes.
 – O sistema exibe uma mensagem de compra efetuada com 
sucesso
Fluxo alternativo: – Cartão não tem crédito, uma imagem é exibida.
 – Operadora não autoriza a compra
Nome do caso de uso: Enviar dados do cartão
Escopo: Finalização de compra
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja/operadora
Pré-condição: Operadora de cartão disponível
Pós condição: Entrega de dados do cartão a operadora
Fluxo Básico: – O sisteme se comunicará com a operadora dedo cartão, a 
mesma valida os dados
Fluxo alternativo: – Cartão não aceito pela operadora de cartão da loja
Nome do caso de uso: Validar dados do cartão
Escopo: Finalização de compra
Ator: Cliente/atendente
Interessados: Cliente/atendente/loja/operadora
Pré-condição: Operadora de cartão disponível
Pós condição: Aprovação da compra
Fluxo Básico: – Tem crédito disponível no cartão
 – A operação valida os dados, e o sistema apresenta uma 
mensagem de pagamento efetuado.
Fluxo alternativo: – Cartão sem crédito
 – Operadora recusa o cartão
7 ANALISE DE REQUISITOS
A análise de requisito é uma parte importante no processo de sistema, é onde é
identificado as necessidades do cliente, negócio e do usuário. Por isso nessa fase de projeto é
feito o levantamento de funcionalidades. 
7.1 Requisitos funcionais
Os requisitos funcionais descrevem o comportamento esperado de um sistema de 
software, e o detalhamento da interação entre o sistema e o usuário.
7.2 Requisitos não funcionais
Os requisitos não funcionais descrevem todas as restrições dos serviços oferecido pelo 
nosso sistema de software, também são atributos e ambiente de sistema, existem 3 tipos de 
classificação a partir dos requisitos não funcionais.
 Requisitos organizacionais: Proveniente da organização do cliente, como uma 
padronização de uma linguagem de desenvolvimento.
 Requisitos de produtos: são aqueles que restringem o comportamento do sistema, 
como a quantidade de espaço em disco que ele usará.
 Requisitos externos: são requisitos de fora da fronteira do software como, requisitos 
legais da legislação
Requisitos não funcionais do sistema:
Operadora de cartão
 Identificador: RFN001
 O sistema precisará de uma operadora de cartão, integrada ao nosso sistema de 
pagamento, permitindo o usuário realizar o pagamento com seu cartão de crédito.
Optimização do sistema:
 Identificador: RFN002
 O sistema será optimizado, garantindo um melhor desempenho e consumindo menos 
hardware, transformando assim em um sistema mais leve.
Segurança:
 Identificador: RFN003
 O sistema contará com vários níveis de acesso, usuário e senha individual, todas 
transações criptografadas, e dados protegidos
Backup do sistema:
 Identificador: RFN004
 O sistema contará com backups periódicos e armazenados em um lugar seguro e de 
rápido utilização, em caso de alguma anormalidade no sistema.
7.3 Requisitos não funcionais de usabilidade
Inteligibilidade:
 Identificador: RFN005
 O sistema será projetado para que qualquer usuário consiga entender a lógica por trás 
do sistema, tornado assim mais fácil sua usabilidade.
Facilidade de aprendizado:
 Identificador: RFN006
 O sistema será projetado para que cada usuário que for usar o sistema tenha uma 
rápida aprendizagem, com layout fácil, informações claras, letras de um bom tamanho,
botões com cores fáceis de memorizar.
Operacionalidade:
 Identificador: RFN007
 O sistema será fácil de operar, pois foi buscado uma melhor operacionalidade, 
evitando erros e transformando o sistema mais seguro para o usuário realizar suas 
tarefas
8 CONTEXTO DE USO
O contexto de uso é todo ecossistema em volta do sistema, e é caracterizado por toda a
situação envolvendo o usuário com sua interação com o sistema. Pode ser definido como
(Quem) todos evolvidos que vão utilizar o sistema, dentro do sistema terá níveis de acesso
onde cada usuário terá um nível de acesso de acordo com seu nível hierárquico dentro da loja,
(o que) qual o papel do sistema, no nosso contexto será feito um sistema para controlar
estoque e processar venda, (onde) plataforma de utilização de nosso sistema, o sistema
desenvolvido será utilizado no desktop com sistema operacional windows.
9 REGRAS DE NEGÓCIO
As regras de negócios é um dos principais componentes da fase de levantamento e
modelagem de requisitos no desenvolvimento de um software, elas são um conjunto de
restrição que definem como um processo de negócio de uma organização deve ser executado,
e também descreve importantes aspectos restritivos na execução de processo.
Abaixo está documentado a regra de negócio do projeto em questão:
Indentificação Níveis de acesso-RN01
Descrição O sistema tem vários níveis de acesso de acordo com a função 
exercida na loja
Fonte Supervisor de loja/Sistema
Histórico 28/05/2022
Indentificação Cadastro de novos funcionários-RN02
Descrição Somente supervisor de loja pode cadastrar novos funcionários
Fonte Supervisor de loja/Sistema
Histórico 28/05/2022
Indentificação Cadastro de Produtos-RN03
Descrição Somente supervisor de loja e Estoquista podem cadastrar produtos
Fonte Estoquista/Supervisor de loja/Sistema
Histórico 28/05/2022
Indentificação Cadastro de clientes-RN04
Descrição O cadastro de cliente deve ser preenchido com as seguintes 
informações:
Nome, RG, CPF, Data de cadastro, Endereço, Telefone e E-mail de 
cliente
Fonte Funcionários/Sistema
Histórico 28/05/2022
Indentificação Código de barras-RN05
Descrição Todo produto devem conter um código de barra
Fonte Funcionário/Sistema
Histórico 28/05/2022
Indentificação Cancelamento de Vendas-RN06
Descrição Somente supervisor de loja pode cancelar uma venda
Fonte Supervisor de loja/Sistema
Histórico 28/05/2022
10 GLOSSÁRIO DO SISTEMA 
TERMO English Term Descrição
 
Usabilidade Usability 
A usabilidade é um termo para
definir a facilidade com que as
pessoas empregam uma ferramenta
ou até mesmo um objeto para
realizar uma tarefaGEEK GEEK
Geek é uma gíria da língua
inglesa cujo significado é alguém
viciado em tecnologia, em
computadores e interne 
Login Login
 
Identificação para acesso a um
determinado computador ou sistema
Requisitos requirements
 
 requisitos pode ser definido
como condições necessárias,
geralmente obrigatórias, para se
conseguir algo. 
11 ORIENTAÇÃO OBJETO
O paradigma de orientação objeto é uma forma de desenvolver um sistema de software
que o enxerga como um conjunto de componentes que interagem entre si para resolver um
determinado problema. Em cada um desses componentes damos o nome de orientação objeto,
e cada objeto possui uma determinada característica que chamamos de atributos, e ações para
serem executadas que chamamos de método.
11.1 Classes
As classes em orientação objeto podem ser definidas como de objetos que possuem o 
mesmo atributo e métodos, a classe pode ser definida como uma especialização de um objeto.
11.2 Diagrama de classes
O diagrama de classe mostra a visão do analista para o programador, definindo 
classes(entidades), atributos, chaves, métodos e relações entre classes, abaixo segue o 
diagrama de classes.
Figura05-Diagrama de Classes
Fonte: autoria propiá
12 MODELO (MER)
O Modelo Entidade Relacionamento (também
chamado Modelo ER, ou simplesmente MER), como o
nome sugere, é um modelo conceitual utilizado na
Engenharia de Software para descrever os objetos
(entidades) envolvidos em um domínio de negócios,
com suas características (atributos) e como elas se
relacionam entre si (relacionamentos).
Em geral, este modelo representa de forma
abstrata a estrutura que possuirá o banco de dados da
aplicação. Obviamente, o banco de dados poderá conter
várias outras entidades, tais como chaves e tabelas
intermediárias, que podem só fazer sentido no contexto
de bases de dados relacionais.
Fonte: Devmidia
Abaixo segue modelo entidade de relacionamento(MER).
Figura06-MER
Fonte: autoria propiá
13 CONCLUSÃO
Chegamos ao fim do projeto PIM V, que teve como objetivo colocar em prática todo
conhecimento adquirido durante o atual bimestre, o projeto teve como principal objetivo o
desenvolvimento de um sistema de controle de venda de uma loja de produtos geek, conforme
foi pedido no escopo do projeto.
Durante o desenvolvimento foi realizado o levantamento de requisito para que o
sistema contasse com tudo o que foi solicitado pelo cliente, conforme foi realizado o
levantamento de requisitos, foi elaborado as regras de negócios para que foram estabelecidas
durante o desenvolvimento, foi feito um levantamento de mercado com todos as soluções
disponíveis que se assemelham com a necessidades do cliente, foi desenvolvido a
automatização de tarefas.
O projeto também conta com diagrama de casos de uso que conta com a descrição do
seu comportamento, dos fluxos principais e alternativos, de exceção e pré e pós condições,
também foi descrito requisitos não funcionais, glossário do sistema, diagrama de classes de
análise, e construído modelos de dados(MER).
14 REFERÊNCIAS
WIKIPÉDIA, 2022.Funções de negócios..2022.Disponível em: https://bit.ly/3OcYasj. Acesso
em: 22 mai. 2022.
DEVMIDIA, 2022.Modelo Entidade Relacional…2021..Disponível em: 
https://bit.ly/3xfjBCa. Acesso em: 05 mai. 2022.
VERSOLATTO, F. R., Análise de Sistema Orientado a Objeto. são Paulo: Sol, 2015.
TORRES, A. S., Gestão Estratégica de Recursos Humanos. são Paulo: Sol, 2012.
BAZOLAN, S. M., Banco de Dados. são Paulo: Sol, 2021.
https://bit.ly/3OcYasj
	1 INTRODUÇÃO
	2 CONTEXTUALIZAÇÃO
	3 FUNÇÕES DE NEGÓCIO
	4 SOLUÇÕES DISPONÍVEIS NO MERCADO
	5 AUTOMATIZAÇÃO DE OPERAÇÕES
	6 CASO DE USO
	6.1 Atores
	6.2 Diagrama de caso de uso
	7 ANALISE DE REQUISITOS
	7.1 Requisitos funcionais
	8 CONTEXTO DE USO
	9 REGRAS DE NEGÓCIO
	10 GLOSSÁRIO DO SISTEMA
	11 ORIENTAÇÃO OBJETO
	11.1 Classes
	11.2 Diagrama de classes
	12 MODELO (MER)
	13 CONCLUSÃO
	14 REFERÊNCIAS