MOdificação na estrutura do MKDOCS

docs/cenario_cliente/cenario.md

@@ -8,6 +8,7 @@ A empresa tida como cliente deste projeto é responsável pelo envase, engarrafa
 
 As empresas do setor tiveram um período de adaptação para se familiarizar com um novo programa de monitoramento mi microbiológico lançado recentemente. Dada a urgência dessa readequação, atualmente há poucos sistemas que se propõem a realizar o registro de informações conforme os novos moldes estabelecidos. Além disso, o uso de planilhas para o registro de dados é predominante, em função da familiaridade dos executores do programa com essa ferramenta. Atualmente, não há produtos de software disponíveis no mercado que atendam integralmente aos novos padrões de processo estabelecidos pelo programa de monitoramento ambiental.  
 
+![](../assets/diagrama.png)
 
 Figura 1: Diagrama de Ishikawa
 

docs/visao_produto_projeto/backlog_produto.md

@@ -1,13 +1,11 @@
 # BACKLOG DO PRODUTO
 
-## Definições
-
-### Backlog
+## Backlog Geral
 O Backlog do Produto é uma lista ordenada de tudo o que é necessário para o desenvolvimento de um produto. Ele serve como a única fonte de trabalho autorizada para a equipe Scrum e é constantemente atualizado pelo Product Owner para refletir as necessidades, mudanças e prioridades do produto. Os itens mais importantes e de maior valor para o cliente são posicionados no topo, enquanto os menos urgentes ficam na parte inferior.
 
 Esse backlog inclui desde funcionalidades e correções até requisitos técnicos e melhorias. Durante a evolução do projeto, os itens do backlog podem ser adicionados, modificados, ou removidos conforme o aprendizado e as condições mudam. Sua manutenção é essencial para garantir que a equipe esteja sempre alinhada com os objetivos do produto e da organização.
 
-### User Stories
+### Definição: User Stories
 Uma história de usuário é uma descrição simples e informal de uma funcionalidade do ponto de vista do usuário final. Ela é utilizada em metodologias ágeis para comunicar o que é necessário desenvolver de forma clara e objetiva, focando nos benefícios que a funcionalidade trará para o usuário. O Cartão, a Conversação e a Confirmação são os três elementos fundamentais para a estruturação de histórias de usuário no contexto de metodologias ágeis.
 
 O **Cartão** é uma descrição breve e clara da intenção da história de usuário, geralmente escrita em 2 ou 3 frases. Ele segue um formato padrão: "Como [ role ], eu quero [ atividade ] para que [ valor de negócio ]". Esse formato ajuda a identificar quem está solicitando a funcionalidade [ role ], o que será realizado [ atividade ] e por que isso é importante [ valor de negócio ].
