lOMoARcPSD|41418076

Pim VI 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 multi pim (Universidade Paulista)

Digitalizar para abrir em Studocu

A Studocu não é patrocinada ou endossada por nenhuma faculdade ou universidade

Baixado por Edith Harper (harperedith21@gmail.com)
 lOMoARcPSD|41418076

UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas

PAULO ROBERTO BORGES JUNIOR – RA 2200042

LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE

CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E
PRODUTOS GEEK.

LAPA
2023

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

PAULO ROBERTO BORGES JUNIOR – RA 2200042

LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CONTROLE

DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS EPRODUTOS GEEK.

Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em

Análise e Desenvolvimento de Sistemas
Orientador (a): VANESSA SANTOS LESSA

LAPA
2023

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

RESUMO

Esse projeto tem o principal objetivo de desenvolver o levantamento e análise

de Requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios
e Produtos Geek, devido à baixa eficácia na forma em realizar as pequenas tarefas
Gerenciadas para controlar as vendas. Devido a essa baixa do controle de vendas
atualmente sendo gerenciado em uma Planilha eletrônica Excel, surgiu a necessidade
de melhoria desenvolvendo um novo sistema desktop robusto, compacto e eficaz, que
tenha módulos de acessibilidade para que, os eventuais usuários portadores de
deficiência consigam utilizá-lo sem problemas no Gerenciamento do controle de
vendas. Para o desenvolvimento do projeto serão utilizadas e embasadas as
disciplinas vigentes do Bimestre, Banco de Dados, Análise de Sistemas Orientada a
Objetos e gestão Estratégica de RH.

Palavras-chave: Engenharia de Software. Orientação a Objetos. Banco de Dados.

Gestão de Recursos Humanos.

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

ABSTRACT

This project has the main objective of developing the survey and analysis of
Requirements of a sales control system for a game store, accessories and Geek
products, due to the low effectiveness in the way of performing small tasks Managed
to control sales. Due to this drop in sales control currently being managed in a Excel
spreadsheet, the need for improvement arose by developing a new robust, compact
and effective desktop system, which has accessibility modules so that Any users with
disabilities can use it without problems in the Sales Control Management. For the
development of the project, the current disciplines of the Bimester, Database, Object
Oriented Systems Analysis and management HR Strategy.

Keywords: Software Engineering, Object orientation, Database, Human resource

Management.

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

Sumário
1 INTRODUÇÃO ......................................................................................................... 6

2 DESCRIÇÃO DO SISTEMA ATUAL ........................................................................ 6

2.1 Problemas Existentes ............................................................................................ 6

2.2 Desejos do Cliente ................................................................................................ 7

3 SOLUÇÕES DE SISTEMAS DISPONÍVEIS NO MERCADO ................................... 7

4 TIME DE DESENVOLVIMENTO .............................................................................. 7

5 LEVANTAMENTO DE REQUISITOS E METODOLOGIA ........................................ 8

5.1 Requisitos.............................................................................................................. 8

5.1.1 Funcionais .......................................................................................................... 9

5.1.2 Não Funcionais ................................................................................................ 11

5.2 Regra de Negócio ............................................................................................... 12

5.3 casos de uso ....................................................................................................... 13

5.3.1 Definição dos Atores ........................................................................................ 14

5.4 diagramas de classes .......................................................................................... 15

5.4.1 Descrição das Classes ..................................................................................... 16

6 MODELO ENTIDADE RELACIONAMENTO .......................................................... 16

7 CONCLUSÃO......................................................................................................... 18

REFERENCIAS ......................................................................................................... 19

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

1 INTRODUÇÃO

O projeto trata-se do levantamento e análise de requisitos de um sistema

Computacional a ser desenvolvido para substituir o atual "sistema" de uma loja de
Produtos geeks, juntamente com a solução e funcionalidade trazer uma solução
tecnológica que facilite a usabilidade e traga desempenho e agilidade para a loja. No
projeto será apresentado, conceitos e metodologia da engenharia de software que irá
apresentar os princípios para uma bom levantamento e análise de Requisitos. Além
dos conceitos da área de Recursos Humanos, para contextualizar o processo de
seleção de um time de desenvolvimento para concepção do projeto e conceito do
banco de dados para definição de um modelo de entidade relacional que irá
representar o comportamento dos dados no SGBD.

2 DESCRIÇÃO DO SISTEMA ATUAL

O cliente contratante para o desenvolvimento do projeto, tem um método de

trabalho onde a eficiência não está sendo atingida. O sistema atual de controle de
vendas trata-se por meio da planilha eletrônica Excel, onde o funcionário preenche a
planilha e faz a atualização

