PIM_VI_ LEVANTAMENTO_DE_REQUISITOS DE SISTEMA_LOJA_GAMES_VSFINAL_4

Prévia do material em texto

UNIP EaD 
Projeto Integrado Multidisciplinar VI 
Curso Superior de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
PIM VI – LEVANTAMENTO DE REQUISITOS DE SISTEMA 
DESKTOP PARA LOJA DE GAMES E PRODUTOS GEEK. 
 
 
 
 
 
 
 
 
 
 
 
 
 
POLO SÃO MIGUEL 
SÃO PAULO – SP 
2021 
 
 
 
 
UNIP EaD 
Projeto Integrado Multidisciplinar VI 
Curso Superior de Tecnologia 
 
 
 
 
 
 
 
PIM VI – LEVANTAMENTO DE REQUISITOS DE SISTEMA 
DESKTOP PARA LOJA DE GAMES E PRODUTOS GEEK. 
 
 
 
 
 
Alunas: Juliana Venâncio da Silva 
RA: 2076859 
Sumaya Távora Costa 
RA: 2062137 
Curso: Tecnólogo em Análise e Desenvolvimento de Sistemas. 
Semestre: 4º 
 
 
 
 
 
 
 
POLO SÃO MIGUEL 
SÃO PAULO – SP 
2021
 
 
 
 
RESUMO 
O presente trabalho propõem um sistema de pontos de vendas, para uma loja 
de produtos, acessórios geek e jogos eletrônicos. O sistema permitirá o 
gerenciamento de produtos, gerenciamento de estoque de acessórios e jogos. 
Contará com cadastros definindo os usuário que utilizarão o sistema, aa princípio o 
atendente e supervisor. Serão levantados os requisitos funcionais, não funcionais, 
casos de uso, diagrama de classes (UML) e modelo de dados (MER) para o 
desenvolvimento. Dando possibilidade de futura inclusões de funções pelo cliente 
posteriormente. Será feita uma análise do mercado atual de sistemas e tecnologias 
existentes. Incluindo as regras de negócios para o funcionamento e avanço do 
sistema. Atendendo ao pedido da Loja de produtos Geek. A metodologia e conceitos 
utilizados terá como base as disciplinas estudadas neste bimestre de Análise de 
Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos 
Humanos. 
 
Palavras-chaves: Sistema de loja, ponto de venda, sistema desktop, 
programação orientada ao objeto, sistema de controle, gerenciamento e venda. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABSTRACT 
The present work proposes a point of sale system for a store that sells products, 
geek accessories and electronic games. The system will allow product management, 
accessory and game inventory management. It will have records defining the users 
who will use the system, at first the attendant and supervisor. Functional and non-
functional requirements, use cases, class diagram (UML) and data model (MER) for 
development will be surveyed. Giving the possibility of future inclusions of functions by 
the customer later. An analysis of the current market for existing systems and 
technologies will be made. Including the business rules for the functioning and 
advancement of the system. At the request of the Geek Products Store. The 
methodology and concepts used will be based on the subjects studied in this bimester 
of Object Oriented Systems Analysis, Database and Strategic Human Resources 
Management. 
 
Keywords: Store system, point of sale, desktop system, object-oriented 
programming, control system, management and sales. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
1 INTRODUÇÃO ............................................................................................... 6 
2. DESENVOLVIMENTO .................................................................................. 7 
2.1 Cenário proposto ..................................................................................... 7 
2.2 Funções de Negócios .............................................................................. 7 
2.3 Soluções disponíveis no mercado de software ........................................ 8 
2.4 Automatizações ..................................................................................... 10 
2.6 Engenharia de Requisitos...................................................................... 10 
2.7 Levantamento de Requisito do Sistema ................................................ 10 
2.8 Requisitos Funcionais ........................................................................... 11 
2.9 Requisitos Não-Funcionais .................................................................... 11 
2.10 Modelo de caso de uso ....................................................................... 13 
2.11 Contexto de uso .................................................................................. 19 
2.12 Regras de Negócio .............................................................................. 19 
2.13 Diagrama de classes de análise (Boundary, Control, Entity) ............... 21 
2.14 Modelo de Entidade Relacional (MER) ................................................ 21 
3 CONCLUSÃO .............................................................................................. 23 
REFERÊNCIAS .............................................................................................. 24 
GLOSSÁRIO ................................................................................................... 26 
 
 
 
 
 
 
6 
 
 
 
1 INTRODUÇÃO 
 
Segundo Manuel Castells (2021) o mundo atualmente vive em uma revolução 
tecnológico econômico, com enormes consequências em ambientes de trabalho. 
Levando ao desemprego total de enorme parte da população. 
Saímos das transformações ocorridas pós década de 70, houve uma 
transformação na comunicação mundial, o Brasil sai da sociedade em transição na 
rede global, termo utilizado por Manuel Castells (2021). 
Na pandemia as empresas correram contra o tempo para se adaptarem ao 
novo cenário tecnológico econômico, onde a administração toda feita através de 
gerenciamento em maquina virtuais em nuvem. 
Tendo em vista que as pequenas empresas, não possuem muitos recursos 
para investimentos iniciais em sistemas de informação. E levando em consideração 
que ainda faz vendas em seu ponto local com atendentes, supervisores e estoquistas. 
Levando em consideração a economia do país que decaiu em 2021. 
 
 Segundo o estudo, a retomada econômica no Brasil "permanece frágil". 
