PIM IV

Prévia do material em texto

2
UNIVERSIDADE PAULISTA
TECNOLÓGO EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
MIGUEL ANGEL ZELEDON SALAS
LEVANTAMENTO E ANÁLISE DE REQUISITOS
Levantamento e análise de requisitos de um sistema de controle de vendas
de uma loja de jogos, acessórios e produtos geek
SÃO PAULO
2022
SUMÁRIO 
INTRODUÇÃO...................................................................................................5 
CAPÍTULO 1 .....................................................................................................6 
1.1 ATIVIDADE PROPOSTA...................................................................5 
1.2 LOJA..................................................................................................5 
CAPÍTULO 2.......................................................................................................7
2.1 REQUISITOS PARA INICIALIZAÇÃO ..............................................7 
2.2 BANCO DE DADOS ..........................................................................8 
2.3 CADASTRO DE CLIENTES ..............................................................9 
2.4 CONSULTA DE ESTOQUE ............................................................11 
2.5 VENDA..............................................................................................11
CAPÍTULO 3 CLASSES .................................................................................13
3.1 POLIMORFISMO ...........................................................................13
3.2 HERANÇA......................................................................................14
CAPÍTULO 4....................................................................................................15 
4.1 REQUISITOS NÃO-FUNCIONAIS ................................................15
CONCLUSÃO....................................................................................................16
RESUMO 
O presente trabalho apresenta os requisitos de sistemas necessários para o controle de vendas de uma loja de jogos, acessórios e produtos geeks, utilizando os conhecimentos adquiridos nas disciplinas e Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos.
A ideia principal é que esse trabalho dê os requisitos de um sistema que seja capaz realizar o cadastro de usuários, login, possa ver a disponibilidade do estoque para ver se os produtos estão disponíveis no momento, guardar os pedidos dentro de um carrinho de compras e finalizar as compras.
Palavras chaves: Geek, loja, vendas, acessórios, produtos
ABSTRACT
This work presents the system requirements needed to control the sales of a store of games, accessories and geek products, using the knowledge acquired in the disciplines and Object Oriented Systems Analysis, Database and Strategic Management of Human Resources.
The main idea is that this work gives the requirements of a system that is able to perform the registration of users, login, can view the availability of stock to see if the products are available at the moment, save the orders into a shopping cart and finalize the purchases.
Keywords: Geek, store, sales, accessories, products
Introdução
Uma loja de produtos geeks, jogos e acessórios, chamada de Loja Geek fechou um contrato com uma empresa de desenvolvimento de softwares para o desenvolvimento de seu sistema de vendas, dado que atualmente ela só faz o controle através de planilhas de Excel.
	O sistema terá que contar um sistema de login, gerenciamento de cadastros, consultas de clientes e estoque de materiais disponível à venda, dado que como existem alguns produtos com raridade maior, embora tenha no estoque, não podem ser encomendados.
	O trabalho visa colocar em prática todos os conhecimentos adquiridos nas matérias do semestre, sendo elas : Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos, além de exercitar metodologias e melhorar as técnicas de análises, além de desenvolver técnica usadas na produção de artefatos UML.
CAPÍTULO 1
1.1 ATIVIDADE PROPOSTA
Na engenharia de software, um dos processos iniciais e mais importantes de todo sistema, é o levantamento de requisitos que aquele sistema vai precisar.
Para isso inicialmente é necessário entender o que é um requisito. Os requisitos é uma exigência de característica ou propriedade que o sistema que está por ser desenvolvido de ter para satisfazer um contrato ou uma funcionalidade. Além disso eles podem ser categorizados como funcionais, de negócios e não-funcionais.
O requisito funcional é aquela característica que o sistema deve ter, para exercer a função de acordo com o planejado e possibilidades que o usuário pode fazer no sistema, tendo isso em vista, os requisitos funcionais do nosso projeto envolvem: acesso do sistema através de login e senha, cadastro de produtos pelo estoquista, banco de dados dos clientes, possuindo código, RG, CPF, nome, data de cadastro, telefone, endereço e e-mail, além dos produtos terem código de barras, nome do produto, categoria, fabricante, quantidade e valor. A venda tem que ter informações tanto do cliente quanto do produto vendido, além de informações adicionais da transação, além do atendente poder cancelar a venda, consultar preços e excluir produtos.
	Já os requisitos não-funcionais, são exigências adjacentes ao funcional, passando características do sistema como um todo, como velocidade, confiabilidade, segurança, restrições e etc. Sendo um exemplo de requisito não-funcional do nosso sistema é que apenas um supervisor poderá excluir um produto de uma venda, caso o cliente não queira mais.
