Exemplo PIM VI - LOJA DE VENDAS DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK

Prévia do material em texto

6
21
unip eAd
projeto integrado multidisciplinar
análise e desenvolvimento de sistemas
LOJA DE VENDAS DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK
florianópolis/sc
2020
nome: xxxxxxx
LOJA DE VENDAS DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK
Projeto Integrado Multidisciplinar
para obtenção do título de graduação
 em Análise e Desenvolvimento de Sistemas
apresentado à Universidade Paulista – UNIP EAD.
Orientador(a): Patrícia Toffolo
florianópolis/sc
2020
RESUMO
Este trabalho faz toda a projeção de um software para loja de vendas de jogos, acessórios e produtos geek, visando gerir o estoque e as vendas da loja, a partir de uma documentação bem elaborada, toda realizada com base em análise de desenvolvimento de sistemas orientada à objetos. Realizado o levantamento de todos os requisitos funcionais, não funcionais, de usabilidade e acessibilidade, e posteriormente utilizando ferramentas de UML, para definição dos casos de uso, o diagrama de classes e ainda o modelo de entidade relacionamento, além da definição de todo o cenário onde será implantado o software, suas regras de negócio e uma rápida pesquisa de mercado de soluções já disponíveis no mercado.
Palavras-chave: sistema para reservas, programação orientada à objetos, projeto de software, roteiro de testes, MPS-BR.
abstract
	This work makes the entire projection of software for the store selling games, accessories and geek products, aiming to manage the store's sales and stock, based on well-prepared documentation, all carried out based on oriented system development analysis. to objects. A survey of all functional, non-functional, usability and accessibility requirements was carried out, and later using UML tools, to define the use cases, the class diagram and also the relationship entity model, in addition to defining the entire scenario. where the software, its business rules and a quick market research of solutions already available on the market will be implemented.
