G4 - Atividade Prática 3

Prévia do material em texto

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS 
DEPARTAMENTO DE COMPUTAÇÃO 
 
Amanda Kelly Rodrigues Cândido 
Gabriel Teixeira Andrade Sousa 
Giovanna de Sousa Sampaio 
Giulianni dos Santos Oliveira 
Gustavo Gomes Cardozo dos Santos 
 
G4 - Atividade prática 3 
 
 
 
 
 
 
 
 
André Luiz Alves 
 
 
 
GOIÂNIA, 
2020 
 2 
Amanda Kelly Rodrigues Cândido 
Gabriel Teixeira Andrade Sousa 
Giovanna de Sousa Sampaio 
Giulianni dos Santos Oliveira 
Gustavo Gomes Cardozo dos Santos 
 
 
 
 
 
 
 
 
 
 
 
G4 -Atividade prática 3 
Relatório apresentado como requisito parcial 
para obtenção de aprovação na disciplina 
Validação e Testes de Sistemas no Curso de 
Engenharia da Computação, na Pontifícia 
Universidade Católica de Goiás. 
André Luiz Alves 
 
 
 
 
 
GOIÂNIA, 
2020 
 3 
Revisões 
A primeira versão deste documento é criada após a sua aprovação e é vinculada a 
uma baseline do software. Esta versão, portanto, não pode ser modificada. As modificações 
que se fizerem necessárias após a criação da baseline farão parte de uma versão seguinte 
que será vinculada a uma outra baseline. Este procedimento pode se repetir sucessivamente. 
As modificações introduzidas em cada versão devem ser registradas seguindo o modelo do 
quadro abaixo. Desta forma, será possível perceber as diferenças entre as diversas versões 
geradas. 
Data Descrição Autor 
20/09/2020 Criação do software Amanda, Gabriel, Giovanna, 
Giulianni, Gustavo 
Sumário 
1. INTRODUÇÃO .................................................................................................................................. 5 
1.1. OBJETIVOS ....................................................................................................................................... 5 
1.2. PÚBLICO ALVO.................................................................................................................................. 5 
1.3. ORGANIZAÇÃO DO DOCUMENTO .......................................................................................................... 5 
2. CASOS DE USO ................................................................................................................................. 5 
2.1. ATORES ........................................................................................................................................... 5 
2.2. LISTA DE CASOS DE USO ...................................................................................................................... 5 
3. REQUISITOS E RESTRIÇÕES FUNCIONAIS (RFUN) ............................................................................. 6 
4. REQUISITOS E RESTRIÇÕES NÃO FUNCIONAIS ................................................................................. 8 
4.1. REQUISITOS E RESTRIÇÕES DE INFORMAÇÃO (RINF) ................................................................................. 8 
4.2. REQUISITOS E RESTRIÇÕES DE INTERFACE HOMEM-COMPUTADOR (RHIC) .................................................... 8 
4.3. REQUISITOS DE INTERFACE EXTERNA (RIEX) ........................................................................................... 9 
4.4. REQUISITOS E RESTRIÇÕES DE PROJETO (RPRO) ..................................................................................... 9 
4.5. REQUISITOS E RESTRIÇÕES DE ARQUITETURA DE SOFTWARE (RARQ) ......................................................... 10 
4.6. REQUISITOS E RESTRIÇÕES DE PLATAFORMA DE HARDWARE (RPHW) ........................................................ 10 
4.7. REQUISITOS E RESTRIÇÕES DE PLATAFORMA DE SOFTWARE (RPSW) .......................................................... 10 
4.8. REQUISITOS E RESTRIÇÕES DE DESEMPENHO (RDES) .............................................................................. 11 
4.9. REQUISITOS E RESTRIÇÕES DE DISPONIBILIDADE (RDIS) ........................................................................... 11 
4.10. REQUISITOS E RESTRIÇÕES DE SEGURANÇA (RSEG) ................................................................................ 11 
4.11. REQUISITOS E RESTRIÇÕES DE MANUTENIBILIDADE (RMAN) .................................................................... 12 
4.12. REQUISITOS E RESTRIÇÕES DE PORTABILIDADE (RPOR) ........................................................................... 13 
4.13. REQUISITOS DE DOCUMENTAÇÃO (RDOC) ........................................................................................... 13 
5. MATRIZ DE RASTREABILIDADE ...................................................................................................... 14 
6. SYSTEM OVERVIEW ....................................................................................................................... 15 
6.1. UML ............................................................................................................................................ 16 
6.2. DIAGRAMA DE CLASSES .................................................................................................................... 18 
6.2.1 Diagrama de classes sem atributos e métodos ..................................................................... 18 
6.2.2 Diagrama de classe com atributos e métodos ...................................................................... 19 
7. CONSTRUÇÃO DE SOFTWARE ........................................................................................................ 20 
7.1. FUNDAMENTOS .............................................................................................................................. 20 
7.2. GERENCIANDO A CONSTRUÇÃO .......................................................................................................... 20 
7.3. CONSIDERAÇÕES PRÁTICAS ................................................................................................................ 20 
8. APROVAÇÃO FORMAL ................................................................................................................... 21 
 4 