Após um vigoroso crescimento no último trimestre de 2020 e nos dois 
primeiros meses deste ano, puxado pelo varejo e o setor de serviços, houve 
um forte recuo em março por conta do agravamento da crise sanitária. (BBC 
BRASIL, 2021) 
 
A presente pesquisa propõe o desenvolvimento do levantamento e análise de 
requisitos de um software de controle de vendas da loja de produtos de jogos 
eletrônicos, acessórios e produtos GEEK. Utilizando os conceitos e metodologias 
estudadas nas disciplinas de Análise de Sistemas Orientada a Objetos, Banco de 
Dados e Gestão Estratégica de Recursos Humanos. Proporcionando aos gestores da 
empresa futuramente readequar o sistema com novas funcionalidades, integrando a 
backups em nuvem. 
Tendo em vista segundo a Lei no 10.098/94, acessibilidade é a possibilidade e 
condição de alcance para utilização, com segurança e autonomia, de espaços 
mobiliários, equipamentos urbanos, transportes, sistemas e meios de comunicação 
por pessoa com deficiência ou com mobilidade reduzida. 
O sistema contará com botões que permitam portadores de necessidades 
especiais a tanto utilizarem o sistema como trabalhar na loja. 
 
 
7 
 
 
 
2. DESENVOLVIMENTO 
 
2.1 Cenário proposto 
 
A loja de venda de jogos eletrônicos e produtos GEEK, atualmente possui o 
gerenciamento de controle de venda através de planilhas de Excel. Com a 
necessidade de automatizar o processo de controle de vendas, foi solicitado as 
empresas de software (grupo do PIM-IV) para realização deste sistema de desktop. 
Com foco em gerenciar as vendas efetuadas aos clientes. O sistema possuirá 
módulos de acessibilidade para portadores de deficiência utilizarem. 
A empresa possui produtos que devem ser baixados do estoque e não podem 
mais ser vendidos ao consumidor final pelo seu nível de raridade. Apenas para 
colecionadores. 
O sistema terá a possibilidade de cadastrar produtos, inserir cadastro de 
atendente e supervisor. Dará baixa em produtos que restam apenas uma unidade, 
desdeque sejam raros para colecionadores. A venda será toda efetivada no sistema 
e o sistema terá uma possibilidade de upload para uma base de dados online para 
acesso restrito aos gestores da empresa. 
Os requisitos serão detalhados no tópico posterior de requisito funcionais. 
 
2.2 Funções de Negócios 
 
O sistema estará acessível a funcionários da empresa de processos primários, 
como marketing, entrega, serviços de pós-vendas e vendas. 
Almeida (2018) os processos primários são aqueles que são atividades 
essenciais para a empresa exercer sua missão de negócios. 
Para cada funcionário será fornecido as informações do banco de dados de 
acordo com a sua função. 
No presente trabalho vamos detalhar apenas requisitos funcionais e não 
funcionais dentro do principal caso de uso, que será utilizado pelo atendente e 
coordenador da loja juntamente com a ação do cliente. 
No processo de suporte, o sistema dará acesso a gestores de estoque, 
estoquistas e gestores de infraestrutura de TI. Dando acesso a cada um de acordo 
com a necessidade de suas funções dentro da empresa. 
8 
 
 
 
Um exemplo: O estoquista só visualizará a página de cadastro e de estoque, 
para verificar quais reposições devem ser feitas e quais os produtos devem ser 
retirados do estoque por existir apenas um em estoque, recolocando para venda 
restrita colecionadores, com valor a consultar. 
O gestor de estoque visualizara todas as páginas referentes ao estoque de 
produtos, para estratégias e compras de produtos a ser realizada. 
Almeida (2018) os processos de suporte, são os que facilitam e ajudam a 
execução dos processos primários. 
 
2.3 Soluções disponíveis no mercado de software 
 
O software proposto neste trabalho será chamado de Vendas GEEK, é um tipo 
de sistema de desktop, muito utilizado no mercado de varejo. O sistema é de gestão 
e da loja e processo de pagamento, conhecidos no mercado como POS (ponto de 
venda). Podendo ser adaptado para outras empresas ou até mesmo servir para 
qualquer loja de produtos físicos em pontos de venda. 
Segundo a pesquisa do Reforming Retail (2018), 20% de todos os restaurantes, 
exceto cafeterias nos EUA, já possuem PO em nuvem. As análises de POS em nuvens 
indicam que 60% dos novos sistemas adquiridos nos últimos 6 meses, são em nuvens. 
Os benefícios dos sistemas em nuvem são: precisão, mantendo o estoque 
automaticamente e diminuído os erros. Gerenciamento de estoques, principalmente 
no ramo de restaurantes, que possuem enormes margens de desperdícios de 
estoque. Agilizar o atendimento, diminuindo as filas, acesso com usabilidade em 
vários locais e dispositivos, permitindo mobilidade e trabalhar remotamente em outros 
locais. Para restaurantes possibilita saídas dos clientes mais rápidas, possibilitando o 
funcionário levar o tablets até as mesas. Ele também pode minimizar o tempo de 
inatividade do sistema. Mesmo se o seu sistema tiver problemas para se conectar à 
nuvem, você pode usá-lo no modo off-line e continuar a gerenciar as transações. 
Assim que a conexão for restabelecida, novos dados podem ser sincronizados sem 
perda de dados. 
Existe enumeras empresas com soluções prontas no mercado, o que difere são 
as funcionalidades oferecidas em cada plano, se o sistema é em nuvem ou locar 
sendo utilizado remotamente e tendo a conexão apenas na finalização da venda. 
9 
 
 
 