Keywords: object-oriented development analysis, UML, use cases, class diagram, MER.
SUMÁRIO
INTRODUÇÃO ........................................................................................................... 6
1 CENÁRIO PROPOSTO ........................................................................................... 7
2 FUNCIONALIDADES DE NEGÓCIO DO SISTEMA............................................... 8
3 PESQUISA DE MERCADO ..................................................................................... 9
4 CONTEXTO DE USO ............................................................................................ 10
5 PROCESSOS DE NEGÓCIO ................................................................................ 11
5.1 PROCESSO DE CONTROLE DE ACESSO DE USUÁRIOS............................... 11
5.2 PROCESSO DE CONTROLE DE ESTOQUE ..................................................... 12
5.3 PROCESSO DE CADASTRO DE CLIENTE ........................................................ 12
5.4 PROCESSO DE CONTROLE DE VENDAS ........................................................ 13
6 CASOS DE USO .................................................................................................... 13
6.1 ESPECIFICAÇÕES DOS CASOS DE USO ........................................................ 15
7 REQUISITOS NÃO FUNCIONAIS ......................................................................... 18
8 REQUISITOS DE USABILIDADE .......................................................................... 19
9 ACESSIBILIDADE ................................................................................................. 20
10 REGRAS DE NEGÓCIO ...................................................................................... 20
11 DIAGRAMA DE CLASSES .................................................................................. 22
11.1 ENTITY, CONTROL E BOUNDARY................................................................... 23
11.2 MODELO DE DIAGRAMA DE CLASSES .......................................................... 23
12 MODELO DE DADOS (MER) .............................................................................. 24
12.1 ENTIDADE ........................................................................................................ 25
12.2 ATRIBUTOS ...................................................................................................... 25
12.3 RELACIONAMENTOS ...................................................................................... 25
12.4 MODELO DE DADOS ....................................................................................... 26
CONCLUSÃO ........................................................................................................... 28
REFERÊNCIA BIBLIOGRÁFICA ............................................................................. 29
GLOSSÁRIO ............................................................................................................ 30
INTRODUÇÃO
A partir de uma revisão bibliográfica realizada, esse projeto tem como finalidade elaborar toda a documentação e análise para o desenvolvimento de um sistema que será implantado em uma loja de vendas de jogos, acessórios e produtos geek. A loja que até o momento contabiliza suas vendas e faz todo o controle de estoque através de planilhas eletrônicas percebeu que com o crescimento das vendas, o aumento na diversidade dos produtos comercializados, o aumento dos clientes à procura de produtos especializados e difíceis de encontrar, tudo isso em conjunto, trouxe a necessidade de adquirir um software para controle automatizado de tais funcionalidades.
Toda a documentação abordada foi realizada em conjunto com os usuários finais do software, analisando o dia-a-dia, as tarefas realizadas, como são realizadas, verificando os requisitos funcionais, não funcionais, além dos requisitos de usabilidade.
A pedido da diretoria da loja, também foram abordados requisitos de acessibilidade, para que o sistema seja utilizável também por pessoas com deficiências físicas moderadas.
O sistema deverá gerenciar toda o controle de estoque dos produtos, iniciando pelo cadastro ao realizar as compras, incluindo aqui qualificação do produto em relação à sua raridade, para que apenas clientes colecionadores tenham acesso a esses produtos. Também deve gerenciar o cadastro dos clientes, mantendo um histórico de compras, bem como todo o processo de venda, desde seu cadastro, como a conexão com Operadoras de cartões para pagamentos realizados com cartões, sua integração ao Sistema Financeiro e emissão de recibos.
Deve contar ainda com um controle de acessos que permitam operações apenas para determinados grupos de usuários, como por exemplo, permitir cancelamento de pedido de vendas, ou até mesmo a exclusão de itens de um pedido, somente com senha de supervisor/administrador.
A documentação elaborada teve como base o cenário atual da loja, todos os seus processos de negócio, fluxos, e ainda foram verificadas soluções encontradas no mercado, de softwares já existentes, para comparativo de melhores opções para o cliente.
Já na parte final da documentação do software, destaca-se a criação dos casos de uso, modelo e especificação, a criação do diagrama de classes e o modelo de entidade relacionamento, com base na especificação de toda a regra de negócio, visando facilitar e desenhar previamente todo o sistema, para que, no momento do desenvolvimento, as regras estejam claras e a codificação seja realizada em um tempo menor.
1 CENÁRIO PROPOSTO
O cenário proposto mostra a necessidade de uma loja de vendas de produtos de jogos, acessórios e produtos geek, para controle de estoque e de vendas de seus produtos, atualmente controlado por meio de planilhas eletrônicas. Com o crescimento das vendas, aumento na variedade e qualificação dos produtos e o aumento de clientes com interesse, as planilhas eletrônicas se tornaram ineficientes e sem nenhum tipo de segurança, incluindo fragilidade ao negócio e perda de informações importantespara a loja. A partir de então, verificou-se a necessidade de implantar um sistema para automatizar algumas funcionalidades do processo de venda, gerenciamento do estoque e consequentemente um maior controle sobre todo o negócio. O sistema inicialmente irá rodar em uma plataforma desktop e deve possuir acessibilidade em todo conteúdo, incluindo funcionalidades para atender usuários com certa deficiência. O acesso ao sistema será realizado através de usuário e senha, previamente cadastrados, podendo os usuários serem enquadrados em supervisores e atendentes. O sistema será composto por um cadastro de produtos, os quais serão categorizados, com a finalidade de gerir o estoque. Contará com cadastro de clientes, com informações importantes e ainda classificação para colecionadores. Cadastro de pedidos de vendas, com controle de exclusão ou cancelamentos, permitidos apenas para usuários supervisores, com integração ao sistema financeiro. Controle de vendas de produtos raros e/ou colecionáveis somente para clientes especiais.
2 funcionalidades de negócio do sistema
Inicialmente o sistema contará com as seguintes funcionalidades de negócio:
- Controle de acesso para usuário do sistema, com cadastro, login e senha diferenciados para usuários (colaboradores) internos da loja, criando diferentes níveis de permissão de acesso e controle, com permissões específicas para usuários supervisores;
- Controle de estoque, onde os produtos serão cadastrados pelo estoquista da loja, contendo toda identificação dos produtos, separados por categorias, e a partir de então será feita toda a consolidação do inventário, com a diminuição de estoque por conta de vendas ou perdas, alteração e exclusão de produtos;
- Cadastro de clientes, contendo todas as informações pertinentes aos clientes;
- Controle de venda, contendo os dados do cliente e os produtos adquiridos por ele. Nas operações de venda, para exclusão de um produto dentro do pedido de venda, ou até mesmo o cancelamento total da venda, deverá ser digitada a senha de um usuário supervisor para maior segurança e integridade das informações;
3 PESQUISA DE MERCADO
Em meados de 1910, nos Estados Unidos, iniciou-se a pesquisa de mercado, a qual teve maior ascensão nas décadas de 50 e 60. Para Bacha (1998, p.36), o Brasil teve seu início em pesquisas de mercado integrado à economia brasileira e em particular ao desenvolvimento da indústria. 
Para pesquisa de mercado deste projeto, foi utilizada a pesquisa dos softwares disponíveis no mercado, que oferecem as funcionalidades semelhantes ao solicitado pela loja de jogos, e verificou-se que existem inúmeros softwares disponíveis. Esses softwares gerenciam o relacionamento com o cliente de diversas empresas, bem como o controle de estoque dos produtos, pelo Brasil e mundo afora, e foram listados abaixo:
- Pipedrive: software de gestão de vendas amplamente utilizado no mundo todo, atualmente utilizado em nuvem, possui um valor razoável de aquisição e mensalidades que são cobradas por usuário, ou seja, o valor aumenta à medida que a empresa também aumenta a quantidade de usuários. A empresa promete aumentar em até 28% as vendas de seus clientes. Há vários relatos de que a ferramenta não é muito intuitiva em seu uso, e que, o acesso ao suporte se torna complicado, demorado, e muitas vezes nem sequer é respondido, devido ao grande número de clientes.
- Sage Start: recomendados para empresas de médio e grande porte, suporta grandes quantidades de massa de dados e trabalha de forma eficiente em rede. Pela propaganda da empresa fornecedora, diz ser o melhor sistema de controle de estoque do mercado. Porem ao pesquisar a satisfação de clientes, é fácil observar que o sistema apresenta diversos bugs e o relacionamento com seus clientes é demorado e ineficaz.
- Smash Controle de Estoque: no ramo dos softwares livres, encontra-se o Smash. Esse software é muito simples e não chega a ser dos mais modernos, utiliza uma interface bastante antiquada e não intuitiva de uso, tendo como uma das poucas vantagens, o fato de não ter custo para quem o usa.
O software que pretendemos disponibilizar para esse projeto da loja de vendas de jogos, acessórios e produtos geek, será criado e planejado em conjunto com os usuários da loja, entre clientes e funcionários, sendo moldado de acordo com as necessidades deles, que são realmente o público a ser atingido. O mesmo poderá ser otimizado, atualizado e evoluído com o passar do tempo e com o aumento da loja, tendo também o seu custo flexível em razão da demanda do próprio cliente. Terá uma interface simples e intuitiva, um acompanhamento próximo durante toda a implantação do sistema, e acima de tudo, contará sempre com um suporte amigo, rápido e próximo, de fácil acesso. Dessa forma, o projeto atual oferece muitas vantagens para a loja de vendas, sendo a melhor solução apresentada e a certeza de um relacionamento entre empresa fornecedora e contratante.
4 contexto de uso
A realização da análise sobre o contexto de uso do problema, sendo nesse projeto a delimitação do que o sistema precisa para atender demandas da loja de vendas, visa descrever o contexto em que um produto, serviço ou sistema está inserido. Essa análise pode ser originada a partir de respostas para as perguntas: Quem irá usar (usuário)? O que será realizado (tarefa)? Onde (ambiente)?
A loja de vendas de jogos, acessórios e produtos geek possui essencialmente o processo de vendas como um todo, que abrange a compra dos produtos para revenda, atendimento aos clientes e efetivação de vendas.
- QUEM? Temos como pessoas envolvidas os clientes que vão até a loja a procura de produtos que lhes interessem, os funcionários e proprietários da loja, que são atendentes/vendedores ou administrativos/supervisores.
- TAREFAS? As tarefas podem ser divididas pelos funcionários e proprietários da loja de vendas, da forma que segue:
- Os atendentes/vendedores são responsáveis pelo atendimento ao cliente, realizando durante o atendimento, consulta de preços, consulta de disponibilidade em estoque e a prestação de toda informação ao cliente. Em caso de consolidação da venda, o atendente/vendedor deverá consultar se o cliente já possui cadastro na loja, e atualizá-lo ou cadastrá-lo, para depois efetivar a venda, informando os produtos, quantidades e por fim, a geração do recibo para conclusão da venda;
- Os administradores/supervisores devem cuidar do processo de compra dos produtos que serão vendidos na loja, contratar e supervisionar os atendentes/vendedores, cadastrar os produtos que chegam dos fornecedores no estoque, dar permissão aos atendentes/vendedores em casos de desistência de vendas (cancelamento total ou exclusão de itens específicos), controlar o estoque, analisar relatórios de vendas para tomada de decisões estratégicas, manter o operacional da loja como um todo;
- AMBIENTE? A loja é dividida em dois ambientes: o espaço de atendimento ao cliente, com balcão de exposição de algumas mercadorias, computadores para cadastro de vendas e clientes, e o espaço chamado de administrativo onde algumas mercadorias ficam armazenadas, todo o acervo administrativo da empresa (documentação), contendo ainda mesas para reuniões e computadores para sistema financeiro e cadastro de estoque dos produtos;
5 PROCESSOS DE NEGÓCIO
Para definição dos processos de negócio do projeto do software para a loja, foi utilizada a literatura 5W1H do inglês Zachman, que define 5 perguntas para uma boa modelagem de processos de negócio (traduzidas para português: Motivo, Quem, O que, Quando, Onde e Como).
5.1 Processo de controle de acesso de usuários
Todo o processo de controle de usuários será realizado de forma automatizada pelo sistema, restando aos administradores/supervisores do sistema, somente classificar os usuários em relação ao seu nível, no cadastro de usuários do sistema.
- MOTIVO: manter controle de acesso dos usuários por nível hierárquico;
- QUEM: todos os usuários do sistema, que serão colaboradores padrões e supervisores;
- O QUE: a segurança do sistema, prevendo diferentesníveis de acesso, de acordo com o “cargo” do usuário;
- QUANDO: ao acessar o sistema pela tela de login, verifica-se o nível de acesso para usar o sistema e suas funcionalidades;
- ONDE: níveis de acesso serão definidos no cadastro do usuário, utilizados para acesso em qualquer computador;
- COMO: colaboradores comuns, tais como, atendente, caixa terão nível 1. Supervisores, tais como, gerentes, administradores e diretores terão nível 2.
5.2 Processo de controle de estoque
O processo de controle de estoque envolve a decisão de compras de produtos que serão comercializados, decisão competente aos administradores. O cadastro dos produtos será feito no sistema, e a partir das vendas também cadastradas no sistema, teremos um estoque automatizado, atualizado, podendo sempre ser consultado em tempo real.
- MOTIVO: controlar todo o estoque dos produtos comercializados na loja;
- QUEM: os usuários do estoque realizarão o cadastro dos produtos no sistema;
- O QUE: cadastro de produtos divididos por categorias (jogos, acessórios e produtos geek), contendo código de barras, preço, grau de raridade, fabricante e quantidade disponível;
- QUANDO: toda vez que chegar novas mercadorias, e em eventuais conferências de estoque / levantamento de inventário;
- ONDE: na tela de cadastro de produtos, no computador do estoque preferencialmente;
- COMO: cadastrando um a um, cada produto, a partir do seu código de barras;
5.3 Processo de cadastro de cliente
Aqui, o cadastro dos clientes visa manter um histórico e fidelização dos mesmos, onde a partir dos cadastros, poderão consultar de forma automatizada informações sobre os clientes, e a partir de então, auxiliar a administração na tomada de decisões.
- MOTIVO: manter dados dos clientes que compram produtos na loja, criando histórico de compras e classificação;
- QUEM: os usuários atendentes realizarão o cadastro do cliente;
- O QUE: cadastro de clientes contendo informações como RG, CPF, nome, endereço, telefone e e-mail;
- QUANDO: será cadastrado ou atualizado, no momento do pedido de venda;
- ONDE: em um terminal de atendimento do balcão;
- COMO: será solicitado ao cliente um documento para cadastro, e posteriormente será perguntado dados que não existam no documento;
5.3 Processo de controle de vendas
Inclui consulta de produtos e a venda, toda feita a partir de cadastros no sistema, ou seja, todo o processo será automatizado, com exceção do atendimento em si, feito pelos atendentes de forma presencial.
- MOTIVO: manter dados dos pedidos de venda e atualização de estoque dos produtos;
- QUEM: os usuários atendentes realizarão o cadastro do pedido de venda;
- O QUE: o pedido de vendas contará com dados do cliente e dados dos produtos adquiridos;
- QUANDO: cliente sinalizar que já encontrou todos os produtos dos quais precisava;
- ONDE: em um terminal de atendimento do balcão;
- COMO: lançar cliente e produtos, finalizar e emitir recibo de cada pedido de venda;
6 CASOS DE USO
A utilização de casos de uso em documentações de softwares objetiva facilitar a comunicação entre os usuários do sistema e a equipe de desenvolvimento, a partir de um ponto de vista das atividades executadas do próprio usuário. Os diagramas de casos de uso são representados por atores, tarefas e o relacionamento entre eles.
Qualquer objeto externo que interaja com o sistema é chamado de ator, tais como usuários, hardwares (impressoras, máquinas de cartão, etc). As tarefas representam as funções do sistema, e os relacionamentos representam a interação entre os atores e as tarefas. Os relacionamentos podem ser: include, extend e de generalização.
Para o projeto do software da loja de vendas, foi criado o diagrama de casos de uso abaixo, conforme demonstra a Figura 1, apresentando uma visão ampla das funcionalidades que o sistema precisa alcançar.
Figura 1 – Casos de uso
Fonte: O autor (2020)
Os atores do projeto são: atendentes/vendedores, administradores/supervisores, o cliente e, não demonstrados na figura, os periféricos que interagem com o sistema, tais como máquinas de cartão e impressora. As tarefas: cadastro de usuário, login de acesso, cadastro de produtos, consulta de produtos, cadastro de clientes, pedido de vendas, cancelamento de pedido, cancelamento de item de um pedido e emissão de recibo. Os relacionamentos identificados são: - Include (relacionamento usado quando um caso de uso é utilizado dentro de outro caso de uso, ou seja a execução do segundo exige a execução do primeiro): quando o atendente/vendedor vai iniciar o pedido de vendas, antes de adicionar um produto ao pedido, necessariamente precisa executar uma consulta do produto, a fim de verificar se existe disponibilidade em estoque; - Extend (utilizado em tarefas opcionais de casos de uso, ou nesse caso, cenários que ocorrerão somente em casos específicos): quando ocorrer, durante o pedido de venda a necessidade de exclusão de um dos itens do pedido ou cancelamento total do pedido, existe uma “extensão” ao caso de uso “Pedido de Venda”; - Generalização (ocorre quando mais de um caso de uso possui as mesmas especificações, compartilham características e fazem uso da reutilização, termo muito utilizado em orientação a objeto): a emissão de recibo é uma generalização do pedido de venda, onde toda a regra do pedido de venda é aplicada na emissão de recibo.
6.1 Especificação dos casos de uso
A seguir é feito o detalhamento dos casos de uso, utilizando tabelas de especificações, contendo a descrição do caso de uso, as prés e pós condições além dos fluxos principais e alternativos:
	ESPECIFICAÇÕES CASOS DE USO
	Descrição
	Logar no sistema
	Ator
	Todos usuários
	Tarefa
	Acessar o sistema
	Pré-condições
	Possuir cadastro de usuário
	Pós-condições
	Usuário acessa o sistema e tem acesso as telas pertinentes ao seu nível de login
	Fluxo Principal
	1- O usuário clica no ícone do sistema para abri-lo;
