diff --git a/docs/engenharia-requisitos.md b/docs/engenharia-requisitos.md new file mode 100644 index 0000000..222b54c --- /dev/null +++ b/docs/engenharia-requisitos.md @@ -0,0 +1,67 @@ +## Atividades de ER e suas técnicas + +### Planejamento Inicial + +#### Elicitação e Descoberta +- **Lean Inception**: A técnica Lean Inception será utilizada para alinhar o time e os stakeholders sobre a visão inicial do produto. Será realizada uma série de workshops colaborativos com o objetivo de identificar os principais requisitos iniciais e criar um backlog do produto. O resultado esperado é um backlog do produto com itens priorizados e prontos para iniciar a primeira sprint. + +### Planejamento da Sprint + +#### Análise e Consenso +- **PBB**: Essa técnica será empregada para declarar e organizar as User Stories (US). O time irá decompor os requisitos em histórias menores, claras e com critérios de aceitação definidos. As histórias serão organizadas no backlog do produto e da sprint. +- **MoSCoW**: Será utilizada para priorizar os requisitos, classificando-os como "Must Have" (essenciais), "Should Have" (importantes), "Could Have" (desejáveis) e "Won't Have" (não serão implementados agora). Isso garante que o time trabalhe nas funcionalidades mais importantes primeiro. +- **DEEP**: A aplicação do conceito DEEP (Detailed, Emergent, Estimated, Prioritized) assegurará que o backlog esteja sempre detalhado, evoluindo conforme as necessidades do projeto, estimado em termos de esforço e priorizado para maximizar o valor. Essa técnica será aplicada em conjunto com a Lean Inception na etapa de priorização dos requisitos: *Revisão Técnica e de Negócio.* +- **DoR**: Será utilizada para definir os critérios mínimos que uma User Story deve atender para estar pronta para entrar em desenvolvimento. Isso inclui clareza dos critérios de aceitação e entendimento comum entre os membros do time. + +#### Elicitação e Descoberta +- **Entrevistas com Stakeholders**: As entrevistas serão conduzidas com os stakeholders para coletar informações detalhadas sobre as expectativas e necessidades do produto. Essa técnica permitirá identificar novas funcionalidades e ajustes necessários no backlog do produto. + +#### Declaração e Organização +- **PBB**: Durante esta etapa, as User Stories serão declaradas e organizadas de forma estruturada, utilizando o modelo de Product Backlog Building. Isso garante que o backlog esteja claro e preparado para as sprints futuras. +- **Pontos por Histórias**: As histórias serão pontuadas com base em critérios de esforço ou complexidade. Isso ajudará na priorização e na organização eficiente do backlog, otimizando o planejamento das sprints. + + +### Execução da Sprint + +#### Verificação +- **DoD**: Durante a execução da sprint, as User Stories finalizadas serão verificadas para garantir que atendem aos critérios do DoD. Isso inclui validação técnica e funcional. + +#### Organização e Atualização +- **PBB**: Durante a sprint, o backlog será continuamente atualizado no modelo PBB, refletindo o progresso e garantindo que o planejamento esteja sempre alinhado com as entregas. + +### Revisão da Sprint + +#### Declaração +- **PBB**: Durante a revisão, o progresso das User Stories será apresentado ao Product Owner, ajustando os itens do backlog conforme feedbacks recebidos. + +#### Validação +- **Coleta de Feedback**: Os stakeholders fornecerão feedbacks a partir da demonstração do produto. Isso será essencial para validar os resultados e ajustar as expectativas para as próximas iterações. + +### Retrospectiva + +#### Organização e Atualização +- **PBB**: O backlog será ajustado após a coleta de feedbacks para refletir os novos critérios de aceitação. +- **Pontos por Histórias**: As histórias serão reavaliadas e reorganizadas para a próxima iteração, garantindo que a priorização esteja alinhada com os objetivos do produto. + + +## Tabela + +| Planejamento Inicial (ocorrerá só no começo do projeto) | Elicitação e Descoberta | Levantamento de requisitos iniciais | Lean Inception | Possui o backlog do produto incial para começar a primeira sprint | +|:-------------------------------------------------------:|---------------------------|----------------------------------------------------------------------------------------------------------|------------------------------|--------------------------------------------------------------------------------------------------------------------------| +| Planejamento da Sprint | Análise e Consenso | Priorização de requisitos definindo os problemas e expectativas | PBB, MoSCoW, DEEP, DoR | Backlog da sprint definido e ajustado para interação atual | +| | Elicitação e Descoberta | Realizar uma serie de perguntas para o stakeholder afim de identificar novas funcionalidades | Entrevistas com stakeholders | Obter se necessário, novos requisitos para o backlog do produto | +| | Declaração e Organização | Declarar as US e organizá-las dentro do modelo de PBB | PBB, Pontos por Histórias | User stories com critérios de aceitação claros e objetivos bem definidos e organizados no backlog do produto e da sprint | +| Execução da Sprint | Verificação | Verificar se as histórias finalizadas atendem ao DoD | DoD | Verificação se os requisitos atendem aos critérios de aceitação | +| | Organização e Atualização | Atualizar as histórias finalizadas no PBB | PBB | Backlog da sprint atualizado continuamente com o decorrer da sprint | +| Revisão da Sprint | Declaração | Mostrar o progresso das histórias de usuários finalizadas pela PBB | PBB | Ajustar os user stories conforme feedback do P.O. | +| | Validação | Coletar informações do stakehorlder a partir da apresnetação do produto da sprint | Coleta de Feedback | Validação com o P.O. dos resultados da Execução da Sprint | +| Retrospectiva | Organização e Atualização | Depois da coleta de feedbacks ajustar o PBB com os seus devidios critérios de DoR e Pontos por Histórias | PBB, Pontos por Histórias | Organizar os requisitos para a próxima iteração | + + +
+ +| Versão | Descrição | Autor | Data | +| ------ | ------------------------------ | ---------------------------------------------- | ---------- | +| 0.1 | Criação da engenhria de requisitos | [Bruno Bragança](http://github.com/BrunoBReis) | 12/12/2024 | + +
\ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index 40a9ed1..a40a376 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -129,6 +129,7 @@ nav: - Cenário Atual: cenario-atual.md - Solução Proposta: solucao-proposta.md - Estratégias de Engenharia de Software: estrategias-ESW.md + - Engenharia de Requisitos: engenharia-requisitos.md - Cronograma de Entregas: cronograma-entregas.md - Interação Entre Equipe e Cliente: interacao-equipe-cliente.md - Lições Aprendidas: licoes-aprendidas.md