Priorização
Versionamento
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 09/09/2020 | 0.1 | Adição da priorização | Ian Rocha |
| 09/09/2020 | 1.0 | Revisão do documento | Murilo Loiola |
Introdução
Conforme os requisitos são levantados, é necessário agregar valor a cada requisito para determinar um ponto de partida para o desenvolvimento. Para isso existem várias técnicas de priorização.
Após uma reunião com todos os integrantes do grupo, foi decidido que usaremos uma técnica bastante conhecida e que atende todas as nossas necessidades, denominada MoSCoW.
MoSCoW
O método MoSCoW é uma técnica de priorização usada para gerenciar e analisar negócios, gerenciar projetos e desenvolvimento de software com o objetivo de chegar a um ponto em comum do ponto de vista dos desenvolvedores acerca da importância que cada requisito possui no produto final.
O termo MoSCoW é um acrônimo derivado da primeira letra de quatro categorias de priorização (Must have, Should have, Could have, Would/Want/Won't have), com a junção da vogal 'o' para se tornar uma palavra pronunciável. Os 'o' estão em letra minúscula para indicar que eles não tem significado.
Must have
Os requisitos rotulados como Must have são críticos para que a entreha atual seja um sucesso. Se nenhum requisito Must have for concluído, a entrega do projeto deve ser considerada uma falha (nota: os requisitos podem ser rebaixados de Must have para categorias de menor importância, respeitando todas as partes interessadas; por exemplo, quando novos requisitos são considerados mais importantes).
Should have
Os requisitos rotulados como Should são importantes, mas não são obrigatórios para a entrega atual. Embora Should possua requisitos que podem ser tão importantes quanto Must, eles geralmente não são tão críticos quanto ao tempo ou pode haver outra maneira de satisfazer o requisito, para que ele possa ser retido até uma futura entrega.
Could have
Os requisitos rotulados como Could são desejáveis, mas não necessários, podendo melhorar a experiência do usuário ou a satisfação do cliente por um baixo custo de desenvolvimento. Estes serão normalmente incluídos se o tempo e os recursos permitirem.
Would have
Os requisitos rotulados como Would have foram acordados pelas partes interessadas como os itens menos críticos e com menor retorno de investimento, ou não apropriados naquele momento. Como resultado, não haverá requisitos não planejados no cronograma para a próxima entrega. Os requisitos não serão descartados e podem ser reconsiderados para inclusão em uma entrega posterior.