PIM VI - Análise de Requisitos de um Sistema de Controle de Vendas de uma Loja de Jogos Geek - 2020

Prévia do material em texto

2
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia
ANÁLISE DE REQUISITOS DE SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS
Araputanga - MT
2020
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia
ANÁLISE DE REQUISITOS DE SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS
Aluno RA: xxxxxxx
Projeto Integrado Multidisciplinar – PIM VI, apresentado como um dos pré-requisitos para aprovação do bimestre vigente no Curso Superior de Tecnologia Análise e Desenvolvimento de Sistemas
Prof. ª Sandra Muniz Bozolan
Araputanga
2020
RESUMO
Neste projeto, será desenvolvido um sistema para realizar a venda e controle de estoque de uma loja que possui produtos e acessórios para jogos e produtos geek. 
O sistema deve realizar todos os cadastros, alterações, consultas e exclusões relacionadas aos produtos que serão comercializados na loja. Os clientes devem estar cadastrados e apenas atendentes, estoquistas e supervisor da loja podem acessar o sistema com níveis de login. 
Para que a loja tenha controle adequado, todos os produtos devem ter código de barras, nome do produto, categoria, fabricante, quantidade e valor do produto.
Atualmente a tecnologia está sendo muito utilizada em várias empresas, pois além de ajudar no desenvolvimento que costumava ser feito com muitos atrasos, a qualidade se destaca com este novo sistema e a forma de atendimento será mais rápida e eficiente.
Palavra Chave: Sistema, Loja, Qualidade, Produtos Geek.
ABSTRACT
In this project, a system will be developed to carry out the sale and inventory control of a store that as products and accessories around games and geek products.
The system should perform all registrations, changes, queries and exclusions related to the products that will be sold in the store. Customers must be registered and only attendants, stockists and supervisors can access the system with login levels.
For the store to have adequate control, all products must have barcode, product name, category, manufacturer, quantity and value of the product. 
Nowadays technology is being used a lot in several companies, because in addition to helping in the development that used to be done with long delays, quality stands out with this new system and the service method will be faster and more efficient.
Key words: System, Store, Quality, Geek Products.
Sumário
1.	INTRODUÇÃO	8
2.	DESENVOLVIMENTO	9
2.1. Modelo casos de uso e atores	9
2.2. Principais atores envolvidos no sistema	9
2.3. Principais objetivos do sistema	10
2.4. Modelagem de caso de uso e seus relacionamentos	10
2.5. Cenário do tipo <<extend>> e <<include>>	11
3.	PROTÓTIPO DE TELAS	13
3.1. Tela Efetuar Login	13
3.2. Tela Cadastrar Usuário	13
3.3. Tela Cadastrar Produto	14
3.4. Tela Realizar Pedido e Pagar Produto	15
4.	ESPECIFICAÇÃO DE CASOS DE USO	16
4.1. Atores casos de uso	16
4.2. Caso de Uso – Efetuar Login	17
4.3. Caso de Uso – Gerenciar Relatório	17
4.4. Caso de Uso – Manter Cliente	18
4.5. Caso de Uso – Manter Fornecedor	18
4.6. Caso de Uso – Manter Produto	19
4.7. Caso de Uso – Manter Compra	19
4.8. Caso de Uso – Manter Venda	20
4.9. Caso de Uso – Consultar Preço	20
4.10. Caso de Uso – Manter Categoria de Produtos	21
4.11. Requisitos Funcionais e Não Funcionais	21
4.12. Regras de Negócio	22
5.	DIAGRAMA DE CLASSES E ENTIDADE RELACIONAMENTO	23
5.1. Diagrama de Classe	23
5.2. Modelo Entidade e Relacionamento (MER)	24
5.2.1. Modelo Conceitual	25
5.2.2. Modelo Lógica	25
5.3. Diagrama de Classes de Análise	26
6.	CONTEXTOS DE USO	28
7.	TOMADA DE DECISÃO	29
 CONCLUSÃO	30
 REFERÊNCIAS	31
