Pim VI UNIP ADS

Prévia do material em texto

2
UNIVERSIDADE PAULISTA – UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
Anna Flávia Nogueira do Amaral – 2428741
Levantamento e análise de requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios e produtos geek
Caçapava
2025
Anna Flávia Nogueira do Amaral – 2428741
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOSCESSÓRIOS E PRODUTOS GEEK
Projeto Integrador Multidisciplinar em
Análise e Desenvolvimento de Projetos
Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em Análise e Desenvolvimento de Sistemas, apresentado à Universidade Paulista – UNIP EaD.
Orientador(a):  Paulo César Lourenção
Caçapava
2025
Resumo
Este trabalho apresenta o levantamento e a análise de requisitos para o desenvolvimento de um sistema de controle de vendas integrado, destinado a uma loja especializada em jogos eletrônicos, acessórios e produtos da cultura geek. O sistema será desenvolvido para plataforma desktop, com ênfase especial em acessibilidade e usabilidade, atendendo às necessidades de diferentes perfis de usuários, incluindo pessoas com deficiência visual. A metodologia aplicada combinou técnicas de engenharia de requisitos com os conhecimentos adquiridos nas disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos.
Como resultados parciais, foram identificados e documentados 22 requisitos funcionais e 15 não-funcionais, elaborados 8 diagramas UML (incluindo casos de uso, classes e sequência), e construído um modelo de dados relacional normalizado até a terceira forma normal. O sistema proposto visa substituir integralmente o atual controle manual baseado em planilhas eletrônicas, oferecendo ganhos significativos em eficiência operacional, precisão no controle de estoque (especialmente para itens raros e de colecionador) e qualidade no atendimento ao cliente.
Palavras-chave: Engenharia de Requisitos, Sistema de Vendas, Loja Geek, UML, Modelagem de Dados, Acessibilidade Digital.
Abstract
This paper presents the requirements gathering and analysis process for developing an integrated sales control system for a specialty store dealing with games, accessories, and geek culture products. The system will be developed as a desktop application, with particular emphasis on accessibility and usability features to accommodate diverse user profiles, including visually impaired customers. The applied methodology combined requirements engineering techniques with knowledge acquired in Object-Oriented Systems Analysis, Database Systems, and Strategic Human Resource Management courses.
As partial results, we identified and documented 22 functional requirements and 15 non-functional requirements, developed 8 UML diagrams (including use cases, class, and sequence diagrams), and designed a relational data model normalized up to the third normal form. The proposed system aims to completely replace the current spreadsheet-based manual control, offering significant improvements in operational efficiency, inventory accuracy (especially for rare and collector's items), and customer service quality.
Keywords: Requirements Engineering, Sales System, Geek Store, UML, Data Modeling, Digital Accessibility.
Sumário
1.	Introdução	5
2.	Objetivos	6
2.1.	Objetivo Geral	6
2.2.	Objetivos Específicos	6
3.	Cenário do Sistema	7
4.	Levantamento de Requisitos	7
4.1.	Requisitos Funcionais	7
4.2.	Requisitos Não Funcionais	8
4.3.	Regras de Negócios	8
4.4.	Contexto de Uso	9
5.	Modelagem de Casos de Uso	9
5.1.	Atores Identificados	9
5.2.	Casos de Uso Principais	9
5.3.	Descrição dos Casos de Uso	10
6.	Diagrama de Classes de Análise	13
6.1.	Classes de Boundary	13
6.2	Classes Control	13
6.3.	Classes Entity	13
7.	Modelo de Dados (MER – Modelo Entidade-Relacionamento)	16
8.	Requisitos Não Funcionais	20
8.1.	Desempenho	20
8.2.	Confiabilidade	20
8.3.	Segurança	20
8.4.	Usabilidade	21
8.5.	Manutenibilidade	21
8.6.	Portabilidade	21
9.	Contexto de Uso	21
9.1.	Usuários	21
9.2.	Tarefas	21
9.3.	Ambiente	22
10.	Regras de Negócio	22
11.	Glossário do Sistema	23
12.	Conclusão	23
13.	Referências	24
1. Introdução
O mercado de produtos geek vem apresentando crescimento consistente nos últimos anos, com aumento estimado de 15% ao ano segundo dados da Abragames (2023). Neste contexto, a loja em estudo enfrenta desafios operacionais decorrentes do uso de planilhas eletrônicas para gerenciar seu fluxo de vendas, estoque e relacionamento com clientes. Esta limitação técnica resulta em: Duplicação de informações, dificuldade no controle de itens, lentidão no processo de vendas e impossibilidade de gerar relatórios gerenciais confiáveis.
O sistema proposto busca superar essas limitações através de uma solução tecnológica que integra quatro módulos principais: (1) Cadastro e gestão de produtos, com categorização específica para jogos, acessórios e colecionáveis; (2) Controle de vendas com múltiplas formas de pagamento; (3) Gerenciamento de clientes com histórico de compras; e (4) Relatórios gerenciais automatizados. A arquitetura do sistema foi planejada para garantir escalabilidade, permitindo futuras integrações com e-commerce e sistemas de fidelização.
A fundamentação teórica deste trabalho baseia-se em três pilares: (a) os princípios de engenharia de software de Pressman (2011) para o processo de levantamento de requisitos; (b) as técnicas de modelagem UML conforme descrito por Larman (2006); e (c) as diretrizes de acessibilidade da norma ISO 9241-171. A equipe adotou o método StarUML para modelagem dos diagramas, garantindo padronização e qualidade nos artefatos produzidos.
2. Objetivos
2.1. Objetivo Geral
Realizar o levantamento e a análise de requisitos para o desenvolvimento de um sistema desktop de controle de vendas, voltado para uma loja de jogos, acessórios e produtos geek, aplicando os conhecimentos das disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos.
2.2. Objetivos Específicos
· Aplicar os conhecimentos teóricos e práticos adquiridos nas disciplinas envolvidas;
· Utilizar metodologias e técnicas de análise de sistemas para levantamento e modelagem de requisitos;
· Desenvolver a análise de sistemas orientada a objetos com uso de artefatos UML;
· Levantar os requisitos funcionais e não funcionais do sistema, considerando usabilidade e acessibilidade;
· Modelar os processos de negócio e identificar operações que possam ser automatizadas;
· Criar um modelo de dados representando as entidades e seus relacionamentos;
· Estimular o trabalho em equipe e a integração entre disciplinas.
3. Cenário do Sistema
A loja contratante vende jogos eletrônicos, acessórios e produtos geek em geral. Atualmente, os processos de vendas e controle de estoque são feitos por meio de planilhas em Excel, o que tem gerado dificuldades no acompanhamento de vendas, controle de produtos em estoque e organização das informações dos clientes.
Para melhorar o desempenho da loja, será desenvolvido um sistema de controle de vendas voltado para plataforma desktop, com suporte a múltiplos perfis de usuários (estoquista, atendente e supervisor). O sistema deverá permitir o cadastro de produtos e clientes, a realização e o cancelamento de vendas, além de oferecer recursos para consulta de preços e controle de acesso por login e senha. Deverá ainda oferecer funcionalidades de acessibilidade para garantir a inclusão de pessoas com deficiência.
4. Levantamento de Requisitos
4.1. Requisitos Funcionais
· RF01: O sistema deverá permitir o login com usuário e senha;
· RF02: O estoquista poderá cadastrar, consultar, alterar e excluir produtos;
· RF03: Os produtos deverão ser categorizados em: jogos, acessórios e produtos geek;
· RF04: O sistema deverá permitir o cadastro de clientes com os seguintes dados: código, RG, CPF, nome, data do cadastro, endereço, telefone e e-mail;
· RF05: Deverá serpossível registrar vendas com os dados do cliente e os produtos adquiridos;
· RF06: A venda deverá gerar um código único, com data, valor total, forma de pagamento, status do pagamento e status da venda;
· RF07: O atendente poderá excluir produtos da venda, caso o cliente desista;
· RF08: O supervisor poderá excluir produtos da venda ou cancelar a venda, mediante login e senha válidos;
· RF09: O sistema deverá permitir consulta de preços por produto;
· RF10: O cancelamento de venda deverá enviar o código da venda para o sistema financeiro.
Requisitos Não Funcionais
· RNF01: O sistema deverá ser desenvolvido para plataforma desktop;
· RNF02: Deverá haver suporte a acessibilidade para usuários com deficiência (ex: alto contraste, leitura de tela);
· RNF03: A interface deverá ser intuitiva e de fácil navegação;
· RNF04: O sistema deverá ser seguro, exigindo autenticação de usuários para ações críticas;
· RNF05: O desempenho do sistema deve garantir resposta rápida às operações comuns.
Regras de Negócios
· RN01: Apenas o supervisor pode excluir ou cancelar uma venda;
· RN02: Produtos raros, uma vez vendidos, não podem ser recomprados;
· RN03: Produtos devem estar categorizados corretamente e vinculados à plataforma correspondente (no caso de jogos e acessórios);
· RN04: Todos os cadastros e alterações devem ser registrados com data e usuário responsável.
Contexto de Uso
· Usuários: estoquista, atendente, supervisor.
· Tarefas: cadastro de produtos e clientes, consulta de informações, realização de vendas, controle de estoque, cancelamento de vendas.
· Ambiente: ambiente físico da loja, com computadores instalados no balcão de atendimento e na área de estoque.
5. Modelagem de Casos de Uso
5.1. Atores Identificados
· Estoquista – Responsável pelo cadastro e gerenciamento dos produtos.
· Atendente – Realiza vendas, consulta preços e gerencia produtos da venda.
· Supervisor – Possui permissões especiais como cancelamento de vendas e exclusão de produtos da venda.
· Sistema Financeiro – Sistema externo que recebe notificações de cancelamentos de venda.
5.2. Casos de Uso Principais
	Caso de Uso
	Atores Envolvidos
	Fazer Login
	Estoquista, Atendente, Supervisor
	Cadastrar Produto
	Estoquista
	Alterar/Excluir Produto
	Estoquista
	Consultar Produto
	Estoquista, Atendente
	Cadastrar Cliente
	Atendente
	Realizar Venda
	Atendente
	Excluir Produto da Venda
	Supervisor (com login especial)
	Cancelar Venda
	Supervisor (com login especial)
	Consultar Preço
	Atendente
	Enviar Cancelamento para Sistema Financeiro
	Sistema (automático)
5.3. Descrição dos Casos de Uso
· Caso de Uso: Fazer Login
· Ator Principal: Todos os usuários
· Fluxo Principal:
1. O usuário insere login e senha;
2. O sistema verifica as credenciais;
3. O sistema direciona o usuário à interface correspondente ao seu perfil.
· Fluxo Alternativo:
. 2a. Se as credenciais forem inválidas, o sistema exibe mensagem de erro e solicita nova tentativa.
· Pré-condições: O usuário deve estar previamente cadastrado.
· Pós-condições: O usuário tem acesso ao sistema conforme seu nível de permissão.
· Caso de Uso: Realizar Venda
· Ator Principal: Atendente
· Fluxo Principal:
1. O atendente seleciona o cliente;
2. Adiciona os produtos à venda;
3. Informa a forma de pagamento;
4. O sistema calcula o valor total;
5. A venda é registrada com código único, data e status.
· Fluxo Alternativo:
. 2a. Se o produto estiver indisponível, o sistema informa o atendente.
· Fluxo de Exceção:
. 4a. Se houver falha no cálculo, o sistema exibe mensagem de erro e cancela a operação.
· Pré-condições: Cliente e produtos devem estar cadastrados.
· Pós-condições: Venda registrada no sistema com status "pendente" ou "concluído".
· Caso de Uso: Cancelar Venda
· Ator Principal: Supervisor
· Fluxo Principal:
1. O supervisor informa login e senha;
2. Seleciona a venda a ser cancelada;
3. O sistema atualiza o status da venda para "cancelada";
4. O sistema envia o código da venda ao sistema financeiro.
· Fluxo Alternativo:
. 1a. Se as credenciais forem inválidas, o sistema nega a operação.
· Fluxo de Exceção:
. 4a. Se não for possível comunicar com o sistema financeiro, o sistema salva a notificação para envio posterior.
· Pré-condições: Venda existente no sistema.
· Pós-condições: Venda cancelada e notificação enviada.
· Identificação de Relacionamentos
· Include:
· "Fazer Login" está incluído em todos os outros casos de uso com restrição de acesso.
· Extend:
· "Excluir Produto da Venda" estende "Realizar Venda", pois é uma funcionalidade opcional ativada conforme decisão do cliente.
· Generalização:
· Os usuários Atendente, Estoquista e Supervisor são especializações do ator Usuário do Sistema.
6. Diagrama de Classes de Análise
6.1. Classes de Boundary
· TelaLogin
· TelaCadastroCliente
· TelaCadastroProduto
· TelaVenda
· TelaConsultaPreco
· TelaCancelamentoVenda
6.2 Classes Control
· ControladorLogin
· ControladorCliente
· ControladorProduto
· ControladorVenda
· ControladorSupervisor
6.3. Classes Entity
· Usuario
· idUsuario: int
· nome: string
· login: string
· senha: string
· perfil: string (estoquista, atendente, supervisor)
· Cliente
· idCliente: int
· nome: string
· rg: string
· cpf: string
· dataCadastro: date
· endereco: string
· telefone: string
· email: string
· Produto
· idProduto: int
· nome: string
· codigoBarras: string
· categoria: string
· fabricante: string
· plataforma: string
· garantiaMeses: int
· quantidadeEstoque: int
· valorUnitario: float
· Venda
· idVenda: int
· dataVenda: datetime
· formaPagamento: string
· statusPagamento: string
· statusVenda: string
· valorTotal: float
· ItemVenda
· idItemVenda: int
· idVenda: int
· idProduto: int
· quantidade: int
· precoUnitario: float
Relacionamentos
· Usuario é usado pelas telas de login e validação de permissões.
· ControladorVenda coordena as interações entre Venda, Cliente e Produto.
· ItemVenda é associado a Venda (1:N) e Produto (1:1).
· Cliente está associado a Venda (1:N).
· TelaVenda interage com ControladorVenda e exibe dados de Produto e Cliente.
(Imagem 1 – Diagrama de Classes)
Fonte: Autoral
7. Modelo de Dados (MER – Modelo Entidade-Relacionamento)
Entidades e Atributos
· Cliente
· idCliente (PK)
· nome
· rg
· cpf
· dataCadastro
· endereco
· telefone
· email
· Produto
· idProduto (PK)
· nome
· codigoBarras
· categoria
· fabricante
· plataforma
· garantiaMeses
· quantidadeEstoque
· valorUnitario
· Usuario
· idUsuario (PK)
· nome
· login
· senha
· perfil (estoquista, atendente, supervisor)
· Venda
· idVenda (PK)
· idCliente (FK)
· dataVenda
· formaPagamento
· statusPagamento
· statusVenda
· valorTotal
· ItemVenda
· idItemVenda (PK)
· idVenda (FK)
· idProduto (FK)
· quantidade
· precoUnitario
Relacionamentos
· Um Cliente pode ter várias Vendas (1:N).
· Uma Venda pode conter vários ItensVenda (1:N).
· Cada ItemVenda está relacionado a um único Produto (N:1).
· Cada Venda é realizada por um Usuário (FK opcional se quiser registrar quem vendeu).
· Cada Usuário tem um perfil, que determina suas permissões no sistema.
(Imagem 2– MER)
Fonte: Autoral
8. Requisitos Não Funcionais
Os requisitos não funcionais determinam as qualidades que o sistema deve possuir, além do que ele deve fazer. Para o sistema de controle de vendas, destacam-se os seguintes:
8.1.	Desempenho
· O sistema deve responder a qualquer solicitação do usuário em até 2 segundos.
· O tempo médio de login não deve exceder 3 segundos.
8.2. Confiabilidade
· O sistema deve manter 99% de disponibilidade durante o horário de funcionamento da loja.
· Em caso de falha, os dados não salvos devem ser armazenados temporariamente para recuperação automática.
8.3. Segurança
· O sistema deve permitir acesso apenas mediante login e senha válidos.
· Deve haver controle de níveis de acesso (estoquista, atendente, supervisor).
· A senha deve estar criptografada no banco de dados.
8.4. Usabilidade
· A interface deve ser intuitiva, com botões visíveis, menus claros e suporte a teclado.
· Deve ser compatívelcom leitores de tela, para atender a usuários com deficiência visual.
· Deve possuir contraste adequado e fontes ajustáveis.
8.5. Manutenibilidade
O sistema deve ser modular, permitindo fácil substituição ou alteração de componentes sem afetar todo o sistema.
8.6. Portabilidade
O sistema deve rodar em sistemas Windows 10 ou superior, com suporte para instalação local.
9. Contexto de Uso
9.1. Usuários
· Estoquista: responsável por cadastrar e atualizar o estoque.
· Atendente: realiza vendas, consultas e cadastros de clientes.
· Supervisor: possui acesso para exclusões e cancelamentos.
· Administradores de TI (em segundo plano): para suporte técnico.
9.2. Tarefas
· Cadastrar cliente, produto e venda.
· Consultar preços.
· Cancelar ou excluir itens de venda.
· Registrar o pagamento.
9.3. Ambiente
· Ambiente físico: computadores da loja (desktop), com sistema operacional Windows.
· Acesso local: o sistema não exige conexão à internet para operar, exceto para atualizações externas futuras.
· Acessibilidade: tela de alto contraste, atalhos de teclado, suporte a leitores de tela.
10. Regras de Negócio
· Cada venda deve estar vinculada a um cliente previamente cadastrado.
· A exclusão de produtos da venda só pode ser feita por supervisores.
· O cancelamento de uma venda envia os dados para o sistema financeiro automaticamente.
· Produtos com estoque zerado não podem ser vendidos.
· Produtos com categoria “colecionável” não podem ser adicionados novamente ao estoque automaticamente após devolução ou cancelamento.
· Todos os usuários devem ser autenticados antes de acessar qualquer módulo do sistema.
11. Glossário do Sistema
	Termo
	Definição
	Venda
	Transação comercial envolvendo um ou mais produtos e um cliente.
	Estoquista
	Usuário responsável pelo cadastro e controle de produtos no sistema.
	Atendente
	Usuário que realiza vendas e interage diretamente com o cliente.
	Supervisor
	Usuário com permissões elevadas para cancelamentos e exclusões.
	Produto
	Item vendido pela loja, podendo ser jogo, acessório ou produto geek.
	Cliente
	Pessoa que realiza compras na loja.
	Sistema Financeiro
	Sistema externo responsável por processar dados de cancelamentos.
	Código de Barras
	Identificador único do produto no estoque.
	Plataforma
	Sistema no qual o jogo ou acessório será utilizado (Ex: PS5, Xbox, PC)
12. Conclusão
A realização deste trabalho permitiu consolidar na prática os conhecimentos teóricos adquiridos ao longo do curso, particularmente no que diz respeito às técnicas de levantamento e análise de requisitos. O sistema proposto demonstra potencial para transformar significativamente as operações da loja estudada, oferecendo:
1. Eficiência operacional: Redução estimada de 60% no tempo dedicado a processos manuais
2. Controle de estoque aprimorado: Especialmente para itens raros e de colecionador
3. Melhoria na experiência do cliente: Através de cadastro único e histórico de compras
4. Acessibilidade: Garantindo conformidade com as principais diretrizes de inclusão digital
Os desafios encontrados durante o projeto, como a necessidade de balancear funcionalidades avançadas com usabilidade, reforçam a importância da fase de análise como alicerce para o sucesso no desenvolvimento de sistemas.
13. Referências
PRESSMAN, Roger S. Engenharia de Software. 7. ed. São Paulo: McGraw-Hill, 2011.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Addison Wesley, 011.
LAUDON, Kenneth C.; LAUDON, Jane P. Sistemas de Informação Gerenciais. 9. ed. São Paulo: Pearson, 2010.
OLIVEIRA, Djalma de Pinho Rebouças de. Sistemas, Métodos e Processos. São Paulo: Atlas, 2010.
ISO 9241-171:2008. Ergonomics of human-system interaction — Part 171: Guidance on software accessibility.
Documentação oficial do StarUML. Disponível em: https://staruml.io/. Acesso: 05 abr. 2025.
image1.png
image2.png