2.1 Problemas Existentes

Tendo conhecimento do sistema atual de trabalho da empresa para o

gerenciamento de vendas, são feitos a partir de planilhas no Excel. Dessa forma a
empresa não transmite eficácia e nem segurança aos dados, que por compor muitas
planilhas e dados, acarreta na demora da inserção e extração de dados, por exemplo.
Outro problema é que não existe um controle de acesso ao “sistema”, qualquer
usuário com a senha pode acessar módulos que eram para ser restritos. Como por
exemplo, o módulo de cancelamento de uma venda que deve ser realizado por um
supervisor e não pelo atendente, o máximo de “segurança” que pode ser atribuída
com o 'gerenciamento” atual de acesso é definir que o usuário possa ler, más não
modificar o conteúdo, sendo essa podendo ser burlada.

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

2.2 Desejos do Cliente

A partir dos problemas expostos, faz se necessárias mudanças nos sistemas

atuais utilizados. A implantação de um sistema automatizado onde o seu acesso será
restrito a diferentes funções tem como objetivo principal agilizar todo o processo de
gerenciamento e integralidade de dados.

3 SOLUÇÕES DE SISTEMAS DISPONÍVEIS NO MERCADO

Existem diversas opções de sistemas de gerenciamento disponíveis no

mercado. Em uma rápida pesquisa na Web com o termo “sistema de gerenciamento
de vendas” diversos resultados aparecem na pesquisa. Na maioria das opções são
sistemas já prontos que a empresa adquiri por meio de uma licença.
Como cenário para efeito de pesquisa, para esse projeto foi realizado
pesquisas em um dos sites mais famosos e visitados na web, o Mercado Livre. Ao
pesquisar pelo termo “sistema de gerenciamento” a plataforma retorna como resultado
para venda diversos sistemas já prontos para usar com assinatura vitalícia O que
chama atenção é que nas descrições do anunciante, o sistema vem com quase/ou
nenhuma modificação caso o cliente deseje. O fator citado é um dos mais prejudiciais
ao cliente, já que não se tem a seguridade de adquirir um sistema com suporte e,
atualizações, além do comprador não poder exigir nenhum requisito adicional no
sistema.
Com um sistema criado do zero, o cliente faz jus a um sistema que irá ter todos
os atributos de sucesso citados no fator prejudicial. Em um sistema com a criação do
zero, o cliente pode definir todos os requisitos e regras ao decorrer do
desenvolvimento, além de poder contar com um time de suporte ao sistema e ser dono
do próprio sistema, não necessitando de renovação de assinaturas ou correr o risco
de ficar sem o sistema, caso algum dia o fabricante do sistema deixe de operar o
sistema.

4 TIME DE DESENVOLVIMENTO
O custo de produção do sistema solicitado é de 30.000 mensais, com o prazo
de entrega para 3 meses. Atualmente a fábrica de software SoftLab (fábrica fictícia,
que irá produzir o sistema) está com todas as equipes elencadas a projetos em

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

andamento. Nesse contexto a SoftLab precisa contratar um novo time de

desenvolvedores para a fabricação do sistema. O líder técnico responsável pelo
projeto solicitou a equipe de Recursos Humanos, identificar possíveis profissionais
para montar um novo time de desenvolvimento.
Os profissionais responsáveis para identificar o novo time de desenvolvimento,
são os recrutadores técnicos. Os recrutadores técnicos devem identificar os seguintes
profissionais: 1 Scrum Master, 4 programadores (1 júnior, 1 pleno e 2 sêniores), 2
analistas de qualidade e 1 coordenador de projetos.
O papel do tech recruiter é selecionar os perfis aderentes a vagas e fazer a
primeira entrevista de seleção para passar para área técnica responsável, já que estes
profissionais têm skills voltadas especialmente para capturar pessoas da área de TI.
Os candidatos aprovados em todos os processos são encaminhados para área
admissional dos Recursos Humanos.

5 LEVANTAMENTO DE REQUISITOS E METODOLOGIA

O desenvolvimento desse sistema. é apoiado na metodologia de

desenvolvimento ágil Scrum. Esse modelo de desenvolvimento é incremental
interativo, onde o desenvolvimento é composto por miniprojetos que são
desenvolvidos ao longo do ciclo que duram em torno de 1 a 4 semanas.
O ágil é um dos modelos mais utilizado no mundo, já que que sua interação é
continua entre desenvolvedores e clientes, a fim de entregar um produto de qualidade
no final do projeto, já que o produto passa por constante feedbacks ao decorrer do
ciclo de desenvolvimento