@@ -58,35 +56,7 @@ A especificação de funcionalidades segue o framework de User Stories (Históri
 | RF-35  | LOCALIZAÇÃO DE INFORMAÇÕES        | INSERIR IMAGEM DE LOCAIS                        | Como operador ou administrador, eu quero inserir uma imagem do local de coleta para facilitar o dia a dia.                              |
 | RF-36  | LOCALIZAÇÃO DE INFORMAÇÕES        | EXCLUIR IMAGEM DE LOCAIS                        | Como operador ou administrador, eu quero excluir uma imagem para remover informações incorretas ou desatualizadas.                      |
 
-
-### Definition of Ready (DoR)
-A Definição de Preparado (DoR) é o conjunto de critérios que determina quando um item de trabalho está pronto para ser iniciado pela equipe. Ela estabelece a clareza e as informações necessárias para que a equipe possa iniciar suas atividades com eficiência. Seja em histórias do usuário ou tarefas de desenvolvimento, o DoR visa proporcionar um entendimento claro e completo do que precisa ser feito antes que o trabalho comece.
-
-#### Definition of Ready (DoR) do PBI
-Para que um item do Product Backlog Item seja candidato para entrar na esteria do processo de desenvolvimento, os seguintes elementos devem ser considerados: 
-
-- O item é independente de outros PBIs ou recursos externos? 
-- O valor do item está claramente especificado?
-- A equipe conseguiu estimar o esforço necessário?
-- O item é pequeno o suficiente para ser concluído na Sprint?
-- Os critérios de aceitação são claros e testáveis?
-- Protótipo pronto e validado pelo cliente?
-
-### Definition of Done (DoD)
-A Definição de Pronto (DoD), é uma lista de critérios que estabelece quando uma determinada tarefa ou trabalho atende aos requisitos para ser considerado pronto. Esses critérios podem abranger desde desenvolvimento e testes até revisões e aprovações, garantindo que a qualidade e integridade do produto final sejam atingidas. Por meio do DoD, as equipes de projeto podem ter uma compreensão clara do que é esperado em cada entrega, promovendo a transparência e a eficiência em todo o processo.
-
-#### Definition of Done (DoD) do PBI
-Para que um Product Backlog Item seja considerado finalizado após o processo de desenvolvimento, os seguintes elementos devem ser avaliados:
-
-- O código foi revisado e atende aos padrões?
-- Os testes foram desenvolvidos e aprovados?
-- O cliente/PO validou o item? 
-- A documentação foi atualizada?
-- A funcionalidade foi integrada ao sistema principal?
-- Os critérios de aceitação foram cumpridos?
-
-
-## Priorização do Backlog do Produto
+## Priorização do Backlog Geral
 O grupo realizou a priorização do backlog do projeto com base em três critérios principais: **valor de negócio**, **complexidade técnica** e i**ndependência de funcionalidades**.  Essa abordagem visa maximizar os resultados e otimizar o uso dos recursos disponíveis.
 
 ### Valor de negócio 
@@ -141,11 +111,9 @@ Abaixo segue a tabela de priorização conforme os pontos avaliados anteriorment
 | US-35  | 3                 | 5                    | 3             | 2        | 13           |
 | US-36  | 3                 | 5                    | 3             | 2        | 13           |
 
-### Minimum Viable Product
+## MVP do projeto Microdata 
 MVP (Minimum Viable Product, ou Produto Mínimo Viável) é uma versão inicial de um produto que contém apenas as funcionalidades essenciais para resolver o problema principal dos usuários. Seu objetivo é validar hipóteses e obter feedback do mercado de maneira rápida e econômica, antes de investir em desenvolvimento completo. O MVP permite que equipes de desenvolvimento entendam o que realmente gera valor para o cliente e ajustem o produto com base em dados reais, minimizando riscos e desperdícios.
 
-
-## MVP do projeto Microdata 
 Foi levado em consideração o quadro de priorização para a definição do MVP do projeto. As hisorias de Usuário que tiveram o somatório de pontos de avaliação igual ou superior a 14 (>=14) são candidatas para o MVP do projeto; as hisorias com somatório inferior a 14 (<14) permanecem como backlog do projeto e poderão ser desenvolvidas em ocasiões futuras. São as histórias do MVP do projeto Microdata:
 
 | INDEX  | US                                                                                                      |

docs/visao_produto_projeto/dor_dod.md

@@ -0,0 +1,35 @@
+# DoR e DoD
+## Definition of Ready (DoR)
+A Definição de Preparado (DoR) é o conjunto de critérios que determina quando um item de trabalho está pronto para ser iniciado pela equipe. Ela estabelece a clareza e as informações necessárias para que a equipe possa iniciar suas atividades com eficiência. Seja em histórias do usuário ou tarefas de desenvolvimento, o DoR visa proporcionar um entendimento claro e completo do que precisa ser feito antes que o trabalho comece.
+
+### Definition of Ready (DoR) do PBI
+Para que um item do Product Backlog Item seja candidato para entrar na esteria do processo de desenvolvimento, os seguintes elementos devem ser considerados: 
+
+- O item é independente de outros PBIs ou recursos externos? 
+- O valor do item está claramente especificado?
+- A equipe conseguiu estimar o esforço necessário?
+- O item é pequeno o suficiente para ser concluído na Sprint?
+- Os critérios de aceitação são claros e testáveis?
+- Protótipo pronto e validado pelo cliente?
+
+## Definition of Done (DoD)
+A Definição de Pronto (DoD), é uma lista de critérios que estabelece quando uma determinada tarefa ou trabalho atende aos requisitos para ser considerado pronto. Esses critérios podem abranger desde desenvolvimento e testes até revisões e aprovações, garantindo que a qualidade e integridade do produto final sejam atingidas. Por meio do DoD, as equipes de projeto podem ter uma compreensão clara do que é esperado em cada entrega, promovendo a transparência e a eficiência em todo o processo.
+
+### Definition of Done (DoD) do PBI
+Para que um Product Backlog Item seja considerado finalizado após o processo de desenvolvimento, os seguintes elementos devem ser avaliados:
+
+- O código foi revisado e atende aos padrões?
+- Os testes foram desenvolvidos e aprovados?
+- O cliente/PO validou o item? 
+- A documentação foi atualizada?
+- A funcionalidade foi integrada ao sistema principal?
+- Os critérios de aceitação foram cumpridos?
+
+## REFERÊNCIAS
+> SCHWABER, Ken; SUTHERLAND, Jeff. The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. 2020. Disponível em: https://scrumguides.org. Acesso em: 15 dez. 2024.
+
+##  Histórico de Versão
+
+| **Data** | **Versão** | **Descrição** | **Autor** |
+| :--------: | :--------: | :--------:  | :--------: | 
+|      15/11/2024      |      1.0      |      Criação do Documento      |     Breno Fernandes, Breno Lucena e Guilherme Storch    |

docs/visao_produto_projeto/engenharia_requisitos.md

@@ -1,13 +1,15 @@
-# Estratégias de Engenharia de Requisitos
+# ENGENHARIA DE REQUISITOS
 
-## 1. Elicitação e Descoberta
+## Atividades e técnicas de ER
+
+### 1. Elicitação e Descoberta
 **Análise Documental**: Utilizar para revisar documentos existentes que fornecem informações sobre o domínio do problema, requisitos anteriores ou projetos similares, a fim de identificar necessidades e soluções já propostas.
 
 **Entrevista**: Realizar para obter informações diretamente dos stakeholders, identificando necessidades, expectativas e limitações iniciais para o produto, com perguntas estruturadas e semi-estruturadas para capturar dados relevantes.
 
 ---
 
-## 2. Análise e Consenso
+### 2. Análise e Consenso
 **Brainstorming**: Facilitar a geração rápida de ideias entre os stakeholders, promovendo a identificação de possíveis requisitos e soluções inovadoras em um ambiente colaborativo.
 
 **Priorização**: Utilizar para classificar os requisitos conforme sua importância e urgência, garantindo que as funcionalidades mais críticas sejam tratadas primeiro.
@@ -22,7 +24,7 @@
 
 ---
 
-## 3. Declaração
+### 3. Declaração de Requisitos
 **Priorização**: Aplicar para garantir que os requisitos sejam organizados de acordo com seu impacto e valor para o projeto, permitindo que a equipe foque nas necessidades mais importantes.
 
 **User Stories**: Representar cada requisito como uma história do usuário, descrevendo o papel, a necessidade e o benefício esperado, facilitando a comunicação clara entre as partes interessadas.
@@ -31,7 +33,7 @@
 
 ---
 
-## 4. Representação
+### 4. Representação de Requisitos
 **User Stories**: Utilizar para descrever os requisitos do sistema de forma simples e compreensível, focando nas necessidades e benefícios esperados dos usuários finais.
 
 **Cenários**: Aplicar para detalhar as histórias do usuário em situações específicas, descrevendo como o sistema deve se comportar em diferentes contextos de uso, ajudando a esclarecer os requisitos e validar as funcionalidades.
@@ -41,21 +43,21 @@
 
 ---
 
-## 5. Verificação e Validação
+### 5. Verificação e Validação de Requisitos
 **Revisão por Pares e Checklists**: Utilizar para verificar se os requisitos estão completos, consistentes e livres de erros, com a colaboração de membros da equipe para garantir a qualidade.
 
 **Walkthrough**: Conduzir sessões de walkthrough para apresentar os requisitos e protótipos aos stakeholders, recebendo feedback para ajustes antes do desenvolvimento.
 
 ---
 
-## 6. Organização e Atualização
+### 6. Organização e Atualização de Requisitos
 **Revisões de Lista de Requisitos**: Realizar para manter a lista de requisitos atualizada e garantir que todos os requisitos foram revisados e aprovados antes da implementação.
 
 **Grooming do Backlog**: Realizar sessões de grooming para revisar, refinar e priorizar os itens no backlog, garantindo que ele esteja alinhado com os objetivos do projeto e as expectativas dos stakeholders.
 
 **Reunião de Encerramento**: Conduzir uma reunião final para revisar o trabalho realizado, garantir que todos os requisitos foram atendidos e fechar oficialmente a fase de requisitos do projeto.
 
-### Quadro das Atividades da Engenharia de Requisitos no RAD
+## ENgenharia de Requisitos e o RAD
 
 <table border="1" cellspacing="0" cellpadding="5">
   <thead>

docs/visao_produto_projeto/requisitos_software.md

@@ -1,47 +1,47 @@
-#Requisitos Funcionais
-
+# REQUISITOS DE SOFTWARE
+## Lista de Requisitos Funcionais
 Requisitos funcionais descrevem as funcionalidades que um sistema deve oferecer para atender às necessidades dos usuários e alcançar os objetivos do projeto. Eles especificam o que o sistema deve fazer, detalhando os serviços, ações ou processos que ele deve executar para possibilitar a realização das tarefas desejadas. Esses requisitos estão diretamente relacionados ao comportamento do sistema, incluindo sua interação com os usuários e outros sistemas, e são essenciais para definir o escopo do projeto e orientar o desenvolvimento.
 
 Os requisitos funcionais do projeto MicroData são, por épico:
-## Acesso E Login
+### Acesso E Login
 - **Rf-01**: Cadastrar Usuário  
 - **Rf-02**: Logar Usuário  
 - **Rf-03**: Visualizar Usuário  
 - **Rf-04**: Editar Usuário  
 - **Rf-05**: Desativar Usuário  
 - **Rf-06**: Recuperar Senha De Usuário  
 
-## Microorganismos
+### Microorganismos
 - **Rf-07**: Cadastrar Microorganismos Observados  
 - **Rf-08**: Listar Microorganismos Observados  
 - **Rf-09**: Editar Microorganismos Observados  
 - **Rf-10**: Desativar Microorganismos Observados  
 - **Rf-11**: Inserir Níveis De Alerta Da Contagem De Microorganismos  
 - **Rf-12**: Buscar Microorganismos Observados  
 
-## Pontos (Locais) Avaliados
+### Pontos (Locais) Avaliados
 - **Rf-13**: Cadastrar Locais De Coleta Avaliados  
 - **Rf-14**: Listar Locais De Coleta Avaliados  
 - **Rf-15**: Editar Locais De Coleta Avaliados  
 - **Rf-16**: Desativar Locais De Coleta Avaliados  
 - **Rf-17**: Buscar Locais De Coleta Avaliados  
 
-## Resultados Do Monitoramento
+### Resultados Do Monitoramento
 - **Rf-18**: Adicionar A Contagem De Microorganismos  
 - **Rf-19**: Listar A Contagem De Microorganismos  
 - **Rf-20**: Editar O Registro De Contagem De Microorganismos  
 - **Rf-21**: Inserir Ações Corretivas De Resultados Acima Do Limite De Contagem Estabelecido  
 - **Rf-22**: Filtrar Um Resultado De Coleta Microbiológica  
 
-## Dashboard
+### Dashboard
 - **Rf-23**: Visualizar Resultados Da Coleta Dos Pontos No Dashboard  
 - **Rf-24**: Visualizar Pontos Acima Do Limite De Contagem No Dashboard  
 - **Rf-25**: Visualizar Resultados Em Função Do Nível De Alerta No Dashboard  
 - **Rf-26**: Filtrar Resultados Por Microorganismo Observado  
 - **Rf-27**: Filtrar Resultados Por Local De Coleta  
 - **Rf-28**: Filtrar Resultados Por Período De Tempo Estudado  
 
-## Localização de Informações e Rastreabilidade
+### Localização de Informações e Rastreabilidade
 - **Rf-29**: Inserir A Planta Baixa Do Processo  
 - **Rf-30**: Excluir A Planta Baixa Cadastrada  
 - **Rf-31**: Delimitar Os Locais De Coleta Avaliados Na Planta Baixa Da Área  
@@ -51,7 +51,7 @@ Os requisitos funcionais do projeto MicroData são, por épico:
 - **Rf-35**: Inserir A Imagem Do Locais De Coleta Cadastrado  
 - **Rf-36**: Excluir A Imagem Do Locais De Coleta Cadastrado   
 
-#Requisitos Não-Funcionais
+## Lista de Requisitos Não-Funcionais
 
 Os requisitos não funcionais referem-se às qualidades que o sistema deve apresentar, enfatizando seu comportamento em vez das funcionalidades específicas. Estruturados segundo o modelo URPS+, esses requisitos englobam categorias como Usabilidade, Confiabilidade, Desempenho e Suportabilidade, o que ajuda na análise e na priorização das características que afetam a qualidade do software. Assim, garantem que o sistema esteja alinhado com os padrões desejados por clientes e usuários.
 

docs/visao_produto_projeto/visao_do_produto.md

@@ -19,10 +19,6 @@ O problema enfrentado pelo setor responsável pela garantia da Qualidade é a di
 **Causa do Problema**  
 A causa do problema é a falta de clareza das informações de monitoramento microbiológico.
 
-![](../assets/diagrama.png)
-
-Figura 1: Diagrama de Ishikawa.
-
 ## Objetivos do Produto
 
 **Objetivo Principal: Centralizar os dados de monitoramento microbiológico**
@@ -93,9 +89,9 @@ Em relação à viabilidade de mercado: é alta, pois o sistema, ao atender às
 
 ## Impacto da Solução 
 
-A implementação para o monitoramento microbiológico do LAQ traz diversos benefícios esperados, entre os quais se destacam a centralização dos dados em uma plataforma digital segura e a facilidade de acesso a análises em tempo real sobre a qualidade ambiental da produção. Isso permitirá à equipe operacional monitorar com precisão os dados microbiológicos e identificar rapidamente áreas que precisam de atenção, minimizando riscos de não conformidade nas auditorias. Além disso, a visualização simplificada das informações será uma ferramenta fundamental para que o LAQ tome decisões rápidas e informadas, reforçando a segurança e a consistência do processo de produção. 
+A implementação para o monitoramento microbiológico do Laboratório traz diversos benefícios esperados, entre os quais se destacam a centralização dos dados em uma plataforma digital segura e a facilidade de acesso a análises em tempo real sobre a qualidade ambiental da produção. Isso permitirá à equipe operacional monitorar com precisão os dados microbiológicos e identificar rapidamente áreas que precisam de atenção, minimizando riscos de não conformidade nas auditorias. Além disso, a visualização simplificada das informações será uma ferramenta fundamental para que o LAQ tome decisões rápidas e informadas, reforçando a segurança e a consistência do processo de produção. 
 
-O impacto no negócio da indústria de refrigerantes será significativo, pois a nova solução tornará o processo de monitoramento mais eficiente e menos suscetível a erros manuais, reduzindo o tempo e o esforço investido nas atividades de controle e geração de relatórios. Com um sistema mais alinhado às normas de auditoria da indústria de refrigerantes LATAM, o LAQ se tornará ainda mais ágil e preparado para responder às demandas de auditorias internas e externas, mantendo um elevado padrão de qualidade. Em longo prazo, esse ganho de eficiência e precisão fortalecerá a imagem da indústria de refrigerantes como uma parceira comprometida com a qualidade e a conformidade, posicionando-a de maneira competitiva e alinhada com as melhores práticas do mercado. 
+O impacto no negócio da indústria será significativo, pois a nova solução tornará o processo de monitoramento mais eficiente e menos suscetível a erros manuais, reduzindo o tempo e o esforço investido nas atividades de controle e geração de relatórios. Com um sistema mais alinhado às normas de auditoria,a indústria se tornará ainda mais ágil e preparado para responder às demandas de auditorias internas e externas, mantendo um elevado padrão de qualidade. Em longo prazo, esse ganho de eficiência e precisão fortalecerá a imagem da empresa como uma parceira comprometida com a qualidade e a conformidade, posicionando-a de maneira competitiva e alinhada com as melhores práticas do mercado. 
 
 
 ##  Histórico de Versão