PIM VI - 2351267

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
 
 
 
 
 
Curso superior de Tecnologia em 
Análise e Desenvolvimento de Sistema 
 
 
 
 
Bruna Dias Bernardo Carvalho – 2351267 
 
 
 
 Levantamento e análise de requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios e produtos geek.
 
 
Barueri 
2024 
Bruna Dias Bernardo Carvalho – 2351267 
Levantamento e análise de requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios e produtos geek. 
 
Projeto Integrado Multidisciplinar em 
Análise e Desenvolvimento de Projetos 
 
 
 
Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em Análise e Desenvolvimento de Sistemas, apresentado à Universidade Paulista – UNIP EaD. 
 
 
 
Prof. Vanessa Lessa
 
 
Barueri 
2024
Bruna Dias Bernardo Carvalho – 2351267
 Levantamento e análise de requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios e produtos geek.
Multidisciplinar (PIM VI)
 
 
 Aprovado em: ___________ 
 
 
Banca Examinadora 
______________________/____/_____ 
Prof. Vanessa Lesa
UNIVERSIDADE PAULISTA – UNIP EaD 
 
	 
Resumo
Este projeto tem como foco principal a criação de um sistema para gerenciamento de vendas em uma loja de jogos, acessórios e produtos geek. Observou-se uma baixa eficiência na forma como as tarefas de controle de vendas são realizadas atualmente, usando uma planilha eletrônica Excel. Isso levou à necessidade de desenvolver um novo sistema desktop, robusto, compacto e eficaz, com módulos de acessibilidade para garantir sua usabilidade por usuários com deficiência.
Para alcançar esse objetivo, serão aplicadas as disciplinas do bimestre, incluindo Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos. Estas disciplinas fornecerão os conhecimentos necessários para o levantamento e análise de requisitos, bem como para o desenvolvimento e implementação do sistema de controle de vendas.
 
 
Abstract
This project has as its main focus the creation of a system for sales management in a store of games, accessories and geek products. A low efficiency was observed in the way sales control tasks are currently carried out, using an Excel spreadsheet. This led to the need to develop a new desktop system, robust, compact and effective, with accessibility modules to ensure its usability by users with disabilities. To achieve this goal, the disciplines of the semester will be applied, including Object-Oriented Systems Analysis, Database and Strategic Management of Human Resources. These disciplines will provide the necessary knowledge for the gathering and analysis of requirements, as well as for the development and implementation of the sales control system.
Sumário
Resumo	4
Abstract	5
1.	Introdução	7
2.	Contexto	7
3.	Agentes Econômicos e Requisitos	8
3.1.	Agentes econômicos	8
4.	Requisitos funcionais e não funcionais	9
4.1.	Regras e requisitos	10
4.2.	Qual metodologia escolher?	11
6	Programação Orientada a Objetos I	30
REFERENCIAS BIBLIOGRAFICAS	34
Introdução
O projeto consiste em realizar o levantamento e análise de requisitos para um novo sistema computacional destinado a substituir o atual sistema de uma loja de produtos geeks. A solução proposta visa não apenas trazer melhorias funcionais, mas também oferecer uma abordagem tecnológica que facilite a usabilidade e promova desempenho e agilidade para a loja.
Durante o projeto, serão apresentados conceitos e metodologias da engenharia de software, fornecendo os princípios necessários para um adequado levantamento e análise de requisitos. Além disso, serão explorados conceitos da área de Recursos Humanos para contextualizar o processo de seleção de uma equipe de desenvolvimento para a concepção do projeto, e conceitos de banco de dados para definir um modelo de entidade relacional que represente o comportamento dos dados no Sistema de Gerenciamento de Banco de Dados (SGBD).
Descrição do sistema
o cliente contratante para o desenvolvimento do projeto utiliza um método de trabalho que não está alcançando eficiência satisfatória. O sistema de controle de vendas em vigor é baseado em uma planilha eletrônica Excel. Nesse sistema, os funcionários preenchem a planilha manualmente e realizam as atualizações necessárias.
2.1 Problema atual
Com base no sistema atual de gerenciamento de vendas da empresa, que depende exclusivamente de planilhas no Excel, há uma falta de eficácia e segurança nos dados. A utilização de várias planilhas e a quantidade de dados resultam em inserções e extrações de informações demoradas. Além disso, há uma questão de segurança, pois não há um controle adequado de acesso ao sistema. Qualquer usuário com a senha pode acessar módulos que deveriam ser restritos, como o módulo de cancelamento de vendas, que deveria ser acessado apenas por supervisores e não por atendentes. Atualmente, o máximo de segurança que pode ser atribuído ao gerenciamento de acesso é definir que os usuários possam ler, mas não modificar o conteúdo, porém essa restrição pode ser burlada.
3. Soluções de sistemas disponíveis no mercado
Diante das muitas opções de sistemas de gerenciamento disponíveis no mercado, é comum encontrar uma variedade de soluções prontas que as empresas podem adquirir mediante licença. Realizando uma rápida pesquisa na web, é possível encontrar uma série de resultados, muitos deles oferecendo sistemas já prontos para uso, disponíveis para compra com uma assinatura vitalícia.
Para este projeto, conduzimos uma pesquisa em um dos sites mais populares e visitados da web, o Mercado Livre. Ao buscar pelo termo "sistema de gerenciamento", encontramos diversos sistemas prontos para uso, com a opção de assinatura vitalícia. No entanto, é importante notar que muitos desses sistemas oferecem pouca ou nenhuma personalização, o que pode ser prejudicial para o cliente.
A falta de flexibilidade para modificar o sistema conforme as necessidades específicas do cliente é um dos principais pontos negativos dessas soluções prontas. Além disso, não há garantia de suporte contínuo ou atualizações por parte do fabricante do sistema. Isso pode ser preocupante para o cliente, pois não há segurança de que o sistema continuará a ser suportado no futuro, especialmente se o fabricante deixar de operar o sistema.
Por outro lado, ao optar por desenvolver um sistema do zero, o cliente tem a vantagem de definir todos os requisitos e regras durante o desenvolvimento. Além disso, pode contar com um time de suporte dedicado ao sistema e torna-se proprietário do próprio software, eliminando a necessidade de renovação de assinaturas ou o risco de perder o acesso ao sistema no caso de descontinuação do fabricante. Essa abordagem oferece maior controle e personalização, garantindo que o sistema atenda perfeitamente às necessidades da empresa.
4. Desenvolvimento
O sistema solicitado tem um custo de produção de 30.000 por mês e deve ser entregue em 3 meses. No entanto, a empresa responsável pela produção, SoftLab, tem todas as suas equipes ocupadas com projetos atuais. Portanto, precisam contratar um novo time de desenvolvedores. O líder técnico do projeto pediu ao departamento de Recursos Humanos para encontrar profissionais adequados para formar essa nova equipe.
Os recrutadores técnicos são encarregados de identificar os seguintes profissionais: 1 Scrum Master, 4 programadores (1 júnior, 1 pleno e 2 sênior), 2 analistas de qualidade e 1 coordenador de projetos.
Esses recrutadores têm a função de selecionar os candidatos com os perfis necessários e realizar a primeira entrevista de seleção. Os candidatos aprovados nessa etapa são então encaminhados para a área técnica responsável. Após a aprovação em todos os processos, os candidatos são enviados para o departamento de Recursos Humanos para o processo de admissão.
5. Levantamento de requisitos e metodologia 
O desenvolvimento desse sistema é baseado na metodologia ágil Scrum. Esse modelo de desenvolvimento é incrementale iterativo, o que significa que o trabalho é dividido em miniprojetos que são desenvolvidos ao longo de ciclos com duração de 1 a 4 semanas.
O método ágil é amplamente utilizado em todo o mundo devido à sua abordagem de interação contínua entre desenvolvedores e clientes. Isso permite a entrega de um produto de qualidade ao final do projeto, pois o produto é constantemente avaliado e recebe feedback ao longo do ciclo de desenvolvimento.
5.1 Requisitos
Os requisitos representam as descrições das características e funcionalidades que um sistema deve possuir. Eles englobam as necessidades dos usuários, exigências do negócio, objetivos da empresa e outros fatores que devem ser incorporados ao sistema. Dentro do contexto de requisitos, destacam-se duas categorias principais: os funcionais e os não funcionais.
Os requisitos funcionais descrevem o comportamento do sistema, ou seja, especificam as ações que o sistema deve ser capaz de executar para atender às necessidades dos usuários e do negócio.
Por outro lado, os requisitos não funcionais especificam características do sistema como um todo, definindo como o sistema deve realizar as ações. Esses requisitos abrangem aspectos como desempenho, atributos de qualidade, usabilidade e outros aspectos cruciais para o desenvolvimento de um sistema. Eles influenciam na seleção de alternativas de projeto, no estilo arquitetural e na forma de implementação do sistema.
Funcionários
Abaixo, seguem descritos os requisitos funcionais do sistema, descritos por módulo, ordem, identificação, classificação, ator e objetivo.
· Acesso
· RF001
· Identificação: Efetuar Login;
· Classificação: Importante;
· Ator: Funcionário;
Objetivo: Este requisito descreve uma funcionalidade na qual o usuário só pode acessar o sistema após realizar um login válido, inserindo seu nome de usuário e senha corretos.
· Cliente
· RF002
· Identificação: Efetuar Login;
· Classificação: Importante
· Ator: Fncionário;
Objetivo: Esse requisito descreve a funcionalidade em que os clientes precisam se registrar no sistema fornecendo uma série de informações pessoais, incluindo RG, CPF, nome, data de nascimento, data de cadastro, endereço, telefone, e-mail e um código único de identificação, o qual será gerado automaticamente pelo sistema.
· Estoque
· RF003
· Identificação: Cadastro de Produtos;
· Classificação: Essencial;
· Ator: Funcionário;
Objetivo: Esse requisito descreve a funcionalidade na qual os produtos disponíveis para venda devem ser registrados no sistema, sendo categorizados em jogos e acessórios geeks.
· RF004
· Identificação: Descrição de Produtos;
· Classificação: Essencial;
· Ator: Funcionário;
Objetivo: Este requisito detalha a funcionalidade em que todos os produtos registrados no sistema devem conter informações de identificação essenciais, incluindo código de barras, nome do produto, categoria, fabricante, quantidade disponível e valor do produto. Além disso, para jogos e acessórios, também devem ser especificadas a plataforma compatível e o prazo de garantia. Essas informações serão utilizadas para o gerenciamento de estoque e apresentadas nas notas fiscais dos consumidores.
· Venda
· RF005
· Identificação: Processo de Vendas;
· Classificação: Essencial;
· Ator: Funcionário;
Objetivo: Este requisito descreve a funcionalidade em que cada venda deve incluir os dados do cliente e os detalhes de todos os produtos adquiridos. Além disso, durante a venda, um código único de venda deve ser gerado, contendo a data da transação, o valor total da compra, opções de pagamento, status do pagamento e status da venda.
· RF006
· Identificação: Exclusão de Produtos;
· Classificação: Essencial;
· Ator: Funcionário;
Objetivo: Este requisito descreve a funcionalidade na qual o atendente tem a capacidade de remover produtos de uma venda caso o cliente opte por não adquiri-los. No entanto, somente o supervisor da loja pode autorizar essa ação, exigindo a inserção de um nome de usuário e senha válidos para realizar a exclusão do produto da venda.
· RF007
· Identificação: Cancelamentos de Venda;
· Classificação: Essencial;
· Ator: Funcionário;
Objetivo: Este requisito estabelece que o atendente tem a capacidade de cancelar uma venda caso o cliente decida não prosseguir. No entanto, apenas o supervisor da loja pode autorizar essa ação, o que requer a inserção de um nome de usuário e senha válidos. Durante o cancelamento, o código de identificação da venda deve ser enviado para o sistema financeiro.
· RF008
· Identificação: Consulta de Preços;
· Classificação: Essencial;
· Ator: Funcionário;
Objetivo: Este requisito descreve a funcionalidade na qual o atendente tem a capacidade de consultar os preços dos produtos.
Não Funcionários
Abaixo, seguem descritos os requisitos não funcionais do sistema, descritos por módulo, ordem, identificação, classificação e objetivo.
· Desempenho
· RNF001
· Identificação: Requisitos de Configuração;
· Classificação: Importante;
Objetivo: Este requisito define os requisitos mínimos de configuração que um computador precisa atender para ser capaz de executar o sistema.
· Requisitos de Configuração do sistema computacional:
· 10 GB de espaço no disco rígido
· 2 GB de Memória RAM
· Processador Dual Core 2.8 GHz
· Sistema Operacional Windowa 7/Linux 15.10
· Usabilidade
· RNF002
· Identificação: Interface do Usuário;
· Classificação: Essencial;
Objetivo: Este requisito detalha a necessidade de usabilidade do sistema, seguindo os princípios de design de interface do usuário para garantir uma experiência amigável. Além disso, em resposta às necessidades do cliente, o sistema deve incluir módulos de acessibilidade para permitir que usuários com deficiência possam utilizá-lo com facilidade.
· Confiabilidade
· RNF003
· Identificação: Rotina de Backups;
· Classificação: Importante;
Objetivo: Este requisito enfatiza a importância da confiabilidade dos dados no sistema, exigindo que seja realizado um backup diário para garantir a segurança e a integridade das informações.
· Segurança
· RNF004
· Identificação: Autenticação de Acessos;
· Classificação: Importante;
Objetivo: Este requisito estabelece a necessidade de controle de acesso tanto ao sistema quanto ao banco de dados. Para acessar esses sistemas, é requerido o uso de um login composto por usuário e senha, com diferentes níveis de privilégio atribuídos.
· Compatibilidade
· RNF005
· Identificação: Compatibilidade em sistemas Operacionais;
· Classificação: Essencial;
Objetivo: Este requisito destaca a necessidade de o sistema ser compatível com diversos sistemas operacionais utilizados na empresa, incluindo Windows e Linux.
· Interoperabilidade
· RNF006
· Identificação: Integração com API de emissão de notas fiscais;
· Classificação: Importante;
Objetivo: Este requisito descreve a necessidade do sistema se comunicar com a API do órgão competente do estado onde está localizado, a fim de possibilitar a emissão de notas fiscais.
5.2 Regra de Negócio
A regra de negócio é um conceito relacionado ao domínio específico abordado no desenvolvimento de software. Ela pode existir independentemente do ambiente computacional. Segundo a definição do ABPMP BPM CBOK V3.0:
“Regra de negócio é a lógica que guia o comportamento e define O QUE,
 ONDE, QUANDO, POR QUE e COMO será feito, além de como o negócio 
