MoScoW
Introdução
O método de priorização de MoSCoW é uma técnica utilizada em gerenciamento de projetos para classificar os requisitos do projeto em ordem de prioridade. Os requisitos foram classificados de acordo com sua importância e relevância para o sucesso do projeto Simplenote.
-
Must Have: Esses são os requisitos ou funcionalidades essenciais e cruciais para o sucesso do projeto. Se qualquer um desses itens não for atendido, o projeto não será considerado bem-sucedido.
-
Should Have: Esses requisitos ou funcionalidades são importantes, mas não são essenciais como os "Must Have". Eles são considerados valiosos e adicionam valor ao projeto, mas o projeto ainda pode ser considerado concluído se alguns deles não forem atendidos.
-
Could Have: Esses requisitos ou funcionalidades são desejáveis, mas não são necessários para o sucesso do projeto. Se houver tempo e recursos disponíveis após a conclusão dos itens "Must Have" e "Should Have", esses itens podem ser considerados.
-
Won't Have (Não Terá): Também conhecido como "Would Have", esses são os requisitos ou funcionalidades que foram decididos que não serão incluídos no projeto atual. Isso pode ser devido a restrições de tempo, recursos ou prioridades.
Legenda
- RF: Requisito funcional
- RNF: Requisito não funcional
Must Have
| Tipo | Requisito | Elicitação |
|---|---|---|
| RF01 | O usúario deve poder visualizar dados de Potência Acumulada do Brasil | Entrevista |
| RF02 | O usúario deve poder visualizar os dados de Balanço de Potência do Brasil | Entrevista |
| RF03 | O usúario deve poder visualizar os dados de Emissões Equivalentes de CO2 do Brasil | Storytelling |
| RF04 | O usúario deve poder visualizar os dados de Consumo de Gás Natural do Brasil | Entrevista |
| RF05 | O usúario deve poder visualizar os dados de Custo de Operação do Brasil | Entrevista |
| RF06 | O usúario deve poder filtrar os dados atualizados de empregabilidade por fonte/tecnologia | Storytelling |
| RNF07 | O sistema deve ser simples e intuitivo | Storytelling |
| RF08 | O usuário deve poder sincronizar dados | Entrevista |
| RF09 | O usuário deve poder filtrar os dados atualizados da matriz energética do Brasil | Entrevista |
Should Have
| Tipo | Requisito | Elicitação |
|---|---|---|
| RF12 | O usuário deveria poder visualizar a fonte de dados de cada gráfico | Entrevista |
| RNF13 | O sistema deveria exportar a dashboard em excel | Storytelling |
| RNF14 | O usuário deveria poder acessar a dashboard sem internet | Entrevista |
| RF15 | O usuário deveria poder pesquisar pelos seus gráficos | Entrevista |
| RNF16 | A dashboard deveria ser compatível com dispositivos móveis | Entrevista |
| RF18 | O usuário deveria poder definir cores para suas dashboards | Entrevista |
Could Have
| Tipo | Requisito | Elicitação |
|---|---|---|
| RF21 | O usuario poderia ver uma mensagem sobre os indicadores do gráfico | -- |
| RF22 | O usuario poderia definir templates para suas visualizações | Entrevista |
| RF23 | O usuario poderia separar suas dashboards por filtros | Entrevista |
Won't Have
| Tipo | Requisito | Elicitação |
|---|---|---|
| RF29 | O usuário não poderá adicionar outra fonte de dados | -- |
| RF30 | O usuário não terá como inserir gráficos na dashboard | -- |