5.1 Requisitos

Os requisitos são as descrições das características e funcionalidades que

devem ser realizadas por um sistema. Nesse contexto engloba as necessidades de
um usuário, exigências do negócio, desejos da empresa, entre diversas outros fatores
que englobam os requisitos que deve ser materializado em um sistema.
No contexto de requisitos duas grandes categorias se destacam, que são os
funcionais e os não funcionais. Os requisitos funcionais descrevem e expressam o

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

comportamento do sistema, ou seja, são os requisitos funcionais que especificam

ações que o sistema deve executar.
Os requisitos não funcionais especificam as ações como o todo do sistema que
define como o sistema fará as ações. Os requisitos não funcionais têm como requisitos
o desempenho, atributos de qualidade, usabilidade, entre diversos outros requisitos
de grande importância no desenvolvimento de um sistema, que define a seleção na
escolha de alternativas de projeto, estilo arquitetural e forma de implementação.

5.1.1 Funcionais

Abaixo, seguem descritos os requisitos funcionais do sistema, descritos por módulo,

ordem, identificação, classificação, ator e objetivo.
. Acesso
. Identificação: Efetuar Logui;
. Classificação: Importante;
. Ator: Funcionário;
. Objetivo: Esse quesito especifica um caso de uso em que o usuário só tem acesso
permitido ao sistema por meio de um Loguin, informando usuário e senha.

. Cliente

. RF002
. Identificação: Cadastro de Clientes;
. Classificação: Essencial;
. Ator: Cliente;
. Objetivo: Esse requisito especifica o caso de uso em que os clientes devem ser
cadastrados com as seguintes informações pessoais: RG, CPF, nome, data de
nascimento, data de cadastro, endereço, telefone, e-mail e um código de identificação
(código a ser gerado pelo sistema automaticamente).

. Estoque

. RF003
. Identificação: Cadastro de Produtos;

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

10

. Classificação: Essencial;
. Ator: Funcionário;
. Objetivo: Esse reqiosito especifica o caso de uso em que os produstos a serem
vendidos devem ser cadastrados no sistema, os quais deverão ser divididos por
categorias: Jogos, acessórios geeks.
. RF004
. Identificação: Descrição de Produtos;
. Classificação: Essencial;
. Ator: Funcionário;
. Objetivo: Esse requisito especifica o caso de uso em que todos os produtos
cadastrados no sistema devem possuir as seguintes informações de identificação;
Código de barras, nome do produto, categoria, fabricante, quantidade e valor do
produto. Para os jogos e os acessórios, devem ser informados em qual plataforma
serão utilizados e qual o prazo de garantia que o Produto possui.
Todas essas informações serão utilizadas para gerenciamento no estoque e
apresentação na nota fiscal do consumidor.

. Venda

. RF005
. Identificação: Processo de venda;
. Classificação: Essencial;
. Ator: Funcionário;
. Objetivo: Esse requisito especifica o caso de uso em que a venda devera possuir os
dados do cliente e todos os produtos adquiridos. Para a venda, tambem deverá ser
gerado um código único de venda, com a data da venda, o valor da venda, opções
para agendamento, status de pagamento e status de venda.

. RF006
. Identificação: Exclusão de produtos;
. Classificação: Essencial;
. Ator: Funcionário;
. Objetivo: Esse requisito especifica o caso de uso em que o atendente poderá excluir
produtos da venda caso o cliente não queira mais adquiri-los. Logo, apenas o

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

11

supervisor da loja poderá permitir a função de exclusão do produto da venda, devendo

informar um usuário e senha validos.

. RF007
. Identificação: Cancelamento de Venda;
. Classificação: Essencial;
. Ator: Funcionário;
. Objetivo; esse requisito especifica o caso de uso em que o atendente poderá
cancelar uma venda caso o cliente não queira prosseguir. Logo apenas o supervisor
da loja poderá permitir a função de exclusão do produto da venda, devendo informar
um usuário e senha validos, no momento do cancelamento o código do cancelamento
da venda deverá ser enviado ao usuário do sistema financeiro.

. RF008
. Identificação: Consulta de Preços;
. Classificação: Essencial;
. Ator: Funcionário;
. Objetivo; esse requisito especifica o caso de uso em que o atendente poderá
consultar os preços dos produtos.

5.1.2 Não Funcionais

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; esse requisito especifica os requisitos mínimos de configuração que um
computador deve ter para rodar o sistema.
. Requisitos de configuração do sistema computacional.

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

12