9. BIBLIOGRAFIA ................................................................................................................................ 21 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 5 
1. Introdução 
Este documento especifica os requisitos do sistema Buteko para apresentar ao leitor. 
1.1. Objetivos 
Este documento tem o objetivo de descrever o software e especificar os requisitos do 
sistema Buteko. 
1.2. Público Alvo 
Clientes, usuários e administradores do sistema Buteko. 
1.3. Organização do documento 
O documento está dividido em tópicos como especificado no conteúdo do sumário, 
mostrado no início do documento. 
2. Casos de Uso 
2.1. Atores 
1. Cliente 
2. Gerente 
3. Telefonista 
4. Garçom 
5. Operador de caixa 
6. Fornecedor 
7. Chef / Cozinheiro 
8. Admin 
2.2. Lista de casos de uso 
Listar todos os casos de uso do software. Para cada caso de uso identificar sua 
categoria (primário, secundário ou opcional). Casos de uso primários são aqueles que 
representam processos comuns principais; casos de uso secundários representam processos 
menos importantes ou raros; casos de uso opcionais representam processos que talvez não 
sejam considerados. Quando define a categoria de um caso de uso é mais fácil de perceber 
quais casos de uso deverão ser expandidos primeiramente. 
 
Ref. Descrição Atores Categoria 
CSU1 Registrar ligação. Telefonista Primário 
CSU2 Registrar pedido. Garçom/Telefonista Primário 
CSU3 Registrar venda. Operador de caixa Primário 
CSU4 Realizar pedido. Cliente Primário 
CSU5 Solicitar cancelamento de 
pedidos dentro do prazo. 
Cliente Primário 
CSU6 Cancelar pedidos. Gerente Primário 
 6 
CSU7 Confeccionar de pratos. Cozinheiro Primário 
CSU8 Aceitar o pedido de pratos para 
preparação. 
Chef Primário 
CSU9 Permitir troca ou exclusão de 
condimentos. 
Gerente Secundário 
CSU10 Solicitar trocaou exclusão de 
condimentos. 
Cliente Primário 
CSU11 Realizar cadastro de 
funcionários. 
Gerente Primário 
CSU12 Transferir mesas de pedido. Gerente Secundário 
CSU13 Adicionar e/ou excluir reservas 
de mesas. 
Gerente Secundário 
CSU14 Cadastrar pratos. Chef Primário 
CSU15 Receber pratos. Chef Primário 
CSU16 Escolher forma de pagamento. Cliente Primário 
CSU17 Receber pagamento. Operador de caixa Primário 
CSU18 Verificar estoque de 
ingredientes do restaurante. 
Admin Secundário 
CSU19 Sinalizar falta de ingredientes. Admin Secundário 
 
3. Requisitos e restrições funcionais (RFUN) 
Elaborar uma lista das funções que o software deve prover. Considerar não apenas 
as funções intrínsecas (essenciais) do software, mas também as de suporte, tais como 
administração da utilização do software, cópias de segurança, auditoria, e controle de 
acesso. Indicar para cada função uma referência, descrição, categoria, prioridade e casos 
de uso em que ela é tratada. 
 