Lista de Figuras
Figure 1- Cenário do tipo <<include>>	11
Figure 2- Cenário do tipo <<extend>>	12
Figure 3 - Tela de Login	13
Figure 4- Cadastrar Usuário	14
Figure 5- Cadastrar Produto	14
Figure 6- Realizar Pedido e Pagar Produto	15
Figure 7- Relação entre atores e caso de uso	16
Figure 8- Diagrama de Classe	24
Figure 9- Modelo Conceitual	25
Figure 10- Modelo Lógico	25
Figure 11- Notação da UML para objetos	26
Figure 12- Diagrama de Classes de Análise	27
INTRODUÇÃO
Com o objetivo de apresentar os conhecimentos adquiridos com as disciplinas: Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégicas de Recursos Humanos, este projeto é elaborado de acordo com o tema proposto: “Levantamento e análise de requisitos para um sistema de controle de vendas para uma loja de jogos eletrônicos, acessórios e produtos geek”.
Os controles e procedimentos de vendas realizados na loja eram feitos manualmente em planilhas do Excel, dificultado a manutenção de uma organização interna de estoque e vendas. E para prestar um atendimento eficiente aos clientes e fazer um controle mais adequado dos produtos, a loja fechou contrato com uma empresa para desenvolver um software de controle e gerenciamento de vendas de produtos.
Para este desenvolvimento será identificado os casos de uso e seus comportamentos, requisitos não funcionais, regas de negócio, desenvolvimento de protótipo de telas, diagrama de classes e modelo entidade relacionamento (MER).
Os envolvidos na gestão de pessoas, têm, portanto, o importante papel de transformar a visão e a mentalidade de organizações que exigem o departamento de recursos humanos uma fonte de despesas, passando a vê-lo como uma fonte de oportunidades e vantagens competitivas, investindo e apostando no mesmo.
Com tecnologia mais avançada, os processos de rotina da loja serão alterados, reduzindo as divergências que acontecem nos estoques e, com isso, ficará mais fácil localizar os itens e consultar o saldo de produtos que será atualizado diariamente. Dessa forma, os gestores poderão traçar planos estratégicos com maior precisão e eficiência.
DESENVOLVIMENTO
Através da disciplina Análise de Sistema Orientada a Objetos serão apresentados às boas práticas para captar e mapear as necessidades das organizações, inseridas em um mercado cada vez mais competitivo, de forma que essas necessidades captadas de forma eficiente se tornem um auxílio ao software que será elaborado neste projeto.
Um sistema de software pode ser identificado como o conjunto de vários componentes que, quando executados, produzem um resultado previamente desejado. Esses componentes podem ser chamados de componentes de software, que são desenvolvidos utilizando métodos e processos que estabelecem uma relação entre a necessidade do cliente e um código executado em uma máquina (PRESSMAN, 2006).
2.1. Modelo casos de uso e atores
O modelo de caso de uso são os objetivos que o sistema deve realizar para atingir o que precisa e serve como um contrato estabelecido entre o cliente e os desenvolvedores. Geralmente é usado como fonte de informação essencial para atividades de análise, projeto e teste. E representa uma possível utilização do sistema por atores, que podem ser pessoas, dispositivo físico, mecanismo ou subsistema que interagem com o sistema de destino, utilizando qualquer um de seus serviços.
Um caso de uso demonstra a interação entre o sistema e os atores envolvidos, para atingir um ou mais objetivos. Precisa estar relacionado a um processo bem definido, com começo, meio e fim. 
Atores são os agentes externos ao sistema que executam uma determinada ação e que esperam algum resultado, ou seja, interagem diretamente com o sistema a partir dos casos de uso (VERSOLATTO, 2015, pág. 61).
2.2. Principais atores envolvidos no sistema
Atores e os casos de uso são desenvolvidos usando os requisitos de clientes e dos possíveis usuários com informações necessárias. Conforme os casos de uso e atores são revelados, eles devem ter uma breve descrição. Antes de apresentar os casos de uso em detalhes, o modelo de caso de uso deve ser revidado pelo cliente para verificar se todos os casos de uso e atores foram encontrados e dessa forma ele podem fornecer o que o cliente deseja.
Existem dois tipos de atores: principais e secundários. Os atores principais interagem diretamente com o sistema computacional,enquanto os atores secundários interagem com outros atores.
Principais atoes do sistema: usuários, atendentes, estoquistas e o supervisor da loja.
Atores secundários: sistema da operadora de cartão.
2.3. Principais objetivos do sistema
· Acessar o site por meio de login e senha;
· Cadastro dos produtos que serão vendidos na loja;
· Cadastro dos clientes;
· Todos os produtos devem ter informações necessárias para que o atendente, estoquista e supervisor possam identificar tudo com mais rapidez e eficiência;
· Venda dos produtos divididos por categoria: acessórios para jogos e produtos geek;
· Realizar reserva dos produtos que estão no estoque;
· Pagamento com (cartão/dinheiro).
2.4. Modelagem de caso de uso e seus relacionamentos
A UML (Unified Modeling Language ou Linguagem Unificada de Modelagem) é uma linguagem de notação usada para modelar e documentar as várias fases do desenvolvimento de sistema orientado a objetos.
Ela define uma série de elementos gráficos – como retângulo, setas, balões e linhas – que são usados em diferentes diagramas para representar os componentes de uma aplicação, suas interações e mudança de estado.
O caso de uso da UML é um diagrama comportamental que visa descrever como será o uso da funcionalidade de um sistema, representando como os casos de uso se comportam entre si no sistema e com os usuários (atores).
· Ator – usuário do sistema que normalmente é identificado como um (bonequinho). Na identificação de um ator, é utilizado um substantivo no singular. Existem dois tipos de atores: principais e secundários. Os atores principais interagem diretamente com o sistema computacional, enquanto os atores secundários interagem com outros atores;
· Caso de Uso – são os objetivos que o sistema deve realizar para atingir o que precisa e serve como um contrato estabelecido entre o cliente e os desenvolvedores. Como um elemento em um diagrama, é a elipse (bola);
· Relacionamentos – pode ser chamado de Associação de Comunicação, desde que haja comunicação entre um ator e um caso de uso. (Eles são identificados com as setas que ligam os casos de uso e ligam os usuários ao caso de uso); 
· <<include>> - o caso de uso de inclusão é incorporado ao comportamento do caso de uso base (é uma reutilização);
· <<extend>> - o caso de uso de extensão pode ou não ser incorporado ao comportamento do caso de uso base (é opcional);
· Herança – o ator filho pode executar todos os casos de uso do ator pai e mais aqueles que apenas ele executa.
2.5. Cenário do tipo <<extend>> e <<include>>
<<Include>> - esse tipo de relacionamento é obrigatório para incluir o outro caso de uso evitando repetir comportamento, tendo o reuso de código, conforme demonstrado na figura 2.
Figure 1- Cenário do tipo <<include>>
Fonte: Desenvolvido pelo aluno
<<Extend>> - No sistema terá um cenário <<extend>> que é o controle de estoque, que será chamado caso não tenha produtos disponíveis, conforme demonstrado na figura 3.
Figure 2- Cenário do tipo <<extend>>
Fonte: Desenvolvido pelo aluno
PROTÓTIPO DE TELAS
A prototipação é um processo que tem como objetivo facilitar o entendimento dos requisitos, apresentar conceitos e funcionalidades do software. Desta forma, será proposta uma solução adequada para o problema do cliente, aumentando sua confiança e valorizando o trabalho.
Sendo a parte mais importante do desenvolvimento do sistema, essa etapa influência diretamente a produtividade da equipe e os valores entregues ao cliente. O processo de prototipação ajuda a entender o propósito do software que será desenvolvido, minimizando riscos e aumentando lucros.
A seguir será apresentado um esboço de cada tela do sistema onde o usuário poderá efetuar login, cadastrar produto, consultar produtos e cadastrar cliente.
É mais barato alterar um produto na sua fase inicial do que fazer alterações em um produto acabado. Estima-se que seja (100 x) cem vezes mais barato a efetuar alterações antes de começar a programação do que esperar que todo o desenvolvimento tenha sido efetuado (Jakob Nielsen, 2013).
3.1. Tela Efetuar Login
O usuário vai acessar o sistema através de uma tela de “Login” conforme está ilustrado na figura 4, inserindo “Login” e “Senha” e pressionar o botão “Acessar”.
Figure 3 - Tela de Login
Fonte: Desenvolvido pelo aluno
3.2. Tela Cadastrar Usuário
	Caso o usuário não tenha cadastro no sistema, terá que cadastrar seus dados com login e senha para poder ter acesso ao sistema, conforme ilustrado na figura 5:
