Three Level Scale
Introdução
Uma forma comum de priorizar os requisitos é dividi-los em três grandes categorias de prioridade: alta, média e baixa, contudo para que ela possa funcionar da forma correta os stakeholders devem concordar em quais são essas prioridades (WIEGERS; BEATTY, p. 319) [1].
A técnica three level scale transforma essa categorização de requisitos em uma matriz 2x2 que avalia a urgência e a importância de um requisito.
Figura 1: Priorização de requisitos com base na importância e urgência. Fonte: Luiz.
Assim, os requisitos na técnica three level scale se dividem em:
-
Alta prioridade: são requisitos que são importantes, pois os consumidores precisam daquela função, e também urgentes, dado que os consumidores precisam dela na próxima release, assim, pela definição, se o requisito pode ser implementado em uma release futura ele não é de alta prioridade (WIEGERS; BEATTY, p. 319) [2].
-
Média prioridade: são requisitos que são importantes, mas os consumidores não precisam deles de forma tão urgente (WIEGERS; BEATTY, p. 319) [3].
-
Baixa prioridade: são requisitos que não são tão importantes e também tão urgentes (WIEGERS; BEATTY, p. 319) [4].
-
Os requisitos no quarto quadrante podem ser considerados urgentes para um determinado stakeholder, talvez por razões políticas, mas eles são importantes para atingir os objetivos de negócio (WIEGERS; BEATTY, p. 319) [5] . Assim, não é ideal que um tempo seja gasto trabalhando no desenvolvimento deles, pois eles não adicionam valor suficiente para o produto (WIEGERS; BEATTY, p. 319) [5].
Metodologia
Conhecendo como a técnica funciona, ela foi aplicada em reunião online gravada com 4 stakeholders a fim de decidir a prioridade dos requisitos elicitados anteriormente no projeto
As técnicas de produção in or out e three level scale foram aplicadas em conjunto, em que ao passar por um requisito, os stakeholders decidiam se aquele requisito era in ou out mas também o grau de importância, sendo eles: alta, média, baixa ou também optaram por não fazer o desenvolvimento dele (quarto quadrante). Ao fazer isso, foi possível poupar tempo dos integrantes do grupo e dos stakeholders.
Gravação da reunião
Participantes da reunião
Tabela 1 - Participantes da reunião da técnica de priorização Three Level Scale.
Nome do participante | Papel |
---|---|
Gabriela | Integrante do grupo atuando como mediadora |
Luiz | Integrante do grupo aplicando a técnica de priorização Three Level Scale |
Fábio | Integrante do grupo aplicando a técnica de priorização in or out |
Mateus | Integrante do grupo aplicando a técnica de priorização QFD |
Pedro Bueno | Estudande de medicina em Buenos Aires, 20 anos de idade, stakeholder 1 |
Janaina | Estudante de arquitetura em Barra do Bugres, 20 anos de idade, stakeholder 2 |
Kamilia Dutra | Estudante de medicina em Buenos Aires, 20 anos de idade, stakeholder 3 |
Requisitos Priorizados com a Técnica Three Level Scale
Tabela 2 - Requisitos priorizados com a técnica three level scale.
Código do requisito | Descrição | Tipo | Status | Categoria de priorização |
---|---|---|---|---|
#RF01 | Deve oferecer a possibilidade do usuário acionar a pesquisa na web | Funcional | Implementado | Alta prioridade |
#RF02 | Deve haver a possibilidade de uso do pensamento profundo para solução de problemas (Deep Thinking) | Funcional | Implementado | Alta prioridade |
#RF03 | O sistema deve aceitar uploads de arquivos de até 10MB nos formatos PDF, DOCX, TXT e imagens (com OCR) com tempo de resposta < 35s | Funcional | Implementado | Alta prioridade |
#RN01 | Deve fazer o uso da arquitetura DeepSeek-V3 | Não funcional | Implementado | Baixa prioridade |
#RN02 | Deve possuir versões para Android e IOS | Não funcional | Implementado | Alta prioridade |
#RF04 | Deve possuir a opção de login com conta Google/Apple ID | Funcional | Implementado | Alta prioridade |
#RF05 | Deve salvar chats entre plataformas | Funcional | Implementado | Média prioridade |
#RF06 | Melhorar as capacidades de "deep thinking" | Funcional | Não implementado | Média prioridade |
#RF07 | Deve haver um campo para a interação com a IA | Funcional | Não implementado | Alta prioridade |
#RF08 | Deve ser possível criar novos chats | Funcional | Implementado | Alta prioridade |
#RF09 | Deve ser possível renomear um chat | Funcional | Implementado | Média prioridade |
#RF10 | Os chats já utilizados devem poder se acessados posteriormente | Funcional | Implementado | Média prioridade |
#RF11 | Deve ser possível dar dislike em uma resposta da IA | Funcional | Implementado | Não fazer |
#RF12 | Deve ser possível dar like em uma resposta da IA | Funcional | Implementado | Não fazer |
#RF13 | Deve ser possível copiar uma resposta da IA | Funcional | Implementado | Alta prioridade |
#RF14 | Deve exibir citações de fontes e referências em respostas baseadas em documentos, indicando página, site e/ou trecho extraído. | Funcional | Parcialmente implementado | Baixa prioridade |
#RF15 | Deve ser possível alterar o idioma do sistema | Funcional | Implementado | Alta prioridade |
#RF16 | Deve ser possível apagar conversas individuais ou de forma geral | Funcional | Implementado | Baixa prioridade |
#RF17 | 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 | Funcional | Parcialmente implementado | Média prioridade |
#RF18 | 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 | Funcional | Parcialmente implementado | Baixa prioridade |
#RF19 | Deve ser possível interromper respostas em andamento | Funcional | Não implementado | Baixa prioridade |
#RF20 | Deve possuir uma API Pública | Funcional | Não implementado | Alta prioridade |
#RF21 | Deve aceitar autenticação via token de acesso | Funcional | Implementado | Não fazer |
#RN03 | Deve guardar um histórico de conversas por 30 dias - O histórico não é persistente se o usuário sair sem salvar | Não funcional | Não implementado | Baixa prioridade |
#RN04 | Deve fazer a exclusão automática de dados de upload | Não funcional | Não implementado | Média prioridade |
#RN05 | 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) | Não funcional | Não implementado | Alta prioridade |
#RF22 | Deve haver uma confirmação para limpar o histórico | Funcional | Não implementado | Alta prioridade |
#RN06 | Em caso de falha, deve retornar mensagens de erro claras | Não funcional | Implementado | Não fazer |
#RN07 | O sistema deve suportar múltiplas requisições simultâneas sem degradação | Não funcional | Implementado | Média prioridade |
#RN08 | 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 | Não funcional | Parcialmente implementado | Baixa prioridade |
#RF23 | Deve suportar busca incremental (exibição de sugestões em tempo real conforme o usuário digita) | Funcional | Não implementado | Baixa prioridade |
#RF24 | Todos os dados sensíveis do usuário devem ser criptografados em trânsito (TLS) e em repouso (AES-256) | Funcional | Implementado | Alta prioridade |
#RF25 | O usuário deve poder controlar quais dados são compartilhados (chat, histórico de buscas, localização) | Funcional | Não implementado | Média prioridade |
#RF26 | Deve haver autenticação multifator opcional para acesso a funcionalidades avançadas | Funcional | Não implementado | Não fazer |
#RF27 | Deve oferecer modo escuro e modo claro, com configuração manual e sincronização automática com o sistema operacional | Funcional | Implementado | Alta prioridade |
#RF28 | 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 | Funcional | Não implementado | Baixa prioridade |
#RN09 | Disponibilizar, no próprio app, informações claras e acessíveis sobre como e onde os dados são armazenados e utilizados. | Não funcional | Não funcional | Não implementado |
#RN10 | 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 funcional | Não implementado | Alta prioridade |
#RF29 | Exibir status do servidor em tempo real (Online, Manutenção, Sobrecarga) | Funcional | Não implementado | Não fazer |
#RF30 | Melhorar retenção de contexto em diálogos longos para evitar “esquecimento” ou mistura de informações previamente dadas | Funcional | Parcialmente implementado | Média prioridade |
#RF12 | Garantir estabilidade na geração de conteúdos pesados (PDF, cálculos), evitando erros de formatação ou falhas | Não funcional | Parcialmente implementado | Média prioridade |
#RF31 | Implementar memória de contexto persistente entre conversas | Funcional | Não implementado | Média prioridade |
#RF32 | Permitir escolha de modelos (seleção de diferentes versões/modelos de IA) | Funcional | Não implementado | Média prioridade |
#RF33 | Permitir organização de conversas em pastas ou listas por tema ou projeto | Funcional | Não implementado | Média prioridade |
#RF34 | Implementar comandos de voz para entrada e saída de informações | Funcional | Não implementado | Alta prioridade |
#RN13 | Atingir ≥ 95 % de usuários avaliando a usabilidade como “Fácil” ou “Muito fácil” em pesquisas futuras | Não funcional | Parcialmente implementado | Baixa prioridade |
#RN14 | Alcançar ≥ 90 % de concordância em “Interface clara e agradável” em pesquisas futuras | Não funcional | Não implementado | Baixa prioridade |
#RF15 | Reduzir para ≤ 5 % os usuários que relatam dificuldade em encontrar opções/ferramentas em pesquisas futuras | Não funcional | Não implementado | Baixa prioridade |
#RF35 | 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 | Funcional | Não implementado | Não fazer |
#RF36 | Fornecer, na interface de envio de imagens, instruções claras e contextualizadas sobre OCR (explicar siglas e limitações) | Funcional | Não implementado | Média prioridade |
#RF37 | Conectar nativamente a ferramentas populares (Google Drive, Google Agendas, Outlook, GitHub etc.) via integrações diretas | Funcional | Não implementado | Média prioridade |
#RF38 | Disponibilizar resumo automático de vídeos (importação de links do YouTube para sumarização) | Funcional | Não implementado | Alta prioridade |
Autor - Luiz.
Com base na técnica de priorização de requisitos foram capaz de classificar os 52 requisitos elicitados anteriormente em quatro categorias, 17 requisitos foram classificados como muito importantes e de alta prioridade, 15 requisitos foram considerados pelos stakeholders como requisitos de média prioridade, 12 requisitos foram de baixa prioridade, não sendo tão urgentes para os consumidores e não tão importantes. Além disso, 8 requisitos foram para a quarta categoria, que não apresentam valor para o produto final desenvolvido.
Referência Bibliográfica
1. WIEGERS, K; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 316.
Foto da referência
2. WIEGERS, K; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 316.
Foto da referência
3. WIEGERS, K; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 316.
Foto da referência
4. WIEGERS, K; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 316.
Foto da referência
5. WIEGERS, K; BEATTY, J. Software Requirements. 3. ed. Redmond: Microsoft Press, 2013. p. 316.
Foto da referência
Link para o documento em versão PDF
Histórico de Versões
Data | Versão | Descrição | Autor | Revisor |
---|---|---|---|---|
02/05/2025 | 0.1 | (#Q04) Documentação referente a aplicação da técnica de priorização Three Level Scale. | @Luiz | @Ana Borges |
20/06/2025 | 1.0 | (#Q04) Transformando os requisitos priorizados em uma tabela para melhor visualização. | @Luiz | @ |
20/06/2025 | 1.1 | (#Q04) Adição dos IDs dos requisitos com hiperlinks na tabela de priorização. | @Luiz | @ |
20/06/2025 | 1.2 | (#Q04) Adição das referências, gravação da reunião e padronização do documento. | @Luiz | @ |