Moscow
Introdução#
Esse documento tem como objetivo realizar a verificação do artefato Moscow a partir do método de inspeção
Checklist de Verificação#
| ID | Descrição | Referência | Status |
|---|---|---|---|
| 1 | Todos os requisitos foram levantados e estão devidamente documentados antes de iniciar a priorização? | Case Method Fast-Track: A RAD Approach | Sim |
| 2 | Os critérios de classificação do MoSCoW (Must, Should, Could, Would ) foram explicados e estão compreendidos por todos? | Case Method Fast-Track: A RAD Approach | Sim |
| 3 | Os requisitos "Must" representam necessidades críticas para o funcionamento mínimo do sistema? | DSDM: Dynamic Systems Development Method: The Method in Practice | Sim |
| 4 | Há consenso de que esses requisitos são inegociáveis e que o sistema não pode ser entregue sem eles? | DSDM: Dynamic Systems Development Method: The Method in Practice | Sim |
| 5 | Os requisitos "Must" cobrem aspectos obrigatórios, como conformidade legal, segurança ou operações principais? | DSDM: Dynamic Systems Development Method: The Method in Practice | Sim |
| 6 | Os "Musts" foram limitados para garantir foco apenas nos itens realmente imprescindíveis? | DSDM: Dynamic Systems Development Method: The Method in Practice | Sim |
| 7 | Os requisitos "Should" são importantes, mas não críticos para o funcionamento básico do sistema? | DSDM: Dynamic Systems Development Method: The Method in Practice | Sim |
| 8 | Os "Shoulds" contribuem significativamente para a usabilidade e a satisfação do usuário final? | DSDM: Dynamic Systems Development Method: The Method in Practice | Sim |
| 9 | Existe uma justificativa clara de por que esses requisitos não são "Must"? | DSDM: Dynamic Systems Development Method: The Method in Practice | Incompleto |
| 10 | Os requisitos "Could" são identificados como melhorias ou aprimoramentos que podem ser realizados se houver tempo e recursos suficientes? | The DSDM Agile Project Framework | Sim |
| 11 | Os "Coulds" não comprometem a entrega do sistema se forem omitidos, mas adicionam valor se implementados? | The DSDM Agile Project Framework | Sim |
| 12 | Existe consenso sobre o fato de que esses requisitos são opcionalmente úteis, mas não essenciais? | The DSDM Agile Project Framework | Sim |
| 13 | Esses requisitos foram priorizados considerando a sua relação custo-benefício? | The DSDM Agile Project Framework | Incompleto |
| 14 | Os requisitos "Would" foram identificados como não sendo prioridade para a versão atual do sistema? | The DSDM Agile Project Framework | Sim |
| 15 | Há um entendimento claro de que esses requisitos podem ser reconsiderados para versões futuras ou descartados definitivamente? | The DSDM Agile Project Framework | Sim |
| 16 | O escopo do projeto é protegido ao garantir que os "Would" não entrem em desenvolvimento na fase atual? | The DSDM Agile Project Framework | Sim |
| 17 | A equipe atingiu um consenso sobre a classificação de cada requisito? | Case Method Fast-Track: A RAD Approach | Sim |
| 18 | Os stakeholders estão alinhados com a priorização, compreendendo os impactos e concessões feitas em cada categoria? | Case Method Fast-Track: A RAD Approach | Não se aplica |
| 19 | A distribuição dos requisitos entre as categorias é realista, sem sobrecarga de "Musts" ou "Shoulds"? | Case Method Fast-Track: A RAD Approach | Sim |
| 20 | A priorização reflete as capacidades reais da equipe e os prazos disponíveis? | Case Method Fast-Track: A RAD Approach | Não se aplica |
| 21 | Cada requisito tem uma justificativa clara e documentada para sua classificação dentro do MoSCoW? | Case Method Fast-Track: A RAD Approach | Incompleto |
Problemas encontrados#
- Durante a inspeção foi constatado que as justificativas para a priorização dos Shoulds embora discutidas não foram documentadas
- O custo benefício foi superficialmente considerado, tendo em visto a falta de conhecimento em relação aos custos
- Como não houve contato com os stackholders no cenário da matéria, a priorização não está alinhada com eles
- A priorização não reflete com acurácia as capacidades da equipe e os prazos, devido ao cenário da matéria
- As justificativas foram discutidas, mas não foram documentadas
Referências#
1. Clegg, D., & Barker, R. (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley.
2. Stapleton, J. (1997). DSDM: Dynamic Systems Development Method: The Method in Practice. Addison-Wesley.
3. DSDM Consortium. (2014). The DSDM Agile Project Framework.
Histórico de Versão#
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 04/09/2024 | 1.0 | Criação do documento e checklists | Felipe Amorim de Araújo, Guilherme Silva Dutra |
| 05/09/2024 | 1.1 | Adição das referências | Felipe Amorim de Araújo, Guilherme Silva Dutra |
| 06/09/2024 | 1.2 | Adição dos status e dos problemas encontrados | Felipe Amorim de Araújo, Guilherme Silva Dutra |