Figure 4- Cadastrar Usuário
Fonte: Desenvolvido pelo aluno
3.3. Tela Cadastrar Produto
	A tela apresentada a seguir, será utilizada para que o funcionário da loja cadastre os produtos com código de barras, nome do produto, categoria, fabricante, quantidade e valor do produto.
Figure 5- Cadastrar Produto
Fonte: Desenvolvido pelo aluno
3.4. Tela Realizar Pedido e Pagar Produto
	Nessa tela o funcionário vai inserir os produtos que o cliente escolheu, na tela vai aparecer os produtos desejados com o código de venda, a data e o valor total. Confirmando a forma de pagamento, se estiver tudo certo, a venda do produto será finalizada.
Figure 6- Realizar Pedido e Pagar Produto
Fonte: Desenvolvido pelo aluno
ESPECIFICAÇÃO DE CASOS DE USO
O caso de uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente, ele descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O diagrama caso de uso é representado por atores, casos de uso, relacionamento entre elementos, associação e generalizações
[...] é um conjunto de métodos, procedimentos e ferramentas que tem por objetivo descobrir, analisar, documentar, verificar e validar esses requisitos.
[...] suas principais características e objetivos é uma visão a respeito da sequência de execução dessas atividades (VERSOLATO, 2015, pág. 59).
Figure 7- Relação entre atores e caso de uso
Fonte: Desenvolvido pelo aluno
4.1. Atores casos de uso
Supervisor (Gerente): O ator é responsável pelas atividades de nível administrativo, tais como: controle de funcionários, cadastro de funcionários, emissão de relatórios gerenciais e controles e autorização de cancelamento de vendas, por isso possui nível superior.
Atendente (funcionário): O ator é responsável pelas atividades de nível mais baixo na organização e por isso possui nível inferior. Ele é responsável pelas práticas de vendas, cadastramento de clientes.
Estoquista (funcionário): O ator é responsável pelas atividades de nível mais baixo na organização e por isso possui nível inferior. Ele é responsável pelo gerenciamento de estoque, compras e cadastros dos produtos.
A seguir serão demonstrados os modelos de descrição de cada caso de uso.
4.2. Caso de Uso – Efetuar Login
Descrição: esse caso de uso permite ao supervisor e funcionários se identificarem através do login e senha.
Ator(es): Supervisor e Funcionários.
Pré-condições: O usuário precisa de um login e senha cadastrada.
Pós-condições: O usuário se autentica no sistema.
Fluxo normal:
1- O ator digita o login e senha nos campos permitidos;
2- O ator pressiona o botão realizar login;
3- O sistema permite que o ator acesse o site;
4- O sistema informa a página.
Fluxo alternativo: 
F1 – Caso o usuário esqueça-se de preencher um dos campos login ou senha, exibir mensagem dizendo que o campo não está preenchido
F2 – Caso as informações do usuário não sejam válidas, exibir mensagem para o cliente fornece login e senha válidas.
4.3. Caso de Uso – Gerenciar Relatório
Descrição: esse caso de uso permite ao supervisor gerar relatório dos produtos, vendas e compras.
Ator: Supervisor.
Pré-condições: O usuário se autentica no sistema.
 O usuário escolhe o tipo de relatórios.
