Técnicas de Engenharia de Requisitos Aplicadas

Durante o desenvolvimento do projeto TodoList, foram aplicadas diversas técnicas e boas práticas da Engenharia de Requisitos para garantir clareza, rastreabilidade e organização do backlog. As técnicas a seguir foram selecionadas para atender ao desafio técnico e orientar a construção incremental da aplicação.

1.Elicitação de Requisitos - Análise do Teste Técnico

A elicitação dos requisitos foi baseada diretamente na análise detalhada do enunciado do desafio técnico. A partir dessa análise, foi possível identificar funcionalidades obrigatórias, comportamentos esperados do sistema e restrições implícitas, que nortearam a criação do backlog inicial.

2.MoSCoW – Priorização das Funcionalidades

A técnica MoSCoW foi utilizada para categorizar as User Stories com base em sua criticidade e impacto na entrega do MVP(Requisitos Obrigatórios do teste). As tags aplicadas foram:

MUST – Funcionalidades essenciais para o funcionamento mínimo do sistema.
SHOULD – Funcionalidades importantes, mas não obrigatórias para a primeira entrega.
COULD – Funcionalidades desejáveis, que podem ser entregues em versões futuras.
WON’T – Funcionalidades fora do escopo atual.

3.DEEP – Organização do Backlog

A técnica DEEP foi aplicada para garantir que o backlog se mantenha saudável ao longo do tempo. Isso significa que os itens de backlog seguem os seguintes princípios:

D – Detailed appropriately: User Stories possuem nível de detalhamento adequado.
E – Estimated: As tarefas possuem estimativas ou tags de prioridade (ex: MUST).
E – Emergent: O backlog é evolutivo, sendo ajustado conforme o progresso.
P – Prioritized: Os itens mais importantes vêm primeiro.

4.DoR – Definition of Ready

Para garantir que uma User Story estivesse pronta para desenvolvimento, foi aplicada a Definition of Ready (DoR), baseada em critérios objetivos:

A US atende aos critérios do modelo INVEST (Independente, Negociável, Valiosa, Estimável, Pequena e Testável).
A US possui critérios de aceitação bem definidos.
A US foi discutida e compreendida por todos os envolvidos(no caso eu).

5.DoD – Definition of Done

A Definition of Done (DoD) foi utilizada para validar se uma User Story foi realmente concluída. Antes de marcar uma US como “Feita”, os seguintes pontos foram avaliados:

Todos os critérios de aceitação foram cumpridos.
As regras de negócio foram respeitadas.
Todos os testes automatizados e manuais passaram com sucesso.
A funcionalidade foi integrada e testada no sistema.