Merge pull request #90 from mdsreq-fga-unb/docs/topico4.2

[DOC]: Realizar o tópico 4.2 da Documentação no GitPages

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

@@ -0,0 +1,29 @@
+# 4. Engenharia de Requisitos
+
+Baseando-se na estratégia de desenvolvimento de software selecionado, mencionado no tópico 3 e consultando os códigos das User Stories da seção [Visão do Backlog](../4-sprints/VisaoGeralBacklog.md), o cronograma preliminar do projeto pode ser visualizada logo abaixo:
+
+Fases do Processo           | Atividades ER             | Prática                    | Técnica                                                        | Resultado Esperado
+--------------------------- | ------------------------- | -------------------------- | -------------------------------------------------------------- | ----------------------------
+**Planejamento de Release** | Elicitação e Descoberta   | Elicitação de Requisitos   | Workshop Lean Inception, Brainstorming, Reuniões com o cliente | Identificação de requisitos presentes dentro do projeto
+                            | Análise e Consenso        | Priorização dos Requisitos | Priorização via Workshop Lean Inception | Definição do valor técnico valor agregado e do impacto na experiência do usuário
+                            | Declaração                | Registro dos Requisitos | Épicos e User Stories | Histórias de usuário que descrevem as funcionalidades presentes no projeto
+                            | Validação e Verificação   | Validação dos requisitos e prioridade dos itens no backlog | Workshop Lean Inception com PBB | Requisitos e prioridades validadas para o início do desenvolvimento
+                            | Organização e Atualização | Organização dos requisitos  | Product Backlog Building (PBB) | Requisitos organizados em um backlog para agregar valor ao cliente o mais breve possível
+**Sprint Planning**         | Elicitação e Descoberta   | Refinamento dos Requisitos | User Stories, Entrevistas | Detalhamento dos requisitos à nível funcional e com a devida clareza para a sprint
+                            | Análise e Consenso        | Mensurar a viabilidade da implementação  | Análise de Risco/Viabilidade | Alinhamento de expectativas para a entrega e alocação adequada de membros para o desenvolvimento do requisito
+                            | Declaração                | "Definição de Critérios de Aceitação" | Definição dos critérios de aceitação, Definition of Ready (DoR) e Definition of Done (DoD) | Funcionalidades com critérios de conclusão bem estabelecidas e com os critérios de inicialização esclarecidas
+                            | Verificação e Validação    | Verificação dos requisitos da sprint | DoR | Equipe segura para iniciar o desenvolvimento
+                            | Organização e Descoberta  | Organização das funcionalidades em andamento ou acrescentadas para a sprint e backlog | Backlog de Requisitos | Sprint organizada com as funcionalidades a serem desenvolvidas e backlog atualizado em casos de incrementos
+**Execução da Sprint**      | Representação             | Desenvolvimento de Protótipos | Prototipagem em Alta Fidelidade | Os protótipos validados auxiliam a equipe a desenvolver a funcionalidade corretamente e evitar o retrabalho 
+                            | Verificação e Validação    | Validação dos protótipos | Critérios de aceitação, feedback do cliente, DoD, DoR | Confirmação de que os requisitos atendem aos critérios definidos, DoR, DoD
+                            | Organização e Atualização | Revisão do Backlog | Fazer uma revisão de como está o Backlog da Sprint | Backlog em dia com o andamento da Sprint
+**Sprint Review**           | Declaração                | Atualização das Histórias de usuário | Debates ao receber feedback do cliente e incorporação desse feedback | Alinhamento do que está sendo desenvolvido com o feedback dos clientes
+                            | Verificação e Validação   | Demonstração ao Cliente do que foi realizado durante a Sprint | Reuniões, Feedbacks | Funcionalidades verificadas pelo feedback dos clientes
+                            | Organização e Atualização | Organização das funcionalidades finalizadas ou debitadas da sprint | Backlog de Requisitos | Backlog atualizado com as funcionalidades atrasadas e implementadas 
+
+---
+## Histórico de Versão
+Data     | Versão | Descrição | Autor | Revisores 
+-------- | ------ | --------- | ----- | ---------
+02/12/24 | 1.0 | Criação do Documento e Adição do Tópico 4 | Daniel Rodrigues | Manuella Magalhães
+03/12/24 | 1.1 | Finalização do Documento | João Pedro | Manuella Magalhães