será gerenciado ou governado. As regras podem assumir muitas formas, de 
simples decisões booleanas a decisões que envolvem regras de lógica mais complexas.
 Regras são declarativas e não podem ser decompostas sem perder seus significados”
As regras de negócio a seguir são baseados nos requisitos funcionais levantados anteriormente.
· RN01
· Nome: Restrição de Acesso;
· Descrição: Acesso as funcionalidades do sistema somente com autenticação por meio de usuário e senha de acordo com o requisito funcional;
· RN02
· Nome: Cancelar;
· Descrição: O cancelamento de uma venda só pode ser feito pelo supervisor;
· RN03
· Nome: Forma de pagamento
· Descrição: Deve ser oferecidas diferentes formas de pagamento ( Dinheiro ou cartão);
· RN04
· Nome: CadastrarProdutos;
· Descrição: Os produtos cadastrados no sistema devem seguir um padrão de identificação no sistema de acordo com o requisito funcional;
· RN05
· Nome: Cadastrar Clientes:
· Descrição: Os clientes cadastrados no sistema devem seguir um padrão de identificação no sistema de acordo com o requisito funcional;
· RN06
· Baixa de cancelamento de Venda
· Descrição: Após um cancelamento de uma compra, a informação deve ser enviado para o módulo financeiro;
· RN07
· Nome: Consultar de Preço
· Descrição: Consulta de preço de um produto no sistema para agilizar a informação caso o cliente necessite saber preço de um produto.
· RN08
· Nome: Exclusão de Produtos
· Descrição: Exclusão de um produto no processo de venda.
Observação: Todas as regras identificadas nesta análise de requisitos são implementadas de forma automatizada.
5.3 Caso de Uso
O caso de uso em um sistema descreve como os usuários interagem com suas funcionalidades. Usando a Linguagem de Modelagem Unificada (UML), o diagrama de caso de uso representa os usuários (ou atores) e suas interações com o sistema. É importante destacar que o caso de uso não descreve como o software será construído, mas sim como ele se comportará após estar pronto. Geralmente, um software é complexo e requer a identificação e documentação de vários casos de uso, cada um descrevendo uma parte das funcionalidades que o software ou suas partes devem oferecer.
Definição dos Atores
Os atores em um caso de uso são indivíduos ou sistemas que têm interações diretas com o sistema em questão.
"Um ator é um papel que um usuário desempenha em relação ao sistema.
 Os atores desempenham os casos de uso. Os atores não precisam ser
 humanos, em bora sejam representados com os bonecos humanos nos
 diagramas de caso de uso. Um ator também pode ser um sistema externo
 que necessita de alguma informação do sistema atual (FOWLER, 2000, p.52).