Melhores sistemas POS em nuvem, segundo Ecommerce Platforms, selecionamos os 
seguintes no âmbito internacional: 
 
 Lightspeed POS 
 Vend Pos 
 POS Airpos 
 
A seguinte pesquisa selecionou três sistemas com planos gratuitos e pagos no 
Brasil que estão sendo utilizado por pequenas empresas: 
 SigeLite - https://www.sigelite.com.br/ 
 PDV MarkeUP - https://marketup.com/ 
 Acompanhe-ME - https://www.sebrae.com.br/ 
 
SigeLite é um software completo de gestão financeira de vendas e controle 
financeiro e emissão de nota e cupons off-line. Ele e totalmente gratuito tem integração 
com marketplaces. 
Ele no plano gratuito funciona off-line com limitação. No plano de R$19,90 
mensal ele tem as integrações e se torna ilimitado. Podendo solicitar o serviço de 
Sigecloud, serviço nas nuvens. 
PDV markeUp é um software gratuito com integrações com marketplace, tem 
acesso online, com integração com marketplaces e acesso online. Ele é personalizado 
de acordo com o segmento da empresa. 
Acompanha-ME é um sistema oferecido pelo SEBRAE gratuito para 
Microempresa. É sistema de controle financeiro, monousuário funciona apenas no 
computador, não é mobile e apenas para Windows. 
O diferencial do Vendas GEEK, que ele é um sistema apenas off-line, com 
acesso online apenas para backup e finalização de compra e de acordo como as 
funcionalidades solicitadas pelo cliente, reduzindo o custo de acordo com a estrutura 
e valor de investimento atual do cliente. Podendo ser adequado futuramente de acordo 
com o crescimento da empresa. 
 
 
 
10 
 
 
 
2.4 Automatizações 
 
No presente trabalho será automatizados processos que são recorrentes de 
vendedores e ou atendentes, como envio de e-mails para produtos reservados por 
clientes cadastrados. Mensagem de aviso de reposição de estoque para estoquistas. 
Clientes que solicitaram para notificações de aviso de determinado produto, será 
enviado e-mail avisando que o produto já está disponível na loja. Marketing através 
de e-mail, com aviso que existem podem ser de seu interesse, o sistema toma base 
a produtos relacionados a última compra. Envio de nota-fiscal por e-mail ou via api 
de WhatApps. 
 
2.6 Engenharia de Requisitos 
 
Engenharia e requisito é um conjunto de métodos, processos e ferramentas 
com o objetivo de resolução de problemas. 
Sommerville (2010) um sistema deve prestar serviços e restringir algumas 
funcionalidades. 
 
2.7 Levantamento de Requisito do Sistema 
 
Pfleeger (2004) identificar os requisitos de um sistema é muito importante para 
o processo de desenvolvimento de um software. Na maior parte das vezes estamos 
automatizando um sistema existente de forma manual. Logo estamos trabalhando 
diretamente com usuário e cliente, com o objetivo de compressão do problema, 
mesmo que não tenha encontrado a solução para ele. 
Os requisitos podem ser separados em três categorias: 
1. Requisitos que devem ser totalmente satisfeitos 
2. Requisitos que são altamente desejáveis, mas não necessários 
3. Requisitos que são possíveis, mas poderiam ser eliminados. 
 
 
 
 
11 
 
 
 
2.8 Requisitos Funcionais 
 
Pfleeger (2004) um requisito funcional é a interação do sistema com o 
ambiente, quais estados são aceitáveis pelo sistema, descrevem como o sistema deve 
se comportar. As questões trazidas pelos requisitos funcionais e independente do 
problema do sistema a ser solucionado. 
Requisitos funcionais do sistema: 
 RF01- Cadastro de Atendente 
 RF02 – Cadastro do Cliente 
 RF03 – Cadastro de Produtos 
 RF04 – Cadastro do Supervisor 
 RF05 – Realiza entrada de produtos 
 RF06 – Gera o pedido 
 RF07 – Realiza o fechamento da Venda com informações da financeira de 
cartão e opções de débito, crédito ou dinheiro. 
 RF08- Envia os dados para a financeira de pagamento caso seja cartão com 
debito ou credito. 
 RF09 – Se for dinheiro o atendente da entrada do valor recebido. 
 RF10 – O atendente finaliza a venda. 
 RF11- Os produtos raros serão descritos no sistema quando restar uma 
