Skip to content

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

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


Documento


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   @