Pós-condições: O usuário finaliza relatórios.
Fluxo normal:
1- O ator preenche, escolhe a opção e os campos;
2- O sistema carrega os dados do relatório.
Fluxo alternativo:
F1 – O usuário pode cancelar o relatório.
4.4. Caso de Uso – Manter Cliente
Descrição: esse caso de uso permite ao funcionário inserir, alterar, excluir e pesquisarcliente.
Ator: Funcionário.
Pré-condições: o funcionário deverá estar autenticado no sistema.
Fluxo normal:
1- O sistema solicita os dados necessários para o cadastro do cliente;
2- O funcionário informa os dados de acordo com os campos a serem preenchidos (código, RG, CPF, nome, data do cadastro, endereço, telefone e e-mail do cliente);
3- O sistema solicita os dados para o cadastro da função;
4- O funcionário informa os dados necessários;
5- O funcionário seleciona a opção “Cadastrar”.
6- O sistema envia uma mensagem “Cliente Cadastrado com Sucesso”.
Fluxo alternativo:
F1- O funcionário não informa os dados necessários para o cliente ser cadastrado, o sistema informa que o cliente não está cadastrado;
F2- Durante o cadastro o funcionário poderá cancelar o processo.
4.5. Caso de Uso – Manter Fornecedor
Descrição: esse caso de uso permite ao supervisor e funcionário que façam o cadastro, consulta, alteração e exclusão dos fornecedores do sistema.
Ator(es): Supervisor e Funcionário.
Pré-condições: o usuário se autentica no sistema.
Pós-condições: os atores cadastram fornecedores no sistema.
Fluxo normal:
1- O usuário seleciona fornecedor;
2- O ator preenche os dados específicos dos materiais e confirma para consultar.
Fluxo alternativo:
F1- O fornecedor pode ser cadastrado;
F2- O fornecedor pode ser excluído.
4.6. Caso de Uso – Manter Produto
Descrição: esse caso de uso permite ao funcionário inserir, alterar, excluir e pesquisar produtos.
Ator: Funcionário.
Pré-condições: O funcionário deverá estar cadastrado no sistema.
Pós-condições: O funcionário executa o sistema.
Fluxo normal: 
1- O sistema solicita os dados necessários para que o produto seja cadastrado;
2- O funcionário executa o sistema preenchendo os dados de acordo com os campos a serem preenchidos (todos os produtos devem possuir: código de barras, nome do produto, categoria, fabricante, quantidade e valor do produto). Para os jogos, acessórios e produtos geek, devem ser informados em qual plataforma serão utilizados e qual prazo de garantia que produto possui;
3- O sistema solicita os dados para o cadastro da função;
4- O funcionário informa os dados necessários;
5- O sistema emite a mensagem “Produto Cadastrado com Sucesso”.
Fluxo alternativo:
F1- Se o funcionário não enviar os dados para o cadastro, o sistema informa “Produto não Cadastrado”;
F2- O funcionário poderá tentar cadastrar novamente.
4.7. Caso de Uso – Manter Compra
Descrição: esse caso de uso permite ao funcionário registrar notas de entrada e saída de produtos no sistema.
Ator: Funcionário.
Pré-condições: O usuário precisa se autenticar.
 O usuário seleciona compras.