1.2 LOJA
O cliente da empresa desenvolvedora de software é uma loja de artigos geeks, jogos e acessórios, sendo assim tem uma variedade ampla de produtos, o controle anteriormente era feito completamente através de planilhas de Excel, o que acaba sendo totalmente ineficiente, dado que tem que não tem automação nenhuma, caso seja feita alguma venda, algum funcionário teria que acessar as planilhas e fazer a diferença manualmente, já com um sistema integrado, tudo se comunicaria e a loja ganharia muito em redução de custos e produtividade, tendo em vista que o nome da é loja Geek, o sistema foi todo personalizado para essa loja e seus funcionários.
CAPÍTULO 2
2 
2.1 REQUISITOS PARA INICIALIZAÇÃO
Para iniciar o sistema, a primeira página deve ser a tela de login, onde o funcionário informará seu login e senha para poder acessar o sistema.
Figura 1 – Tela de login
		Fonte: Figma, 2022
Figura 2 – Tela de login(UML)
		Fonte: Lucidchart, 2022
Além do sistema em si, com a tela de login, será necessário um sistema de autenticação, onde guardará as informações login de cada funcionário, e será a primeira tela que o funcionário verá, assim que iniciar o sistema. Assim que o funcionário colocar as validações corretas, dará acesso ao sistema, para poder fazer todas as demais funções. Para que o login possa ser validado, é necessário que a máquina esteja conectado à internet no momento da validação, então essa é uma pré-condição para o acesso ao banco de dados e consequentemente ao sistema.
2.2 BANCO DE DADOS
Para armazenar todas as informações de estoque, clientes, vendas e até mesmo informações de login para os funcionários e para isso foi utilizado uma solução de banco de dados on-premisse, onde o servidor fica na filial. Para isso foi desenhado como estaria disponibilizado os schemas das tabelas e informando as tabelas, os relacionamentos, em um esquema em estrela onde as tabelas fatos ficam centralizadas e as tabelas dimensões em volta.
A escolha do esquema em estrela foi pela simplicidade e performance que o esquema apresenta e ainda sendo capaz de suprir as necessidades do sistema.
Figura 3 – Tabelas do sistema e seus relacionamentos
		Fonte: Lucidchart, 2022
2.3 CADASTRO DE CLIENTES
Para o cadastro de cliente qualquer pessoa que tenha acesso ao sistema pode fazer.
Figura 4 – Tela de cadastro de clientes
		Fonte: Figma,2022
Todos os campos são obrigatórios para o cadastro do cliente, assim que o funcionário preencher todos os dados do cliente corretamente e submeter o formulário, aparecerá uma mensagem de êxito, informando que o cliente foi cadastrado, caso não tenha preenchido corretamente, o sistema informará onde está o erro e solicitará que seja feito a correção.
	Assim que o cadastro for feito, o sistema irá até o banco de dados inserir essas novas informações, adicionando aos dados a data de cadastro e criando um ID único para aquele cliente.
	Além disso na tela anterior há a opção de excluir e/ou alterar um cliente da base de dados, apenas informando o CPF do cliente e assim que for feito a alteração/exclusão, os dados no Banco de dados serão modificados 
2.4 CONSULTA DE ESTOQUE
Para a consulta de estoque é rodada uma query na tabela de estoque, através do código de barras que é informado pelo usuário na tela de estoques.
Figura 5 – Tela de estoque
		Fonte: Figma, 2022
Interessante nesse ponto é que é possível desacoplar as funções para o estoque para as máquinas de consulta dentro da loja física da loja, aproveitando também e mostrando o valor oficial do produto em outra tabela, fazendo uso de polimorfismo e herança das linguagens orientada a objeto.
2.5 VENDA
Para a venda, acaba passando por vários fluxos e os requisitos para que a venda aconteçam são maiores que nas outras etapas. A partir do momento que o cliente demonstra o interesse em compra do produto, é necessário ver se o produto está disponível no estoque, caso não esteja, volta pro começo do ciclo, tentando converter a venda para outro produto. Caso tenha o produto em estoque, é necessário ver qual será a forma de pagamento, se for Pix ou dinheiro, é só fazer esperar a transferência e finalizar a venda, inserir todos os dados da venda na tabela fato de vendas e atualizando a tabela de estoque com o novo valor. Caso seja cartão de crédito é necessário ver se o pagamento foi aprovado ou não, caso seja, finalizar a venda, caso não, oferecer uma nova forma de pagamento ou cancelado a venda atual.
Figura 6 – Ciclo de venda
		Fonte: Lucidchart, 2022