unidade no sistema, o próprio sistema retira da tabela de produtos para venda 
direta. 
 RF12 – O sistema terá possiblidade de diminuir e aumentar as fontes. 
 RF13 – O sistema terá acesso por meio de digital e voz. 
 
2.9 Requisitos Não-Funcionais 
 
Pfleeger (2004) os requisitos não-funcionais descrevem as restrições que 
ocorrerão no sistema. Isso sim limita as opções de criar soluções do problema. 
Dentro do contexto da loja e jogos eletrônicos propomos os seguintes requisitos 
não-funcionais:12 
 
 
 
Tabela 1 - Requisitos não-funcionais do sistema Venda GEEK. 
Identificação: Nome: Descrição: 
RQNF01 Segurança no acesso Boas práticas de 
segurança de acesso ao 
usuário funcionário. 
Utilização de sistema de 
firewall para segurança 
do sistema. 
RQNF02 Disponibilidade do 
sistema 
Sistema de backup de 
hardware para o uso do 
sistema. 
RQNF03 Operadoras de cartões 
disponíveis no mercado 
Meios de pagamento via 
operadoras financeiras no 
processo de finalização 
da compra. 
RQNF04 Ter bom desempenho na 
transferência dos dados 
na internet 
Na finalização da compra 
o sistema com conexão à 
internet para não ocorrer 
desistência do cliente na 
finalização da compra. 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
 
Tabela 2 - Requisitos não-funcionais de usabilidade do sistema Venda GEEK. 
Identificação: RQNF01 Categoria: Usabilidade 
Data: 29/05/2020 Prioridade: Importante 
Nome: Uso de design responsivo para interfaces gráficas 
Descrição: 
O sistema deve ter uma interface intuitiva para 
visualização em desktops. 
 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
Tabela 3 - Requisitos não-funcionais de usabilidade do sistema Venda GEEK. 
Identificação: RQNF02 Categoria: Usabilidade 
Data: 29/05/2020 Prioridade: Importante 
Nome: Módulos de acessibilidade para portadores de 
necessidades especiais. 
Descrição: 
O sistema deve ter funções que possibilitam, 
aumentar fontes, acessar através de digital e leitura 
por áudio das suas funções. 
 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
 
 
 
13 
 
 
 
2.10 Modelo de caso de uso 
 
Identificando as funções a serem automatizadas de acordo com o processo 
de venda do cliente, já existente através de planilhas de Excel. Foram extraídos os 
casos de uso, conforme o diagrama da figura 1 a seguir: 
Fig. 1 – Diagrama de caso de uso filtrar consulta 
 
Fonte: Produzida pelos autores com base nos dados de (VERSOLATTO, Fábio Rossi, 2004.) 
 
A seguir na tabela 1 os requisitos não funcionais propostos para o Sistema 
Vendas Geek, após feito os casos de usos, conforme os atores do sistema: 
 
Tabela 1 - Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 1, 
do sistema Vendas GEEK. 
Identificação Listar produtos 
Escopo: Escolha Produto 
Descrição: Esse caso permite ao cliente com o atendente acesse a página 
de produtos no qual deseja. 
Nível: Primário. 
Atores: Atendente do caixa/Cliente 
Interessados: Atendente do caixa/Cliente/Loja 
Pré-condição: Atendente estar autenticado o no sistema 
Pós-condição: O atendente/Cliente escolhe o produto selecionado 
14 
 
 
 
Fluxo normal 1. O atendente realiza a consulta na barra de pesquisa no 
sistema 
2. O sistema mostra na tela os produtos referentes a palavra-
chave ou código de barra solicitado 
 
Requisitos 
Relacionados: 
RQNF02 – Disponibilidade do Sistema 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
Tabela 2 - Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 1, do 
sistema Vendas GEEK. 
Identificação Filtrar consulta de produtos 
Escopo: Escolha o produto desejado 
Descrição: Este caso de uso possibilita o cliente por meio do atendente, 
pesquise as características por produtos. Exemplo: fabricante, 
gênero, coleção, classificação por faixa etária e etc. 
Nível: Primário. 
Atores: Atendente do caixa com o cliente 
Interessados: Atendente do caixa/Cliente/Loja 
Pré-condição: Atendente estar autenticado no sistema 
Pós-condição: O atendente adiciona o produto desejado pelo cliente obterá o 
resultado da consulta o produto selecionado 
Fluxo normal 1. O Atendente juntamente com o cliente fornece pelo 
menos um dado no campo de pesquisa e aperta o botão 
da lupa para pesquisar; 
2. O sistema faz a varredura procurando dados iguais ou 
semelhantes do que foi informado; 
3. O sistema mostra na tela o que foi resultado da pesquisa. 
Fluxo 
alternativo: 
1. Caso o botão da lupa seja acionado sem dados inserido, 
o sistema exibe a seguinte mensagem: “Você deve 
preencher com alguma informação a ser pesquisada”. 
2. Se o sistema não achar nenhum produto com os dados 
informados pelo atendente no campo de pesquisa. O 
sistema imprime na tela a seguinte mensagem: “Não foi 
encontrado nenhum produto com as informações 
inseridas para pesquisa”. 
Requisitos 
Relacionados: 
RQNF02 – Disponibilidade do Sistema 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
 
