Baixe o app para aproveitar ainda mais
Prévia do material em texto
UNIVERSIDADE PAULISTA – UNIP EaD Projeto Integrado Multidisciplinar – PIM III Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas GIOVANNA BARROS VIEIRA DOS SANTOS - 2263231 ANÁLISE E LEVANTAMENTO DE REQUISITOS DE SISTEMA Santo André 2023 GIOVANNA BARROS VIEIRA DOS SANTOS – 2263231 Projeto Integrado Multidisciplinar em Análise e Desenvolvimento de Sistemas Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em Análise e desenvolvimento de sistemas, apresentado à Universidade Paulista – UNIP EaD. Orientador (a): Profa. Dra. Vanessa Lessa Santo André 2023 RESUMO Este trabalho foi desenvolvido com base nos conteúdos de analise de sistemas orientados a objetos, gestão estratégica de recursos humanos e banco de dados. O sistema tem como objetivo principal, gerenciar o estoque de produtos e das vendas realizadas pela empresa de venda de jogos eletrônicos e produtos geeks. Este software também será capaz de consultar preços dos produtos cadastrados e realizar o cadastro de novos clientes e produtos, bem como atualizações, exclusões e consultas. Para demonstrar de uma forma simples as telas que serão apresentadas pelo software, foi utilizado uma plataforma de design, o Figma e para realizar os diagramas, utilizamos uma ferramenta de diagramação chamada Lucidchart. ABSTRACT This work was developed based on the contents of object-oriented systems analysis, strategic human resources management and database. The system's main objective is to manage the inventory of products and the sales made by the company selling video games and geek products. This software will also be able to consult prices of registered products and perform the registration of new customers and products, as well as updates, deletions and queries. To demonstrate in a simple way the screens that will be presented by the software, we used a design platform, Figma and to make the diagrams, we used a diagramming tool called Lucidchart. SUMÁRIO 1. INTRODUÇÃO ............................................................................................ 6 2. CASOS DE USO ......................................................................................... 7 3. MODELAGEM DE CASOS DE USO ........................................................... 8 3.1. LOGIN ...................................................................................................... 8 3.2. CADASTRO CLIENTE ............................................................................. 9 3.3. CADASTRO PRODUTO ........................................................................ 13 3.4. EFETUAR VENDA ................................................................................. 15 4. REQUISITOS NÃO FUNCIONAIS DE USABILIDADE ............................. 18 5. CONTEXTO DE USO ................................................................................ 19 5.1. USUÁRIOS E TAREFAS ....................................................................... 19 5.2. AMBIENTE ............................................................................................. 19 6. REGRAS DE NEGÓCIO ............................................................................ 19 6.1. CONTROLE DE ACESSO ..................................................................... 19 6.2. CADASTRO DE CLIENTES................................................................... 20 6.3. CADASTRO DE PRODUTOS ................................................................ 20 6.4. VENDAS ................................................................................................ 20 6.5. CONTROLE DE ESTOQUE ................................................................... 21 7. DIAGRAMA DE CLASSES DE ANÁLISE ................................................. 21 8. MODELO DE DADOS (MER) .................................................................... 22 9. DIAGRAMA ENTIDADE-RELACIONAMENTO (DER) .............................. 24 10. CONCLUSÃO ........................................................................................ 25 11. REFERENCIAS ...................................................................................... 26 6 1. INTRODUÇÃO Uma empresa do ramo de venda de jogos eletrônicos e produtos geek decidiu investir um sistema que permita o controle de estoque e vendas realizadas. O sistema será utilizado por atendentes, estoquistas e pelo supervisor da loja, permitindo realizar cadastros, alterações, consultas e exclusões relacionados aos produtos e clientes. No contexto do projeto, o atendente será responsável por efetuar vendas, cadastrar clientes e suas extensões e consultar os preços, o estoquista será responsável pelo cadastro dos produtos e suas extensões, e por fim, apenas o supervisor será capaz de excluir o produto da venda ou cancelar uma venda. É importante destacar que o sistema será capaz de identificar diferentes níveis de acesso, permitindo que apenas usuários autorizados realizem operações restritas. Com isso, garantimos a segurança e responsabilidades nas ações realizadas pelos usuários, proporcionando uma melhor experiencia para os clientes e colaboradores da empresa. 7 2. CASOS DE USO Tem como objetivo, descrever como será o uso de uma funcionalidade de um sistema. São usados para capturar os requisitos funcionais do sistema, ou seja, o que o sistema deve fazer para atender as necessidades dos usuários. Descreve uma sequência de ações e interações entre o usuário (ator) e o sistema para alcançar um objetivo especifico. É a descrição do sistema em termos de entrada e saída de ações, realizadas em uma resposta a uma solicitação do usuário. Os casos de uso para o sistema apesentados neste trabalho serão os seguintes: RF 01 – Realizar login RF 02 – Cadastrar cliente RF 03 – Alterar cliente RF 04 – Consultar cliente RF 05 – Excluir cliente RF 06 – Cadastrar produto RF 07 – Alterar produto RF 08 – Consultar produto RF 09 – Excluir produto RF 10 – Efetuar venda RF 11 – Excluir produto da venda RF 12 – Adicionar produto a venda RF 13 – Cancelar venda RF 14 – Consultar preço 8 3. MODELAGEM DE CASOS DE USO 3.1. LOGIN Identificação: Login Escopo: sistema de controle de acesso e autenticação Descrição: este caso de uso descreve o processo de autenticação e login no sistema Ator primário: atendente, estoquista e supervisor Interessados: atendente, estoquista e supervisor Pré-condições: • O sistema deverá estar operável • O usuário deverá possuir uma conta válida no sistema Pós-condições: • Usuário autenticado Fluxo normal 1. Usuário acessa o software 2. O sistema exibe a tela de login solicitando usuário e senha 3. Usuário insere suas credenciais 4. Sistema verifica a veracidade das credenciais 5. Se as credenciais forem válidas, o sistema libera o acesso do usuário Fluxo alternativo 1. Se as credenciais forem inválidas, uma mensagem de erro é exibida 2. Caso o usuário não lembre da senha, poderá solicitar a redefinição da mesma 9 Figura 1 – Tela login Fonte - Print Screen - Acervo próprio 3.2. CADASTRO CLIENTE Identificação: cadastrar cliente 10 Escopo: cadastro de um novo cliente no sistema de controle de estoque e vendas Descrição: permite que os atendentes da loja cadastrem novos clientes no sistema Ator primário: atendente Interessados: atendente e cliente Pré-condições: • O sistema deve estar operacional, • O ator deverá ter permissão para cadastrar o cliente Pós-condições:• Os dados dos clientes são registrados no sistema Fluxo normal 1. Após efetuar o login, o sistema exibe a tela de opções 2. O ator seleciona a opção cliente 3. É exibido todos os cadastros de clientes 4. O ator seleciona a opção incluir 5. O sistema exibe a tela para cadastro 6. O ator preenche todas as informações do cliente 7. O ator confirma cadastro 8. O sistema valida os dados preenchidos 9. O sistema salva o cadastro do cliente Fluxo alternativo 1. Caso exista campos em branco, uma mensagem de erro é exibida solicitando que os campos sejam preenchidos 2. Se os dados fornecidos não passarem na validação, o sistema exibe a mensagem de erro e solicita que o ator (atendente/supervisor) corrija as informações fornecidas 3. Cliente já cadastrado, o sistema exibe a mensagem e volta a tela principal 11 Requisitos relacionados RF 03 – Alterar cliente RF 04 – Consultar cliente RF 05 – Excluir cliente Figura 2 – Tela de opções Fonte - Print Screen - Acervo próprio 12 Figura 3 – Tela clientes Fonte - Print Screen - Acervo próprio Figura 4 – Tela cadastro cliente Fonte - Print Screen - Acervo próprio 13 3.3. CADASTRO PRODUTO Identificação: cadastrar produto Escopo: cadastro de um novo produto no sistema de controle de estoque e vendas Descrição: permite o cadastro de um novo produto no sistema e suas principais informações Ator primário: estoquista Interessados: estoquista Pré-condições: • O estoquista deve ter acesso ao sistema bem como estar autenticado como usuário com permissão para esta ação Pós-condições: • O novo produto é cadastrado no sistema e está disponível para consultas e vendas Fluxo normal 1. Após efetuar o login, o sistema exibe a tela de opções 2. O estoquista seleciona a opção produto 3. É exibido a lista de todos os produtos cadastrados no sistema 4. O estoquista seleciona a opção incluir 5. O sistema exibe a tela para cadastro 6. O ator preenche todas as informações do produto 7. O ator salva o cadastro do produto 8. O sistema valida os dados preenchidos 9. O sistema salva o cadastro do produto Fluxo alternativo 1. Caso exista campos em branco, uma mensagem de erro é exibida solicitando que os campos sejam preenchidos Requisitos relacionados 14 RF 07 – Alterar produto RF 08 – Consultar produto RF 09 – Excluir produto Figura 5 – Tela produtos Fonte - Print Screen - Acervo próprio 15 Figura 6 – Tela cadastro produtos Fonte - Print Screen - Acervo próprio 3.4. EFETUAR VENDA Identificação: Efetuar venda Escopo: Sistema de venda de jogos eletrônicos e produtos geek Descrição do proposito: Descreve o processo de efetuar uma venda no sistema. Ator primário: atendente Interessados: atendente e cliente Pré-condições: • O atendente/supervisor deve estar autenticado no sistema • Os produtos devem estar cadastrados no sistema e disponíveis no estoque Pós-condições: • A venda é registrada no sistema • Estoque atualizado com as quantidades vendidas 16 Fluxo normal 1. Após efetuar o login, o sistema exibe a tela de opções 2. O atendente seleciona a opção efetuar venda 3. O sistema gera um código único da venda 4. Digitando o CPF do cliente, as informações do mesmo já são preenchidas 5. O atendente registra os produtos escolhidos pelo cliente bem como suas quantidades 6. O sistema verifica a disponibilidade dos produtos 7. O sistema calcula o valor total da venda 8. Atendente seleciona a forma de pagamento 9. Pagamento é realizado 10. Atendente finaliza a venda 11. Estoque é atualizado Fluxo alternativo 1. Se algum produto escolhido não estiver disponível, o atendente é informado 2. Caso o cliente solicite o valor de um item, basta o atendente clicar na opção consultar preço 3. Caso o cliente queira exclui um produto da venda, é solicitado usuário e senha autorizados para realizar a ação 4. Caso o cliente queira cancelar a venda, é solicitado usuário e senha autorizados para realizar a ação 5. Se a venda for cancelada, o código de venda será enviado para o sistema financeiro Requisitos relacionados RF 10 – Efetuar venda RF 11 – Excluir produto da venda RF 12 – Adicionar produto a venda RF 13 – Cancelar venda 17 RF 14 – Consultar preço Figura 7 – Tela de vendas Fonte - Print Screen - Acervo próprio 18 Caso o atendente tente excluir um produto da venda ou cancelar a venda, a seguinte mensagem será exibida Figura 8 – Tela de vendas Fonte - Print Screen - Acervo próprio 4. REQUISITOS NÃO FUNCIONAIS DE USABILIDADE Requisitos não funcionais de usabilidade são aqueles que se referem à facilidade de uso, eficiência e satisfação do usuário. No projeto apresentado, podemos identificar as seguintes: Facilidade de aprendizagem: O sistema é intuitivo, permitindo que os usuários aprendam a usar a interface sem a necessidade de treinamentos externos Eficiência de uso: O sistema não é complexo, permite ao usuário realizar ações sem muitos cliques. Feedback ao usuário: O sistema exibe mensagens de confirmação do usuário para cada ação solicitada, evitando erros. 19 Eficiência de pesquisa: O sistema fornece uma funcionalidade de pesquisa eficiente, permitindo que os usuários encontrem rapidamente os produtos cadastrados no sistema 5. CONTEXTO DE USO 5.1. USUÁRIOS E TAREFAS Dentro do contexto, temos: Atendente: São responsáveis por realizar o atendimento ao cliente na loja. Precisam ter fácil acesso ao sistema bem como as informações detalhadas dos produtos para repassar ao cliente. Ficam responsáveis também pela venda, cadastro de clientes e consulta de produtos Estoquista: São responsáveis por controlar o estoque de produtos, cadastrar novos produtos e atualizar informações sobre eles Supervisor: É responsável por gerenciar a loja bem como supervisionar o trabalho do atendente e estoquista. Tem acesso restrito as funções como exclusão de produtos da venda e cancelamento de vendas. 5.2. AMBIENTE O sistema será utilizado em uma loja física, O acesso rá feito por meio de computadores ou notebooks localizados da loja. Os usuários irão interagir com a interface realizando e atualizando cadastros tanto de produtos quanto de clientes, realizando vendas e consulta de preços. 6. REGRAS DE NEGÓCIO 6.1. CONTROLE DE ACESSO O sistema deve possuir controle de acesso com níveis de login para garantir a segurança das informações 20 Cada usuário deve possuir credenciais únicas Os atendentes terão acesso limitado, não podendo realizar a exclusão de produtos da venda e cancelamento da venda Os estoquistas terão acesso apenas para cadastro de produtos e controle de estoque O supervisor terá acesso a todas as funcionalidades do sistema incluindo as limitadas para o atendente 6.2. CADASTRO DE CLIENTES Os clientes serão cadastrados com informações obrigatórias como: código, CPF, nome, data do cadastro, endereço, telefone e e-mail O código de cada cliente deverá ser exclusivo 6.3. CADASTRO DE PRODUTOS Os produtos devem ser cadastrados com informações obrigatórias como: código de barras, nome do produto, categoria, fabricante, quantidade e valor do produto Para os jogos e acessórios, deve ser informado em qual plataforma serão utilizados e também qual o prazo de garantia do produto. O código de barras deve ser exclusivo 6.4. VENDAS As vendas devem ser registradas com informações como: código único de venda, data de venda, valor da venda, opções para pagamento (dinheiro/cartão), status de pagamento e status da venda. Apenas o supervisor da loja será capaz de excluir um produto da venda ou cancelar uma venda mediante a usuário e senha autorizados. Ao cancelar uma venda, o código da venda cancelada deverá ser enviado para o sistema financeiro. 216.5. CONTROLE DE ESTOQUE Ao realizar uma venda, o sistema deve atualizar automaticamente a quantidade disponível em estoque Caso a quantidade em estoque seja zero, o sistema deve sinalizar a necessidade para reposição do estoque 7. DIAGRAMA DE CLASSES DE ANÁLISE É um diagrama definido pela UML que tem como objetivo fazer a representação gráfica das classes, seus atributos, métodos e relacionamentos. Fornece uma visão geral da estrutura do sistema e como funciona as interações entre as classes. Os objetos são divididos em três categorias de acordo com o seu tipo de responsabilidade: Entidade (Entity): são os objetos mais próximos do domínio do mundo real. Tem como objetivo manter as informações referentes ao domínio do problema que queremos resolver Fronteira (Boundary): é a camada de interação entre o usuário (atores externos) e o sistema. Controle (Control): realiza o sequenciamento da execução de um caso se uso, faz a coordenação entre as camadas internas do sistema (entidade) com as camadas externas (fronteira). 22 8. MODELO DE DADOS (MER) O modelo de Entidade-Relacionamento (MER), projeta e descreve a estrutura de um sistema de informação. Fornece uma representação visual das entidades (objetos) envolvidos no sistema, seus atributos (propriedades) e os relacionamentos entre elas. • Entidades: representam objetos do mundo real ou conceitos dentro do sistema. No nosso projeto, temos como exemplo a entidade cliente • Atributos: são as propriedades, características que descrevem uma entidade. Fornecem informações mais detalhadas sobre a entidade. Temos como exemplo da entidade cliente, o atributo “nome”. • Relacionamentos: representam as associações ou conexões entre as entidades. Podem ser de três diferentes tipos: 23 − Um-para-um (1:1) − Um-para-muitos(1:N) − Muitos-para-muitos(N:N) Temos como exemplo, a entidade cliente e venda, onde um cliente pode ter varias vendas, enquanto uma venda está associada a um único cliente 24 9. DIAGRAMA ENTIDADE-RELACIONAMENTO (DER) 25 10. CONCLUSÃO O software se mostrou eficiente, possibilitando o cadastro de clientes e produtos. Além disso, é capaz de realizar vendas e consultas de estoque e preço. Com os testes realizados com a prototipação de tela, podemos concluir que o software se mostra eficiente aos requisitos solicitados, considerando uma característica importante que é identificar diferentes níveis de acesso. Isso nos garante a confiabilidade do sistema. Neste projeto, fica claro a importância da automatização de algumas ferramentas nas empresas para que possam melhorar seus relacionamentos com os clientes além de agilizar o trabalho de seus colaboradores. Portanto, com este trabalho, podemos concluir que os requisitos solicitados pelo cliente foram alcançados com sucesso. 26 REFERENCIAS Figma. Figma. Disponível em: <https://www.figma.com/file/Rfpgn0acjymurvkeVbpchV/Untitled?type=design&n ode-id=12-10&t=dYjhsZuHnYjtJuZ2-0>. Acesso em: 4 jun. 2023. Documentos. Lucid.app. Disponível em: <https://lucid.app/documents#/documents?folder_id=home>. Acesso em: 4 jun. 2023. DRA, Profa ; LESSA. Orientação do PIM VI. [s.l.: s.n., s.d.]. Disponível em: <https://ava.ead.unip.br/bbcswebdav/pid-3329783-dt-content-rid- 10673136_1/institution/Conteudos_AVA/PIM%20- %20DP/SUP%20TEC%20EM%20AN%C3%81LISE%20E%20DESENVOLVIM ENTO%20DE%20SISTEMAS/3018-50%20- %20PROJETO%20INTEGRADO%20MULTIDISCIPLINAR%20VI/Slide.pdf>. Acesso em: 4 jun. 2023. ALURA. MER e DER: Definições, Banco de Dados e Exemplos. Alura. Disponível em: <https://www.alura.com.br/artigos/mer-e-der-funcoes>. Acesso em: 4 jun. 2023. TYBEL, Douglas. Diagrama de classes (UML): Orientações básicas na elaboração. DevMedia. Disponível em: <https://www.devmedia.com.br/orientacoes-basicas-na-elaboracao-de-um- diagrama-de-classes/37224>. Acesso em: 4 jun. 2023. SANTOS. Requisitos não funcionais: o guia completo! Betrybe.com. Disponível em: <https://blog.betrybe.com/tecnologia/requisitos-nao- funcionais/>. Acesso em: 4 jun. 2023.
Compartilhar