diff --git a/docs/Entregas/Entrega2.md b/docs/Entregas/Entrega2.md
new file mode 100644
index 0000000..bd007d1
--- /dev/null
+++ b/docs/Entregas/Entrega2.md
@@ -0,0 +1 @@
+# Apresentação Unidade 2
\ No newline at end of file
diff --git a/docs/FasesOpenUP/Concepcao.md b/docs/FasesOpenUP/Concepcao.md
new file mode 100644
index 0000000..57b9c37
--- /dev/null
+++ b/docs/FasesOpenUP/Concepcao.md
@@ -0,0 +1,102 @@
+# Concepção
+
+A fase de Concepção do projeto foi fundamental para estabelecer a base e os direcionamentos necessários para o desenvolvimento contínuo. Nessa fase, foram realizados os seguintes marcos importantes:
+
+## Planejamento do Projeto
+A equipe estabeleceu os objetivos, cronograma e recursos necessários para o desenvolvimento do projeto. A definição das etapas e marcos foi fundamental para garantir um alinhamento contínuo durante todo o ciclo de vida do projeto.
+
+## Definição do Escopo
+O escopo do projeto foi detalhadamente definido, incluindo as funcionalidades principais, as necessidades do cliente e os resultados esperados. Isso ajudou a garantir que o time tivesse clareza sobre as entregas e a visão do produto.
+
+## Decisão dos Cargos
+Atribuição dos papéis e responsabilidades dentro da equipe, garantindo a organização e fluidez do processo de desenvolvimento, com a definição dos membros chave para as funções:
+
+- Gerente de Projeto: Manoela.
+- Desenvolvedor FrontEnd: Alexandre, com participação da Manoela.
+- Desenvolvedor BackEnd: Enrico, com participação do Kaio e Pedro Henrique.
+- Desenvolvedor CI/CD / Testes: Gustavo.
+- Analista de Requisitos: Pedro Henrique, com a participação de toda a equipe.
+
+## Organização da Documentação
+A documentação do projeto foi organizada de forma estruturada, incluindo todos os arquivos e artefatos necessários. Isso facilitou o acompanhamento do progresso do projeto.
+
+## Capacitações
+Realização de sessões de capacitação para garantir que todos os membros da equipe estivessem atualizados e capacitados nas tecnologias, ferramentas e metodologias que seriam utilizadas durante o projeto.
+
+## Definição do MVP
+O MVP foi definido, contendo as funcionalidades essenciais necessárias para que o produto fosse lançado e pudesse ser utilizado pelos primeiros usuários. Maior detalhamento pode ser encontrado na Visão de Produto e Projeto, na aba Backlog do Produto.
+
+
+
+Autores: [Alexandre Júnior](https://github.com/AlexandreLJr), [Gustavo Haubert](https://github.com/GustavoHaubert), [Manoela Garcia](https://github.com/manu-sgc)
+
+
+## Definição do DoR e DoD
+O DoR foi estabelecido, garantindo que cada item do backlog estivesse claramente definido, sem ambiguidades, e pronto para ser trabalhado pela equipe, com todos os critérios de aceitação e requisitos alinhados.
+O DoD foi estabelecido para garantir que as funcionalidades entregues estivessem completas e atendendo a todos os critérios de qualidade acordados, como testes unitários, integração e validação com os stakeholders.
+Maior detalhamento de ambos pode ser encontrado na Visão de Produto e Projeto, na aba DoR e DoD.
+
+## Declaração de Requisitos Funcionais e Não Funcionais
+Foram definidos os requisitos funcionais e não funcionais, abordando tanto as funcionalidades do sistema quanto as qualidades que ele deve possuir para garantir um produto de alta qualidade e que atenda às necessidades dos usuários. Maior detalhamento pode ser encontrado na Visão de Produto e Projeto, na aba Requisitos de Software.
+
+## User Story
+User Stories foram criadas para representar as funcionalidades do sistema de forma clara e objetiva, ajudando a equipe a entender as necessidades do cliente. A priorização e maior detalhamento pode ser encontrado na Visão de Produto e Projeto, na aba Backlog do Produto.
+
+**US01** - Como cliente, quero me cadastrar no sistema para poder agendar serviços para meus pets.
+
+**US02** - Como cliente, quero cadastrar meus pets com informações como nome, idade e raça, para facilitar a escolha dos serviços mais adequados.
+
+**US03** - Como cliente, quero agendar serviços de banho e tosa para meus pets, especificando detalhes como o tipo de tosa desejada, para garantir que recebam os cuidados necessários.
+
+**US04** - Como cliente, quero visualizar os horários disponíveis para agendamentos, para escolher o momento mais conveniente para mim e para meus pets.
+
+**US05** - Como cliente, quero cancelar ou reagendar serviços com antecedência, caso surjam imprevistos, para evitar transtornos.
+
+**US06** - Como cliente, quero consultar o histórico dos serviços realizados para meus pets, para acompanhar os cuidados prestados e os custos envolvidos.
+
+**US07** - Como cliente, quero acessar o Instagram do pet shop pelo sistema, para acompanhar novidades e promoções.
+
+**US08** - Como cliente, quero enviar fotos do meu pet ao sistema, para usar como referência em pedidos de tosa personalizada ou para ter salvo em seu cadastro.
+
+**US09** - Como cliente, quero avaliar os serviços prestados com uma nota e comentários, para ajudar a melhorar a qualidade do atendimento.
+
+**US10** - Como administrador, quero visualizar e analisar as avaliações fornecidas pelos clientes, para identificar melhorias nos serviços oferecidos.
+
+**US11** - Como administrador, quero acessar os dados cadastrais dos clientes, para entrar em contato com eles e atender melhor suas demandas.
+
+**US12** - Como administrador, quero visualizar informações detalhadas sobre os pets dos clientes, para oferecer um atendimento de qualidade.
+
+**US13** - Como funcionário, quero vizualizar as informações dos pets cadastrados, como nome, idade, raça e nome do dono, para prestar os serviços com mais eficiência.
+
+**US14** - Como administrador, quero ajustar os preços dos serviços sempre que necessário, para acompanhar custos e promoções.
+
+**US15** - Como administrador, quero acessar um calendário com todos os agendamentos organizados por data e horário, para gerenciar melhor os atendimentos.
+
+**US16** - Como administrador, quero mover ou reagendar horários no calendário, para acomodar ajustes necessários nos atendimentos.
+
+**US17** - Como administrador, quero cancelar agendamentos quando preciso, notificando os clientes de forma clara e imediata, para liberar a agenda quando não for possível receber o pet.
+
+**US18** - Como funcionário, quero acessar o calendário com os agendamentos do dia organizados por horário, para gerenciar melhor o fluxo de trabalho e atender os clientes conforme programado.
+
+**US19** - Como administrador, quero acessar relatórios financeiros detalhados, para entender melhor os lucros e despesas do pet shop.
+
+## Regras de Negócio
+As regras de negócio foram estabelecidas, descrevendo as condições, processos e lógicas essenciais que o sistema deve seguir para garantir que os objetivos de negócio sejam atendidos corretamente.
+
+1. Um cliente pode cadastrar múltiplos pets, mas cada pet deve ter informações como nome, idade, raça e tamanho obrigatoriamente preenchidas.
+
+2. Raça e tamanho dos pets influenciam na escolha dos serviços e preços.
+
+3. Clientes podem cancelar ou reagendar um serviço até 24 horas antes do horário marcado sem penalidades.
+
+4. O administrador pode cancelar agendamentos, mas precisa notificar os clientes com antecedência de 2 horas.
+
+5. Serviços agendados devem ser organizados por ordem cronológica no calendário.
+
+6. Dias e horários de atendimento devem ser configuráveis pelo administrador (ex.: feriados, dias sem expediente).
+
+7. O sistema deve gerar relatórios financeiros detalhados (ex.: lucro mensal, serviços mais solicitados) com base nos agendamentos concluídos.
+
+8. Clientes podem avaliar os serviços prestados apenas após a conclusão do atendimento.
+
+9. Notas e comentários de avaliação devem estar vinculados ao agendamento específico e visíveis apenas para o administrador.
\ No newline at end of file
diff --git a/docs/FasesOpenUP/Construcao.md b/docs/FasesOpenUP/Construcao.md
new file mode 100644
index 0000000..c68b36a
--- /dev/null
+++ b/docs/FasesOpenUP/Construcao.md
@@ -0,0 +1,16 @@
+# Construção
+A Fase de Construção é o momento em que o sistema começa a tomar forma através do desenvolvimento de código, integração de componentes e validação com os stakeholders. As principais atividades planejadas para essa fase incluem:
+
+## Desenvolvimento do Código
+- Implementação do banco de dados, estruturando tabelas, relacionamentos e otimizando consultas para atender aos requisitos funcionais e não funcionais.
+- Desenvolvimento do backend utilizando Java e o framework Spring Boot, garantindo o funcionamento dos serviços, regras de negócio e integração com o banco de dados.
+- Construção do frontend, seguindo o design aprovado no protótipo do Figma e garantindo a responsividade e usabilidade do sistema.
+
+## Testes
+- Realização de testes unitários para validar as funcionalidades individuais do backend e do frontend.
+- Execução de testes de integração, verificando a comunicação entre os módulos e componentes do sistema.
+- Aplicação de testes de usabilidade para garantir que a interface do usuário esteja clara, funcional e eficiente.
+
+## Validação com o Cliente
+- Apresentação de versões intermediárias do sistema ao cliente, com o objetivo de validar as funcionalidades implementadas, ajustar detalhes e obter feedback.
+- Garantia de que as entregas atendam aos critérios de aceite definidos no DoR e no DoD, priorizando a satisfação do cliente.
\ No newline at end of file
diff --git a/docs/FasesOpenUP/Elaboracao.md b/docs/FasesOpenUP/Elaboracao.md
new file mode 100644
index 0000000..c3a82aa
--- /dev/null
+++ b/docs/FasesOpenUP/Elaboracao.md
@@ -0,0 +1,96 @@
+# Elaboração
+Na fase de Elaboração, a equipe focou em desenvolver as funcionalidades e validar a arquitetura, enquanto continuava a capacitação da equipe e a análise de riscos para garantir a entrega de um produto de alta qualidade. Os marcos cumpridos nessa fase foram:
+
+## Capacitações
+Capacitações contínuas foram realizadas com foco nas tecnologias utilizadas no projeto, garantindo que a equipe estivesse atualizada e equipada para lidar com as necessidades de desenvolvimento, como o uso do Spring Boot, Java, e outras ferramentas necessárias para o backend e frontend.
+
+## Prototipagem
+Protótipos interativos foram desenvolvidos no **Figma**, permitindo que a equipe visualizasse e testasse o fluxo de navegação do sistema e a experiência do usuário antes da implementação. Isso facilitou a comunicação com o cliente, ajudando a validar o design e as funcionalidades propostas.
+
+[Link do figma](https://www.figma.com/design/35bsz8P6wMWnZAo6fzlmDj/Prot%C3%B3tipo---pet-shop-guar%C3%A1?node-id=0-1&t=WOYEH2ExE34RqevI-1)
+
+## Análise de Riscos
+A análise de riscos foi realizada para identificar possíveis obstáculos no desenvolvimento, como desafios técnicos, limitações de recursos, e riscos de mercado. A equipe definiu estratégias de mitigação para lidar com os riscos identificados, minimizando a chance de imprevistos durante as fases seguintes do desenvolvimento.
+
+**1. Riscos Técnicos**
+
+| **Risco** | **Probabilidade** | **Impacto** | **Mitigação** |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Falhas na integração entre o sistema de agendamento e o backend | Média | Alta | Realizar testes contínuos durante o desenvolvimento e usar ferramentas confiáveis para integração. |
+| Lentidão no sistema devido ao volume de agendamentos | Baixa | Média | Monitorar desempenho e otimizar consultas ao banco de dados. |
+| Dificuldades no acesso ao sistema por dispositivos móveis | Média | Alta | Implementar design responsivo e realizar testes em diferentes dispositivos. |
+| Erros no cálculo de receitas mensais | Alta | Alta | Validar o cálculo financeiro com casos de teste e revisão pelo cliente. |
+
+**2. Riscos Humanos**
+
+| **Risco** | **Probabilidade** | **Impacto** | **Mitigação** |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Falta de engajamento do cliente no acompanhamento do projeto | Média | Alta | Agendar reuniões e manter comunicação clara sobre o progresso e decisões importantes. |
+| Falta de habilidade técnica em alguma área crítica (ex.: backend ou design) | Média | Alta | Fazer treinamentos rápidos e capacitações. |
+
+**3. Riscos de Requisitos**
+
+| **Risco** | **Probabilidade** | **Impacto** | **Mitigação** |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Alteração nos requisitos após o início do desenvolvimento | Média | Alta | Usar ciclos curtos de desenvolvimento (ex.: Sprints) e validar funcionalidades com o cliente. |
+| Requisitos incompletos ou mal definidos | Média | Alta | Realizar sessões detalhadas de levantamento e revisão dos requisitos. |
+
+**4. Riscos de Cronograma**
+
+| **Risco** | **Probabilidade** | **Impacto** | **Mitigação** |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Atraso na entrega do MVP | Média | Alta | Estabelecer prazos realistas e priorizar funcionalidades essenciais para o MVP. |
+| Sobrecarga de tarefas na equipe | Alta | Média | Dividir as tarefas igualmente e evitar escopo excessivo. |
+
+**5. Riscos de Negócio**
+
+| **Risco** | **Probabilidade** | **Impacto** | **Mitigação** |
+|---------------------------------------|-------------------|--------------|------------------------------------------------|
+| Falta de aceitação do sistema pelos usuários (dono e clientes do pet shop) | Média | Alta | Incluir o cliente nas decisões de design e realizar testes com usuários finais antes do lançamento. |
+| O sistema não atender totalmente às expectativas do cliente | Média | Alta | Recolher feedback e ajustar o escopo quando necessário. |
+
+**Plano de Monitoramento de Riscos**
+
+1. **Periodicidade**: Revisar os riscos a cada Sprint ou semanalmente.
+2. **Indicadores**:
+
+ - Taxa de erros no sistema durante os testes.
+ - Adesão do cliente às reuniões.
+ - Progresso das tarefas no cronograma.
+
+
+## Arquitetura
+
+O projeto adota uma arquitetura em camadas, com o frontend em React.js, o backend em Spring Boot com PostgreSQL e a comunicação entre eles feita por meio de uma API RESTful. Essa estrutura proporciona maior organização, manutenibilidade e escalabilidade.
+
+
+
+Autores: [Pedro Henrique Fernandino](https://github.com/PedroHenrique061), [Kaio Enzo Salgado](https://github.com/kaioenzo), [Enrico Zoratto](https://github.com/sidts)
+
+
+
+**Frontend (React.js - Camada de Apresentação):**
+
+A camada de apresentação, construída com React.js, é responsável por interagir diretamente com o usuário. Ela lida com a interface, exibindo informações e capturando as ações do usuário. O React.js, com sua estrutura baseada em componentes, facilita a criação de interfaces dinâmicas e reutilizáveis.
+
+**Backend (Spring Boot com PostgreSQL - Camadas de Negócio e Dados):**
+
+O backend é dividido em duas camadas principais:
+
+* **Camada de Negócio (Spring Boot):** Esta camada contém a lógica de negócios da aplicação, processando as requisições do frontend, aplicando regras de negócio e gerenciando as interações com a camada de dados.
+
+* **Camada de Dados (PostgreSQL):** Responsável pelo armazenamento e recuperação dos dados da aplicação. O PostgreSQL, um sistema de gerenciamento de banco de dados relacional. A camada de negócio interage com a camada de dados por meio de abstrações, permitindo que o banco de dados seja alterado sem impactar a lógica de negócios.
+
+**Comunicação (API REST - Camada de Integração):**
+
+A API REST atua como uma camada de integração entre o frontend e o backend. Ela define um conjunto de endpoints que o frontend pode acessar para interagir com a aplicação.
+
+**Infraestrutura(AWS, Vercel, GitHub Actions):**
+
+O backend e o banco de dados é hospedado na AWS (Amazon Web Services), enquanto o frontend é hospedado na Vercel. A integração contínua e a entrega contínua (CI/CD) são realizadas por meio do GitHub Actions.
+
+## Histórico de Revisão - Arquitetura
+
+| Data | Versão | Descrição | Autor |
+|------------|--------|-------------------------------------------------------|------------|
+| 29/10/2024 | 1.0 | Criação do documento | Kaio Enzo |
diff --git a/docs/FasesOpenUP/Transicao.md b/docs/FasesOpenUP/Transicao.md
new file mode 100644
index 0000000..f0263dc
--- /dev/null
+++ b/docs/FasesOpenUP/Transicao.md
@@ -0,0 +1,12 @@
+# Transição
+A Fase de Transição é dedicada à entrega final do sistema, garantindo que ele esteja pronto para uso pelo cliente. Nesta etapa, o foco principal é a disponibilização do produto em ambiente de produção e a validação final com o cliente por meio de demonstrações e ajustes, se necessários.
+
+## Hospedagem
+- Configuração do ambiente de produção para hospedagem do sistema.
+- Implantação do sistema em um servidor ou serviço de hospedagem apropriado, garantindo acessibilidade ao cliente e usuários finais, no caso Vercel.
+- Testes finais em ambiente de produção para verificar a funcionalidade, desempenho e segurança do sistema.
+
+## Walkthrough
+- Realização de um walkthrough detalhado com o cliente, apresentando todas as funcionalidades do sistema.
+- Demonstração de como cada funcionalidade atende aos requisitos estabelecidos durante a concepção e construção.
+- Recolhimento de feedback do cliente para pequenos ajustes ou melhorias necessárias antes da entrega oficial.
\ No newline at end of file
diff --git a/docs/Unidades/Unidade2.md b/docs/Unidades/Unidade2.md
new file mode 100644
index 0000000..b83b60b
--- /dev/null
+++ b/docs/Unidades/Unidade2.md
@@ -0,0 +1 @@
+# Lições Aprendidas na Unidade 2
\ No newline at end of file
diff --git "a/docs/Vis\303\243oProduto/Arquitetura.md" "b/docs/Vis\303\243oProduto/Arquitetura.md"
deleted file mode 100644
index ffcd7ca..0000000
--- "a/docs/Vis\303\243oProduto/Arquitetura.md"
+++ /dev/null
@@ -1,34 +0,0 @@
-
-O projeto adota uma arquitetura em camadas, com o frontend em React.js, o backend em Spring Boot com PostgreSQL e a comunicação entre eles feita por meio de uma API RESTful. Essa estrutura proporciona maior organização, manutenibilidade e escalabilidade.
-
-
-
-Autores: [Pedro Henrique Fernandino](https://github.com/PedroHenrique061), [Kaio Enzo Salgado](https://github.com/kaioenzo), [Enrico Zoratto](https://github.com/sidts)
-
-
-
-**Frontend (React.js - Camada de Apresentação):**
-
-A camada de apresentação, construída com React.js, é responsável por interagir diretamente com o usuário. Ela lida com a interface, exibindo informações e capturando as ações do usuário. O React.js, com sua estrutura baseada em componentes, facilita a criação de interfaces dinâmicas e reutilizáveis.
-
-**Backend (Spring Boot com PostgreSQL - Camadas de Negócio e Dados):**
-
-O backend é dividido em duas camadas principais:
-
-* **Camada de Negócio (Spring Boot):** Esta camada contém a lógica de negócios da aplicação, processando as requisições do frontend, aplicando regras de negócio e gerenciando as interações com a camada de dados.
-
-* **Camada de Dados (PostgreSQL):** Responsável pelo armazenamento e recuperação dos dados da aplicação. O PostgreSQL, um sistema de gerenciamento de banco de dados relacional. A camada de negócio interage com a camada de dados por meio de abstrações, permitindo que o banco de dados seja alterado sem impactar a lógica de negócios.
-
-**Comunicação (API REST - Camada de Integração):**
-
-A API REST atua como uma camada de integração entre o frontend e o backend. Ela define um conjunto de endpoints que o frontend pode acessar para interagir com a aplicação.
-
-**Infraestrutura(AWS, Vercel, GitHub Actions):**
-
-O backend e o banco de dados é hospedado na AWS (Amazon Web Services), enquanto o frontend é hospedado na Vercel. A integração contínua e a entrega contínua (CI/CD) são realizadas por meio do GitHub Actions.
-
-## Histórico de Revisão
-
-| Data | Versão | Descrição | Autor |
-|------------|--------|-------------------------------------------------------|------------|
-| 29/10/2024 | 1.0 | Criação do documento | Kaio Enzo |
\ No newline at end of file
diff --git "a/docs/Vis\303\243oProduto/Backlog.md" "b/docs/Vis\303\243oProduto/Backlog.md"
new file mode 100644
index 0000000..ed0e7c9
--- /dev/null
+++ "b/docs/Vis\303\243oProduto/Backlog.md"
@@ -0,0 +1,133 @@
+# Backlog do Produto
+É importante ressaltar que todas as histórias de usuário apresentadas a seguir foram elaboradas com base na lista de requisitos funcionais descritos anteriormente neste documento. Trata-se de uma lista inicial, sujeita a ajustes ao longo do desenvolvimento do produto da Pet Shop Guará, conforme necessário.
+
+## Backlog Geral
+
+### Cadastro
+**US01** - Como cliente, quero me cadastrar no sistema para poder agendar serviços para meus pets.
+
+**US02** - Como cliente, quero cadastrar meus pets com informações como nome, idade e raça, para facilitar a escolha dos serviços mais adequados.
+
+### Agendamento de Serviços
+**US03** - Como cliente, quero agendar serviços de banho e tosa para meus pets, especificando detalhes como o tipo de tosa desejada, para garantir que recebam os cuidados necessários.
+
+**US04** - Como cliente, quero visualizar os horários disponíveis para agendamentos, para escolher o momento mais conveniente para mim e para meus pets.
+
+**US05** - Como cliente, quero cancelar ou reagendar serviços com antecedência, caso surjam imprevistos, para evitar transtornos.
+
+**US06** - Como cliente, quero consultar o histórico dos serviços realizados para meus pets, para acompanhar os cuidados prestados e os custos envolvidos.
+
+### Redirecionamento
+**US07** - Como cliente, quero acessar o Instagram do pet shop pelo sistema, para acompanhar novidades e promoções.
+
+### Upload de Fotos
+**US08** - Como cliente, quero enviar fotos do meu pet ao sistema, para usar como referência em pedidos de tosa personalizada ou para ter salvo em seu cadastro.
+
+### Feedbacks
+**US09** - Como cliente, quero avaliar os serviços prestados com uma nota e comentários, para ajudar a melhorar a qualidade do atendimento.
+
+**US10** - Como administrador, quero visualizar e analisar as avaliações fornecidas pelos clientes, para identificar melhorias nos serviços oferecidos.
+
+### Gestão de Clientes e Pets
+**US11** - Como administrador, quero acessar os dados cadastrais dos clientes, para entrar em contato com eles e atender melhor suas demandas.
+
+**US12** - Como administrador, quero visualizar informações detalhadas sobre os pets dos clientes, para oferecer um atendimento de qualidade.
+
+**US13** - Como funcionário, quero vizualizar as informações dos pets cadastrados, como nome, idade, raça e nome do dono, para prestar os serviços com mais eficiência.
+
+### Gestão de Preços
+**US14** - Como administrador, quero ajustar os preços dos serviços sempre que necessário, para acompanhar custos e promoções.
+
+### Calendário e Agendamentos
+**US15** - Como administrador, quero acessar um calendário com todos os agendamentos organizados por data e horário, para gerenciar melhor os atendimentos.
+
+**US16** - Como administrador, quero mover ou reagendar horários no calendário, para acomodar ajustes necessários nos atendimentos.
+
+**US17** - Como administrador, quero cancelar agendamentos quando preciso, notificando os clientes de forma clara e imediata, para liberar a agenda quando não for possível receber o pet.
+
+**US18** - Como funcionário, quero acessar o calendário com os agendamentos do dia organizados por horário, para gerenciar melhor o fluxo de trabalho e atender os clientes conforme programado.
+
+### Relatórios
+**US19** - Como administrador, quero acessar relatórios financeiros detalhados, para entender melhor os lucros e despesas do pet shop.
+
+## Priorização do Backlog Geral
+Nesta seção, realizamos a priorização dos itens do backlog utilizando a técnica MoSCoW, que organiza as funcionalidades em três categorias principais:
+
+- **Must have**: Funcionalidades essenciais para o funcionamento do produto, que devem ser entregues sem exceção.
+- **Should have**: Funcionalidades importantes, porém que podem ser implementadas após as funcionalidades essenciais.
+- **Could have**: Funcionalidades desejáveis, que agregam valor, mas não são prioritárias no escopo inicial.
+- **Wont't have**: Funcionalidades que não serão aplicadas, por, inicialmente, não agregarem valor.
+
+A priorização teve como objetivo garantir que o desenvolvimento fosse focado nas funcionalidades mais críticas, alinhando o produto às necessidades do negócio e aos recursos disponíveis. Cada integrante do grupo deu notas de 1 a 4, cada uma tendo sua recṕroca nas categorias do MoSCoW, para cada um dos requisitos. A partir da média dessas notas, foi realizada a priorização.
+
+[Tabela com a priorização do backlog](https://docs.google.com/spreadsheets/d/1aYJmucRqJq6MdoH8feihHwS9ilAsIxsUSNQwmB7tk8o/edit?usp=sharing)
+
+A tabela a seguir apresenta a classificação de cada item do backlog, proporcionando clareza e organização para as próximas etapas do projeto.
+
+| **ID** | **Descrição** | **Prioridade** |
+|---------|------------------------------------------------------------------------------------------------|----------------|
+| **US01** | Cadastrar Usuários | Must have |
+| **US02** |Cadstrar Pets | Must have |
+| **US03** |Agendar Serviço | Must have |
+| **US04** |Exibir Horários Disponíveis | Must have |
+| **US05** |Cancelar agendamentos | Should have |
+| **US06** |Consultar Histórico de Serviços | Could have |
+| **US07** |Redirecionar para as Redes Sociais | Could have |
+| **US08** |Fazer Upload de Fotos | Could have |
+| **US09** |Fornecer Feedback sobre o Serviço | Should have |
+| **US10** |Consultar os Feedbacks Forncecidos | Should have |
+| **US11** |Consultar Dados dos Clientes | Must have |
+| **US12** |Consultar Informações dos Pets | Must have |
+| **US13** |Consultar Informações dos Pets por Parte dos Funcionários | Should have |
+| **US14** |Alterar os Preços dos Serviços | Should have |
+| **US15** |Vizualizar Calendário com Agendamentos | Must have |
+| **US16** |Alterar o Calendário | Should have |
+| **US17** |Cancelar Agendamentos | Should have |
+| **US18** |Vizualizar Calendário com Agendamentos do Dia por Parte dos Funcionários | Must have |
+| **US19** |Consultar Dados Financeiro | Should have |
+
+## MVP
+O Produto Mínimo Viável (MVP) é uma versão do produto que inclui as funcionalidades essenciais e prioritárias, selecionadas por meio da técnica MoSCoW, para atender às necessidades principais do cliente, permitindo o lançamento inicial do sistema com as funcionalidades mais críticas.
+
+As funcionalidades escolhidas para o MVP são:
+
+1. **Cadastrar Usuários**
+
+2. **Cadastrar Pets**
+
+3. **Agendar Serviços**
+
+4. **Exibir Horários Disponíveis**
+
+5. **Consultar Dados dos Clientes**
+
+6. **Visualizar Calendário com Agendamentos**
+
+7. **Consultar Informações dos Pets**
+
+8. **Visualizar Calendário com Agendamentos do Dia por Parte dos Funcionários**
+
+9. **Alterar os Preços dos Serviços**
+
+10. **Cancelar Agendamentos por Parte do Dono**
+
+11. **Alterar o Calendário**
+
+12. **Cancelar Agendamentos por Parte do Cliente**
+
+13. **Fornecer Feedback sobre o Serviço**
+
+14. **Consultar Informações dos Pets por Parte dos Funcionários**
+
+15. **Consultar dados financeiros**
+
+16. **Consultar feedbacks fornecidos**
+
+
+
+Autores: [Alexandre Júnior](https://github.com/AlexandreLJr), [Gustavo Haubert](https://github.com/GustavoHaubert), [Manoela Garcia](https://github.com/manu-sgc)
+
+
+Essas funcionalidades são essenciais para a operação inicial do sistema e foram priorizadas para garantir que o produto atenda às necessidades básicas do cliente e colaboradores do pet shop, com o objetivo de facilitar a gestão de serviços e o relacionamento com os clientes.
+
+As funcionalidades que não entraram no MVP, as da classificação *Could Have*, serão feitas após a conculsão do MVP, por não serem críticas para o funcionamento do sistema.
\ No newline at end of file
diff --git "a/docs/Vis\303\243oProduto/Cronograma.md" "b/docs/Vis\303\243oProduto/Cronograma.md"
index 8ca2c88..d526db7 100644
--- "a/docs/Vis\303\243oProduto/Cronograma.md"
+++ "b/docs/Vis\303\243oProduto/Cronograma.md"
@@ -2,24 +2,59 @@
| Sprint | Início | Fim | Objetivos e Entregas Esperadas |
|--------|---------------|---------------|-----------------------------------------------------------------------------------------------|
-| 0 | 04/11/2024 | 10/11/2024 | Planejamento do projeto, definição do escopo, decisão dos cargos, organização da documentação.|
-| 1 | 11/11/2024 | 17/11/2024 | Entrega da Unidade 1, capacitações, definir o MVP, definir DoR e DoD. |
-| 2 | 18/11/2024 | 24/11/2024 | Capacitações, protótipo no Figma, arquitetura, análise de riscos. |
-| 3 | 25/11/2024 | 01/12/2024 | Desenvolver o banco de dados, criar as funções de cadastro do dono do animal e do pet, testes das funções feitas na semana. |
-| 4 | 02/12/2024 | 08/12/2024 | Estilizar os cadastros, criar a função de agendamento de banho e tosa, mostrandos os horários e dias disponíveis, criar a função de cancelar o agendamento, testes das funções/estilizações feitas na semana. |
-| 5 | 09/12/2024 | 15/12/2024 | Estilizar o agendamento e o cancelamento, criar a página do dono do negócio, criar a função de consultar as informações dos pets e dos clientes, testes das funções/estilizações feitas na semana. |
-| 6 | 16/12/2024 | 22/12/2024 | Entrega da Unidade 2, estilizar a página do dono e as consultas de pets e clientes, criar a função de alterar os preços dos serviços, criar a função de ver o calendário de agendamentos, testes das funções/estilizações feitas na semana. |
-| | 23/12/2024 | 01/01/2025 | Recesso |
-| 7 | 02/01/2025 | 12/01/2025 | Estilizar a alteração de preços e o calendário de agendamentos, criar a função de alterar o calendário e cancelar agendamentos, testes das funções/estilizações feitas na semana. Validação da página do usuário com nosso cliente. |
-| 8 | 13/01/2025 | 19/01/2025 | Fazer a hospedagem, criar a página dos funcionários com a consulta das informações sobre os clientes e pets e com acesso ao calendário de agendamentos, testes das funções/estilizações feitas na semana. |
-| 9 | 20/01/2025 | 26/01/2025 | Entrega da Unidade 3, estilizar a página dos funcionários, criar link para direcionamento para o instagram do petshop, criar função de consultar os agendamentos anteriores para os clientes, criar a função de upload de fotos, testes das funções/estilizações feitas na semana. |
-| 10 | 27/01/2025 | 02/02/2025 | Estilizar a consulta de agendamentos anteriores e o upload de fotos, criar a função de feedback sobre os serviços prestados, criar a função do planner financeiro, validação com o cliente, testes das funções/estilizações feitas na semana. |
-| 11 | 03/02/2025 | 09/02/2025 | Fazer as mudanças pedidas pelo cliente, estilizar o feedback e o planner, testes das funções/estilizações feitas na semana. |
-| 12 | 10/02/2025 | 12/02/2025 | Encerramento do projeto, entrega da Unidade 4. |
-
-criar a função de upload de fotos para o agendamento e o cadastro dos pets
-criar a função de consultar os agendamentos já feitos pelo usuário
-dar feedback sobre o serviço prestado
+| 0 | 04/11/2024 | 10/11/2024 | - Planejamento do projeto |
+| | | | - Definição do escopo |
+| | | | - Decisão dos cargos |
+| | | | - Organização da documentação |
+| 1 | 11/11/2024 | 17/11/2024 | - Entrega da Unidade 1 |
+| | | | - Capacitações |
+| | | | - Definir o MVP |
+| | | | - Definir DoR e DoD |
+| | | | - Declaração de requisitos funcionais e não funcionais |
+| | | | - User story |
+| | | | - Regras de negócio |
+| 2 | 18/11/2024 | 24/11/2024 | - Capacitações |
+| | | | - Protótipo no Figma |
+| | | | - Arquitetura |
+| | | | - Análise de riscos |
+| 3 | 25/11/2024 | 01/12/2024 | - Desenvolver o banco de dados |
+| | | | - Desenvolvimento do cadastro do dono do animal e do pet |
+| | | | - Testes das funções/estilizações feitas na semana |
+| 4 | 02/12/2024 | 08/12/2024 | - Desenvolver o agendamento de banho e tosa, mostrando os horários e dias disponíveis |
+| | | | - Desenvolver o cancelamento do agendamento |
+| | | | - Testes das funções/estilizações feitas na semana |
+| 5 | 09/12/2024 | 15/12/2024 | - Criar a página do dono do negócio |
+| | | | - Desenvolver a consulta das informações dos pets e dos clientes |
+| | | | - Testes das funções/estilizações feitas na semana |
+| 6 | 16/12/2024 | 22/12/2024 | - Entrega da Unidade 2 |
+| | | | - Desenvolver a alteração dos preços dos serviços |
+| | | | - Desenvolver a visualização do calendário de agendamentos |
+| | | | - Testes das funções/estilizações feitas na semana |
+| | 23/12/2024 | 01/01/2025 | **Recesso** |
+| 7 | 02/01/2025 | 12/01/2025 | - Desenvolver a alteração do calendário |
+| | | | - Desenvolver o cancelamento dos agendamentos por parte do dono |
+| | | | - Testes das funções/estilizações feitas na semana |
+| | | | - Validação da página do usuário com nosso cliente |
+| 8 | 13/01/2025 | 19/01/2025 | - Criar a página dos funcionários |
+| | | | - Consultar as informações sobre os pets |
+| | | | - Acesso ao calendário de agendamentos do dia |
+| | | | - Testes das funções/estilizações feitas na semana |
+| 9 | 20/01/2025 | 26/01/2025 | - Desenvolver a função de dar feedback sobre os serviços prestados |
+| | | | - Desenvolver a função de ver feedback sobre os serviços prestados |
+| | | | - Desenvolver o planner financeiro |
+| | | | - Testes das funções/estilizações feitas na semana |
+| 10 | 27/01/2025 | 02/02/2025 | - Fazer a hospedagem |
+| | | | - Criar link para direcionamento para o Instagram do petshop |
+| | | | - Desenvolvimento da consulta dos agendamentos anteriores para os clientes |
+| | | | - Desenvolvimento do upload de fotos |
+| | | | - Validação com o cliente |
+| | | | - Testes das funções/estilizações feitas na semana |
+| 11 | 03/02/2025 | 09/02/2025 | - Fazer as mudanças pedidas pelo cliente |
+| | | | - Testes das funções/estilizações feitas na semana |
+| 12 | 10/02/2025 | 12/02/2025 | - Walkthrough com o cliente |
+| | | | - Encerramento do projeto |
+| | | | - Entrega da Unidade 4 |
+
## Considerações Importantes
@@ -31,6 +66,6 @@ dar feedback sobre o serviço prestado
* Fase de concepção - Sprints 0 e 1
* Fase de elaboração - Sprint 2
* Fase de construção - Spints 3 a 10
- * Fase de transição - Sprints 11 e 12
+ * Fase de transição - Sprints 10 a 12
diff --git "a/docs/Vis\303\243oProduto/DoRDoD.md" "b/docs/Vis\303\243oProduto/DoRDoD.md"
new file mode 100644
index 0000000..cb8c210
--- /dev/null
+++ "b/docs/Vis\303\243oProduto/DoRDoD.md"
@@ -0,0 +1,39 @@
+# DoR e DoD
+
+## Definition of Ready (DoR)
+O **Definition of Ready (DoR)** define os critérios que devem ser atendidos para que as *user story* estejam prontas para ser desenvolvidas. No contexto do nosso projeto, alguns critérios para determinar se um requisito está *Ready* incluem:
+
+- O requisito possui informações necessárias?
+Os detalhes devem ser suficientes para que a equipe de desenvolvimento entenda o que precisa ser feito, sem ambiguidades.
+
+- O requisito cabe em uma Sprint?
+Ele deve ser suficientemente pequeno e bem delimitado para ser concluído dentro de uma única Sprint.
+
+- O requisito está coberto por critérios de aceitação?
+Os critérios devem estar claramente definidos, garantindo que todos saibam o que é necessário para considerar o requisito completo.
+
+- O requisito está representado por uma história de usuário e por um protótipo?
+O requisito deve ser descrito no formato de história de usuário e representado por meio de prototipagem, facilitando o entendimento pelo time.
+
+- O requisito está bem alinhado com o cliente ?
+O requisito deve estar bem entendido entre o cliente e a equipe, para que assim o processo de desenvolvimento possa começar com ambas as partes em acordo.
+
+
+## Definition of Done (DoD)
+O **Definition of Done (DoD)** define os critérios que precisam ser cumpridos para que uma funcionalidade seja considerada completa. Isso inclui:
+
+- Cumprimento dos critérios de aceitação
+Todos os critérios definidos previamente devem ser atendidos, garantindo que a funcionalidade cumpre os requisitos do negócio.
+
+- Aderência aos padrões de codificação
+O código deve seguir os padrões definidos pela equipe, garantindo qualidade, consistência e facilidade de manutenção.
+
+- Completo em termos de desenvolvimento
+A funcionalidade deve estar totalmente implementada, sem partes faltando.
+
+- Testes Unitários e de Integração Realizados e Aprovados
+Todos os testes foram executados, garantindo que a funcionalidade não afeta negativamente outras partes do sistema e que se comporta como esperado.
+
+- Validação pelo Cliente
+O cliente aprovou as funcionalidades desenvolvidas até o momento da reunião, confirmando que atende às expectativas e ao escopo definido.
+
diff --git "a/docs/Vis\303\243oProduto/EngRequisitos.md" "b/docs/Vis\303\243oProduto/EngRequisitos.md"
new file mode 100644
index 0000000..a8abf0f
--- /dev/null
+++ "b/docs/Vis\303\243oProduto/EngRequisitos.md"
@@ -0,0 +1,91 @@
+# Engenharia de Requisitos
+
+## Atividades e Técnicas de ER e OpenUP
+
+### **Concepção**
+
+#### **Elicitação e Descoberta**
+
+- **Entrevista com o cliente**: Realizar entrevistas para entender as necessidades, expectativas e objetivos principais do projeto, garantindo que os requisitos reflitam as prioridades do cliente.
+- **Análise de concorrentes**: Estudo detalhado das soluções existentes no mercado para identificar boas práticas e oportunidades de diferenciação.
+- **Brainstorming**: Sessões de brainstorming com a equipe para levantar ideias e explorar soluções inovadoras para atender às necessidades do cliente.
+
+#### **Análise e Consenso**
+
+- **Análise de Domínio de Requisito**: Entendimento aprofundado das áreas envolvidas no projeto, assegurando que os requisitos sejam viáveis e relevantes ao contexto do cliente.
+- **Análise de viabilidade**: Avaliação da viabilidade técnica e temporal dos requisitos levantados.
+- **Reuniões entre os membros da equipe**: Discussão e alinhamento dos objetivos e prioridades, promovendo o consenso entre os participantes.
+
+#### **Declaração**
+
+- **Reuniões entre os membros da equipe**: Sessões colaborativas para redigir e validar os documentos de requisitos.
+- **Documento de visão de produto**: Documento que descreve o escopo e as metas principais do projeto, alinhando todos os stakeholders.
+- **Especificação de Requisitos**: Documento detalhado contendo os requisitos funcionais e não funcionais do sistema.
+- **Features**: Listagem das principais funcionalidades organizadas em níveis hierárquicos (temas, épicos e histórias de usuário).
+
+#### **Verificação e Validação**
+
+- **Reuniões entre os membros da equipe**: Sessões colaborativas para verificar e validar os requisitos.
+- **Revisão dos critérios de aceitação**: Definir critérios objetivos para validar que os requisitos foram corretamente implementados.
+- **Brainstorming**: Sessões para validar ideias, explorar melhorias e alinhar expectativas sobre os requisitos levantados.
+
+#### **Organização e Atualização**
+- **MoSCoW**: Aplicação do método MoSCoW para priorização dos requisitos.
+- **User Story**: Abordagem para descrever os requisitos sob a perspectiva dos usuários.
+
+---
+
+### **Elaboração**
+
+#### **Representação**
+
+- **Prototipagem**: Criação de protótipos para validar funcionalidades e melhorar a comunicação entre a equipe e os stakeholders.
+- **Diagramas**: Produção de diagramas (como arquitetura) para representar os processos e requisitos do sistema.
+
+#### **Análise e Consenso**
+
+- **Análise de risco**: Identificação e análise de potenciais riscos ao projeto, incluindo mitigação de impactos e criação de planos de contingência.
+
+---
+
+#### **Verificação e Validação**
+
+- **Walkthrough**: Revisão com o cliente em cima do protótipo mostrando todas as funcionalidades que serão aplicadas ao produto.
+- **Feedback**: Feedback sobre o protótipo criado e melhorias que o cliente gostaria que fossem feitas.
+
+---
+
+### **Construção**
+
+#### **Organização e Atualização**
+
+- **Alinhamento da equipe**: Realização de reuniões regulares para alinhar o progresso e ajustar as prioridades, garantindo que todos estejam na mesma direção.
+- **Feedback**: Coleta e aplicação de feedback para refinar as entregas e atender melhor às expectativas do cliente e da equipe.
+
+#### **Verificação e Validação**
+
+- **Entrevista com o cliente**: Reuniões com o cliente para apresentar os resultados parciais e validar que os requisitos estão sendo atendidos.
+- **Feedback**: Recolher opiniões sobre o progresso e implementar melhorias com base nas observações recebidas.
+
+---
+
+### **Transição**
+
+#### **Verificação e Validação**
+
+- **Walkthrough**: Sessões de revisão guiada onde as funcionalidades são apresentadas ao cliente e equipe para validação e ajustes finais.
+
+## Engenharia de Requisitos e o OpenUP
+| **Fases do OpenUP** | **Atividades da ER** | **Prática** | **Técnica** | **Resultados Esperados** |
+|----------------------|------------------------------|----------------------------------|-------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
+| **Concepção** | **Elicitação e Descoberta** | Conhecimento do cliente e do problema | Entrevista com o cliente, Análise de Concorrentes, Brainstorming | Lista de necessidades, Declaração do problema, Lista de requisitos, Proposta de solução |
+| | **Análise e Consenso** | Análise de requisitos | Análise de Domínio de Requisito, Análise de viabilidade, Reuniões entre os membros da equipe | Criação do MVP |
+| | **Declaração** | Registros dos requisitos | Reuniões entre os membros da equipe, Documento de visão de produto, Especificação de Requisitos, Features | SRS - Software Requirements Specification|
+| | **Verificação e Validação** | Validação de Requisitos | Reunião entre os membros da equipe, Revisão de Critérios de Aceitação, Brainstorming | DoD e DoR
+| | **Organização e Atualização** | Priorização de Requisitos | MoSCoW, User Story | Requisitos priorizados para montar o mvp, Backlog de Requisitos |
+| **Elaboração** | **Representação** | Criação de Protótipos | Prototipagem e Diagramas | Protótipo |
+| | **Análise e Consenso** | Alinhamento de requisitos | Análise de Risco, Lean Inception | User Story, Especificação de Requisitos de Software (SRS) |
+| | **Verificação e Validação** | Validação do protótipo | Walkthrough, Feedback | Resultados do Walkthrough |
+| **Construção** | **Organização e Atualização**| Revisão do produto | Alinhamento da equipe, Feedback | Atualização dos requisitos |
+| | **Verificação e Validação** | Revisão do produto | Walkthrough, Feedback, DoD | Resultados do walkthrough |
+| **Transição** | **Verificação e Validação** | Revisão do produto finalizado | Walkthrough | Resultados do Walkthrough, Qualidade de Requisitos |
diff --git "a/docs/Vis\303\243oProduto/Intera\303\247\303\243o.md" "b/docs/Vis\303\243oProduto/Intera\303\247\303\243o.md"
index 09cbe06..2b21262 100644
--- "a/docs/Vis\303\243oProduto/Intera\303\247\303\243o.md"
+++ "b/docs/Vis\303\243oProduto/Intera\303\247\303\243o.md"
@@ -6,9 +6,9 @@
|--------------------|------------------------------------------------------------|---------------------|------------------------|
| Gerente de Projeto | Coordena o projeto, garante a comunicação entre cliente e equipe, controla prazos e entregas. | Manoela | - |
| Desenvolvedor FrontEnd | Responsável pela interface do usuário, design e implementação das funcionalidades no lado do cliente. | Alexandre | Manoela |
-| Desenvolvedor Backend | Implementa a lógica de negócios, integração com banco de dados e APIs. | Enrico |Kaio e Pedro Henrique |
+| Desenvolvedor Backend | Implementa a lógica de negócios, integração com banco de dados e APIs. | Enrico |Gustavo e Pedro Henrique |
| Analista de Requisitos | Identifica, documenta e gerencia requisitos funcionais e não funcionais. Realiza elicitação, análise, validação e especificação dos requisitos. Garante alinhamento com os objetivos do projeto e participa de revisões e testes.. | Pedro Henrique | Gustavo, Alexandre, Enrico, Kaio e Manoela |
-| Desenvolvedor CI/CD / Tester | Codificar testes unitários, criar integração e entrega contínua. Realizar testes funcionais, garantindo a qualidade do produto. | Kaio | Gustavo |
+| Desenvolvedor CI/CD / Tester | Codificar testes unitários, criar integração e entrega contínua. Realizar testes funcionais, garantindo a qualidade do produto. | Gustavo | |
## Comunicação
diff --git "a/docs/Vis\303\243oProduto/Requisitos.md" "b/docs/Vis\303\243oProduto/Requisitos.md"
new file mode 100644
index 0000000..3ccc668
--- /dev/null
+++ "b/docs/Vis\303\243oProduto/Requisitos.md"
@@ -0,0 +1,56 @@
+# Requisitos de Software
+
+## **Lista de Requisitos Funcionais**
+
+Os requisitos funcionais detalham as funcionalidades específicas que o sistema deve oferecer para atender às demandas do Pet Shop Guará. Abaixo, está apresentado o conjunto inicial desses requisitos.
+
+### Requisitos do Cliente do Petshop
+1. **Cadastrar Usuários**: Permitir o cadastro de clientes, incluindo informações como nome e telefone.
+2. **Cadstrar Pets**: Permitir que o cliente faça o cadstro de seus pets com informações como nome, idade, raça, e tudo o que seja relevante para o serviço de banho e tosa.
+3. **Agendar Serviços**: Permitir que o cliente agende serviços de banho e tosa para seus animais, escolhendo entre os serviços disponíveis, em horários que estejam disponíveis, e adicionando especificações sobre o serviço.
+4. **Exibir Horários Disponíveis**: Mostrar ao cliente os horários disponíveis para agendamentos, com base na disponibilidade do pet shop e dos funcionários.
+5. **Cancelar agendamentos**: Permitir que o cliente cancele ou reagende serviços, seguindo uma política de tempo de antecedência mínima definida pelo pet shop.
+6. **Consultar Histórico de Serviços**: Oferecer ao cliente acesso ao histórico dos serviços realizados, incluindo data, serviços prestados, e valores cobrados.
+7. **Redirecionar para as Redes Sociais**: Permitir que o cliente seja redirecionado para a rede social do pet shop, no caso o Instagram.
+8. **Fazer Upload de Fotos**: Permitir que o cliente envie fotos do seu animal para cadastro ou para referências de tosas.
+9. **Fornecer Feedback sobre o Serviço**: Permitir que o cliente avalie o serviço prestado com uma nota de 1 a 5 estrelas e comentários adicionais.
+
+### Requisitos do Dono do Negócio
+10. **Consultar Dados dos Clientes**: Permitir que o dono do pet shop acesse os dados cadastrais dos clientes, incluindo informações de contato e histórico de agendamentos.
+11. **Consultar Informações dos Pets**: Permitir que o dono acesse informações dos pets cadastrados, como nome, idade e raça.
+12. **Alterar os Preços dos Serviços**: Permitir que o dono modifique os preços dos serviços com base em diferentes critérios como custo de acordo com as características do animal ou promoções.
+13. **Vizualizar Calendário com Agendamentos**: Permitir que o dono visualize todos os agendamentos em um calendário, com horários e datas organizados.
+14. **Alterar o Calendário**: Permitir que o dono mova ou reagende horários e configure datas sem atendimento ou com horários especiais.
+15. **Cancelar Agendamentos**:Permitir que o dono cancele agendamentos com o envio de notificações adequadas aos clientes.
+16. **Consultar Dados Financeiro**: Permitir que o dono acesse relatórios financeiros, detalhando o custo dos serviços que foram realizados e o valor cobrado por cada um.
+17. **Consultar os Feedbacks Forncecidos**: Permitir que o dono veja e analise os feedbacks dos clientes para identificar áreas de melhoria.
+
+### Requisitos dos Funcionários
+18. **Consultar Informações dos Pets**: Permitir que os funcionários acessem as informações dos pets cadastrados, como nome, idade, raça e o nome do dono.
+19. **Vizualizar Calendário com Agendamentos do Dia**: Permitir que os funcionários vejam os agendamentos do dia atual.
+
+## **Lista de Requisitos Não Funcionais**
+
+Os requisitos não funcionais especificam as qualidades e restrições do sistema, como desempenho, segurança e usabilidade. Abaixo, os requisitos não funcionais são classificados com o modelo URPS+.
+
+### **Usabilidade (Usability)**
+1. **Interface Instintiva**: O sistema deve possuir uma interface amigável, permitindo que clientes e funcionários usem as funcionalidades sem a necessidade de treinamento avançado.
+2. **Feedback Visual**: O sistema deve fornecer mensagens claras de erro, sucesso ou validação para todas as ações realizadas pelos usuários.
+
+### **Confiabilidade (Reliability)**
+3. **Disponibilidade**: O sistema deve ter uma taxa de disponibilidade de 99,9%, garantindo que fique em funcionamento durante a maior parte do tempo.
+4. **Recuperação de Falhas**: Em caso de falha, o sistema deve ser capaz de se recuperar e retornar ao estado funcional sem perda de dados.
+
+### **Desempenho (Performance)**
+5. **Processamento**: O sistema deve ser capaz de processar até 10 requisições simultâneas sem sofrer degradação significativa de desempenho.
+6. **Eficiência**: As funcionalidades principais (ex.: agendamento, consulta de calendário) devem ter um tempo de resposta inferior a 3 segundos.
+
+### **Suportabilidade (Supportability)**
+7. **Compatibilidade**: Deve ser acessível em dispositivos móveis e navegadores modernos, como o Google Chrome e Safari, garantindo boa experiência para todos os usuários. ???
+
+### **Requisitos de Implementação**
+8. **Linguagem de Programação**: O sistema deve ser desenvolvido utilizando Java, com o framework Spring Boot.
+9. **Banco de Dados**: O sistema deve utilizar PostgreSQL como banco de dados relacional.
+
+### **Requisitos de Interface**
+10. **Integração com Redes Sociais**: Deve permitir redirecionamentos para a rede social do pet shop, o Instagram.
\ No newline at end of file
diff --git "a/docs/Vis\303\243oProduto/Arquitetura.jpg" b/docs/assets/imgs/Arquitetura.jpg
similarity index 100%
rename from "docs/Vis\303\243oProduto/Arquitetura.jpg"
rename to docs/assets/imgs/Arquitetura.jpg
diff --git a/docs/assets/imgs/mvp.png b/docs/assets/imgs/mvp.png
new file mode 100644
index 0000000..5a1050a
Binary files /dev/null and b/docs/assets/imgs/mvp.png differ
diff --git a/docs/index.md b/docs/index.md
index a4d6241..408e50a 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -10,9 +10,9 @@
## Equipe
- | [Alexandre Júnior](https://github.com/AlexandreLJr) | [Enrico Zoratto](https://github.com/sidts) | [Gustavo Haubert](https://github.com/GustavoHaubert) | [Kaio Enzo Salgado](https://github.com/kaioenzo) | [Manoela Garcia ](https://github.com/manu-sgc) | [Pedro Henrique Fernandino](https://github.com/PedroHenrique061) |
-| :---: | :---: | :---: | :---: | :---: | :---: |
-| [
](https://github.com/AlexandreLJr) | [
](https://github.com/sidts) | [
](https://github.com/GustavoHaubert) | [
](https://github.com/kaioenzo) | [
](https://github.com/manu-sgc) | [
](https://github.com/PedroHenrique061) |
+ | [Alexandre Júnior](https://github.com/AlexandreLJr) | [Enrico Zoratto](https://github.com/sidts) | [Gustavo Haubert](https://github.com/GustavoHaubert) | [Manoela Garcia ](https://github.com/manu-sgc) | [Pedro Henrique Fernandino](https://github.com/PedroHenrique061) |
+| :---: | :---: | :---: | :---: | :---: |
+| [](https://github.com/AlexandreLJr) | [](https://github.com/sidts) | [](https://github.com/GustavoHaubert) | [](https://github.com/manu-sgc) | [](https://github.com/PedroHenrique061) |
## Histórico de Revisão
diff --git a/mkdocs.yml b/mkdocs.yml
index 31e365e..a5d47ed 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -18,11 +18,22 @@ nav:
- Visão do Produto e Projeto:
- Solução Proposta : VisãoProduto/Solucao.md
- Estratégias de Engenharia de Software : VisãoProduto/Estrategias.md
+ - Engenharia de Requisitos: VisãoProduto/EngRequisitos.md
- Cronogramas e Entregas : VisãoProduto/Cronograma.md
- Interação entre Equipe e Cliente : VisãoProduto/Interação.md
- - Arquitetura : VisãoProduto/Arquitetura.md
+ - Requisitos de Software: VisãoProduto/Requisitos.md
+ - DoR e DoD: VisãoProduto/DoRDoD.md
+ - Backlog do Produto: VisãoProduto/Backlog.md
- Lições Aprendidas:
- Unidade 1 : Unidades/Unidade1.md
+ - Unidade 2 : Unidades/Unidade2.md
+ - Fases do OpenUP:
+ - Concepção: FasesOpenUP/Concepcao.md
+ - Elaboração: FasesOpenUP/Elaboracao.md
+ - Construção: FasesOpenUP/Construcao.md
+ - Transição: FasesOpenUP/Transicao.md
- Apresentações:
- Apresentação Unidade 1 : Entregas/Entrega1.md
+ - Apresentação Unidade 2 : Entregas/Entrega2.md
+