. 10 GB de espaço no disco rígido. 2 GM de memória ram . Processador Dual Core

2.8 GHZ. Sistema operacional Windows 7/Linux 15.10. Usabilidade.

RNF002
. Identificação: Interface do usuário;
. Classificação: Essencial;
. Objetivo; esse requisito especifica o requisito de usabilidade apoiado nos princípios
da interface do usuário, onde é explicito que um sistema deve fornecer um sistema
amigável. E por necessidade do cliente. O sistema deve atender módulos de
acessibilidade para que eventuais usuários portadores de deficiência consigam utilizá-
lo.

. Confiabilidade
. RNF003
. Identificação: Rotina de Backups;
. Classificação: Importante;
. Objetivo; Esse requisito especifica a necessidade do sistema quanto a confiabilidade
dos dados, sendo necessário a realização do backup diariamente do sistema.

. Segurança
. RNF004
. Identificação: Autenticação de Acessos;
. Classificação: Importante;
. Objetivo; esse requisito especifica a necessidade do controle de acessos ao sistema
e ao banco de dados. Para o acesso a esses sistemas é necessário o uso de Login
contendo usuário e senha com níveis de privilégio.

5.2 Regra de Negócio

A regra de negócio é um conceito associado ao domínio de aplicação tratado

no desenvolvimento de software. A regra de negócio pode ser independente do mundo
computacional. As regras de negócio a seguir são baseadas nos requisitos funcionais
levantados anteriormente.

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

13

. Compatibilidade.
. RNF005
. Identificação: Compatibilidade em sistemas Operacionais;
. Classificação: Essencial;
. Objetivo: Esse requisito especifica a necessidade do sistema ser compatível com
diferentes sistemas computacionais presentes na empresa, que são eles, Windows e
Linux.

. Interoperabilidade.
. RNF006
. Identificação: Integração com API de emissão de notas fiscais;
. Classificação: Importante;
. Objetivo: Esse requisito especifica a necessidade do sistema se comunicar com a
API do órgão competente do estado onde o sistema esta alocado, para a emissão de
notas fiscais. . Nome: Forma de Pagamento;
. Descrição: Deve ser oferecidas diversas formas de pagamento.

. RN01
. Nome: Baixa de cancelamento de venda;
. Descrição: Após cancelamento de uma venda a informação deve ser enviada para o
modulo financeiro.

. RN02
. Nome: Consulta 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.

. RN03. Nome: Exclusão de produtos; . Descrição: Exclusão de um produto no

processo de venda.

5.3 casos de uso

O caso de uso tem como objetivo a descrição de como será o uso de uma
funcionalidade de um sistema. Na Linguagem de modelagem unificada (UML), o

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

14

diagrama de caso de uso resume os detalhes dos usuários do seu sistema (também
conhecidos como atores) e as interações deles com o sistema. É importante notar que
não descreve como o software deverá ser construído, mas sim como ele deverá se
comportar quando estiver pronto. Um software frequentemente é um produto
complexo, e sua descrição envolve a identificação e documentação de vários casos
de uso, cada um deles descrevendo uma "fatia" do que o software ou uma de suas
partes deverá oferecer.

5.3.1 Definição dos Atores

Os atores de um caso de uso são pessoas ou sistema que interagem

diretamente com o sistema um ator pode invocar vários casos de uso e um caso de
uso pode ser invocado por vários atores De acordo com Furlan (1998, p.175), “o ator
comunica-se com o sistema a través do envio e recebimento de mensagens, sendo
que um caso de uso é sempre iniciado a partir do momento que um ator envia sua
mensagem (estímulo) ”.
A figura 1 representa os atores que irão participar dos cenários, baseados a
partir das regras de negócio. O ator funcionário responsável pelas rotinas de processo
de venda, exclusão, cadastro etc. Nota: Foi adotado o conceito de herança do ator
funcionário sendo elencados 3 filhos: Atendente, supervisor e Estoquista. O ator
cliente sendo o afetado direto pelas ações do ator funcionário.
O ator Sistema Financeiro responsável pela rotina de processamento de venda
e cancelamento.

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

15

5.4 diagramas de classes

O diagrama de classes está entre os mais utilizados e mais úteis de diagramas

UML. O digrama modela a estrutura de um sistema ou produto de software, suas
classes, seus atributos, operações e relações entre objetos.
O diagrama de classes é poderosa ferramenta para a documentação de um
sistema ou produto de software, sendo uma das técnicas mais utilizadas no
desenvolvimento orientado a objetos.
Na figura 2 é apresentado o diagrama de classes, contendo relação entre
classes. Nesse diagrama UML é tratado o termo tem um (representado pelo número
1) e o termo tem vários (representado pelo símbolo *) para a relação entre classes.

