Buscar

PIM VI

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.

Continue navegando