MoSCoW
Introdução
A técnica MoSCoW é uma abordagem utilizada para priorização de requisitos em projetos, especialmente em contextos de desenvolvimento ágil. Seu objetivo principal é fornecer uma maneira clara de classificar as necessidades dos stakeholders, permitindo que a equipe de projeto saiba o que é mais urgente e essencial para o sucesso da entrega. A metodologia facilita a tomada de decisões, ajudando a equilibrar as expectativas e os recursos disponíveis ao longo do ciclo de vida do projeto.
Objetivo da Técnica
A técnica MoSCoW tem como objetivo garantir que os requisitos mais importantes sejam atendidos primeiro. Ela organiza os requisitos em quatro categorias: Must Have (deve ter), Should Have (deve ter, mas pode ser adiado), Could Have (poderia ter, mas não é essencial) e Won't Have (não terá agora). Com isso, é possível priorizar as entregas, otimizar os recursos e garantir que os aspectos críticos do projeto sejam entregues de forma eficiente e no prazo estipulado.
Participantes (Stakeholders)
- Nathalia Zika Mendes Sinfrônio • Estudante de direito - Projeção
- Luis Henrique Soares da Silva • Estudante de análise e desnvolvimento de Sistemas - UCB
- Pedro Henrique Galdino • Estudante de Engenhria de Software
Aplicação da Técnica de Priorização
A intenção foi contar com a participação de diferentes usuários para obter uma visão mais ampla e realista sobre as prioridades dos requisitos de software. Buscamos envolver estudantes de diversas faculdades, já que esse público representa um dos principais usuários do aplicativo. Ao incluir diferentes perspectivas dentro do mesmo perfil de usuário, conseguimos identificar com mais precisão quais funcionalidades são indispensáveis, desejáveis, opcionais ou descartáveis, garantindo que o desenvolvimento do sistema esteja alinhado às reais necessidades do público-alvo.
MoSCoW
A seguir, apresenta-se (Figura 10) a priorização dos requisitos elicitados. Cada linha da tabela reúne o identificador único do requisito (ID), sua classificação como funcional ou não funcional, a descrição detalhada do requisito, a descrição resumida do requisito, o status de implementação, a sua prioridade de acordo com a execução da técnica e o seu rastreamento. Essa visão estruturada permite acompanhar de forma clara e organizada a priorização de cada requisito e identificar as prioridades dos stakeholders e os requistos que agregam mais valor e menor custo ao sistema.
Autor: @Gabriela
TABELA 1/ MoSCoW
| ID | Categoria | Descrição final | Descrição | Status | Prioridade | Rastreamento |
|---|---|---|---|---|---|---|
| #RF01 | Funcional | Deve oferecer a possibilidade do usuário acionar a pesquisa na web | Pesquisa na Web de promps de usuário / O sistema deve oferecer um botão para ativar/desativar busca na web | Implementado | Should | #RDF01 e #RIF01 |
| #RF02 | Funcional | Deve haver a possibilidade de uso do pensamento profundo para solução de problemas (Deep Thinking) | Pensamento profundo para solução de problemas | Implementado | Must | #RDF02 |
| #RF03 | Funcional | O sistema deve aceitar uploads de arquivos de até 10MB nos formatos PDF, DOCX, TXT e imagens (com OCR) com tempo de resposta < 35s | Leitura e interpretação de arquivos PDF / O sistema deve aceitar uploads de arquivos nos formatos PDF, DOCX, TXT e imagens (com OCR) / Extrair e processar texto de arquivos de até 10MB / Expandir cobertura de OCR para suportar múltiplos formatos de imagem e extrair texto de forma confiável. / Garantir tempo de resposta de OCR < 35 s por imagem e confiabilidade na extração de texto de diferentes formatos de imagem. | Implementado | Must | #RDF03, #RIF01, #RIF05, #RQF19 e #RQN09 |
| #RN01 | Não funcional | Deve fazer o uso da arquitetura DeepSeek-V3 | Utilização da arquitetura DeepSeek-V3 | Implementado | Must | #RDN04 |
| #RN02 | Não funcional | Deve possuir versões para Android e IOS | Versões para Android e IOS | Implementado | Could | #RDN05 |
| #RF04 | Funcional | Deve possuir a opção de login com conta Google/Apple ID | Login com conta Google/Apple ID | Implementado | Could | #RDF06 |
| #RF05 | Funcional | Deve salvar chats entre plataformas | Salvamento de chat entre plataformas | Implementado | Should | #RDF07 |
| #RF06 | Funcional | Melhorar as capacidades de "deep thinking" | Melhorar as capacidades de "deep thinking" | Não implementado | Must | #RDF08 |
| #RF07 | Funcional | Deve haver um campo para a interação com a IA | Deve haver um campo para a interação com a IA | Implementado | Must | #ROF01 |
| #RF08 | Funcional | Deve ser possível criar novos chats | Deve ser possível criar novos chats | Implementado | Should | #ROF02 |
| #RF09 | Funcional | Deve ser possível renomear um chat | Deve ser possível renomear um chat | Implementado | Would | #ROF03 |
| #RF10 | Funcional | Os chats já utilizados devem poder se acessados posteriormente | Os chats já utilizados devem poder se acessados posteriormente | Implementado | Should | #ROF04 |
| #RF11 | Funcional | Deve ser possível dar dislike em uma resposta da IA | Deve ser possível dar dislike em uma resposta da IA | Implementado | Wont | #ROF05 |
| #RF12 | Funcional | Deve ser possível dar like em uma resposta da IA | Deve ser possível dar like em uma resposta da IA | Implementado | Wont | #ROF06 |
| #RF13 | Funcional | Deve ser possível copiar uma resposta da IA | Deve ser possível copiar uma resposta da IA | Implementado | Must | #ROF07 |
| #RF14 | Funcional | Deve exibir citações de fontes e referências em respostas baseadas em documentos, indicando página, site e/ou trecho extraído. | As respostas devem ser capazes de disponibilizarem links / Citar fontes externas na busca web / Exibir citações de fontes e referências em respostas baseadas em documentos, indicando página, site e/ou trecho extraído. | Parcialmente implementado | Must | #ROF08, #RIF06 e #RQF22 |
| #RF15 | Funcional | Deve ser possível alterar o idioma do sistema | Deve ser possível alterar o idioma do sistema | Implementado | Must | #ROF09 |
| #RF16 | Funcional | Deve ser possível apagar conversas individuais ou de forma geral | Deve ser possível apagar chats antigos / O sistema deve permitir limpar o histórico de conversas | Implementado | Could | #ROF10 e #RIF04 |
| #RF17 | Funcional | Deve ser possível regenar uma resposta da IA de forma manual ou de forma automática no caso de erro de servidor ou sobrecargado sistema | Deve ser possível regenerar uma resposta da IA / Implementar botão “Tentar novamente” ou retry automático em caso de erro de servidor, sem precisar recarregar a página. / Implementar retry automático ou fila de processamento de prompts quando o sistema estiver sobrecarregado, sem recarregar a página. | Parcialmente implementado | Must | #ROF11, #RQF09 e #RQF18 |
| #RF18 | Funcional | O sistema deve exibir respostas formatadas em Markdown em respostas para tabelas ou listas complexas Markdown (títulos, listas, código) com a possibilidade de edição do Markdown pelo usuário | As respostas devem suportar formatações como textos de tamanhos diferentes, linhas, textos em negrito e emojis / O sistema deve exibir respostas formatadas em Markdown em respostas para tabelas ou listas complexasMarkdown (títulos, listas, código). / Markdown em respostas para tabelas ou listas complexas / Adicionar editor de texto avançado com suporte a Markdown e formatação de código. | Parcialmente implementado | Should | #ROF12 , #RIF03, #RIF13 e #RQF15 |
| #RF19 | Funcional | Deve ser possível interromper respostas em andamento | Interromper respostas em andamento | Não implementado | Wont | #RIF07 |
| #RF20 | Funcional | Deve possuir uma API Pública | API Pública | Não implementado | Must | #RIF08 |
| #RF21 | Funcional | Deve aceitar autenticação via token de acesso | Aceitar autenticação via token de acesso | Implementado | Must | #RIF09 |
| #RN03 | Não funcional | Deve guardar um histórico de conversas por 30 dias - O histórico não é persistente se o usuário sair sem salvar | Histórico de conversas por 30 dias - O histórico não é persistente se o usuário sair sem salvar (não há login obrigatório) | Não implementado | Could | #RIN10 |
| #RN04 | Não funcional | Deve fazer a exclusão automática de dados de upload | Exclusão automática de dados de upload | Não implementado | Must | #RIN11 |
| #RN05 | Não funcional | A interface deve seguir diretrizes de usabilidade (botões visíveis, texto legível, feedback imediato) e de acessibilidade (alteração no tamanho da fonte, leitura) | Acessibilidade avançada / A interface deve seguir diretrizes de usabilidade (botões visíveis, texto legível, feedback imediato). | Não implementado | Must | #RIN12 e #RQF05 |
| #RF22 | Funcional | Deve haver uma confirmação para limpar o histórico | Confirmação ao limpar histórico | Não implementado | Must | #RIF14 |
| #RN06 | Não funcional | Em caso de falha, deve retornar mensagens de erro claras | Em caso de falha, deve retornar mensagens de erro claras | Implementado | Must | #RIN15 |
| #RN07 | Não funcional | O sistema deve suportar múltiplas requisições simultâneas sem degradação | O sistema deve suportar múltiplas requisições simultâneas sem degradação | Implementado | Should | #RIN16 |
| #RN08 | Não funcional | O processamento de arquivos grandes (PDF/DOCX) deve ocorrer em ≤10 segundos e o tempo médio de resposta deve ser <= 2 s em operações simples | O processamento de arquivos grandes (PDF/DOCX) deve ocorrer em ≤10 segundos. / Diminuir o tempo médio de resposta para <= 2 s em operações simples e <= 10 s em operações complexas. | Parcialmente implementado | Should | #RIN17 e #RQN04 |
| #RF23 | Funcional | Deve suportar busca incremental (exibição de sugestões em tempo real conforme o usuário digita). | Deve suportar busca incremental (exibição de sugestões em tempo real conforme o usuário digita). | Não implementado | Wont | #RQF01 |
| #RF24 | Funcional | Todos os dados sensíveis do usuário devem ser criptografados em trânsito (TLS) e em repouso (AES-256). | Todos os dados sensíveis do usuário devem ser criptografados em trânsito (TLS) e em repouso (AES-256). | Implementado | Must | #RQF02 |
| #RF25 | Funcional | O usuário deve poder controlar quais dados são compartilhados (chat, histórico de buscas, localização). | O usuário deve poder controlar quais dados são compartilhados (chat, histórico de buscas, localização). | Não implementado | Must | #RQF03 |
| #RF26 | Funcional | Deve haver autenticação multifator opcional para acesso a funcionalidades avançadas. | Deve haver autenticação multifator opcional para acesso a funcionalidades avançadas. | Não implementado | Could | #RQF04 |
| #RF27 | Funcional | Deve oferecer modo escuro e modo claro, com configuração manual e sincronização automática com o sistema operacional. | Deve oferecer modo escuro e modo claro, com configuração manual e sincronização automática com o sistema operacional. | Implementado | Must | #RQF06 |
| #RF28 | Funcional | Deve incluir tutorial interativo na primeira execução, explicando as principais funcionalidades. / Implementar tutorial interativo (tour guiado) destacando recursos avançados (DeepThink, Reason etc.) no onboarding. | Deve incluir tutorial interativo na primeira execução, explicando as principais funcionalidades. / Implementar tutorial interativo (tour guiado) destacando recursos avançados (DeepThink, Reason etc.) no onboarding. | Não implementado | Must | #RQF07 |
| #RN09 | Não funcional | Disponibilizar, no próprio app, informações claras e acessíveis sobre como e onde os dados são armazenados e utilizados. | Disponibilizar, no próprio app, informações claras e acessíveis sobre como e onde os dados são armazenados e utilizados. | Não implementado | Must | #RQN01 |
| #RN10 | Não funcional | Especificar e permitir ao usuário optar por participar ou não do uso de seus dados em processos de re-treinamento ou venda de modelos. | Especificar e permitir ao usuário optar por participar ou não do uso de seus dados em processos de re-treinamento ou venda de modelos. | Não implementado | Must | #RQN02 |
| #RN11 | Não funcional | Especificar e permitir ao usuário optar por participar ou não do uso de seus dados em processos de re-treinamento ou venda de modelos. | Especificar e permitir ao usuário optar por participar ou não do uso de seus dados em processos de re-treinamento ou venda de modelos. | Não implementado | Must | #RQN02 |
| #RF29 | Funcional | Exibir status do servidor em tempo real (Online, Manutenção, Sobrecarga). | Exibir status do servidor em tempo real (Online, Manutenção, Sobrecarga). | Não implementado | Could | #RQF08 |
| #RF30 | Funcional | Melhorar retenção de contexto em diálogos longos para evitar “esquecimento” ou mistura de informações previamente dadas. | Melhorar retenção de contexto em diálogos longos para evitar “esquecimento” ou mistura de informações previamente dadas. | Parcialmente implementado | Must | #RQF10 |
| #RN12 | Não funcional | Garantir estabilidade na geração de conteúdos pesados (PDF, cálculos), evitando erros de formatação ou falhas. | Garantir estabilidade na geração de conteúdos pesados (PDF, cálculos), evitando erros de formatação ou falhas. | Parcialmente implem. | Must | #RQN05 |
| #RF31 | Funcional | Implementar memória de contexto persistente entre conversas. | Implementar memória de contexto persistente entre conversas. | Não implementado | Must | #RQF11 |
| #RF32 | Funcional | Permitir escolha de modelos (seleção de diferentes versões/modelos de IA). | Permitir escolha de modelos (seleção de diferentes versões/modelos de IA). | Não implementado | Must | #RQF12 |
| #RF33 | Funcional | Permitir organização de conversas em pastas ou listas por tema ou projeto. | Permitir organização de conversas em pastas ou listas por tema ou projeto. | Não implementado | Could | #RQF13 |
| #RF34 | Funcional | Implementar comandos de voz para entrada e saída de informações. | Implementar comandos de voz para entrada e saída de informações. | Não implementado | Should | #RQF16 |
| #RN13 | Não funcional | Atingir ≥ 95 % de usuários avaliando a usabilidade como “Fácil” ou “Muito fácil” em pesquisas futuras. | Atingir ≥ 95 % de usuários avaliando a usabilidade como “Fácil” ou “Muito fácil” em pesquisas futuras. | Parcialmente implementado | Must | #RQN06 |
| #RN14 | Não funcional | Alcançar ≥ 90 % de concordância em “Interface clara e agradável” em pesquisas futuras. | Alcançar ≥ 90 % de concordância em “Interface clara e agradável” em pesquisas futuras. | Não implementado | Must | #RQN07 |
| #RN15 | Não funcional | Reduzir para ≤ 5 % os usuários que relatam dificuldade em encontrar opções/ferramentas em pesquisas futuras. | Reduzir para ≤ 5 % os usuários que relatam dificuldade em encontrar opções/ferramentas em pesquisas futuras. | Não implementado | Must | #RQN08 |
| #RF35 | Funcional | Ajustar visualização do título ao passar o mouse sobre o nome do chat na barra lateral de histórico para que não cubra outros elementos e posicione em local adequado. | Ajustar visualização do título ao passar o mouse sobre o nome do chat na barra lateral de histórico para que não cubra outros elementos e posicione em local adequado. | Não implementado | Could | #RQF17 |
| #RF36 | Funcional | Fornecer, na interface de envio de imagens, instruções claras e contextualizadas sobre OCR (explicar siglas e limitações). | Fornecer, na interface de envio de imagens, instruções claras e contextualizadas sobre OCR (explicar siglas e limitações). | Não implementado | should | #RQF20 |
| #RF37 | Funcional | Conectar nativamente a ferramentas populares (Google Drive, Google Agendas, Outlook, GitHub etc.) via integrações diretas. | Conectar nativamente a ferramentas populares (Google Drive, Outlook, GitHub etc.) via integrações diretas. / Integrar agendamento e lembretes com calendários externos (Google, Outlook). | Não implementado | Could | #RQF14 |
| #RF38 | Funcional | Disponibilizar resumo automático de vídeos (importação de links do YouTube para sumarização). | Disponibilizar resumo automático de vídeos (importação de links do YouTube para sumarização). | Não implementado | Must | #RQF23 |
Dificuldades Enfrentadas na Execução da Técnica
Durante o desenvolvimento do projeto, a principal dificuldade enfrentada foi a limitação de tempo. Devido à necessidade de realizar uma mudança significativa no aplicativo, o cronograma inicialmente planejado precisou ser ajustado, o que comprometeu parte da organização e execução das etapas. Como consequência, a reunião destinada à aplicação da técnica de priorização MoSCoW, que originalmente seria realizada de forma presencial para facilitar a comunicação e o alinhamento entre os integrantes, teve que ser feita de forma online.
Bibliografia
Requisitos Aula 07 - Professores Milene Serrano e Maurício Serrano.
Software Requeriments, Third Edition - Karl Wiegers and Joy Beatty.
Autores / Revisores
| Data | Descrição | Autor | Revisor |
|---|---|---|---|
| 03/05/2025 | Técnica de elicitação MoSCow | @Davi | @Gabriela |
Gravação
| Data | Descrição | Link | Autor | Revisor |
|---|---|---|---|---|
| 03/05/2025 | Gravacão Execução Técnica MoSCoW | MoSCoW | @Davi | @Gabriela |