Merge branch 'mainDoc' of https://github.com/mdsreq-fga-unb/2024.2-T0…

…3-CafeDoSitio into mainDoc

docs/sections/2-docPage/3-estrategiasEngSoftware.md

@@ -39,7 +39,7 @@ Fonte: Elaborado pelos autores (2024)
 
 Conforme explicitado na figura 1, o processo de desenvolvimento de software mais indicado para o projeto é o Scrum/XP, uma combinação do Extreme Programming (XP) com o framework de gestão de projetos Scrum. Tanto Scrum, quanto XP foram desenvolvidos no contexto de abordagem ágil de desenvolvimento de software e ciclo de vida do produto iterativo e incremental.
 
-O diferencial do Scrum/XP para o Unified Process na escolha através do framework já mencionado, foi a não existência de requisitos de alta confiabilidade. Por outro lado, a escolha do Scrum/XP já era desejada pelo time de desenvolvimento devido a experiências anteriores bem sucedidas com o processo.
+O diferencial do Scrum/XP para o FDD na escolha através do framework, foi a flexibilidade de requisitos. Por outro lado, a escolha do Scrum/XP já era desejada pelo time de desenvolvimento devido a experiências anteriores bem sucedidas com o processo.
 
 ---
 ####Referências:

docs/sections/2-docPage/4-engenhariaRequisitos.md

@@ -30,13 +30,6 @@
 
 **Critérios de aceitação:** São definidos critérios de aceitação, ou seja, é acordado junto com os stakeholders do projeto e o Project Owner o que uma User Story precisa ter para ser aceita. Sendo isso feito para que ambas as partes, equipe de desenvolvimento e stakeholders, tenham compreensão do que determinada funcionalidade ou item precisa ter para ser considerada concluída.
 
-
-**Definition of Ready (D.O.R.):** É usado um conjunto de critérios que visam qualificar quando uma User Story está pronta para ser trabalhada. Garantindo que a equipe de desenvolvimento tenha informações claras necessárias para começar a implementar a funcionalidade.
-
-
-**Definition of Done (D.O.D.):** É também utilizado um conjunto de critérios que visam descrever o que determinada funcionalidade precisa ter para ser considerada concluída e finalizada, testada e poder ser entregue para o cliente.
-
-
 **Debates e incorporação de Feedback:** A equipe de desenvolvimento apresenta o que foi desenvolvido. Ao receber o feedback do cliente acerca da funcionalidade desenvolvida a equipe faz a incorporação desse feedback à funcionalidade.
 
 
@@ -66,11 +59,7 @@ Antes da validação com o cliente, a equipe realiza reuniões internas para rev
 
 ### 4.1.6 Organização e Atualização de Requisitos
 
-**Product Backlog Building (PBB):** Essa técnica organiza os requisitos em um formato hierárquico, desde os objetivos de negócio até as histórias de usuário, ajudando a manter o backlog atualizado, alinhado às necessidades dos stakeholders e adaptável ao longo do desenvolvimento.  As etapas incluem:  
-1. **Definir os objetivos de negócio**: Identificar as metas que o produto deve alcançar.  
-2. **Identificar funcionalidades**: Mapear as principais funcionalidades para atender aos objetivos.  
-3. **Criar histórias de usuário**: Detalhar as funcionalidades em partes menores, descritivas e acionáveis.  
-4. **Priorizar o backlog**: Organizar os itens para maximizar valor e minimizar riscos.  
+A organização foi feita com base no Lean Inception. Utilizando a fórmula **Prioridade = (4 * Valor_Agregado) - Esforço**
 
 ## 4.2 Engenharia de Requisitos e o Scrum/XP
 

docs/sections/2-docPage/9-backlogDeProduto.md

@@ -83,7 +83,7 @@ Em outras palavras, caso o nível de esforço seja nível 1, por exemplo, isto s
     - **2:** Agrega valor médio ao produto, contribuindo moderadamente para a satisfação dos usuários ou objetivos do negócio.
     - **3:** Agrega alto valor, sendo essencial para o sucesso do produto e trazendo impacto significativo para os usuários ou para o negócio.
 
-Para calcular a **prioridade** das funcionalidades com base nos três níveis de avaliação (Esforço, Valor Agregado e UX), iremos utilizar uma fórmula que combine os pesos de cada critério. O objetivo é priorizar funcionalidades que agreguem mais valor e ofereçam uma boa experiência ao usuário, mas com menor esforço.
+Para calcular a **prioridade** das funcionalidades com base nos três níveis de avaliação (Esforço, Valor Agregado), iremos utilizar uma fórmula que combine os pesos de cada critério. O objetivo é priorizar funcionalidades que agreguem mais valor e ofereçam uma boa experiência ao usuário, mas com menor esforço.
 
 **Prioridade = (4 * Valor_Agregado) - Esforço**
 
@@ -129,13 +129,12 @@ RQNF06 | 3                       | 1                | 11
 
 ## 9.3 - MVP
 
-Decidido durante a produção do Workshop Lean Inception, foi estabelecido o MVP do produto de software da Família do Sítio e a sua versão de incremento baseando-se na definição de 3 categorias, como dito na seção anterior:
+Decidido durante a produção do Workshop Lean Inception, foi estabelecido o MVP do produto de software da Família do Sítio e a sua versão de incremento baseando-se na definição de 2 categorias, como dito na seção anterior:
 
 - Esforço de Execução;
 - Valor Agregado;
-- Impacto na experiência do Usuário:
 
-Com esta técnica, foi possível elencar as funcionalidades de maior valor agregado e impacto na experiência do usuário para as primeiras produções feita pelo time. Dessa forma, as funcionalidades **que estão em MVP**, são:
+Com esta técnica, foi possível elencar as funcionalidades de maior valor agregado para as primeiras produções feita pelo time. Dessa forma, as funcionalidades **que estão em MVP**, são:
 
 ### 9.3.1 - Requisitos Funcionais