15 
 
 
 
Tabela 3 - Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 1, 
do sistema Vendas GEEK. 
Identificação: Adicionar carrinho 
Escopo: Escolha Produto 
Descrição: Esse caso de uso permite que o Atendente/Cliente adicione 
produtos ao carrinho de compras para posteriormente efetivar 
a compra. 
Nível: Primário. 
Atores: Atendente do caixa/Cliente 
Interessados: Atendente do caixa/Cliente/Loja 
Pré-condição: Atendente estar autenticado o no sistema 
Pós-condição: O Atendente/Cliente tem o resultado da consulta 
Fluxo normal 1. O Atendente/Cliente preenche pelo menos um campo 
do formulário de pesquisa 
2. O sistema utiliza o dado de entrada e mostra dados 
semelhantes existentes no banco de dados do 
sistema. 
3. O sistema mostra na tela os resultados 
Fluxo alternativo: 1. Caso pressione o botão pesquisa sem preencher os 
dados. 
2. Exibir mensagem: “Pelo menos um dado deve ser 
informado”. 
3. Caso o sistema não encontre nenhum produto com o 
dado que foi preenchido na barra de pesquisa, exibir 
mensagem: “Nenhum produto foi encontrado”. 
Requisitos 
Relacionados: 
RQNF02 – Disponibilidade do Sistema 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
Tabela 4 - Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 1, 
do sistema Vendas GEEK. 
Identificação Adicionar carrinho 
Escopo: Escolha Produto 
Descrição: Este caso de uso permite que o atendente/cliente adicione 
produtos no carrinho. 
Nível: Primário. 
Atores: Atendente do caixa/Cliente 
Interessados: Atendente do caixa/Cliente/Loja 
Pré-condição: Atendente estar autenticado o no sistema 
Pós-condição: O carrinho de compras deve estar com produtos adicionados 
Fluxo normal 1. O Atendente/cliente pressiona o botão de detalhes 
do produto; 
2. O sistema direciona para a página com a lista de 
produtos escolhidos, criando uma folha de pedido 
3. O sistema armazena a informação em uma tabela 
de transição. 
16 
 
 
 
Requisitos 
Relacionados: 
RQNF02 – Disponibilidade do Sistema 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
Tabela 5 – Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 1, 
do sistema Vendas GEEK 
Identificação Remover carrinho 
Escopo: Escolha Produto 
Descrição: Este caso de uso permite o Atendente remover produtos do 
carrinho. 
Nível: Primário. 
Atores: Atendente do caixa/Cliente 
Interessados: Atendente do caixa/Cliente/Loja 
Pré-condição: Atendente estar autenticado o no sistema 
Pós-condição: O carrinho de compras deve estar com produtos adicionados 
Fluxo normal 1. O Atendente/cliente pressiona o botão de detalhes do 
produto; 
2. O sistema direciona para a página com a lista de produtos 
escolhidos, criando uma folha de pedido 
3. O sistema armazena a informação em uma tabela de 
transição. 
Requisitos 
Relacionados: 
RQNF02 – Disponibilidade do Sistema 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
Fig. 2 – Diagrama de caso de uso consulta estoque e reserva 
 
Fonte: Produzida pelos autores com base nos dados de (VERSOLATTO, Fábio Rossi, 2004.) 
 
17 
 
 
 
Tabela 6 – Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 2, 
do sistema Vendas GEEK 
Identificação FinalizarCompra 
Escopo: Finalização da compra pelo atendente 
Descrição: Finalização da compra pelo atendente, defini a forma de 
pagamento e pode reservar produtos para o cliente 
Nível: Primário 
Atores: Atendente, cliente e loja 
Interessados: Atendente, cliente e loja 
Pré-condição: O carrinho de comprar tem que estar cheio com dados de 
produtos inseridos 
Pós-condição: O Atendente finaliza o processo de compra no sistema 
ou reserva produtos disponíveis para reserva em estoque. 
Fluxo normal 1. O Atendente e Cliente informa a quantidade de cada 
produto que deseja adquirir 
2. O Atendente/Cliente pressiona o botão de finalização da 
compra. 
Requisitos 
Relacionados: 
RQNF2 – Disponível no estoque do sistema; 
RQNF3- Operadora de cartão disponível 
 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
 
Tabela 7 – Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 2, 
do sistema Vendas GEEK 
Identificação Consultar Estoque 
Escopo: Efetivação da compra 
Descrição: Este caso de uso permite que o sistema consulte a 
disponibilidade dos produtos no estoque do sistema 
Nível: Secundário 
Atores: Atendente/Cliente 
Interessados: Atendente/Cliente/Loja/Operadora 
Pré-condição: Ter dados de compras no carrinho 
Pós-condição: O Atendente/Cliente termina o processo de compra ou reserva 
o produto em estoque do sistema 
Fluxo normal: 1. O sistema consulta a disponibilidade de cada produto no 
estoque do sistema. 
2. O sistema retorna impresso na tela a disponibilidade de 
cada produto 
Fluxo 
alternativo: 
1. Caso o produto não tenha o suficiente no estoque do 
sistema, logo o sistema sugere a reserva do mesmo 
Requisitos 
Relacionados: 
RQNF2 – Disponibilidade do sistema; 
RQNF3- Operadora de cartão disponível. 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
Tabela 8 – Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 2, 
do sistema Vendas GEEK 
18 
 
 
 