2- É exibida a tela de login;
3- Usuário informa login e senha e clica no botão “Ok”; (3.1 e 3.2)
4- Sistema abre a tela principal;
	Fluxos Alternativos
	3.1 – Login não encontrado: sistema emite mensagem “Login inválido” e não abre o sistema;
7.2 – Erro na validação da senha: sistema emite mensagem “Senha inválida” e não abre o sistema; 
Tabela 1: Especificação do caso de uso “Logar no sistema”
Fonte: O autor (2020)
	ESPECIFICAÇÕES CASOS DE USO
	Descrição
	Cadastrar usuário
	Ator
	Administradores/supervisores
	Tarefa
	Criar um cadastro para cada usuário do sistema
	Pré-condições
	1- Ficha preenchida de admissão do funcionário, com a descrição do cargo que irá ocupar;
2- Estar logado no sistema com senha de administrador/supervisor;
	Pós-condições
	Após o cadastro com dados do novo usuário, será criado um login de acesso ao sistema com senha escolhida pelo usuário
	Fluxo Principal
	1- Acessa o menu Cadastro de usuários;
2- Clica no botão “novo”;
3- Preenche os campos: nome, cpf, data de admissão, e-mail, login, nível de acesso (1 ou 2) e acessibilidade;
4- Solicita ao novo funcionário preencher o campo senha;
5- Clica no botão “salvar”;
6- Sistema valida campos obrigatórios; (7.1, 7.2 e 7.3)
7- Sistema emite mensagem “Cadastrado com sucesso”;
8- Finalização do cadastro;
	Fluxos Alternativos
	7.1 – Erro na validação do CPF: sistema emite mensagem “CPF inválido” e não salva o cadastro;
