Moscow
Introdução
Após a coleta de vários requisitos por meio de métodos como introspecção, análise documental e observação, torna-se essencial aplicar técnicas que permitam definir a prioridade desses requisitos, avaliando a relevância de cada um. Assim, nesta seção, a abordagem adotada para a priorização dos requisitos é o Moscow.
Metodologia
O método MoSCoW é uma abordagem para priorizar requisitos, auxiliando a equipe de desenvolvimento a tomar decisões de maneira mais eficiente. Ele organiza os requisitos em quatro categorias principais:
- M (Must-Have): Itens indispensáveis que o projeto precisa incluir.
- S (Should-Have): Requisitos importantes, mas que não são essenciais para a entrega inicial.
- C (Could-Have): Funcionalidades desejáveis que podem ser incluídas se houver recursos e tempo disponíveis.
- W (Won't-Have ou Would/Won't): Elementos que não serão implementados na versão atual, mas podem ser considerados no futuro.
Must-Have
A categoria Must-Have abrange as tarefas essenciais para a conclusão do projeto, que devem ser tratadas como prioridade máxima. Esses itens possuem um impacto significativo no produto e agregam valor crucial, sendo indispensáveis para evitar problemas que poderiam comprometer a experiência do cliente. As demandas classificadas como Must-Have são as mais urgentes e requerem atenção imediata da equipe.
Should-Have
A categoria Should-Have inclui tarefas relevantes para o projeto, mas que não são tão cruciais quanto as classificadas como Must-Have. Embora sejam importantes, sua ausência não inviabiliza o andamento do projeto.
Could-Have
A categoria Could-Have abrange tarefas de menor importância em comparação com as do grupo Should-Have. Esses requisitos adicionam valor ao projeto, mas sua falta não compromete de forma significativa sua execução.
Would/Want/Won't-Have
A categoria Would/Want/Won't-Have reúne tarefas de baixa relevância para o projeto. A inclusão ou exclusão desses itens não impacta de maneira relevante o sucesso do projeto.
Requisitos
A Tabela 1 a seguir contém a priorização dos Requisitos elicitados. Nem todos os requisitos estão presentes na tabela pois diferentes métodos elicitaram requisitos semelhantes.
Legenda:
- INT: Requisitos de Introspecção
- ADD: Requisitos da Análise de Documento
- OBS: Requisitos da Observação
| Rastreabilidade | Descrição | Categoria |
|---|---|---|
| INT04 | O usuário deve poder atualizar seus dados cadastrais pelo app. | must |
| INT05 | O aplicativo deve enviar notificações de vencimento de faturas. | should |
| INT07 | O aplicativo deve ser compatível com as versões mais recentes do Android e iOS. | must |
| INT10 | O aplicativo deve ser otimizado para diferentes tamanhos de tela e dispositivos (responsivo). | could |
| INT12 | O usuário deve poder consultar e pagar débitos anteriores. | must |
| INT13 | O aplicativo deve disponibilizar a opção de cadastro em débito automático. | could |
| INT14 | O usuário deve poder consultar o mapa de interrupções de fornecimento. | must |
| INT15 | O aplicativo deve permitir agendar atendimento presencial na unidade mais próxima. | would |
| INT16 | O aplicativo deve exibir dicas de consumo consciente e economia de água. | should |
| INT17 | O usuário deve poder registrar e acompanhar ordens de serviço. | should |
| INT18 | O aplicativo deve disponibilizar alertas sobre manutenção programada. | must |
| INT19 | O usuário deve poder solicitar alteração na titularidade da conta. | must |
| INT24 | O sistema deve possuir integração com serviços de pagamento populares como Pix e cartões de crédito. | should |
| INT27 | O sistema deve enviar e-mails e SMS transacionais para confirmar ações como pagamentos. | should |
| ADD01 | Permitir a revisão de contas diretamente pelo aplicativo. | should |
| ADD05 | O aplicativo deve permitir que o usuário solicite desobstrução de esgoto e acompanhe os atendimentos. | must |
| ADD11 | O aplicativo deve garantir uma interface do usuário acessível e fácil de navegar. | should |
| ADD12 | O aplicativo deve oferecer suporte a múltiplos idiomas para atender usuários diversificados. | must |
| ADD14 | O aplicativo deve minimizar riscos de vulnerabilidades e proteger contra ataques conhecidos. | should |
| ADD24 | O aplicativo deve implementar autenticação multifator para aumentar a segurança do acesso. | could |
| ADD25 | O usuário deve poder localizar postos de atendimento da CAESB no mapa. | should |
| ADD30 | O aplicativo deve permitir suporte offline para funcionalidades básicas, como visualização de contas armazenadas. | must |
| OBS02 | O aplicativo deve permitir que o usuário selecione o ano ou mês da segunda via da conta. | must |
| OBS06 | O aplicativo deve permitir que o usuário visualize as regiões em que haverá falta de água. | should |
| OBS09 | O aplicativo deve permitir filtrar os atendimentos em andamento ou finalizados. | should |
| OBS11 | O aplicativo deve permitir que o usuário busque um atendimento pelo protocolo. | could |
| OBS12 | O aplicativo deve permitir que o usuário simule o faturamento pelo aplicativo. | could |
Entrevista
Assista a gravação no youtube clicando aqui.
Vídeo 01: Gravação da entrevista de priorização
Autor(a): Natan Almeida| Entrevistador | Entrevistado | Duração | Local | Horário | Data |
|---|---|---|---|---|---|
| Natan | Tatiane | 4m17s | Casa do entrevistado | 14:00 | 24/11/2024 |
Autor: Natan Almeida
Referências
1. MILENE, Profa.; MAURÍCIO, Prof. Elicitação de requisitos: técnicas - priorização. Disponível em: https://aprender3.unb.br/pluginfile.php/2972449/mod_resource/content/2/Requisitos%20-%20Aula%2007.pdf Acesso em: 23 nov. 2024.
Histórico de Versão
| Versão | Data | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|
| 1.0 | 21/11/2024 | Criação do artefato | Letícia Resende | Natan Almeida |
| 1.1 | 24/11/2024 | Adição vídeo e respostas | Natan Almeida | Letícia Resende |