Ref. Função Categoria Prioridade Casos de Uso 
RFUN1 O sistema deverá registrar a 
venda de um produto. 
Evidente Alta CSU3 
RFUN2 O sistema deverá atualizar o 
estoque do produto usado. 
Oculta Média CSU18 
RFUN3 O sistema deverá fazer 
alteração de pedidos e mesas. 
Evidente Alta CSU12 
RFUN4 O sistema deverá permitir 
troca de mesa para o pedido. 
Evidente Média CSU12 
RFUN5 O sistema deverá permitir 
alteração dos condimentos. 
Evidente Média CSU9/CSU10/
CSU19 
 7 
RFUN6 O sistema deverá permitir 
excluir pedidos. 
Oculta Alta CSU6 
RFUN7 O sistema deverá enviar 
pedido de compra ao Cliente. 
Oculta Alta CSU2 
RFUN8 O sistema deverá permitir 
cadastro dos funcionários. 
Oculta Média CSU11 
RFUN9 O sistema deverá permitir a 
exclusão de funcionários 
cadastrados. 
Oculta Média CSU11 
RFUN10 O sistema deverá ter controle 
de ocupação de mesas. 
Oculta Média CSU2/CSU12 
RFUN11 O sistema deverá permitir 
fazer reservas de mesas. 
Oculta Alta CSU13 
RFUN12 O sistema deverá permitir 
excluir reservas de mesas. 
Oculta Alta CSU13 
RFUN13 O sistema deverá permitir o 
Cliente visualizar o cardápio. 
Evidente Alta CSU4 
RFUN14 O sistema deverá permitir ao 
Chef atualizar cardápio. 
Oculta Alta CSU14 
RFUN15 O sistema deverá enviar 
pedido ao Chef. 
Oculta Alta CSU8/CSU15 
RFUN16 O sistema deverá ter controle 
dos funcionários. 
Oculta Alta CSU11 
RFUN17 O sistema deverá permitir 
somente o Gerente cancelar 
pedidos após o prazo. 
Oculta Média CSU6 
RFUN18 O pedido só pode ser 
cancelado antes do 
Cozinheiro começar a 
preparar o prato. 
Evidente Alta CSU5 
RFUN19 O sistema deverá permitir ao 
Cozinheiro encerrar prato. 
Oculta Média CSU7 
RFUN20 O sistema deverá permitir que 
somente o Garçom receba 
pedidos no restaurante. 
Evidente Alta CSU2 
RFUN21 O sistema deverá permitir que 
somente o Telefonista receba 
pedidos por telefone. 
Evidente Alta CSU2/CSU1 
RFUN22 O sistema permitirá ao 
Cliente fazer pedidos pelo 
aplicativo ou site. 
Evidente Média CSU4 
 8 
RFUN23 Somente o Gerente pode 
permitir a transferência de 
mesas. 
Oculta Baixa CSU12 
RFUN24 Somente o Gerente pode dar 
descontos. 
Oculta Baixa CSU17 
RFUN25 O sistema deverá aceitar 
formas de pagamento Online. 
Evidente Alta CSU16/CSU1
7 
RFUN26 O sistema deverá avisar no 
cardápio online quando um 
prato estiver em falta. 
Evidente Alta CSU10/CSU1
8/CSU19 
RFUN27 O sistema deverá informar 
quando estiver faltando um 
condimento. 
Evidente Alta CSU10/CSU1
8/CSU19 
4. Requisitos e restrições não funcionais 
Elaborar uma lista de todos os requisitos não funcionais. Considerar requisitos de 
informação, de interface, de projeto, de arquitetura de software, de plataforma de hardware, 
de plataforma de software, de plataforma de comunicação, de desempenho, de 
disponibilidade, de segurança, de manutenibilidade, de portabilidade e de documentação. 
A lista poderá ser dividida por tipo de requisito, mas é importante que os requisitos tenham 
uma identificação única para que possam ser referenciados sem ambiguidades no futuro. 
4.1. Requisitos e restrições de informação (RINF) 
Elaborar uma lista de todas as necessidades de informação que o software não pode 
deixar de atender. Esta lista deverá ser classificada em informações cadastrais e 
informações gerenciais. Estes requisitos de informação são importantes para verificar a 
qualidade da modelagem de dados que for feita. 
 