Identificação Reservar produto 
Escopo: Efetivação da compra 
Descrição: Este caso de uso permite o Atendente e cliente reservar 
produtos disponíveis para reserva, caso de produtos raros 
apenas para colecionadores. 
Nível: Secundário 
Atores: Atendente/Cliente 
Interessados: Atendente/Cliente/Loja/Operadora de cartão 
Pré-condição: Ter dados de compras no carrinho 
Pós-condição: Ter feito a reserva do produto no estoque do sistema 
Fluxo normal 1. O Atendente com o cliente pressiona botão de reserva do 
produto; 
2. – O sistema reserva o produto e a quantidade solicitada 
pelo cliente 
Requisitos 
Relacionados: 
RQNF2 – Disponibilidade do sistema; 
RQNF3- Operadora de cartão disponível 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
 
Tabela 9 – Requisitos não funcionais de acordo com o caso de uso mostrado na da figura 2, 
do sistema Vendas GEEK 
Identificação Enviar dados do cartão a financeira dos cartões 
Escopo: Efetivação da compra 
Descrição: Neste caso de uso envia os dados do cartão do cliente para 
serem validados na operadora de cartões 
Nível: Secundário 
Atores: Atendente/Cliente 
Interessados: Atendente/Cliente/Loja/Operadora de cartão 
Pré-condição: Ter dados de compras no carrinho 
Pós-condição: Efetivação da compra mediante autorização da operadora de 
cartão 
Fluxo normal 1. O Atendente solicita os dados do cartão, caso seja 
débito ou crédito; 
2. O cliente informa os dados; 
3. Após o cliente passar o cartão na máquina da operadora 
de cartão; 
4. O atendente pressiona o botão autorizar a compra; 
5. O sistema envia dos dados para a operadora de cartão; 
6. O sistema exibe mensagens informando que a compra 
foi realizada; 
Fluxo-
Alternativo 
1. Se o Atendente pressiona o botão de Autorizar sem os 
dados da operadora de cartão a compra não é efetivada. 
Requisitos 
Relacionados: 
RQNF2 – Disponibilidade do sistema; 
RQNF3- Operadora de cartão disponível 
Fonte: Produzida pelos autores com base nos dados de (BOURQUE; FAIRLEY, 2004.) 
 
19 
 
 
 
2.11 Contexto de uso 
 
Contexto de uso é uma descrição detalhada dos requisitos de um sistema de 
software, utilizando uma determinada metodologia. 
Em engenharia de software, qualquer modelo de processos é importante 
ressaltar a problemática referente aos sistemas, definir: quem produz o que, como e 
quando: 
Quem? 
O sistema será utilizado por funcionários e proprietário da loja, através de login 
e senha. 
O que? 
O sistema Venda GEEK será utilizado para efetuar vendas dos produtos físicos 
da loja física de jogos eletrônicos. 
Onde? 
Será utilizado nos computadores da loja física 
 
2.12 Regras de Negócio 
 
Dexter (2013) regras de negócio é o que define a forma de fazer o negócio, 
refletindo a política interna, o processo definido ou as regras básicas de conduta. Ou 
seja, é um conjunto de instruções que os usuários já seguem e que o sistema a ser 
desenvolvido deve comtemplar. Restrições, validações, condições e exceções do 
processo são exemplos clássicos de regras de negócio. Uma regra de negócio não 
necessariamente será refletida no sistema como uma funcionalidade, mas ela com 
certeza determinará o comportamento de uma ou mais funcionalidades do sistema. 
 
Para cada caso de uso será definida uma regra de negócio a ser aplicada: 
 
 
 
 
 
 
 
 
 
 
 
20 
 
 
 