7.2 – Erro na validação do e-mail: sistema emite mensagem “E-mail inválido” e não salva o cadastro;
7.3 – Não preenchimento de campos obrigatórios: sistema emite mensagem “Campo NOMEDOCAMPO é obrigatório” e não salva o cadastro;
Tabela 2: Especificação do caso de uso “Cadastrar usuário”
Fonte: O autor (2020)
	ESPECIFICAÇÕES CASOS DE USO
	Descrição
	Cadastrar produtos
	Ator
	Administradores/supervisores
	Tarefa
	Criar um cadastro para produtos comercializados na loja
	Pré-condições
	1- Chegar produtos novos, a partir de pedidos de compras;
2- Estar logado no sistema com senha de administrador/supervisor;
	Pós-condições
	Após o cadastro básico, categorizar os produtos por raridade e incluir a quantidade disponível em estoque
	Fluxo Principal1- Acessa o menu Cadastro de produtos;
2- Clica no botão “novo”;
3- Preenche os campos: nome do produto, código de barras, fabricante, categoria (jogos, acessório, geek), quantidade, valor, plataforma, prazo de garantia e grau de raridade (os dois últimos somente para categorias jogos e acessórios);
4- Clica no botão “salvar”;
5- Sistema valida campos obrigatórios; (6.1, 6.2, 6.3)
6- Sistema emite mensagem “Cadastrado com sucesso”;
7- Finalização do cadastro;
	Fluxos Alternativos
	6.1 – Erro na validação do código de barras: sistema emite mensagem “Código de barras inválido” e não salva o cadastro;
6.2 – Produto já cadastrado: sistema verifica nome e código de barras e encontra produto com as mesmas características, emitindo a mensagem “Produto já cadastrado” e não salva o cadastro;
6.3 – Não preenchimento de campos obrigatórios: sistema emite mensagem “Campo NOMEDOCAMPO é obrigatório” e não salva o cadastro;
Tabela 3: Especificação do caso de uso “Cadastrar produto”
Fonte: O autor (2020)
	ESPECIFICAÇÕES CASOS DE USO
	Descrição
	Cadastrar cliente
	Ator
	Todos os usuários
	Tarefa
	Cadastrar clientes
	Pré-condições
	1- Estar logado no sistema;