Ref. Tipo Descrição Casos de Uso 
RINF1 Cadastral O sistema deverá solicitar as 
informações do funcionário: Nome, 
Telefone, CPF e endereço. 
CSU11 
RINF2 Cadastral O produto deverá conter informações de 
código, descrição e preço. 
CSU14 
RINF3 Gerencial Para definir o funcionário do mês o 
sistema deve analisar a quantidade 
vendida no mês e a comissão paga aos 
funcionários. 
CSU11 
 
4.2. Requisitos e restrições de interface Homem-Computador 
(RHIC) 
Definir todos os aspectos de Interface Homem Computador (IHC) incluindo: 
conteúdo de informações, fatores ergonômicos, dispositivos de interação, formato de 
 9 
apresentação, tipo de diálogo, e mecanismos de ajuda alocados a cada perfil/grupo/tarefa 
de usuário. 
 
Ref. Descrição Casos de Uso 
RIHC1 Para facilitar a usabilidade na transação de venda, 
pede-se que a tela de vendas tenha uma fonte que 
permita uma fácil visualização. 
Todos 
RIHC2 O software deverá ser de fácil usabilidade. Todos 
RIHC3 O software deverá ter uma seção onde apresenta o 
cardápio do dia. 
CSU2 
RIHC4 O tempo de resposta do programa, deverá ser de no 
máximo 3 segundos. 
Todos 
 
4.3. Requisitos de Interface Externa (RIEX) 
Identificar e descrever as interfaces com outros softwares/sistemas que o software 
deverá prover. Por exemplo, um software comercial deve gerar informações para o Sistema 
de Arrecadação da Secretaria da Fazenda Estadual 
 
Ref. Descrição Casos de Uso 
RIEX1 O software deverá gerar recibo quando solicitado pelo 
cliente. 
CSU16 
RIEX2 O software deverá emitir uma nota fiscal após o 
recebimento. 
CSU16 
 
4.4. Requisitos e Restrições de Projeto (RPRO) 
Nesta seção serão especificados todos os requisitos e restrições associados a 
condução do projeto de desenvolvimento e que podem limitar ou definir ações que serão 
executadas. 
 
Ref. Descrição Casos de Uso 
RPRO1 O software deverá ser desenvolvido pela equipe de 
desenvolvimento do sistema Buteko. 
Todos 
RPRO2 O software deverá ser desenvolvido utilizando a 
ferramenta CASE, na linguagem Java, gerando um 
código padrão da empresa. 
Todos 
 
RPRO3 A equipe responsável deverá dar um feedback 
mensal sobre o andamento do projeto. 
Todos 
 
RPRO4 O projeto só será iniciado pela equipe responsável 
somente quando o protótipo for aceito pelo cliente. 
Todos 
 10 
4.5. Requisitos e restrições de arquitetura de software (RARQ) 
Se o software tiver de ser desenvolvido em uma arquitetura específica, então essa 
arquitetura deverá ser descrita. 
 
Ref. Descrição Casos de Uso 
RARQ1 O software deverá ser desenvolvido com uma 
arquitetura de camadas que permita isolar as 
funcionalidades ligadas ao negócio das mesmas 
relacionadas com a interface homem-computador. 
Todos 
 
4.6. Requisitos e restrições de plataforma de hardware 
(RPHW) 
Identificar e descrever requisitos e restrições relacionadas com a plataforma de 
hardware que será utilizada pelo software: 
 
Ref. Descrição Casos de Uso 
RPHW1 Aparelhos celulares e computadores deverão 
operar o software. 
Todos 
 
4.7. Requisitos e restrições de plataforma de software (RPSW) 
Se o software tiver que ser executado em plataforma(s) de software específica(s), 
essa(s) plataforma(s) de software deverá(ão) ser definida(s): 
▪ Sistema Operacional: identificar e descrever o sistema operacional em que o 
software deverá ser executado; 
▪ Softwares Básicos: identificar SGBD, linguagem de programação, ferramentas 
CASE e outros.Ref. Descrição Casos de Uso 
RPSW1 O software deverá ser desenvolvido para operar em 
sistemas mobile como IOS e ANDROID. 
Todos 
RPSW2 O software deverá ser desenvolvido para operar em 
sistemas operacionais como WINDOWS, MAC e 
LINUX. 
Todos 
 
RPSW3 O software deverá ter suporte de portabilidade as 
versões mais recentes dos sistemas operacionais. 
Todos 
 
