docs: adiciona seção de engenharia de requisitos (#9)

* docs: adiciona atividades ER e backlog

* docs: adiciona nova seção e plugin de imagem

* build: adiciona novos requisitos para o mkdocs

* ci: adiciona mkdocs glightbox plugin

.github/workflows/docs.yml

@@ -30,4 +30,5 @@ jobs:
             mkdocs-material-
       - run: pip install mkdocs-material 
       - run: pip install mkdocs-video
+      - run: pip install mkdocs-glightbox
       - run: mkdocs gh-deploy --force

docs/engenharia-requisitos/atividades_er.md

@@ -0,0 +1,79 @@
+## Planejamento da release
+
+### Elicitação e descoberta
+
+- **Entrevista**: Entrevistas realizadas com o cliente da Ideia Space podem ajudar a entender as necessidades específicas da startup para o desenvolvimento de uma solução de aprendizado gamificada.
+- **Brainstorming**: Sessão para gerar ideias de forma criativa e colaborativa. O foco está em identificar funcionalidades, mecânicas de gamificação e métricas de desempenho que atendam às necessidades do sistema educacional.
+
+### Análise e Consenso 
+- **Negociação**: Técnica usada para resolver conflitos entre stakeholders da Ideia Space que podem ter visões divergentes sobre os requisitos do sistema. O foco está em compreender os objetivos de cada parte e encontrar soluções que alinhem esses interesses.
+- **Product Backlog Building (PBB)**: Processo de construir e organizar o Product Backlog.
+
+### Declaração 
+- **Histórias de usuário**: Declarações simples e objetivas que descrevem funcionalidades do sistema do ponto de vista do usuário. Na Ideia Space, essas histórias ajudam a traduzir as necessidades dos stakeholders em requisitos claros e priorizáveis, representando como o software gamificado será usado em situações reais.
+- **Especificação de requisitos**: Documentação detalhada e estruturada das funcionalidades e características esperadas do sistema.
+
+### Organização e Atualização 
+- **MoSCoW**: Técnica de priorização utilizada para organizar e classificar os requisitos de um projeto com base em sua importância e urgência
+- **Timeboxing**: Definir períodos de trabalho limitados para as atividades e técnicas
+
+
+## Planejamento da Sprint
+
+### Elicitação e Descoberta
+- **Workshop de Requisitos**: Sessão colaborativa com stakeholders e membros da equipe para  entender melhor as necessidades do projeto. O objetivo é garantir que todas as partes interessadas compreendam o que será desenvolvido na sprint e alinhem os requisitos com os objetivos de negócio.
+- **Questionário**: Técnica para coletar informações de stakeholders de forma estruturada, garantindo que os requisitos sejam compreendidos de maneira clara e objetiva. A utilização de questionários ajuda a esclarecer dúvidas e refinar as histórias de usuários.
+
+### Declaração
+- **Mapeamento de Histórias de Usuários (USM)**: Técnica usada para organizar as histórias de usuários e entender a jornada do usuário com o sistema. Ajuda a priorizar e visualizar as funcionalidades mais importantes para a sprint, garantindo que estejam alinhadas com os objetivos do projeto.
+
+### Verificação e Validação
+- **Definição de Acabado (DoD)**: Estabelecimento de um conjunto de critérios que determinam quando uma história ou tarefa está completamente pronta para ser considerada como finalizada. Isso garante que a qualidade e a funcionalidade atendam aos padrões acordados antes de ser entregue.
+- **Definição de Pronto (DoR)**: Técnica para garantir que as histórias de usuário estejam suficientemente detalhadas e com todos os requisitos necessários para que a equipe de desenvolvimento possa começar a trabalhar nelas. Este processo ajuda a garantir que as histórias estejam “prontas para ser trabalhadas”.
+
+## Execução da Sprint
+
+### Representação
+- **Mockup**:  Uma representação visual estática de um sistema ou produto, criada para ilustrar sua interface de usuário (UI), layout e funcionalidades principais. É usado para ajudar stakeholders e equipes de desenvolvimento a entender e validar requisitos relacionados ao design e à usabilidade antes do início do desenvolvimento real.
+- **Prototipagem**:  Uma  representação visual estática de um sistema ou produto, criada para ilustrar sua interface de usuário (UI), layout e funcionalidades principais. É usado para ajudar stakeholders e equipes de desenvolvimento a entender e validar requisitos relacionados ao design e à usabilidade antes do início do desenvolvimento real.
+- **Modelagem de domínio**: é o processo de compreender e representar o universo de um problema ou área específica (o domínio) em termos conceituais, criando um modelo que descreve os elementos principais, suas características, comportamentos e relacionamentos. É uma prática comum na engenharia de software e no design de sistemas para alinhar o entendimento entre as partes interessadas e guiar o desenvolvimento de soluções.
+
+### Verificação e Validação
+- **Checklist de Verificação**: é usado para garantir que o produto ou sistema está sendo construído corretamente, ou seja, que o trabalho realizado atende às especificações e aos padrões definidos pelos requisitos técnicos e design.
+- **Checklist de Validação**: é usado para garantir que o produto ou sistema construído atende às necessidades e expectativas do usuário final, ou seja, que ele resolve o problema para o qual foi projetado.
+- **Definição de Acabado (DoD)**: Estabelecimento de um conjunto de critérios que determinam quando uma história ou tarefa está completamente pronta para ser considerada como finalizada. Isso garante que a qualidade e a funcionalidade atendam aos padrões acordados antes de ser entregue.
+- **Feedback**: refere-se ao processo de coleta, análise e utilização de informações fornecidas pelos stakeholders (usuários, clientes, desenvolvedores, etc.) durante o ciclo de desenvolvimento do sistema, com o objetivo de ajustar, refinar ou validar os requisitos. O feedback é fundamental para garantir que o produto final atenda às expectativas dos usuários e aos objetivos de negócio, além de ajudar a identificar e corrigir problemas e falhas no início do processo.
+
+
+## Revisão da Sprint
+
+### Elicitação e Descoberta
+- **Entrevistas com stakeholders**: Entrevistas com stakeholders nos ajudarão a entender as mudanças que ocorreram dentro e fora da organização
+Histórias e cenários: Histórias e cenários feitos com base no novo ambiente nos ajudará a identificar quais são as novas necessidades dos usuários geradas pelas mudanças.
+
+### Análise e Consenso
+
+- **Reuniões de revisão**: Durante essas reuniões, o objetivo é revisar junto ao cliente o progresso dos trabalhos realizados na sprint, verificar se os requisitos atendem às expectativas e se há algum ajuste necessário para atender as necessidades.
+
+### Verificação e Validação
+- **Refinamento de backlog**: O refinamento de backlog é uma prática essencial para manter os requisitos priorizados para serem trabalhados na próxima sprint. O uso da técnica MoSCoW será útil para ponderar os riscos e o valor que será entregue ao cliente ao ajustar o backlog, sendo feito de acordo com mudanças nas prioridades ou no contexto do projeto.
+
+## Engenharia de Requisitos e ScrumXP
+
+| **Fases do Processo**          | **Atividades ER**                     | **Prática**                                   | **Técnica**                                                                 | **Resultado Esperado**                                                                                     |
+|--------------------------------|---------------------------------------|---------------------------------------------|-----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|
+| **Planejamento da Release**    | **Elicitação e Descoberta**           | Levantamento de requisitos                 | - Entrevista<br>- Brainstorming                                              | Levantamento de requisitos funcionais e não funcionais                                                   |
+|                                | **Análise e consenso**                | Organização de requisitos                  | - Negociação<br>- PBB                                                       | Backlog do produto                                                                                       |
+|                                | **Declaração**                        | Formalização dos requisitos                | - Histórias de usuário<br>- Especificação de requisitos                      | Histórias de usuário registradas que descrevem os requisitos da release                                   |
+|                                | **Organização e Atualização**         | Organização do backlog                     | - MoSCoW<br>- Timeboxing                                                     | Requisitos priorizados com estimativas consensuais entre a equipe.                                       |
+| **Planejamento da Sprint**     | **Elicitação e descoberta**           | Refinamento do backlog                     | - Workshop de Requisitos<br>- Questionário                                   | Histórias refinadas e alinhadas com o objetivo do cliente                                                |
+|                                | **Declaração**                        | Escolha das histórias para desenvolvimento | Mapeamento de histórias de usuários (USM)                                    | Definição do conjunto de histórias que serão desenvolvidas na sprint definidas e alinhadas.               |
+|                                | **Verificação e Validação**           | Refinamento dos critérios das histórias de usuários | Definição de Acabado (DoD), Definição de Pronto (DoR)                        | Histórias com critérios de aceitação claros e alinhados com o time.                                       |
+| **Execução da Sprint**         | **Representação**                     | Alinhamento entre a equipe e o cliente quanto à visualização/representação | - Mockup<br>- Prototipagem<br>- Modelagem de Domínio                        | Reconhecimento dos requisitos na prototipagem/interface desenvolvida.                                    |
+|                                | **Verificação e Validação**           | Garantir funcionalidades completas, monitorar o progresso com ajustes necessários e manter alta qualidade de código. | - Checklist de Validação<br>- Checklist de Verificação<br>- Definição de Acabado (DoD)<br>- Feedback | Itens desenvolvidos que atendem às necessidades do cliente e aos requisitos, garantindo que os objetivos da sprint foram cumpridos e a qualidade do código mantida. |
+| **Revisão da Sprint**          | **Elicitação e Descoberta**           | Coleta de novos requisitos (se houver mudanças no ambiente). | - Entrevistas com stakeholders<br>- Histórias e Cenários                    | Backlog de produto atualizado e feedbacks quanto à usabilidade.                                          |
+|                                | **Análise e consenso**                | Alinhamento com stakeholders e análise dos critérios de aceitação. | - Reuniões de Revisão<br>- Testes manuais e automatizados                   | Assegurar a implementação correta das funcionalidades na plataforma.                                     |
+|                                | **Verificação e Validação**           | Atualizar o backlog com base nas mudanças ou novas informações. | Refinamento de Backlog (Técnica MoSCoW)                                     | Backlog com itens mais claros e ajustados às necessidades do cliente.                                    |
+| **Planejamento da Próxima Release** | *Fase que só será realizada após a entrega da release anterior* | **Análise e consenso**                    | - Análise de Risco<br>- Negociação<br>- Análise de Objetivo de Domínio       | Backlog organizado e Lista de Necessidades                                                              |
+|                                | **Verificação e Validação**           | Revisão da release anterior e alinhamento de pendências e objetivos | - Revisão em pares<br>- Feedback                                             | Revisão da release anterior                                                                              |
+|                                | **Elicitação e Descoberta**           | Levantamento dos próximos requisitos       | - Entrevista<br>- Brainstorming<br>- Análise Documental                      | Lista de RFs e RNFs                                                                                      |

docs/engenharia-requisitos/backlog.md

@@ -0,0 +1,11 @@
+## Product Backlog Building (PBB)
+
+O processo de construir e organizar o backlog escolhido foi o **PBB**.
+
+<iframe width="768" height="432" src="https://miro.com/app/embed/uXjVL6aX70g=/?pres=1&frameId=3458764610749937648&embedId=342470256869" frameborder="0" scrolling="no" allow="fullscreen; clipboard-read; clipboard-write" allowfullscreen></iframe>
+
+## Priorização de requisitos MoSCoW
+
+A planilha, em sua última alteração, pode ser acessada [aqui](https://docs.google.com/spreadsheets/d/e/2PACX-1vQL5DP-U470Z16udMEHnrMGjlRgxlKxCEnvf6jxM4X-bK0PxK98PxexC1vTWRbZsLB-G2l--wVSjE7M/pubhtml)
+
+![Planilha MosCOW](../assets/priorizacao-requisitos-planilha.png)

mkdocs.yml

@@ -11,6 +11,9 @@ nav:
       - Estratégias de Engenharia de Software: produto/estrategias.md
       - Cronograma e entregas: produto/cronograma-entregas.md
       - Interação entre equipe e cliente: produto/interacao.md
+  - Engenharia de Requisitos:
+    - Atividades e Técnicas de ER: engenharia-requisitos/atividades_er.md
+    - Backlog: engenharia-requisitos/backlog.md
   - Apresentações: apresentacoes/index.md
 
 theme:
@@ -65,3 +68,4 @@ markdown_extensions:
 
 plugins:
   - mkdocs-video
+  - glightbox

requirements.txt

@@ -1 +1,4 @@
+# MkDocs
+mkdocs-material
 mkdocs-video
+mkdocs-glightbox