2- Cliente entregar documento para cadastro;
	Pós-condições
	Após o cadastro do cliente, será possível realizar vendas, e classificar clientes colecionadores;
	Fluxo Principal
	1- Acessa o menu Cadastro de clientes;
2- Clica no botão “novo”;
3- Preenche os campos: CPF, nome, data do cadastro, endereço, telefone e e-mail;
4- Clica no botão “salvar”;
5- Sistema valida campos obrigatórios; (5.1, 5.2 e 5.3)
6- Sistema emite mensagem “Cadastrado com sucesso”;
7- Finalização do cadastro;
	Fluxos Alternativos
	5.1 – Erro na validação do CPF: sistema emite mensagem “CPF inválido” e não salva o cadastro;
5.2 – Erro na validação do e-mail: sistema emite mensagem “E-mail inválido” e não salva o cadastro;
5.3 – Não preenchimento de campos obrigatórios: sistema emite mensagem “Campo NOMEDOCAMPO é obrigatório” e não salva o cadastro;
Tabela 4: Especificação do caso de uso “Cadastrar cliente”
Fonte: O autor (2020)
	ESPECIFICAÇÕES CASOS DE USO
	Descrição
	Cadastrar pedido de vendas
	Ator
	Todos os usuários
	Tarefa
	Realizar a venda
	Pré-condições
	1- Cliente sinalizar que deseja finalizar a compra;
2- Cliente estar cadastrado no sistema;
3- Produto estar cadastrado no sistema e possuir disponibilidade de estoque;
4- Usuário estar logado no sistema;
	Pós-condições
	Após o cadastro e finalização do pedido de venda, produtos terão a quantidade em estoque atualizada
	Fluxo Principal
	1- Acessa o menu Cadastro de Pedido de venda;
2- Clica no botão “novo”;
3- Preenche os campos código do cliente e consulta insere os produtos a partir do seu código de barras;
4- Clica no botão “Finalizar pedido”;
5- Sistema valida campos; (6.1, 6.2 e 6.3)
6- Sistema insere código da venda, data, valor total e status da venda; (7.1, 7.2)
7- Usuário informa a forma de pagamento;
8- Sistema emite recibo de venda e adiciona status de pagamento; (8.1)
9- Finalização do pedido de venda;
	Fluxos Alternativos
	6.1 – Produto não disponível em estoque, sistema emite mensagem “Produto indisponível” e não salva o cadastro;
6.2 – Produto selecionado é item raro, o sistema verifica se o cliente é classificado como colecionador, e em caso negativo, emite a mensagem “Produto raro, somente para colecionadores cadastrados” e não salva o cadastro;
6.3 – Não preenchimento de campos obrigatórios: sistema emite mensagem “Campo NOMEDOCAMPO é obrigatório” e não salva o cadastro;
7.1 – Usuário insere produto errado no pedido de venda, com a necessidade da exclusão, é necessário solicitar ao administrador/supervisor que digite a senha de nível 1;
7.2 – Cliente solicita cancelamento da venda, com a necessidade de cancelar o pedido de venda, é necessário solicitar ao administrador/supervisor que digite a senha de nível 1. Nesse passo o sistema precisa comunicar ao sistema financeiro o cancelamento da venda;
8.1 – Pagamento com cartão não concluído pela Operadora do Cartão, sistema emite mensagem “Pagamento não realizado” e não salva o pedido de vendas, até que seja inserida nova forma de pagamento;
Tabela 5: Especificação do caso de uso “Cadastrar pedido de venda”
Fonte: O autor (2020)
Além dos casos de uso especificados acima, existe ainda a necessidade de alterações em cadastros de produtos e de clientes, quando tem mudança de dados tais como mudança de endereço, telefone ou e-mail do cliente, alteração de qualificação de cliente normal para colecionador, além de mudança em produtos ou exclusão, quando não há mais fabricação do mesmo.
7 requisitos não funcionais
Requisitos não funcionais são aqueles não expressos claramente no escopo do projeto, não são solicitados pelos usuários, mas que existem e garantem certa qualidade ao sistema desenvolvido. Podem ser fatores externos contidos no ambiente onde o projeto será instalado, como por exemplo, a segurança, confiabilidade, integridade dos dados, tempo de resposta e espaço em disco. Abaixo foram listados os requisitos não funcionais do projeto de software para a loja de vendas:
	REQUISITOS NÃO FUNCIONAIS
	IDENTIFICAÇÃO
	DESCRIÇÃO
	RNF01 – Configuração do servidor
	O servidor deve conter sistema operacional Windows 7 ou superior, 8 GB de memória RAM, 500 GB de HD, ou superiores, para garantia de desempenho do sistema
	RNF02 – Configuração das estações
	Estações devem conter sistema operacional Windows 7 ou superior
	RNF03 – Configuração da rede
	Todos os computadores devem conectar-se em rede, além do servidor e periféricos que serão compartilhados
	RNF04 – Comunicação com o banco de dados
	Todas as alterações, exclusões, inserções, ou seja, todas as operações realizadas no sistema precisam ser atualizadas em tempo real para garantir veracidade e precisão nas informações
	RNF05 – Segurança
	Incluir programas que garantam segurança contra invasões ao ambiente do sistema, com antivírus, firewalls, etc
	RNF05 – Comunicação com a Operadora de cartão
	Nos pedidos de venda que a forma de pagamento é com cartão, é necessária a disponibilidade junto à Operadora do cartão
	RNF06 – Comunicação com Sistema Financeiro
	O sistema de vendas transmite o tempo todo informações ao sistema financeiro, e portanto, depende da disponibilidade do sistema financeiro