Pós-condições: O usuário já tem produtos e fornecedores cadastrados.
Fluxo normal: O ator preenche os dados principais dos materiais que forem comprados e confirma a compra.
Fluxo alternativo: O usuário pode cancelar o pedido.
4.8. Caso de Uso – Manter Venda
Descrição: esse caso de uso permite ao funcionário fornecer informações para a movimentação de vendas.
Ator: Funcionário.
Pré-condições: O funcionário deverá estar cadastrado no sistema.
Pós-condições: O funcionário deverá fornecer informações sobre as vendas.
Fluxo normal:
1- O sistema solicita os dados principais para movimentar as vendas;
2- O funcionário informa os dados nos campos que precisam ser preenchidos;
3- O sistema solicita os dados para o cadastro da função;
4- O funcionário informa os dados essenciais;
5- O funcionário seleciona a opção “Salvar”;
6- O sistema informa “Operação Realizada com Sucesso”.
Fluxo alternativo:
F1- O funcionário poderá excluir produtos da venda caso o cliente não queira mais adquiri-los. Somente o supervisor da loja poderá excluir o produto da venda, precisará informar um usuário e senha válidos;
F2- No momento do cancelamento, o código da venda deve ser enviado para o sistema financeiro.
4.9. Caso de Uso – Consultar Preço
Descrição: esse caso de uso permite ao funcionário consultar preços dos produtos.
Ator: Funcionário.
Pré-condições: o funcionário deverá estar autenticado no sistema.
Pós-condições: o funcionário tem o resultado da consulta dos preços.
Fluxo normal: 
1- O funcionário para pesquisar deve preencher no campo de filtro algum dado do produto cadastrado como: código, descrição ou código de barra para poder pesquisar;
2- O sistema utiliza dados fornecidos para consultar no controle de estoque: quantidade disponível, valor e prazo de garantia;
3- O resultado da consulta é demonstrado na tela do sistema.
Fluxo alternativo: 
F1- Caso o cliente pressione o botão e não forneça nenhum dos campos: código, descrição ou código de barra, exibir uma mensagem que é obrigatório preencher os campos;
F2- Caso não encontre nenhum produto, exibir uma mensagem “Produto não Cadastrado”.
4.10. Caso de Uso – Manter Categoria de Produtos
Descrição: esse caso de uso permite ao funcionário inserir, alterar, excluir e pesquisar produtos.
Ator: Funcionário.
Pré-condições: o funcionário deverá estar cadastrado no sistema.
Pós-condições: o funcionário pode pesquisar produtos no sistema.
Fluxo normal: 
1- O sistema solicita os dados necessário para o cadastro da categoria de produtos;
2- O funcionário informa os dados de acordo com os campos a serem preenchidos. Jogos, acessórios e produtos geek deverão ser divididos por categorias;
3- O sistema solicita os dados para o cadastro de função;
4- O funcionário informa os dados necessários;
5- O funcionário seleciona a opção “Cadastrar”;
6- O sistema emite uma mensagem “Categoria Cadastrada com Sucesso”.
Fluxo alternativo:
F1- Se o funcionário não informar os dados para o cadastro da função, o sistema informa que o produto não está cadastrado;
F2- O funcionário poderá cancelar o processo durante o cadastro.
4.11. Requisitos Funcionais e Não Funcionais
· Requisitos Funcionais: são todas as necessidades, características ou funcionalidades esperadas em um processo que podem ser atendidos pelo software. De forma geral, um requisito funcional expressa uma ação que deve ser realizada através do sistema.
· Requisitos Não Funcionais: muitas vezes se aplicam à implementação e operação do sistema como um todo ao contrário de focar em funcionalidades ou serviços individuais de sistema.
O sistema oferecerá o acesso ao acervo dos jogos eletrônicos, acessórios e produtos geek da loja através de login e senha, onde possibilitará ao supervisor, atendentes ou estoquistas terem um controle dos estoques dos produtos e as vendas realizadas.
4.12. Regras de Negócio
Este artigo tem como finalidade a implantação de modelo de regras de negócio paralelamente ao desenvolvimento de software, oferecendo uma visão transparente aos usuários finais quanto aos processos de seus negócios. Ou seja, é um conjunto de instruções que os usuários já seguem e que o sistema a ser desenvolvido deve contemplar. Restrições validações condições e exceções do processo.
As regras de negócio restringem e definem como um determinado processo de negócio deve ser executado, além de demonstrar conhecimento em relação a um processo, também constituem aspectos restritivos difíceis na execução desse processo.
Uma regra de negócio não será refletida no sistema como uma funcionalidade, mas ela determinará o comportamento de uma ou mais funcionalidades do sistema.
Logo a seguir será mencionada apenas uma documentação de regras de negócios que foram aplicadas ao conhecimento do cenário do projeto para que se possa ter um conhecimento de como funcionam as regras de negócios.
	Identificação
	Cliente autenticado no site – regra de negócio (RN01).
	Descrição
	O cliente deve ser autorizado via login a acessar o site.
	Fonte
	Cenário descrito em Projeto de Sistema de Controle de Vendas de Jogos Eletrônicos, Acessórios e Produtos Geek.
	Histórico
	Data da identificação: 04/09/2020