Figura 3 — Diagrama de Classes

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

16

5.4.1 Descrição das Classes

. Cliente: Essa classe define os atributos e métodos necessários para “manipular” o

cliente no sistema. Essa classe tem relação com a classe endereço, que recebe os
atributos e métodos para manipular um endereço ao cliente.
. Endereço: Essa classe define os atributos e métodos para “manipular” o processo
de venda no sistema.
. Venda: Essa classe define os atributos e métodos para “manipular” o processo de
venda no sistema. Essa classe tem relação com a classe produto, que recebe os
atributos e métodos para manipular o produto no processo de venda, que tambem tem
relação com a classe, Forma de pagamento que recebe atributos e métodos para
manipular a forma de pagamento no processo de venda.
. Produto: Essa classe define os atributos e métodos para manipular o produto no
sistema. Essa classe essa classe tem relação com a classe categoria, que define os
atributos e métodos para definir uma categoria ao produto.
. Categoria: Essa classe define os atributos e métodos para definir uma categoria ao
produto.
. Estoque: Essa classe define os atributos e métodos para manipular um produto no
estoque. Essa classe tem relação com a classe produto.
. Financeiro: Essa classe define os atributos e métodos para manipular as vendas no
modulo financeiro. Essa classe tem relação com a classe venda.
. Funcionário: Essa classe define os atributos e métodos para manipular o acesso de
funcionários nas funcionalidades do sistema.
. Atendente: Estoquista, Supervisor, essas classes filhas herdam da classe pai
Funcionário.

6 MODELO ENTIDADE RELACIONAMENTO

Nesse projeto, o Banco de Dados utilizado foi o MySQL relacional em sua
versão 8.0.25.0. O MySql é um dos SBDA mais utilizados no mundo, devido a sua

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

17

facilidade e desempenho, por esse motivo foi adotado nesse projeto. Abaixo, na figura
3 é representado o modelo de entidade relacionamento do banco de dados.

Figura 4 — MER

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

18

7 CONCLUSÃO
Diante da contextualização do caso proposto, foi realizado o levantamento e
análise de requisitos de um novo sistema tecnológico que substitui o atual "sistema"
de controle de vendas feito no Excel, utilizado tecnologias e metodologias para
confecção do projeto.
Com o apoio dos conceitos das disciplinas cursadas no atual bimestre, foi
confeccionado a análise e levantamento de requisitos de um novo sistema funcional
para loja de produtos geeks.
Utilizando os conceitos da disciplina Análise Orientada a Objetos, foi possível
definir os requisitos, regras de negócio e caso de uso para o sistema.
Com a disciplina Gestão de RH foi possível contextualizar a equipe de RH
responsável por procurar novos desenvolvedores para o cenário proposto.
A disciplina de Banco de Dados, foi utilizada para definir o modelo de entidade
de relacionamento do sistema.
Ao final foi possível a criação de um projeto viável e funcional, obedecendo as
metodologias e análises para o desenvolvimento do mesmo.

Baixado por Edith Harper (harperedith21@gmail.com)

 lOMoARcPSD|41418076

19

REFERENCIAS

CAVALCANTI, ANDERSON. Modelo de Casos de Uso e Diagrama de Casos de Uso.

DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO.
Disponível em: https://www.dca.ufrn.br/~anderson/FTP/dca0120/P2_Aula3.pdf.
Acesso em: 04 mai. 2023.
PEREIRA, ROBERTO. Casos de Uso. LInterHAD. Disponível em:
https://interhad.nied.unicamp.br/courses/roberto-pereira/ci163-projeto-de-software-
ufpr-1/agenda/cap02-1-mar2013.pdf . Acesso em: 04 mai. 2023.
VENTURA, Plínio. O que é Requisito Funcional. Disponível em:
https://www.ateomomento.com.br/o-que-e-requisito-funcional/ . Acesso em: 18 mai.
2023 . VENTURA, Plínio. O que é um Requisito Não-Funcional. Disponível em:
https://www.ateomomento.com.br/o-que-e-um-requisito-nao-funcional/. Acesso em:
19 mai. 2023 .
VIANA, Davi. Partindo dos processos de negócio e chegando aos requisitos de
sistemas. dheka. Disponível em: https://www.dheka.com.br/processos-de-negocio-e-
requisitos-de-sistemas/ . Acesso em: 19 mai. 2023.

Baixado por Edith Harper (harperedith21@gmail.com)