Técnica de Priorização: MoSCoW
Introdução
A técnica MoSCoW, concebida por Dai Clegg para o método RAD e posteriormente incorporada ao DSDM, é amplamente reconhecida na engenharia de requisitos, especialmente em metodologias ágeis. Seu objetivo é facilitar a priorização de funcionalidades com base em sua criticidade e impacto, classificando-as em quatro categorias: Must Have, Should Have, Could Have e Won't Have (por agora). Essa abordagem ajuda equipes a alinhar expectativas, gerenciar recursos de forma eficiente e focar no valor real ao usuário final. Essa técnica é defendida por autores como Milene Serrano e Maurício Serrano, que destacam sua eficácia no projeto, bem como pela Agile Business Consortium. Fonte: https://aprender3.unb.br/pluginfile.php/3096086/mod_resource/content/2/Requisitos%20-%20Aula%2007.pdf e https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html.
Integrantes do Grupo
Na tabela 1 contêm todos os integrantes da equipe que participaram desta etapa de Priorização dos Requisitos com a técnica MoSCoW e o que a pessoa desenvolveu durante o projeto.
Tabela 1 - Integrantes do grupo envolvidos
| Nome | Quais etapas participou |
|---|---|
| Lucas Alves | Priorização, documentação e gravação com personas |
| Kaleb Macedo | Priorização, documentação, gravação com personas, gravação com usuário real e validação |
| Othavio Bolzan | Revisão da etapa final |
Fonte: Autoria de Kaleb Macedo
Usuários Reais Envolvidos
Na tabela 2 contêm as informações do usuário participante desta etapa de Validação da Priorização, ela contêm o nome e informações sobre a gravação que foi feita, incluindo o link para a autorização da gravação e sua postagem no Youtube de forma não listada.
Tabela 2 - Usuários envolvidos
| Nome | Data | Hora | Local | Duração da etapa | Autorização da gravação |
|---|---|---|---|---|---|
| Luana Souza | 04/05/2025 | 15h30 | Presencial | 20 minutos | Link |
Fonte: Autoria de Kaleb Macedo
Metodologia
A técnica de priorização utilizada nesta etapa foi o MoSCoW, que classifica os requisitos de acordo com sua importância. Inicialmente, foi feito o levantamento por meio de técnicas como entrevistas, questionários e introspecção com base em personas, seguido por uma simulação de uso com um usuário real. Essa metodologia é descrita por Milene Serrano e Maurício Serrano (2023), destacando a importância de envolver o usuário na validação de requisitos para maximizar a relevância das funcionalidades priorizadas. Fonte: https://aprender3.unb.br/pluginfile.php/3096086/mod_resource/content/2/Requisitos%20-%20Aula%2007.pdf
Estrutura de Priorização
Must Have
Requisitos essenciais para o funcionamento do sistema.
Tabela 1: Must have
| Tipo | Descrição | Técnicas |
|---|---|---|
| RF01 | Permitir ao usuário pesquisar e filtrar clínicas e profissionais credenciados por especialidade, região administrativa, tipo de atendimento e proximidade. | EN01, EN02, IS02, IS06, QT03, QT08 |
| RF03 | Exibir carteirinha digital mesmo sem conexão (modo offline) e permitir acesso rápido e estável. | EN04, IS09, QT01 |
| RF04 | Enviar notificações configuráveis via app, SMS ou e-mail sobre ven e-mail sobre vencimento de fatura, retornos médicos pendentes, abertura de agenda, cancelamentos de horários, horários favoritos disponíveis, prazos importantes, confirmações ou alterações de agendamento e disponibilidade de demonstrativos de IR. | EN05, EN06, GF02, GF03, GF07, GF10, IS07, IS12, QT06 |
| RF05 | Permitir agendamento e cancelamento de consultas e exames diretamente pelo aplicativo, com pagamento automático para prestadores da Rede de Atendimento. | EN07, GL01, IS01, IS05, GL06 |
| RF09 | Permitir ao usuário visualizar histórico de consultas, exames realizados, resultados de exames laboratoriais e coparticipações. | GF04, GF08, IS03, IS04, QT04 |
| RF15 | Permitir baixar comprovantes de agendamento. | IS08 |
| RNF01 | A interface deve ser intuitiva, clara, adaptada para idosos e pessoas com baixa familiaridade tecnológica, organizada em categorias e responsiva em smartphones Android e iOS. | EN10, GF13, IS13, QT11 |
| RNF02 | Garantir carregamento rápido e fluído de todas as telas, com tempo de resposta das ações não ultrapassando 2 segundos. | EN11, GF17, IS14, QT12 |
| RNF03 | Assegurar segurança no acesso e armazenamento de dados pessoais, criptografar dados sensíveis conforme LGPD, incluir autenticação em dois fatores e ser transparente quanto ao uso e segurança dos dados. | EN12, GL12, GF12, GF14, IS18, QT15 |
| RNF05 | O sistema deve ser compatível com diferentes versões do Android e iOS, a partir das versões mais utilizadas no mercado. | GF18, IS17, QT11 |
| RNF07 | Garantir conformidade com a Portaria nº 127/2024, legislações complementares e padrões da LGPD. | GL10, QT15 |
| RNF10 | Garantir que informações críticas, como a carteirinha digital, estejam acessíveis em até três cliques ou com no máximo 2 cliques a partir da tela inicial. | GF15, IS16 |
| RNF13 | Deve funcionar de forma offline para acesso à carteirinha e histórico de consultas. | IS19 |
| RNF16 | As informações exibidas devem ser claras, completas e atualizadas em tempo real. | QT13 |
Fonte: Lucas Alves e Kaleb Macedo.
Should Have
Requisitos importantes, mas que podem ser adiados se necessário.
Tabela 2: Should have
| Tipo | Descrição | Técnicas |
|---|---|---|
| RF06 | Exibir valor específico de consulta em cada clínica, aplicar percentuais de coparticipação, gerar e baixar demonstrativos de despesas médicas para imposto de renda, consultar histórico de demonstrativos de IR e mostrar extrato financeiro atualizado diariamente. | EN08, GL04, IS10, IS11, QT02, QT05 |
| RF07 | Permitir cadastro de titulares, dependentes e optantes com validação de documentos e elegibilidade. | GL01, GL08, GL09 |
| RF08 | Verificar se procedimentos estão na TABGDFSAÚDE, atendem às DUT, estão sujeitos a carência ou são excluídos, exigindo solicitação médica e análise técnica para autorizações prévias. | GL02, GL03, GL05, GL07, QT09 |
| RF13 | Adicionar consulta à rede odontológica. | QT07 |
| RNF04 | Manter o sistema disponível 24/7 para autorizações de urgência/emergência e apresentar alta disponibilidade (mínimo de 99% uptime). | GL11, QT10 |
| RNF08 | Processar autorizações prévias em até 10 dias úteis. | GL13 |
| RNF12 | O aplicativo deve oferecer suporte por chat ou telefone. | IS15 |
| RNF15 | O sistema deve exigir autenticação via GovBR para login. | GF11 |
Fonte: Lucas Alves e Kaleb Macedo.
Could Have
Requisitos desejáveis, mas que não são prioritários.
Tabela 3: Could have
| Tipo | Descrição | Técnicas |
|---|---|---|
| RF02 | Disponibilizar sistema de avaliação de clínicas com notas e comentários. | EN03, GF01 |
| RF10 | Permitir que o usuário favorite horários de consulta desejados. | GF06 |
| RF12 | Divulgar informações sobre novas funcionalidades no aplicativo. | GF05 |
| RF14 | Apresentar novas clínicas e clínicas próximas de acordo com a localização do usuário. | EN09 |
| RNF09 | Comunicar-se com a folha de pagamento do GDF para descontos de mensalidades. | GL14 |
| RNF11 | Manter histórico de notificações acessível ao usuário por no mínimo 6 meses. | GF16 |
| RNF14 | O layout deve ser consistente com o portal oficial do plano. | QT16 |
Fonte: Lucas Alves e Kaleb Macedo.
Won't Have (por agora)
Requisitos que não serão implementados nesta fase do projeto.
Tabela 4: Won't have
| Tipo | Descrição | Técnicas |
|---|---|---|
| RF11 | Oferecer um canal para o usuário enviar feedback sobre atendimentos. | GF09 |
| RNF06 | O aplicativo deve ser compatível com leitores de tela para garantir acessibilidade a pessoas com deficiência visual. | IS20, QT14 |
Fonte: Lucas Alves e Kaleb Macedo.
Gravação da Validação com Usuário
Para validar a priorização, foi realizada uma reunião com a usuária Luana Souza, conduzida por Kaleb Macedo. Durante a reunião, foram discutidas e validadas as categorias atribuídas aos requisitos.
- Gravação 1: YouTube - Validação MoSCoW
Gravação com Persona
Para validar a priorização, foi realizada uma simulação de entrevista com as personas, conduzida por Kaleb Macedo e Lucas Alves. Durante a simulação, foram discutidas e validadas as categorias atribuídas aos requisitos com base na técnica MoSCoW.
- Gravação 2: YouTube - Validação MoSCoW
Resultado
Os requisitos foram classificados com base na técnica MoSCoW em quatro categorias: Must Have, Should Have, Could Have e Won't Have. Cada um dos requisitos foi justificado e vinculado às técnicas de elicitação utilizadas, e os artefatos completos foram descritos e apresentados em tabelas, conforme seção anterior deste documento.
Referência Bibliográficas
Serrano, Milene; Serrano, Maurício. Requisitos (Aula 07): Elicitação, Modelagem e Análise. UnB Gama, Brasília, 2023. Disponível em: https://aprender3.unb.br/pluginfile.php/3096086/mod_resource/content/2/Requisitos%20-%20Aula%2007.pdf. Acesso em: 2 de maio de 2025.
Agile Business Consortium. MoSCoW Prioritisation. Disponível em: https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html. Acesso em: 2 de maio de 2025.
Visual Paradigm. Prioritizing Requirements with MoSCoW Method: A Guide for Agile Projects. Disponível em: https://guides.visual-paradigm.com/prioritizing-requirements-with-moscow-method-a-guide-for-agile-projects/. Acesso em: 2 de maio de 2025.
Histórico de Versões
| Versão | Data | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|
| 1.0 | 02/05/2025 | Criação do documento com introdução, metodologia e aplicação da técnica MoSCoW | Lucas Alves e Kaleb Macedo | Isaque Camargos |
| 1.1 | 04/05/2025 | Inclusão dos participantes, metodologia detalhada, referências e histórico | Lucas Alves e Kaleb Macedo | Othavio Bolzan |
| 1.2 | 11/05/2025 | Alterações pedidas pelo professor sobre a página do MOSCOW | Kaleb Macedo | Othavio Bolzan |
| 1.3 | 11/05/2025 | Padronização da página do MOSCOW | Kaleb Macedo | Othavio Bolzan |