DIAGRAMA DE CLASSES E ENTIDADE RELACIONAMENTO 
5.1. Diagrama de Classe
[...] diagrama de classes é um diagrama UML que tem como objetivo representar a estrutura estática das classes de um sistema de software.
Um diagrama de classes é a representaçãodas classes, seus atributos, métodos e o relacionamento entre essas classes [...] (VERSOLATO, 2015, pág. 118).
No desenvolvimento de software, o diagrama de classes contém muitas informações que podem estar escondidas em seus elementos por pessoas não treinadas para observá-lo, sejam eles desenvolvedores ou analistas de negócios, mesmo sem saber como fazê-lo, criadores são responsáveis por diagramação.
É essencial que os desenvolvedores consigam fazer uma interpretação correta deste diagrama de forma a gerar classes e atributos corretos e, para a utilização dos construtores de classes na construção das regras de negócio de software a partir das regras existentes nas ligações entre as classes.
Na elaboração do Diagrama de Classes, foram aplicadas as técnicas aprendidas na análise de sistema orientada a objetos para identificar as pesquisas necessárias para a construção do diagrama: identificação de classes, lista de classes, identificação de relacionamentos e construção do diagrama de classes. Em seguida, os atributos foram identificados a partir das características vinculadas às classes escolhidas e, por fim, identificação dos métodos a partir das ações a serem realizadas pela classe e seus atributos.
Em Classe, um atributo define os valores que podem ser salvos em uma instância. Um relacionamento e comunicação entre qualquer par de classes pode ser realizado a partir de termos, associação, generalização e dependência.
A seguir será demonstrado um diagrama de classe na figura 4:
Figure 8- Diagrama de Classe
Fonte: Desenvolvido pelo aluno
5.2. Modelo Entidade e Relacionamento (MER)
É um modelo abstrato desenvolvido pelo Prof. Peter Chen, a fim de representar as estruturas de dados de forma mais natural e mais próxima do mundo real dos negócios. Seus aspectos estruturais formalizam matematicamente a maneira como os dados estão organizados no modelo relacional (Pinto, 2012, pág. 36).
O Dr. Peter Chen propõe o modelo Entidade-Relacionamento (ER) para projetos de banco de dados, dando uma nova e importante percepção dos conceitos de modelos de dados. Assim com as linguagens de alto nível, a modelagem ER possibilita ao projetista concentrar-se apenas na utilização dos dados, sem se preocupar com estrutura lógica de tabelas.
O Modelo Entidade e relacionamento (MER) foi criado com o objetivo de demonstrar o significado relacionado aos dados do universo, utilizado na fazer conceitual de projetos, onde o esquema conceitual do banco de dados é idealizado.
O principal objetivo que o MER caracteriza é a entidade, que representa qualquer caso do mundo real que possui uma existência independente de objetos, pessoas, conceitos e outros. Toda entidade tem particularidade que são chamadas de atributos e algumas se relacionam uma com as outras. 
Logo abaixo será demonstrado como funcionam os Modelos Conceitual e Lógico no MER.
5.2.1. Modelo Conceitual 
O objetivo é criar um modelo de forma gráfica, sendo este chamado de Diagrama Entidade e Relacionamento (DER), que identificará as entidades e relacionamentos de uma forma global.
Figure 9- Modelo Conceitual
Fonte: Desenvolvido pelo aluno
5.2.2. Modelo Lógica
Basicamente determinam se todos os requisitos do negócio foram reunidos. Ele é revisado pelos desenvolvedores, pelo gerenciamento e pelos usuários finais para ver se é necessário coletar mais informações antes do início da modelagem física.
Figure 10- Modelo Lógico
Fonte: Desenvolvido pelo aluno
5.3. Diagrama de Classes de Análise
Classes de análise usadas para capturar os principais “blocos de responsabilidade” no sistema. Elas representam as classes prototípicas do sistema e são um ‘primeiro passo’ nas principais abstrações que o sistema deve tratar.
A funcionalidade externa de um sistema orientado a objetos é fornecida por meio de colaborações entre objetos. Externamente ao sistema, os atores visualizam resultado de cálculos, relatórios produzidos, confirmações de requisições realizadas etc. Internamente, os objetos do sistema colaboram uns com os outros para produzir os resultados visíveis de fora. Essa colaboração pode ser vista sob o aspecto dinâmico e sob o aspecto estrutural estático (BEZERRA, 2007). 
Em diagrama de classe de análise uma técnica de identificação muito utilizada é a Análise de Robustez. Para cada caso de uso, identificar os objetos e os eventos que os relacionam através de um diagrama de robustez. Objetos podem ser de três tipos: de fronteira, de controle ou de entidade.
Figure 11- Notação da UML para objetos
· Objeto de Fronteira (boundary) – realizam a comunicação do sistema com atores. Em outras palavras, são objetos de fronteira que permitem ao sistema interagir com seu ambiente;
· Objetos de Controle (control) – é também chamado de controlar. Objetos de controle servem como uma ponte de comunicação entre objetos de fronteira e objetos de entidade. São responsáveis por coordenar a execução de alguma funcionalidade especial do sistema.
· Objeto de Entidade (entily) – representa um conceito encontrado no domínio do problema. Normalmente servem como um repositório para alguma informação manipulada pelo sistema.
Figure 12- Diagrama de Classes de Análise
Fonte: Desenvolvido pelo aluno
CONTEXTOS DE USO
Com os avanços da tecnologia e a popularização dos dispositivos móveis, o contexto de uso (cenário onde a interação usuário/produto acontece) ganho cada vez mais audiência.
Em que cenário seu produto ou serviço poder ser utilizado? Que expectativas o usuário terá em cada um desses contextos? Que experiência deve ser oferecida em cada situação? É preciso mapear o cotidiano do público-alvo, visando identificar momentos e situações em que sua solução pode ser utilizada. 
Basear-se em questionários é o principal meio de análise de contexto de uso, os artifícios do contexto de uso surgem a partir das respostas a três questões: 
Quem irá utilizar a aplicação? (usuário). 
O que eles realizarão com a aplicação? (tarefas)
Onde eles usarão a aplicação? (ambiente)
· Usuário: Os funcionários da loja utilizarão o sistema da loja para efetuar vendas de jogos eletrônicos, acessórios e produtos geek, porem foi necessário pensar as diferentes características de cadastro/acesso para cada cargo;
· Tarefas: O objetivo principal elaborado para o funcionamento do sistema foi permitir que o usuário realizasse vendas de jogos eletrônicos e outros através de pedidos efetuados por clientes. Para garantir a segurança e obter rastreabilidade da venda, foi incluído cadastro dos produtos, cadastro dos usuários, acesso (login) de funcionário cadastrado, consulta de preços, possibilidade de cancelamento de venda;
· Ambiente: Para que o usuário tenha acesso ao desktop, será necessário o uso de algum computador capaz de se conectar a internet e de apresentar através de uma interface o layout do sistema (computador ou notebook).
TOMADA DE DECISÃO
Através dos conhecimentos adquiridos em Gestão Estratégicos de Recursos Humanos consegui obter tomadas de decisão muito importantes no projeto. Foi escolhido um processo para escolher uma das várias alternativas existentes para resolver um problema ou para programar alguns novos procedimentos, que são essenciais para o desenvolvimento do projeto. A comunicação entre o cliente e o desenvolvedor foi muito importante, pois era necessário saber ouvir e abrir o diálogo e obter decisões importantes para poder realizar este projeto da melhor forma que o cliente deseja.
Uma tomada de decisão eficiente necessita do controle, planejamento e administração das consequências que delas decorrem, com isso a organização precisa obter uma postura proativa para que possa realizar mudanças no ambiente externo. Para que tudo corra bem é necessário que o colaborador saiba ouvir, abra o processo de diálogo e a atitude participativa do cliente.
Esses foram os métodos mais adequados para poder interagir com o cliente, que sempre buscará uma forma de conhecer o sistema desenvolvido e que entenda claramente como funciona para poder interagir com o público-alvo, que são aspessoas que desejam comprar jogos eletrônicos, acessórios e produtos geek de forma rápida e eficiente.
CONCLUSÃO
Com o objetivo de desenvolver um software com sistema para controlar o estoque dos produtos e as vendas de uma loja que vende jogos eletrônicos, acessórios e produtos geek, a atividade inicial a ser realizada é o levantamento e análise de requisitos, identificando as necessidades ou requisitos do cliente.
No contexto do projeto, usei as técnicas utilizadas em modelos de casos de uso, diagrama de classes, modelo de entidade e relacionamento (MER), diagrama de classes de análise, desenvolvimento de sistemas e armazenamento de dados do sistema, dessa forma consegui colocar em prática todos os conhecimentos adquiridos com as disciplinas de Análise de Sistema Orientada a Objetos, Administração de Banco de Dados e Gestão Estratégica de Recursos Humanos.
Embora não seja estritamente necessário para o desenvolvimento de software, essas atividades iniciais assumidas no projeto não devem ser desconsideradas, pois são de grande importância porque vão garantir menos dificuldade no decorrer da atividade do desenvolvimento do software, maior qualidade do produto final e maior facilidade em futuras alterações, devido à maior disponibilidade de documentação. 
REFERÊNCIAS
ARTIGO ENGENHARIA DE SOFTWARE 3 – Requisitos não funcionais. Disponível em: https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-funcionais/9525 
DEVMEDIA. Introdução a Requisitos de Software. Disponível em: https://www.devmedia.com.br/introducao-a-requisitos-de-software/29580.
DIAGRAMA DE CASOS DE USO. O que é UML e Diagrama de caso de uso. https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408. 
FUNPAR. Diretrizes: Classe de Análise. Disponível em: <http://www.funpar.ufpr.br:8080/rup/process/modguide/md_acls2.htm>
MODELO ENTIDADE RELACIONAMENTO (MER). Disponível em: https://www.devmedia.com.br/modelo-entidade-relacionamento-mer/19821
O QUE É UML E DIAGRAMA DE CASO DE USO: Introdução Prática à UML. Disponível em: https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
ORIENTAÇÕES BÁSICAS NA ELABORAÇÃO DE UM DIAGRAMA DE CLASSES. Disponível em: https://www.devmedia.com.br/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes/37224
PINTO, Gisele Lopes Batista. Administração de Banco de Dados / Gisele Lopes Batista Pinto; Luiz Fernando dos Santos – São Paulo: Editora Sol, 2012. 108 p., il.
TORRES, Ani Sobral. Gestão Estratégica de Recursos Humanos. Ani Sobral Torres. – São Paulo: Editora Sol. 140 p., il.
VERSOLATTO, Fábio Rossi. Análise de Sistemas Orientada a Objetos. / Fábio Rossi Versolatto. – São Paulo: Editora Sol, 2015. 164 p., il.