Tabela 10 – Tabela de Regra de Negócios do sistema Venda GEEK. 
Identificação: RGN01- Acesso ao Sistema 
Descrição: Todo o acesso ao sistema será feito através de login e senha. 
Fonte: Coordenador de canais de cliente/Autoatendimento 
Histórico: 01/06/2021 
Identificação: RGN03- Cadastro de produtos 
Descrição: O estoquista cadastra os produtos que serão vendidos na loja, 
os quais deverão ser divididos por categorias: jogos, acessórios 
e produtos GEEK. 
Para todos os produtos devem ser inseridos código de barras, 
nome do produto, categoria, fabricante, quantidade e valor do 
produto. Para jogos e acessórios deve ser informado qual 
plataforma será utilizada e os prazos e garantias do produto. 
Fonte: Coordenador de canais de cliente/Estoquista 
Histórico: 01/06/2021 
Identificação: RGN04- Cadastro de clientes 
Descrição: Os cadastros dos clientes devem possuir: código, RG, CPF, 
nome, data do cadastro, endereço, telefone e e-mail do cliente 
Fonte: Coordenador de canais de cliente/Autoatendimento 
Histórico: 01/06/2021 
Identificação: RGN05- Fluxo do Pedido de vendas 
Descrição: O pedido de vendas devera possuir todos os dados dos clientes 
e todos os produtos adquiridos. Com endereço para entrega. 
Formas de pagamento (dinheiro/cartão). Com código único. 
Data da venda. O status de pagamento. 
Fonte: Coordenador de canais de cliente/Autoatendimento 
Histórico: 01/06/2021 
Identificação: RGN06- Exclusão de produto no pedido de vendas 
Descrição: Apenas o supervisor pode excluir o produto da venda caso o 
cliente não queira. Através de login e senha. 
Fonte: Supervisor de canais de cliente 
Histórico: 01/06/2021 
Identificação: RGN07- Cancelamento de venda realizada 
Descrição: Apenas o supervisor pode cancelar a venda. Através de login e 
senha. 
Fonte: Supervisor de canais de cliente 
Histórico: 01/06/2021 
Identificação: RGN06- Consulta de preço de produto 
Descrição: Apenas o atendente poderá consultar preço de produto. 
Fonte: Autoatendimento / Atendente 
Histórico: 01/06/2021 
Fonte: Produzida pelos autores com base nos dados de (BEZERRA, 2006.) 
 
 
 
 
21 
 
 
 
2.13 Diagrama de classes de análise (Boundary, Control, Entity) 
 
Bezerra (2006) segundo o autor o objeto tem a obrigação de cumprir sua função 
no sistema, porem em alguns casos, não consegue de forma autônoma. 
São divididos em três grupos de responsabilidade: Classe entidade, classe de 
controle e classe de fronteira. A forma de organização dessas classe, que também 
são chamadas de classes de análise. De acordo com o princípios de orientaçãoa 
objetos: divisão de responsabilidades. A seguir no próximo tópico 2.14 o Diagrama de 
classes de análise juntamente com o Modelo de entidade relacional do sistema 
Vendas Geek. 
 
2.14 Modelo de Entidade Relacional (MER) 
 
O modelo entidade relacionamento (também chamado ER, ou simplesmente 
MER), como o nome sugere, é um modelo conceitual utilizado na engenharia de 
software para descrever os objetos e 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 a estrutura que possuirá o banco de dados da 
aplicação. A seguir o Modelo de entidade relacional do sistema e as entidades 
relacional Vendas Geek. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
22 
 
 
 
Fig. 3 – UML – Modelo de entidade relacional com as entidades de classes 
 
 
Fonte: Produzida pelos autores com base nos dados de (Object Management Group - OMG.) 
 
 
 
 
23 
 
 
 
3 CONCLUSÃO 
 
A presente pesquisa tem como objetivo principal a análise e levantamento de 
requisitos para a criação de um sistema para uma loja Geek, auxiliando no controle, 
gerenciamento e vendas, utilizando metodologias e conceitos abordados nas 
disciplinas estudadas neste bimestre de Análise de Sistemas Orientada a Objetos, 
Banco de Dados e Gestão Estratégica de Recursos Humanos. 
Nesta pesquisa ficou visível que ao identificar a problemática existente nos 
processos de negócios de uma empresa, torna-se nítido os requisitos não funcionais 
a serem identificados para um sistema. Todo problema que está relacionado a 
execução de tarefas corriqueiras do dia a dia de pessoas pode ser resolvido através 
de sistemas, desde que utilize as metodologias e conceitos de modelagem de 
Engenharias de Software e Análise de Sistemas Orientada a objetos para a realização 
do mesmo. 
Contudo é preciso ter metodologias e conceitos de modelagem de software, 
compreender os objetos e classes a serem transportados para os diagramas, levando 
ao desenvolvimento de abordagens, que podem ser utilizadas nas regras de negócios, 
como será e para quem é o sistema, como vai ser utilizado e logo chegar a produzir 
produtos com qualidade e manutenção mais rápidas. Possibilitando o acesso a 
qualquer desenvolvedor realizar manutenção. 
Outra vantagem importante ressaltar é a customização das interfaces, 
acessibilidade para usuários portadores de deficiência e diminuição dos custos para 
as empresas que solicitam estes sistemas. 
 
 
 
 
 
 
 
 
 
 
24 
 
 
 
REFERÊNCIAS 
Livros 
 
BOURQUE, P.; FAIRLEY, R. E. (Eds.). Guide to the Software Engineering Body of 
Knowledge, Version 3.0. Washington: IEEE Computer Society. Disponível em:< 
https://cs.fit.edu/~kgallagher/Schtick/Serious/SWEBOKv3.pdf >. Acesso em: 29 maio 
de 2021. 
 
CASTELL, M. Globalización, sociedad y política en la era de la Información. Bitácora 
Urbano Territorial, [S. l.], v. 4, n. 1, p. 42-53, 2000. Disponível em: 
https://revistas.unal.edu.co/index.php/bitacora/article/view/18812. Acesso em: 4 jun. 
2021. 
 