Tabela 6: Requisitos não funcionais
Fonte: O autor (2020)
8 requisitos de usabilidade
Para atender princípios de qualidade do sistema são definidos requisitos de usabilidade que determinam as necessidades em cada cenário/tela produzido.
	REQUISITOS DE USABILIDADE
	IDENTIFICAÇÃO
	DESCRIÇÃO
	RU01 – Fácil utilização
	O sistema deve ser de uso intuitivo, mesmo para usuários sem experiência
	RU02 – Fácil memorização
	O usuário deve alcançar certo nível de conhecimento do sistema sem necessidade de apoio, após poucos dias utilizando
	RU03 – Produtividade
	As tarefas executadas antes de forma manual, e agora através do sistema, deverão ser realizadas em um tempo menor
	RU04 – Satisfação
	Os usuários deverão apresentar conforto e segurança ao utilizar o sistema
	RU05 – Desempenho
	O sistema deve produzir as respostas às ações dos usuários em um curto espaço de tempo
	RU05 – Comunicação com o usuário
	O sistema deve garantir clareza na comunicação com o usuário, através de mensagens de confirmação, apresentação de resultados sobre inclusões, exclusões, etc
Tabela 7: Requisitos de usabilidade
Fonte: O autor (2020)
9 acessibilidade
Cada vez mais é necessário incluir nos projetos de softwares acessibilidade para pessoas que portam alguns tipos de necessidades especiais. Acessibilidade é o termo geral usado para indicar a possibilidade de qualquer pessoa usufruir todos os benefícios de uma vida em sociedade, entre eles, o uso da Internet (Nicholl, 2001) e (NBR 9050, 1994). Neste projeto serão incluídas funcionalidades para atender certos tipos de deficiências, descritos abaixo:
	REQUISITOS DE ACESSIBILIDADE
	IDENTIFICAÇÃO
	DESCRIÇÃO
	RA01 – Não utilização de mouse
	Para usuários que tenham deficiênciamotora, e por essa razão não consigam utilizar o mouse, porém, conseguem digitar no teclado, haverá uma “Opção de Acessibilidade” para que o teclado numérico passe a funcionar como setas do mouse
	RA02 – Cores fortes
	Para usuários que possuam dificuldades visuais haverá a “Opção de Acessibilidade” para o sistema apresentar cores fortes e com alto contraste
	RA03 – Aumento das fontes
	Para usuários que possuam dificuldades visuais haverá a “Opção de Acessibilidade” para o sistema apresentar fontes grandes e possibilidade de aplicar zoom nas telas do sistema
Tabela 8: Requisitos de acessibilidade
Fonte: O autor (2020)
10 REGRAS DE NEGÓCIO
As regras de negócio da loja de vendas traduzem a forma e as regras aplicadas no seu dia-a-dia visando o bom funcionamento das operações, refletindo a política aplicada aos negócios, visando a obtenção dos objetivos da empresa, a satisfação dos clientes, a utilização plena dos recursos e também, o atendimento às regras e leis vigentes. A partir da definição das regras de negócio, são especificadas as particularidades que deverão ser aplicadas no sistema. Restrições, validações, exceções e condições são regras de negócios. Uma regra de negócio não será, necessariamente, refletida no sistema, mas com certeza irá determinar um ou mais comportamento dentro dele. Abaixo foram descritas as regras de negócio a serem desenvolvidas no sistema:
	REGRAS DE NEGÓCIO
	IDENTIFICAÇÃO
	DESCRIÇÃO
	RN01 – Cadastro de usuários
	1- Ao contratar novos funcionários para a loja de vendas, um usuário administrador/supervisor deve cadastrá-los
2- Deverá ser criado um e-mail próprio da loja para o novo funcionário
3- A senha para usuários deverá conter no mínimo 8 caracteres, incluindo números, letras e ao menos uma letra maiúscula, a fim de conter segurança
4- Usuários que possuam alguma das deficiências elencadas nos “Requisitos de Acessibilidade”, deverão possuir distinção no cadastro, para que, quando logue no sistema, o mesmo já apresente as opções de acessibilidade
	RN02 – Cadastro de produtos
	1- Os produtos cadastrados no sistema devem possuir uma flag indicando se é um produto de colecionador
2- Produtos que tenham muita saída devem contar com quantidade mínima de estoque, e o sistema deve avisar aos administradores/supervisores quando chegar ao nível baixo de estoque
	RN03 – Cadastro de clientes
	1- A partir do histórico de vendas dos clientes, o sistema deverá possibilitar o cadastro de clientes “especiais”, aqueles que compram com frequência na loja, podendo ser chamados de colecionadores. Esses clientes poderão adquirir os produtos ditos como raros
2- Caso o cliente esteja no mês de seu aniversário, sistema deve emitir alerta para que seja disponibilizado um brinde para esse cliente
	RN04 – Pedido de vendas
	1- Os pedidos de venda poderão ser pagos em dinheiro ou cartão