Um ator pode acionar diversos casos de uso, e um caso de uso pode ser acionado por diversos atores. De acordo com Furlan (1998, p.175), "o ator se comunica com o sistema através do envio e recebimento de mensagens, sendo que um caso de uso sempre é iniciado a partir do momento em que um ator envia sua mensagem (estímulo)".
Na figura 1, são representados os atores que participarão dos cenários, com base nas regras de negócio. O ator funcionário é responsável pelas operações de venda, exclusão, cadastro, entre outras. Observação: O conceito de herança do ator funcionário foi adotado, com três filhos: Atendente, Supervisor e Estoquista. O ator Cliente é diretamente afetado pelas ações do ator funcionário. O ator Sistema Financeiro é responsável pelo processamento de vendas e cancelamentos.
Figura 1 – Atores do Sistema
Abaixo estão as descrições em texto dos casos de uso:
Conclusão
REFERENCIAS BIBLIOGRAFICAS 
 
Legislação e Normas — Planalto (www.gov.br) 
Manual.pdf (unip.br) 
Vantagens do mps (https://promovesolucoes.com)
Programação orientada a objeto I CONTEÚDO – PROGRAMAÇÃO ORIENTADA A OBJETOS I 6857-60_... (unip.br)
Projeto de interface com o usuário CONTEÚDO – PROJETO DE INTERFACE COM O USUÁRIO 6859-60_... (unip.br)
Engenharia de software II CONTEÚDO – ENGENHARIA DE SOFTWARE II 6856-60_57501_R_E1_... (unip.br)
Economia e mercado CONTEÚDO – ECONOMIA E MERCADO 3081-50_57501_R_E1_20241 (unip.br)
7 
 
7 
 
7 
 
image1.png