RPSW4 O software deverá ter suporte de portabilidade as 
versões mais recentes dos sistemas mobile. 
Todos 
 
 11 
4.8. Requisitos e restrições de desempenho (RDES) 
Identificar e descrever os requisitos e restrições de desempenho do software. 
 
Ref. Descrição Casos de Uso 
RDES1 O ambiente onde o software rodará deverá permitir 
picos de acesso sem queda de velocidade. 
Todos 
RDES2 O tempo de resposta máximo permitido para 
transações on-line é de 3 segundos. 
Todos 
RDES3 O software deverá ser capaz de suprir altas transações 
simultâneas da função “Registrar Venda”. 
CSU3 
RDES4 O sistema deverá apresentar funcionalidades 
necessárias para uma alta eficiência de desempenho. 
Todos 
RDES5 O sistema deverá permitir acessos simultâneos sendo 
operados por diferentes perfis de usuários do sistema. 
Todos 
 
4.9. Requisitos e restrições de disponibilidade (RDIS) 
Especificar os requisitos de disponibilidade necessários para o software de uma 
forma global: 
▪ Período de disponibilidade: horário comercial, 24 horas por dia, etc. 
▪ Período máximo para recuperação do software em caso de falha. 
 
 
Ref. Descrição Casos de Uso 
RDIS1 O software deverá permanecer operante de forma 
contínua. 
Todos 
RDIS2 O sistema deve reiniciar por completo em até, no 
máximo, 10 segundos. 
Todos 
RDIS3 As funcionalidades “RFUN1” e “RFUN17” não 
podem ficar mais do que 30 minutos indisponíveis. 
Todos 
RDIS4 O software restringir pedidos fora do horário de 
funcionamento do estabelecimento. 
Todos 
 
RDIS5 
 
As manutenções e atualizações do sistema deverão 
ser feitas fora do horário de funcionamento do 
estabelecimento. 
Todos 
RDIS6 O software deverá permitir exceções no sistema para 
horários de funcionamento. 
Todos 
4.10. Requisitos e restrições de segurança (RSEG) 
Especificar os requisitos de segurança necessários para controle de acesso ao 
software. Definir a necessidade de: 
 12 
▪ Verificação de senha; 
▪ Criptografia de dados; 
▪ Registro das operações efetuadas; 
▪ Habilitação de funções por perfil de usuário; 
▪ Acesso seletivo aos dados e funções. 
 
 
Ref. Descrição Casos de Uso 
RSEG1 O software deverá solicitar autorização do gerente para 
excluir uma venda já registrada. 
CSU5 
RSEG2 Somente usuários previamente cadastrados possuem 
acesso a versão mobile. 
Todos 
RSEG3 Somente usuários previamente cadastrados podem 
realizar compras no software. 
Todos 
RSEG4 Para qualquer atualização efetuada deverá ser registrado o 
usuário que realizou a operação bem como a data e hora. 
Todos 
RSEG5 Todo usuário do software deverá ser associado a um perfil 
que define as funcionalidades que poderão ser utilizadas 
por ele. 
Todos 
 
4.11. Requisitos e restrições de manutenibilidade (RMAN) 
Especificar os requisitos que visam facilitar a manutenção posterior do software, 
tais como: 
▪ Requisitos de reutilização (exemplo: uso de implementação orientada a objetos; 
bibliotecas de classes e padrões de projeto); 
▪ Requisitos de modularização (exemplo: valores para métricas de acoplamento 
entre módulos; máximo de pontos de função por módulo); 
▪ Requisitos de configuração (exemplo: regras para controle de versões); 
▪ Requisitos de documentação (exemplo: documentação de programa) 
 
 
Ref. Descrição Casos de Uso 
RMAN1 O projeto das responsabilidades de cada classe de objetos 
deverá seguir os padrões GRASP sugeridas no livro 
Utilizando UML e Padrões de Craig Larman [1]. 
Todos 
RMAN2 Todo programa deve estar documentado de acordo com 
as orientações contidas na Norma de Documentação de 
Programas da empresa [2] 
Todos 
 13 