2- Para adicionar um produto no pedido de venda, o mesmo deverá conter no estoque a quantidade necessária
3- Deve ser avaliado no momento da inserção do produto no pedido de venda, se o produto é classificado como raro, e permitir que seja inserido somente para os clientes especiais / colecionadores
4- Sistema deve calcular troco, quando pedido em dinheiro pago com valor superior ao valor total do pedido
5- Na emissão do recibo de venda, deve constar o código e o nome do cliente, os produtos e suas quantidades, a forma de pagamento e a data da venda
6- Caso o usuário inserir um produto errado, ou o cliente desista desse produto durante o processo de cadastramento da venda, deverá solicitar senha para um usuário administrador/supervisor
7- Caso o cliente desista da compra, necessário solicitar senha de usuário administrador/supervisor para cancelamento total da venda
8- Quando o pagamento for com cartão, caso o sistema não consiga a comunicação com a Operadora do Cartão, o sistema deverá cancelar o procedimento e gerar uma mensagem de alerta, verificando se deseja cadastrar uma nova forma de pagamento ou o cancelamento do pedido
Tabela 9: Regras de negócio
Fonte: O autor (2020)
11 DIAGRAMA DE CLASSES
Chegando na fase do escopo do projeto de desenvolvimento do software para a loja de vendas, teremos agora a definição do diagrama de classes. Tais diagramas estão entre os tipos mais utilizados de UML, pois mapeiam de forma clara toda a estrutura de um determinado sistema, apresentando suas classes, atributos, operações e relações entre os objetos. Segundo Bezerra, 2006, a melhor forma de se representar a estrutura estática de um sistema orientado a objetos é utilizando o modelo de classes.
Uma classe pode ser representada através de um retângulo, dividido em três partes: na parte superior fica o nome da classe representada, na parte do meio encontram-se os atributos (que definem as qualidades dessa classe), e na parte final, os métodos e/ou operações que a classe pode executar (que demonstram como essa classe interage com os dados). 
No diagrama de classes podem ser identificadas ainda, as interações entre os objetos da classe, sendo essas interações mais comuns:
- Dependência: utilizada quando uma classe depende das informações de outra classe, sendo representada por uma seta com linha tracejada.
- Associação: utilizada quando duas classes ou mais interagem entre si, demonstrada através de uma linha que liga as classes.
- Agregação: utilizada quando uma classe está contida por inteiro em outra classe, representada com uma seta que sai da classe que representa a parte e conecta a um losango, na classe que representa o todo. 
- Composição: muito semelhante a agregação, representa a dependência integral de uma classe que é parte de outra classe, ou seja, essa classe existe somente se existe a classe com o todo, aqui representado da mesma forma que na agregação, porem com o losango preenchido.
- Associativa: são classes que interagem com associações no diagrama, e não mais com outras.
- Herança: simbolizada por uma linha reta e contendo na ponta uma seta fechada que aponta para a classe pai, ou superclasse, quando uma classe herda características de outra classe, fazendo reutilização, grande fator da programação orientada a objetos.
11.1 Entity, control e boundary
As classes são diferenciadas pelo tipo de responsabilidade que as cercam, podendo ser classes de fronteira (boundary), classes de controle (control) e classes entidade (entity).
A partir da definição de suas responsabilidades, aumenta-se a reutilização de código fonte, ao desenvolver de fato o sistema. 
	- Entidade: aqui são representadas as classes que mais se aproximam de fatos ou objetos do cotidiano, normalmente encontrados nos casos de uso. Onde são armazenadas as informações e comportamentos do problema tratado pelo sistema.
	- Fronteira: fazem a conexão entre o sistema e o mundo real, através de interação com atores externos, como hardwares, outros sistemas integrados, etc.
	- Controle: faz a comunicação entre as classes entidade e de fronteira, mantendo uma organização dos fluxos contidos em todo o sistema.
11.2 Modelo de diagrama de classes
Foi elaborado o diagrama de classes de análise do projeto de sistema para loja de vendas utilizando o aplicativo Atash Professional 8.2.0, abaixo:
Figura 2: Diagrama de Classes
Fonte: O autor (2020)
 
A partir da observação do diagrama de classes é possível identificar as classes de fronteira, ou seja, as interações do sistema com o mundo externo, que no caso foram as classes OperadoraCartao, responsável por receber os dados do cartão, processar o pagamento, e devolver ao sistema a autorização do pagamento e a classe Recibo, que imprime o recibo de comprovação da venda ao cliente, finalizando aqui, o procedimento da venda.
12 modelo de dados (mer)
O modelo de entidade relacional trata de conjuntos de tabelas com seus atributos, ou colunas, que em conjunto definem as características dessas tabelas. Cada linha da tabela representa um elemento único. É um modelo que visa fazer uma representação dos dados, tabelas e seus relacionamentos, utiliza linguagem semelhante à do cotidiano, e que poderá ser utilizadoposteriormente para a criação do banco de dados. Utilizado no momento da projeção conceitual do sistema para a loja de vendas, este modelo foi criado por Peter Chan para projetos de bancos de dados.
12.1 Entidade
Entidades são os objetos representados no modelo de entidade relacional que trata de uma situação do mundo real de forma abstrata ou concreta, sendo independente ou não para existir. Podem ser usuários, clientes, produtos, carros, livros, entre infinitos outros exemplos de objetos do nosso cotidiano que podem ser representados nesses modelos. No âmbito das entidades, elas podem ser classificadas em entidades fortes, que independem de qualquer outro objeto para existir. Neste projeto temos como classes fortes, as classes USUARIO, CLIENTE, PRODUTO. Entidades fracas são entidades que precisam de outras entidades para explicar sua existência, pois separadamente, tais entidades não geram sentido, sendo no projeto exemplos de entidades fracas CATEGORIA e ITEMPEDIDO.
12.2 Atributos
Cada entidade possui características que a definem, no caso do modelo de entidade relacional, são os atributos, ou, mais tecnicamente falando, as colunas das tabelas. Por exemplo, um produto possui nome, fabricante, código de barras, etc., um cliente possui nome, CPF, e-mail, endereço, etc.
12.3 Relacionamentos
Com o conhecimento das entidades e seus atributos dentro do escopo do projeto, serão definidos os relacionamentos entre essas entidades, que podem ser classificadas a partir da quantidade de objetos contidos em cada uma das entidades, podendo ser: um pra um, onde um elemento de uma entidade relaciona-se com exatamente um elemento da outra entidade (1..1); um para muitos, onde um elemento da entidade relaciona-se com um ou mais elementos de outra entidade (1..N); muitos para muitos, vários elementos de uma entidade relacionam-se com um ou mais elementos da outra entidade (N..N).
Abaixo foi indicado o MER simplificado contendo as entidades do projeto de sistema para a loja de vendas e seus relacionamentos, utilizando o aplicativo Atash Professional 8.2.0.
Figura 3: Modelo Entidade Relacionamento - MER
Fonte: O autor (2020)
12.4 Modelo de Dados
Como última fase da do planejamento e documentação para o sistema da loja de vendas de jogos, acessórios e produtos geek, foi elaborado um escopo inicial do modelo de base de dados, criado com o Microsoft SQLServer 2014 e ainda, utilizando a ferramenta para geração da imagem abaixo, o aplicativo MS SQL Maestro 12.9.0.2.
Figura 4: Modelo de banco de dados
Fonte: O autor (2020)
CONCLUSÃO
Após todo o estudo realizado para este projeto de documentação do software para a loja de jogos, acessórios e produtos geek, realizado em diversas etapas, pode-se concluir que a projeção, análise, levantamento de todos os requisitos, estudo dos usuários, ambientes e tarefas realizadas por eles é extremamente importante para se ter uma ideia do que realmente o sistema precisa realizar ao ser entregue para seu cliente.
Tudo se inicia a partir da observação, conversa com os usuários, e a escrita do projeto inicia-se também em uma linguagem natural muito próxima a realidade. Em linguagem comum, foi descrito o cenário proposto, analisando as pessoas envolvidas, as quais se tornarão os usuários do sistema, quais são e de que modo são executadas as tarefas dessas pessoas no seu trabalho na loja, e um refinamento dos negócios realizados na loja, as regras de negócio implícitas e explícitas. Feito ainda, uma pesquisa de mercado com soluções concorrentes, indicando os prós e contras de cada uma das soluções pesquisadas.
Foram elaboradas documentações detalhadas de todo o problema que o sistema deve solucionar, através da utilização de diagramas de casos de uso, especificando seus fluxos. Em seguida o diagrama de classes e por fim, o modelo de entidade relacionamento, também com um breve escopo da estrutura do banco de dados.
É possível perceber após toda a elaboração dessa documentação, que temos ao seu final, praticamente um sistema totalmente desenhado, bem especificado. Dessa forma a programação em si do sistema será realizada muito rapidamente, e ao final, teremos um produto com muita qualidade agregada. A utilização da análise de forma profunda antes do desenvolvimento do software de fato, é extremamente importante para que o produto final realmente produza o efeito esperado.
referências BIBLIOGRÁFICAS
 ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS - ABNT. NBR 9050/2015: Acessibilidade a edificações, mobiliário, espaços e equipamentos urbanos. Rio de Janeiro, 2015.