CAPÍTULO 3 – CLASSES
3 
3.1 POLIMORFISMO
A palavra polimorfismo significa ter muitas formas. Em palavras simples, podemos definir polimorfismo como a capacidade de uma mensagem ser exibida em mais do que uma forma. Uma pessoa ao mesmo tempo pode ter características diferentes. Como um homem ao mesmo tempo é um pai, um marido, um empregado. Portanto, a mesma pessoa possui um comportamento diferente em situações diferentes e isso é chamado de polimorfismo
Figura 7 – Polimorfismo
Fonte: inf.pucrs.br/~michael/aulas/algo_progII/apresentacoes/Heranca-Polimorfismo-MetAbstrato.htm
O polimorfismo é considerado uma das características importantes da Programação Orientada a Objeto. O polimorfismo nos permite realizar uma única ação de diferentes maneiras. Por outras palavras, o polimorfismo permite definir uma interface e ter múltiplas implementações. A palavra "poli" significa muitas e "morfismo" significa formas, portanto, significa muitas formas.
3.2 HERANÇA
A herança é um pilar importante da Programação orientação a objetos. É o mecanismo em POO pelo qual uma classe é autorizada a herdar as características (campos e métodos) de outra classe. 
Figura 7 – Herança
Fonte: inf.pucrs.br/~michael/aulas/algo_progII/apresentacoes/Heranca-Polimorfismo-MetAbstrato.htm
Pode ser caracterizada por:
Super Classe: A classe cujas características são herdadas é conhecida como super classe (ou uma classe base ou uma classe pai).
Subclasse: A classe que herda a outra classe é conhecida como uma subclasse (ou uma classe derivada, classe alargada, ou classe infantil). A subclasse pode adicionar os seus próprios campos e métodos para além dos campos e métodos da superclasse.
Reescrita: A herança apoia o conceito de poder ser utilizada novamente, ou seja, quando queremos criar uma nova classe e já existe uma classe que inclui algum do código que queremos, podemos derivar a nossa nova classe da classe existente. Ao fazer isto, estamos reutilizando os campos e métodos da classe existente.
	E uma forma interessante de utilizar essas classes, são por exemplo nas máquinas de verificação de preços e estoque dentro da loja física, onde você já tinha a utilização de uma classe para ter as informações de estoque e outra de preço, utilizando a herança para herdar essas características, é possível criar uma nova classe que herde essas características para poder informar no totem.
CAPÍTULO 4 
4 
4.1 REQUISITOS NÃO-FUNCIONAIS
Além de todos os requisitos funcionais que foram citados acima, existem os requisitos não-funcionais, que visam a utilização do sistema em si no quesito de segurança, escalabilidade, acessibilidade, disponibilidade, confiabilidade, tecnologias e manutenção.
O cliente já espera que esses requisitos sejam cumpridos, dado que qualquer software necessita desses requisitos para rodar, dado que não dá pra rodar o software normalmente se o banco de dados estiver fora do ar ou caso o site esteja sofrendo vários ataques externos de segurança e não há nenhuma medida preventiva contra.
Segue os principais Requisitos Não-Funcionais do sistema e suas definições:
Performance: É a capacidade do sistema executar transações em relação à quantidade de recursos disponibilizado ao sistema, funcionando com todas as suas funcionalidades e de maneira estável
Usabilidade: O usuário necessita ser apto para mexer no sistema, sem que tenha feito um curso, ou algo do gênero, fazendo assim, um sistema que seja intuitivo para qualquer usuário de primeira viagem.
Segurança: É necessário garantir que não tenha nenhum acesso sem autorização ao sistema, aos dados ou aos programas que o ecossistema gere.
Manutenção: Isso acaba afetando diretamente na facilidade de uma pessoa conseguir dar manutenção no sistema, de maneira eficaz, sem perder muito tempo.
Disponibilidade: O sistema não pode passar muito tempo fora do ar, dado que isso acaba gerando prejuízo diretamente ao cliente, por isso por mais que um sistema seja propenso a dar algum erro, entrar em manutenção ou queda de performance, é necessário que isso seja por um tempo mínimo, gerando um tempo de disponibilidade alto do sistema.
CONCLUSÃO 
Com ajuda de todo o conhecimento adquirido durante o semestre, se faz possível elaborar os requisitos que um sistema complexo como o de um sistema de ERP básico necessita.
É necessário prestar atenção em todos os fluxos e além disso, se faz claro também um sistema de testes unitários para que não aconteçam exceções que possam de alguma forma prejudicar o cliente ou o sistema.
Além de ser um sistema de Desktop, que possibilite acessibilidade em alguns aspectos para seus utilizadores, pode fazer alterações diretamente nos Banco de dados do sistema, como criação de novos produtos, alteração em cadastro de cliente e etc.
REFERÊNCIAS BIBLIOGRÁFICAS
A importância de fazer o levantamento de requisitos para um sistema 	Disponível em: https://vverner.com/a-importancia-de-fazer-o-levantamento-de-requisitos-para-um-sistema/ acesso em 06 de jun 2022.
Modelagem Dimensional – Star Schema e Snowflake Schema	Disponível em: https://www.dbccompany.com.br/modelagem-dimensional-star-schema-e-snowflake-schema/ acesso em 06 de jun 2022.
HERANÇA, REESCRITA E POLIMORFISMO	Disponível em: https://www.alura.com.br/apostila-java-orientacao-objetos/heranca-reescrita-e-polimorfismo?gclid=CjwKCAjwy_aUBhACEiwA2IHHQEkXWmsCQMctfurRySAMg97ew6Y0eFQOw-hUa2vf48XJ-HdaOcPnmRoCgJUQAvD_BwE acesso em 06 de jun 2022.
Herança, Polimorfismo, Classes e Métodos Abstratos	Disponível em:
https://www.inf.pucrs.br/~michael/aulas/algo_progII/apresentacoes/Heranca-Polimorfismo-MetAbstrato.htm acesso em 06 de jun. 2022