4.12. Requisitos e restrições de portabilidade (RPOR) 
Identificar as diversas plataformas de software e hardware com as quais o software 
deve ser compatível. Devem ser consideradas tanto plataformas de desenvolvimento como 
plataformas de produção. Outros exemplos de requisitos de portabilidade são: 
▪ Percentual de componentes que podem ter código dependente da plataforma 
hospedeira; 
▪ Percentual de código que pode ser dependente da plataforma hospedeira; 
▪ Uso de uma linguagem reconhecidamente portável. 
 
 
Ref. Descrição Casos de Uso 
RPOR1 O software deverá ser capaz de rodar tanto em 
computadores Desktop com Windows 8 ou superior 
ou com Linux ou em Mac OS X v 10.9, e em 
celulares com sistemas Android 5.0 ou superior ou 
em IOS 6.0. 
Todos 
RPOR2 O software deverá permitir a utilização dos 
seguintes Bancos de dados: SQL Server, MySql, 
MongoDB, POstgre SQL ou Oracle 
Todos 
 
4.13. Requisitos de documentação (RDOC) 
Especificar os requisitos de documentação do produto de software que será 
desenvolvido 
 
Ref. Descrição Casos de Uso 
RDOC1 O software deve prover ajuda on-line em todas as 
suas telas. 
Todos 
RDOC2 O software deverá conter um Chatbot para eventuais 
dúvidas sobre funcionamento. 
Todos 
RDOC3 A empresa responsável pelo desenvolvimento 
deverá prestar suporte ao sistema. 
Todos 
 
 
 
 
 
 
 14 
5. Matriz de Rastreabilidade 
Especificar a Matriz de Rastreabilidade a partir dos Casos de Uso e Requisitos 
Funcionais. 
 
 
 15 
6. System Overview 
O Sistema Buteko tem o objetivo de facilitar a interação do cliente com diversos 
estabelecimentos como: bares, choperias e lanchonetes trazendo um modelo simples e 
prático de solicitações de pedidos cadastros de clientes dentre outas muitas funcionalidades 
o que automatiza grande parte do processo de interação entre o cliente e o a empresa além 
de rodar na maioria dos sistemas operacionais atuais inclusive em plataforma mobile. 
A seguir mostraremos um Diagrama de Contexto que resume todas as atividades de 
processamento e também ajuda os usuários a visualizar o nível mais alto do sistema com 
os limites do sistema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 16 
6.1. UML 
Diagrama de Casos de Uso 
Exemplo: 
 
Exemplo de caso de uso detalhado. 
 
 
 
 17 
Modelo: 
 
 
 18 
6.2. Diagrama de Classes 
6.2.1 Diagrama de classes sem atributos e métodos 
 
 19 
6.2.2 Diagrama de classe com atributos e métodos 
 
 
 20 
7. Construção de Software 
7.1. Fundamentos 
O termo Construção de Software se refere à construção detalhada de um software 
funcional, através de uma combinação de codificação, verificação e teste. Seus 
fundamentos são: 
 
• Minimizar complexidade; 
• Antecipar mudanças; 
• Construir para verificação; 
• Reuso; 
• Padrões de construção; 
 
7.2. Gerenciando a Construção 
Já quando se trata do processo deve-se atentar aos seguintes tópicos: 
 
• Construção em modelos de ciclo de vida; 
• Planejamento da construção; 
• Mensuração da construção; 
 
7.3. Considerações práticas 
Devido à influência de variáveis do mundo real, construção está mais relacionado 
as considerações práticas do que alguma outra área de conhecimento (KA). Por isso é 
importante destacar: 
 
• Design de construção; 
• Linguagem de construção; 
• Codificação; 
• Teste na construção; 
• Reuso na construção; 
• Qualidade de construção; 
• Integração; 
 
 
 
 
 
 
 21 
8. Aprovação Formal 
Data: 22/09/2020 
Local: Goiânia, Goiás, Brasil 
Versão: 1.0 
9. Bibliografia 
Fontes de informação usadas para desenvolver o Documento de Requisitos do 
sistema Buteko. 
[1] EOR – Modelo de Documento de Especificação de Objetivos e Requisitos de 
Software, Versão 1.0, setembro de 2017. 
Meta-Modelo usado como guia para definição do formato e conteúdo deste 
documento. 
 
Participantes na criação deste Documento de Requisitos:Amanda Rodrigues, 
Gabriel Teixeira, Giovanna Sampaio, Giulianni Oliveira e Gustavo Gomes.