Bacha, Maria de Lourdes. Introdução à pesquisa de marketing. São Paulo: CenaUn, 1998.
Bezerra, Eduardo. Princípios de Análise de Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2006.
G. Booch, J. Rumbaugh, I. Jacobson. UML, Guia do Usuário. 2ª Ed., Editora Campus, 2005
https://meusucesso.com/artigos/inovacao-e-tecnologia/5-programas-de-controle-de-estoque-para-usar-na-sua-empresa-79/
Acessado em 12/05/2020 às 8h12min.
https://tassioauad.com/2017/03/14/requisitos-na-engenharia-de-usabilidade/
Acessado em 17/05/2020 às 10h23min.
https://www.ateomomento.com.br/caso-de-uso-include-extend-e-generalizacao/
Acessado em 14/05/2020 às 08h22min.
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332
Acessado em 23/05/2020 as 17h51min.
https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml
Acessado em 19/05/2020 às 7h48min.
Nicholl, A. R. J. O ambiente que promove a inclusão: conceitos de acessibilidade e usabilidade. Revista Assentamentos Humanos, Marília, v.3, n. 2, p. 49-60, dez. 2001.
UNIP -Universidade Paulista. Ref.: Análise de Sistemas Orientada a Objetos. Florianópolis, 2020.
UNIP -Universidade Paulista. Ref.: Banco de Dados. Florianópolis, 2020.
GLOSSÁRIO
Acessibilidade: é a qualidade do que é acessível, ou seja, é aquilo que é atingível, que tem acesso fácil. Viabilidade de uso do sistema para pessoas portadoras de deficiência.
Antivírus: programa de proteção para o computador que verifica a existência de arquivos danosos (vírus), trata-os e elimina-os, bem como protege a entrada dos mesmos no computador.
Automatizar: utilizar ferramentas eletrônicas ou mecânicas que otimizam e agilizam a produção de um artefato ou serviço.
Bugs: apresentação de erros nos sistemas, os quais podem ser causados por falhas na codificação, defeitos, etc.
Código de Barras: Código de barras é uma representação gráfica de dados numéricos ou alfanuméricos. A decodificação dos dados é realizada por um tipo de scanner - o leitor de código de barras -, que emite um raio vermelho que percorre todas as barras (Wikipédia, 2020)
Disponibilidade: qualidade do que é disponível, receptível. No projeto fala-se da disponibilidade de sistemas externos, que trata do fato de outro sistema encontrar-se em funcionamento naquele momento.
Fidelização: fazer com que os clientes voltem a loja para novas compras no futuro, criar um vínculo com o cliente.
Firewalls: programa de computador responsável por aplicar segurança nas redes de computadores.
Flag: no mundo tecnológico, trata-se de um campo que trabalha como um semáforo, o qual ativa ou desativa a informação da flag através de suas características estarem presentes ou não.
Funcionalidades: em informática, é o conjunto de tarefas e funções que determinado aplicativo possui, se propõe a realizar.
Geek: termo moderno classificando determinada população que aprecia tecnologia, eletrônica, histórias em quadrinhos, mangás, livros, filmes e séries e se comportam de maneira peculiar.
Hardware: peças e produtos que formam a parte física dos computadores e seus periféricos, como memória RAM, placa mãe, impressoras.
Implantação: no âmbito da tecnologia, seria a introdução de software em empresas ou clientes, processo de instalação, treinamento, acompanhamento.
Interface: é a fronteira que define a comunicação entre entidades, podendo ser por exemplo, as telas do sistema, um relatório impresso, qualquer artefato que faça ligação entre o sistema e seu mundo exterior.Nível hierárquico: definição de posicionamentos a partir de classificações. No ramo empregatício vemos os níveis hierárquicos como os atendentes no nível inferior, e os supervisores em nível superior.
Nuvem: centros de dados disponibilizados na internet, onde ficam armazenados dados em locais/servidores não físicos.
Plataforma Desktop: indica o local onde o programa será executado, nesse caso para programas locais nos computadores.
Requisitos: é sinônimo de condição, exigência, quesito, imposição, obrigação, formalidade, determinação, preceito, entre outros.
Sistema Operacional: programa responsável pela interface entre usuário e computador, o qual gerencia todos os recursos do sistema.
Superclasse: as classes que originam, herdam outras classes, que serão as subclasses.
Tela Principal: tela aberta do sistema após inserir login e senha, onde são apresentadas todas as funcionalidades do sistema, todos acessos para as demais telas.