FOWLER, M.; SCOTT, K.; UML essencial: um breve guia para a linguagem-padrão 
de modelagem de objetos, Bookman, 2005. Disponível em:< 
https://plataforma.bvirtual.com.br/>. Acesso em: 27 maio de 2021. 
 
PFLEEGER, S. L.; "Engenharia de Software - Teoria e Prática", 2ª Edição, Makron 
Books, 2004. Disponível em:< https://plataforma.bvirtual.com.br/>. Acesso em: 29 
maio de 2021. 
 
PRESSMAN, R. S.; Software Engineering: A Practitioner's Approach, 7 ed., 
McGraw Hill, 2010. - SOMMERVILLE, I.; Software Engineering, 8. ed., Addison-
Wesley, 2007. Disponível em:< https://plataforma.bvirtual.com.br/>. Acesso em: 28 
maio de 2021. 
 
LARMAN, C.; Utilizando UML e padrões: uma introdução à análise e ao projeto 
orientados a objetos e ao desenvolvimento interativo, 3a edição, Bookman, 2008. 
Disponível em:< https://plataforma.bvirtual.com.br/>. Acesso em: 10 maio de 2021. 
 
VON MAYRHAUSER, A.; Software Engineering: Methods and Management, 
Academic Press, 1990. Disponível em:< https://plataforma.bvirtual.com.br/>. Acesso 
em: 09 maio de 2021. 
 
 
Sites 
 
Falta de vacina preocupa e PIB do Brasil deve crescer menos que média mundial 
em 2021, prevê OCDE. Disponível em:<https://www.bbc.com/portuguese/brasil-
57304465/>. Acesso em: 04 junho de 2021. 
 
Market Trends Point to Cloud POS as the Future. Disponível em:< 
https://www.lingaros.com/blog/market-trends-point-to-cloud-pos-as-the-future/>. 
Acesso em: 29 maio de 2021. 
 
Have We Reached Peak Legacy POS? Disponível em:< 
https://reformingretail.com/index.php/2018/08/28/have-we-reached-peak-legacy-
pos/>. Acesso em: 29 maio de 2021. 
 
25 
 
 
 
Cinco opções de sistemas para gestão em frente ao caixa. Disponível em: 
<https://www.codemoney.com.br/blog/5-opcoes-de-sistemas-para-gestao-de-frente-
de-caixa/>. Acesso em: 29 maio de 2021. 
 
DEXTRA. Requisito ou Regra de Negócio? São Paulo, 2013. Disponível em: 
<https://dextra.com.br/pt/requisito-ou-regra-de-negocio>. Acesso em: 30 maio de 
2021. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
26 
 
 
 
GLOSSÁRIO 
 
Termo: English Term: Descrição: 
Fronteira, Controle e 
Entidade. 
Boundary, 
Control, Entity 
As classes são divididas em três grupos de 
responsabilidade as classes: Classe entidade, classe 
de controle e classe de fronteira. A forma de 
organização dessas classe, que também são 
chamadas de classes de análise. De acordo com o 
princípios de orientação a objetos: divisão de 
responsabilidades 
Designer de Interface 
do usuário 
User Interface 
Design 
O design da interface do usuário (IU) se concentra em 
prever o que os usuários podem precisar fazer e 
garantir que a interface tenha elementos fáceis de 
acessar, entender e usar para facilitar essas ações. UI 
reúne conceitos de design de interação, design visual 
e arquitetura de informação. 
 
Firewall Firewall É uma solução de segurança baseada em hardware ou 
software (mais comum) que, a partir de um conjunto de 
regras ou instruções, analisa o tráfego de rede para 
determinar quais operações de transmissão ou 
recepção de dados podem ser executadas. 
Geek Geek 
É um anglicismo e uma gíria inglesa que se refere a 
pessoas peculiares ou excêntricas, fãs 
de tecnologia, eletrônica, jogos eletrônicos ou 
de tabuleiro, histórias em 
quadrinhos, mangás, livros, filmes e séries. 
Embora frequentemente considerado como um 
pejorativo, o termo é usado pelos jovens sem malícia 
e como uma fonte de orgulho. Seu significado evoluiu 
conotar "alguém que está interessado em um assunto 
(normalmente intelectual ou complexo) para sua 
própria causa". 
Marketplaces. Marketplaces. Marketplaces. 
Login Login Identificação em um campo preenchido no cadastro do 
usuário, que pode ser o nome do usuário, e-mail, CPF 
ou telefone para acesso ao sistema. 
Tablets Tablets É um dispositivo pessoal em formato de prancheta que 
pode ser usado para acesso à Internet, organização 
pessoal, visualização de fotos, vídeos, leitura de livros, 
jornais e revistas, para entretenimento com jogos e 
interação com pessoas distantes usando o Skype e o 
Hangouts. 
Usabilidade Usability Usabilidade é um termo usado para definir a facilidade 
com que as pessoas podem empregar uma ferramenta 
ou objeto a fim de realizar uma tarefa específica e 
importante. A usabilidade pode também se referir aos 
métodos de mensuração da usabilidade e ao estudo 
dos princípios por trás da eficiência percebida de um 
objeto.