docs/sections/2-docPage/4-cronogramaEntregas.md → docs/sections/2-docPage/5-cronogramaEntregas.md

@@ -1,4 +1,4 @@
-# 4. Cronograma e Entregas
+# 5. Cronograma e Entregas
 
 Baseando-se na estratégia de desenvolvimento de software selecionado, mencionado no tópico 3 e consultando os códigos das User Stories da seção [Visão do Backlog](../4-sprints/VisaoGeralBacklog.md), o cronograma preliminar do projeto pode ser visualizada logo abaixo:
 

docs/sections/2-docPage/5-interacaoEquipeCliente.md → docs/sections/2-docPage/6-interacaoEquipeCliente.md

@@ -1,6 +1,6 @@
-# 5. Interação entre Equipe e Cliente
+# 6. Interação entre Equipe e Cliente
 
-## 5.1 - Composição da Equipe
+## 6.1 - Composição da Equipe
 
 | Papel     | Descrição      | Responsável       | Participantes       |
 |:--------------:|:--------------:|:--------------:|:--------------:|
@@ -10,7 +10,7 @@
 | Desenvolvedor Backend  | Desenvolve a lógica do servidor, gerencia banco de dados e integrações.   | Daniel Rodrigues    | Arthur, Marcella    |
 | Analista de Requisitos |  Identifica, documenta e gerencia as necessidades e expectativas do cliente. | Ana Carolina | Arthur, Daniel, João, Manuella, Marcella |
 
-## 5.2 Comunicação
+## 6.2 Comunicação
 
 ### > Ferramentas de Comunicação:
 
@@ -32,7 +32,7 @@
 - **Reunião de Validação (a cada 2 Semanas):** As reuniões com a presença dos Stakeholders validando as funcionalidades por meio do Deploy ocorrerão a cada 15 dias, ou seja, 2 semanas com o time de desenvolvimento. Esse modelo foi adotado para se adaptar à agendas dos stakeholders, uma vez que não conseguem se encontrar com o time em um intervalo menor semanal por conta das demandas da empresa.
 - **Interações Adicionais por WhatsApp e Trello:**  Outras validações ocorrerão assincronamente via WhatsApp, para o aviso inicial de uma nova demanda, e via plataforma Trello, para documentar e estabelecer o prazo da demanda, com os stakeholders. Essa interação surgiu para compensar as sprints que não contarão com a presença dos Stakeholders para as validações.
 
-## 5.3 Processo de Validação
+## 6.3 Processo de Validação
 
 1. As funcionalidades da Sprint passarão pela checagem de Definition of Ready (DoR), que irá verificar a escrita correta da história de usuário, se há documentação e se foi declarado junto ao cliente os critérios de aceitação.
 

mkdocs.yml

@@ -9,9 +9,10 @@ nav:
     - Cenário Atual do Cliente e Negócio: sections/2-docPage/1-cenarioAtual.md
     - Solução Proposta: sections/2-docPage/2-solucaoProposta.md
     - Estratégias de Engenharia de Software: sections/2-docPage/3-estrategiasEngSoftware.md
-    - Cronograma e Entregas: sections/2-docPage/4-cronogramaEntregas.md
-    - Interação entre Equipe e Cliente: sections/2-docPage/5-interacaoEquipeCliente.md
-    - Lições Aprendidas: sections/2-docPage/6-LicoesAprendidas.md
+    - Engenharia de Requisitos: sections/2-docPage/4-engenhariaRequisitos.md
+    - Cronograma e Entregas: sections/2-docPage/5-cronogramaEntregas.md
+    - Interação entre Equipe e Cliente: sections/2-docPage/6-interacaoEquipeCliente.md
+    - Lições Aprendidas: sections/2-docPage/10-LicoesAprendidas.md
   - Entregas:
     - Unidade 1: sections/5-entregas/Unidade1.md
   - Ciclos e Backlog: