MoSCoW
Funções dos autores
| Nome | Função |
|---|---|
| João Pedro Costa | Ajustes e suporte técnico para validação, Revisão Geral |
| Julia Gabriela | Revisão geral |
| Ryan Salles | Criação do documento, manutenção e validação |
| Gabriel Flores | Suporte técnico para validação |
| João Igor | Suporte técnico para validação |
Introdução
Esse documento visa priorizar os requisitos elicitados utilizando a técnica MoSCoW.
Segundo Wiegers (2013), a técnica de priorização MoSCoW funciona como uma forma de explicar e demonstrar aos clientes e partes interessadas quando e se uma determinada funcionalidade será implementada utilizando a escala de nome homônimo, apresentada por meio do Tabela 1.
| Sigla | Nome | Nome traduzido | Significado |
|---|---|---|---|
| M | Must | Precisa | O requisito precisa ser implementado para obter sucesso. Ausência destes requisitos implicam na não realização do projeto. |
| S | Should | Deve | O requisito é importante e deve ser implementado, se possível. Ausências causam impactos relevante, mas não catastróficos. |
| C | Could | Poderia | O requisito pode ser implementado caso hajam recursos remanescentes para tal. Ausências causam impactos mínimos. |
| W | Won't | Não Deve | O requisito não será implementado nesse período. A ausência desse requisito não causará impactos durante o período |
Os requisitos priorizados por essa técnica são essencialmente mutáveis ao apresentar a classifiação W com a restrição de um período de tempo, podendo ser alterada para outra classificação no futuro. Caso isso não seja esclarecido, as partes interessadas, clientes e/ou podem se sentir compelidas a manter o maior número possível de requisitos na categoria Must.
Adicionalmente, segundo WIEGERS (2013),
Metodologia
Essa seção tratará brevemente sobre como a técnica foi utilizada.
Para cada requisito elicitado, ele foi separado em um requisito funcional ou não funcional, posteriormente, ele foi priorizado utilizando o modelo da Tabela 2, cada um correspondendo a uma tupla.
| Tipo | Nome | Rastro | Prioridade |
|---|---|---|---|
| RX | Um nome descritivo | QSTX, ENTY, ADDZ | M/S/C/W |
Legenda:
- RX : Requisito n° X, podendo ser um Requisito Funcional(RF) ou Não Funcional(RNF).
- QSTX, ENTY, etc. : Um código de identificação para onde o requisito foi elicitado
- MSCW : Uma categoria de priorização MoSCoW.
Priorização
Essa seção contêm a priorização realizada.
Requisitos Funcionais
Essa subseção apresenta a priorização de requisitos funcionais por meio da tabela 3.
| ID | Nome | Implementado | Prioridade |
|---|---|---|---|
| RF01 | Cadastro de Famílias | Sim | Should |
| RF02-v2 | Cadastro de Pessoas | Sim | Must |
| RF03 | Cadastro de Domicílios | Sim | Should |
| RF04 | Cadastro de Agricultores Familiares | Sim | Must |
| RF05 | Atualização de Dados de família | Sim | Should |
| RF06 | Processamento de Dados | Sim | Must |
| RF07 | Correção de Inconsistências | Sim | Should |
| RF08 | Consulta de Dados | Sim | Won't |
| RF09 | Relatórios e Divulgação | Sim | Could |
| RF10 | Formulários de Coleta | Sim | Must |
| RF11 | Cadastro MEI | Não | Should |
| RF12 | Informações MEI | Não | Could |
| RF13 | Personalização MEI | Não | Should |
| RF14 | Consultar dados cadastrais | Sim | Should |
| RF15 | Pré-cadastrar família | Sim | Must |
| RF16 | Localizar postos de atendimento | Sim | Must |
| RF17 | Enviar notificações | Sim | Must |
| RF19 | Cadastro de Usuário | Sim | Must |
| RF20 | Atualização de Dados do Usuário | Sim | Should |
| RF21 | Consultar Situação Cadastral | Sim | Won't |
| RF22 | Emissão de Comprovante de Cadastro | Sim | Should |
| RF23 | Filtragem de Benefícios | Não | Must |
| RF24-v2 | Consulta de status de Benefícios | Sim | Must |
| RF25 | Informações Cadastrais | Sim | Should |
| RF26 | Chatbot de atendimento automatizado | Não | Could |
| RF27 | Notificação de pendências ou atualizações | Não | Must |
| RF28-v2 | Simulador de benefícios sociais | Não | Could |
| RF29 | Upload de documentos | Não | Must |
| RF30 | Agendamento de atendimento no CRAS | Não | Must |
| RF31 | Notificações Personalizadas | Não | Won't |
| RF32 | Guia de Atualização Cadastral | Não | Must |
| RF33 | Simulador de Benefícios | Não | Could |
| RF34 | Chat de Atendimento | Não | Should |
| RF35 | Tutoriais Interativos | Não | Must |
| RF36 | Vídeos Explicativos | Não | Should |
| RF37 | Assistência por Voz | Não | Should |
| RF38 | Modo escuro | Não | Must |
| RF40-v2 | Login | Sim | Must |
Requisitos Não Funcionais
Essa seção apresenta os resultados da priorização dos requisitos não funcionais elicitados por meio da Tabela 2.
| ID | Nome | Implementado | Prioridade |
|---|---|---|---|
| RNF01 | Desempenho | Não | Must |
| RNF02 | Segurança | Sim | Must |
| RNF03 | Escalabilidade | Sim | Must |
| RNF04 | Conformidade Legal | Sim | Must |
| RNF05 | Acessibilidade | Não | Should |
| RNF06 | Disponibilidade | Sim | Must |
| RNF07 | Compatibilidade com Aplicativo Off-line | Não | Must |
| RNF08 | Transmissão via Conectividade Social | Não | Could |
| RNF09 | Acesso Restrito | Sim | Must |
| RNF10 | Interface intuitiva e amigável | Sim | Should |
| RNF11 | Suporte a grande base de usuários | Sim | Should |
| RNF12 | Integração com sistemas oficiais | Sim | Must |
| RNF13 | Usabilidade | Não | Should |
| RNF14 | Compatibilidade com Dispositivos | Sim | Must |
| RNF15 | Acessibilidade para pessoas com deficiência visual | Não | Should |
| RNF16 | Backup e restauração de sessão | Não | Should |
| RNF17 | Alta disponibilidade e recuperação de desastres | Não | Should |
| RNF18 | Possibilidade de outros idiomas | Não | Could |
| RNF19 | Integração MEI | Não | Must |
| RNF19 | Integração com o GOV.br | Não | Must |
Conclusão
Uma técnica razoavelmente similar ao Three Level Scale, todavia, pouco restrita pela bibliografia utilizada.
Apesar de permitir dinamismo na priorização e discussão dos requisitos apresentados, além das prioridades poderem ser diretamente comparáveis ao three level scale, o MoSCoW demonstra dificuldade em evitar a necessidade de ser explicado ao cliente, não possui uma tradução fácil do método e demonstra ser de uso difícil para grandes grupos de usuários, observado que não é possível realizar a exata média de um Must com um Should, por exemplo, levando a dificuldades da ordem exata com a qual os requisitos deveriam ser implementados, levando em consideração a dependência entre requisitos. A 100$ parece permitir maiores facilidades nesse aspecto de grupos de usuários e uma priorização final mais clara.
Ao menos, a bibliografia utilizada dá a entender que é possível transferir a escala da Three Level Scale para o MoSCoW sem grandes esforços, portanto exigindo menos retrabalho para priorizar os requisitos.
Validação
A validação da priorização foi realizada presencialmente. As informações da reunião presencial são apresentadas por meio da tabela 3 e 4.
| Campo | Informação |
|---|---|
| Local | UnB - FCTE |
| Data | 05/06/2025 |
| Horário | 9:20 |
| Duração | Cerca de 5 minutos |
| Nome | Função |
|---|---|
| Artur | Usuário/ Project Owner |
| João Pedro | Secretário |
| Ryan Salles | Entrevistador |
| João Igor | Observador |
| Gabriel Flores | Secretário |
Referências
FIRST things first: Setting requirement priorities. In: WIEGERS, Karl E.; BEATTY, Joy. Software Requirements. 3. ed. [S. l.]: Microsoft Press, 2013. cap. 16, p. 320-321. ISBN 0735679665.
A figura 1 apresenta a referência WIEGERS e BEATTY (2013).
Histórico de Versões
| Versão | Data | Descrição | Autor | Revisor |
|---|---|---|---|---|
| 1.0 | 28/04/2025 | Criação da página da técnica MoSCoW | Ryan Salles | João Pedro Costa |
| 1.1 | 04/05/2025 | Adicionando links e corrigindo tabelas | João Pedro Costa | Ryan Salles |
| 2.0 | 03/07/2025 | Refatoração do documento e conserto em cascata ocasionado pelo versionamento dos requisitos | Ryan Salles | João Pedro Costa |
| 2.1 | 07/07/2025 | Conserto de legenda e padronização das tabelas da validação | Ryan Salles | João Pedro Costa |