Pular para conteúdo

Priorização

Introdução

As técnicas de priorização de requisitos têm como principal objetivo ajudar os projetos de desenvolvimento de software a determinar quais requisitos são mais importantes, essenciais ou urgentes para serem implementados. Isso é crucial porque, em qualquer projeto de software, há uma quantidade limitada de recursos, como tempo, dinheiro e mão de obra. Portanto, é fundamental garantir que esses recursos sejam alocados da maneira mais eficiente possível para atender às necessidades e expectativas dos clientes ou usuários finais.4

Objetivo

O objetivo deste documento é fornecer uma visão abrangente sobre as técnicas de priorização de requisitos no contexto de projetos de desenvolvimento de software. Que visam garantir que os recursos limitados disponíveis, como tempo, dinheiro e mão de obra, sejam alocados de maneira eficiente e eficaz, atendendo às necessidades e expectativas dos clientes ou usuários finais. O documento também detalha as metodologias e técnicas específicas utilizadas no projeto, como Three Level Scale, MoSCoW e In or Out, descrevendo o processo de aplicação e os critérios de revisão e ajuste dos itens priorizados.

Metodologia

A metodologia utilizada para priorização envolveu a seleção e aplicação de três técnicas distintas: Three Level Scale, MoSCoW e In or Out. Primeiramente, os requisitos foram coletados e documentados. Em seguida, uma reunião online foi realizada com a participação de membros da equipe e o usuário José Roberto, onde cada técnica foi aplicada sequencialmente para avaliar e classificar os requisitos. As decisões foram registradas e analisadas para garantir a consistência e alinhamento com os objetivos do projeto, resultando em uma lista priorizada que reflete as necessidades e limitações identificadas.

Participantes

No dia 16 de abril de 2024, às 19h30, foi realizada uma reunião online entre três membros da equipe e o usuário José Roberto, servidor público do TST, utilizando a plataforma Microsoft Teams. Durante a reunião, eles discutiram e priorizaram os requisitos do projeto, colaborando ativamente para identificar e classificar as necessidades essenciais. Isso garantiu um alinhamento estratégico e eficiente para as próximas etapas do projeto. A ata da reunião de priorização está disponível em Link da ata. A tabela 1 apresenta os participantes da reunião.

Tabela 1: Participantes

Nome Função
Douglas Marinho Entrevistador
João Artur Entrevistador
Luiz Gustavo Entrevistador
José Roberto Usuário

Fonte: João Artur

Técnicas Utilizadas

Three Level Scale

Na abordagem da técnica de priorização Three Level Scale, os requisitos são divididos em três categorias de acordo com sua prioridade relativa: alta, média e baixa. Este método foi aplicado por um desenvolvedor em conjunto com um usuário, onde o desenvolvedor desempenhou o papel de facilitador, orientando o usuário durante o processo.1

A chave para o sucesso dessa técnica reside na concordância das partes interessadas sobre o significado de cada nível de prioridade na escala. Assim, durante o processo de priorização, consideramos tanto a urgência quanto a importância de cada requisito. Desta forma, as categorias de prioridade foram definidas da seguinte maneira:

  • Alta prioridade: requisitos que são tanto importantes quanto urgentes, e devem ser implementados na próxima release;
  • Média prioridade: requisitos importantes, mas que não têm urgência imediata, portanto, podem ser programados para uma release futura;
  • Baixa prioridade: requisitos que não são nem importantes nem urgentes, e sua implementação pode ser adiada para um momento posterior.

Embora a técnica não envolva a atribuição de classificações numéricas aos requisitos, mas sim uma categorização em grupos de prioridade, é crucial considerar as dependências entre eles. As interdependências podem influenciar a importância e o impacto dos requisitos, portanto, é recomendado avaliá-las durante o processo de priorização. Dessa forma, as decisões informadas sobre a priorização podem ser tomadas levando em conta todas as interações entre os requisitos.1

Critérios de Revisão e Ajuste dos Itens

Para garantir que a priorização dos requisitos continue relevante e alinhada com os objetivos do projeto ao longo do tempo, é essencial incluir um processo de revisão periódica e ajuste dos itens nos níveis de prioridade. Este processo envolve:

  1. Revisão Periódica: Realizar reuniões periódicas (mensais) para reavaliar os níveis de prioridade dos requisitos e ajustar conforme necessário.
  2. Feedback dos Stakeholders: Coletar feedback contínuo dos stakeholders para identificar qualquer mudança nas necessidades e expectativas que possam impactar a priorização dos requisitos.
  3. Monitoramento de Progresso: Acompanhar o progresso do projeto e o impacto das implementações realizadas para ajustar a priorização baseada em novas informações e resultados.
  4. Documentação de Ajustes: Manter uma documentação atualizada de todas as mudanças nos níveis de prioridade, incluindo as justificativas para essas mudanças, para garantir transparência e rastreabilidade.

Ao incorporar esses critérios, a técnica "Three Level Scale" se torna mais dinâmica e capaz de se adaptar às mudanças no ambiente do projeto, garantindo que os recursos sejam sempre alocados de forma eficiente para atender às necessidades mais urgentes e importantes.

MoSCoW

A ideia central do método MoSCoW é classificar os requisitos ou funcionalidades do projeto em quatro categorias, ajudando a equipe a focar nos elementos mais importantes e decisivos para o sucesso do projeto. As quatro categorias formam um acrônimo - Must have, Should have, Could have e Won't have.2

  • Must have: Esses são os requisitos essenciais para que o projeto seja considerado um sucesso. Eles são críticos e não podem ser deixados de fora.
    • Exemplo: Autenticação de usuários para acesso seguro.
  • Should have: Esses são os requisitos importantes, mas não vitais para o sucesso do projeto. Eles são considerados secundários em relação aos "Must haves", mas ainda são significativos e devem ser incluídos se possível.
    • Exemplo: Notificações push sobre novas publicações relevantes.
  • Could have: Esses são os requisitos desejáveis, mas não essenciais. Eles são considerados opcionais e podem ser incluídos se houver tempo e recursos disponíveis.
    • Exemplo: Integração com redes sociais para compartilhamento de documentos.
  • Won't have: Esses são os requisitos que a equipe decidiu explicitamente não incluir no escopo do projeto, pelo menos na iteração atual. Eles podem ser considerados para futuras versões do projeto, mas não serão abordados no momento. Isso geralmente é feito devido a restrições de tempo, recursos ou prioridades.
    • Exemplo: Suporte multilíngue para a interface do usuário.

Ao fornecer exemplos específicos para cada tipo de requisito, a equipe pode entender melhor como aplicar o método MoSCoW na prática e garantir que os requisitos sejam priorizados de acordo com sua importância e urgência.

In or Out

A técnica "In or Out" é uma abordagem simples para priorizar requisitos. Consiste em listar os requisitos e, junto com um grupo de stakeholders, tomar uma decisão binária: "Está dentro ou está fora?". Ao aplicar essa técnica, é importante ter em mente os objetivos do negócio e procurar reduzir a lista de requisitos para apenas o mínimo necessário para aquela versão.3

Critérios de Inclusão e Exclusão

Critérios de Inclusão: - Requisitos que são essenciais para a funcionalidade básica do sistema. - Requisitos que atendem às necessidades críticas dos usuários finais. - Requisitos que, se não implementados, comprometeriam a usabilidade ou a segurança do sistema.

Exemplo de Inclusão: - Autenticação de usuários para acesso seguro (RF01) foi incluído porque é essencial para garantir a segurança do sistema e a proteção dos dados dos usuários.

Critérios de Exclusão: - Requisitos que não são essenciais para a funcionalidade básica do sistema. - Requisitos que podem ser adiados para versões futuras sem comprometer a operação atual do sistema. - Requisitos cuja implementação requer recursos significativos que não estão disponíveis no momento.

Exemplo de Exclusão: - Integração com sistemas de assinatura digital (RF08) foi excluído porque, embora desejável, não é crítico para a operação inicial do sistema e pode ser implementado em uma versão futura.

Justificativa dos Critérios

Os critérios de inclusão e exclusão são justificados pela necessidade de focar nos requisitos que têm o maior impacto na funcionalidade e na segurança do sistema, além de garantir que os recursos disponíveis sejam utilizados da maneira mais eficiente possível. A decisão de incluir ou excluir requisitos é baseada na avaliação dos benefícios e dos custos associados à implementação de cada requisito.

Processo de Revisão e Ajuste dos Critérios

Para garantir que os critérios de inclusão e exclusão permaneçam relevantes e alinhados com os objetivos do projeto, é importante estabelecer um processo regular de revisão e ajuste. Este processo envolve:

  1. Revisão Periódica: Realizar reuniões periódicas (mensais) para reavaliar os critérios e verificar se ainda são adequados.
  2. Feedback dos Stakeholders: Coletar feedback contínuo dos stakeholders sobre a eficácia dos critérios e identificar áreas de melhoria.
  3. Análise de Desempenho: Avaliar o desempenho do projeto em relação aos requisitos implementados e ajustar os critérios conforme necessário para refletir as lições aprendidas.
  4. Documentação de Ajustes: Documentar todas as mudanças nos critérios e as justificativas para essas mudanças, garantindo transparência e rastreabilidade.

Exemplo de Processo de Revisão

  • Revisão Periódica: Em uma reunião trimestral, a equipe de desenvolvimento e os stakeholders revisam os critérios de inclusão e exclusão.
  • Feedback dos Stakeholders: Durante a reunião, os stakeholders mencionam que um requisito inicialmente excluído agora se tornou uma prioridade devido a mudanças nas necessidades dos usuários.
  • Análise de Desempenho: A equipe analisa o impacto dos requisitos implementados e percebe que alguns critérios podem ser ajustados para melhor refletir a urgência e importância dos requisitos.
  • Documentação de Ajustes: As mudanças nos critérios são documentadas e compartilhadas com todos os membros do projeto para garantir entendimento e alinhamento.

Ao incorporar essas práticas, a técnica "In or Out" se torna mais robusta e adaptável às necessidades dinâmicas do projeto, garantindo que os requisitos mais críticos sejam priorizados e implementados de maneira eficaz.

Tabela de Requisitos Priorizados

A tabela 2 a seguir mostra a lista de requisitos priorizados usando as tecnicas de: Three Level Scale, MoSCoW e In or Out.

Tabela 2: Tabela de priorização de requisitos

Tipo Descrição ID Three Level Scale MoSCoW In or Out
RF01 Autenticação de usuários para acesso seguro OBS01 Alto Must Have In
RF02 Visualização de edições diárias do Diário Oficial OBS02 Alto Must Have In
RF03 Busca por palavras-chave em documentos OBS03 Baixo Could Have In
RF04 Filtragem de conteúdo por data, categoria ou órgão emissor OBS04 Alto Must Have In
RF05 Download de edições e documentos em formatos PDF OBS05 Médio Won't Have Out
RF06 Notificações push sobre novas publicações relevantes OBS06 Médio Could Have In
RF07 Acesso a edições anteriores arquivadas OBS07 Médio Must Have In
RF08 Integração com sistemas de assinatura digital OBS08 Baixo Won't Have Out
RF09 Compartilhamento de documentos via redes sociais e email OBS09 Baixo Must Have In
RF10 O aplicativo deve permitir buscas detalhadas por tópicos específicos IS01 Médio Could Have In
RF11 O aplicativo deve oferecer a funcionalidade de salvar documentos para consulta offline IS02 Alto Must Have In
RF12 O aplicativo deve enviar notificações personalizadas sobre novas publicações relevantes IS03 Médio Could Have In
RF13 O aplicativo deve oferecer acesso ao histórico de publicações legislativas IS04 Baixo Won't Have Out
RF14 O aplicativo deve ter um sistema de marcadores para rastrear alterações em documentos específicos IS05 Médio Could Have In
RF15 O aplicativo deve fornecer uma interface que facilite a leitura de textos legislativos IS06 Alto Must Have In
RF16 O aplicativo deve incluir uma funcionalidade de compartilhamento de documentos IS07 Médio Won't Have Out
RF17 O aplicativo deve manter um índice atualizado e pesquisável de todos os documentos publicados IS08 Baixo Won't Have Out
RNF01 Alta disponibilidade do sistema, com 99,9% de uptime OBS10 Alto Won't Have Out
RNF02 Compatibilidade com as versões mais recentes de sistemas operacionais móveis OBS11 Médio Could Have In
RNF03 Design responsivo que se adapta a tablets e smartphones OBS12 Alto Must Have In
RNF04 Segurança de dados com criptografia de ponta-a-ponta OBS13 Alto Must Have In
RNF05 Suporte multilíngue para facilitar o acesso por usuários não-nativos OBS14 Médio Won't Have Out
RNF06 Tempo de resposta de busca inferior a 2 segundos OBS15 Alto Must Have In
RNF07 Implementação de medidas de acessibilidade para usuários com deficiência OBS16 Alto Must Have In
RNF08 Facilidade de atualização de conteúdo pelo gestor do sistema OBS17 Médio Must Have In
RNF09 Suporte técnico com tempo de resposta de 24 horas OBS18 Médio Must Have In
RNF10 O aplicativo deve ter uma interface de usuário intuitiva e fácil de navegar IS09 Alto Must Have In
RNF11 O aplicativo deve garantir a segurança e a privacidade dos dados dos usuários IS10 Alto Must Have In
RNF12 O aplicativo deve estar disponível 24/7, com exceção de períodos de manutenção programada IS11 Alto Must Have In
RNF13 O aplicativo deve apresentar um tempo de resposta rápido (< 2 segundos) nas buscas IS12 Alto Must Have In
RNF14 O aplicativo deve ser acessível de acordo com os padrões da WCAG 2.1 IS13 Médio Could Have In
RNF15 O aplicativo deve ter um mecanismo robusto de backup e recuperação de dados IS14 Médio Won't Have Out
RNF16 O aplicativo deve ser escalável para acomodar um crescente número de usuários e documentos IS15 Alto Must Have In
RNF17 O aplicativo deve oferecer suporte multilíngue para atender a uma base de usuários diversificada IS16 Médio Won't Have Out

Fonte: Douglas Marinho, João Artur e Luiz Gustavo


Gravação da Reunião

Referência Bibliográfica

1. WIEGERS, Karl; BAETTY, Joy. Software Requirements Third Edition. Cápitulo Firts Things Setting Requirements, tópico Three Level Scale, página 319 Disponível em: <https://aprender3.unb.br/pluginfile.php/2844990/mod_resource/content/2/PriorizaA%CC%83%C2%A7A%CC%83%C2%A3o%20de%20Req.pdf> Acesso em 10 de abril de 2024.

2. WIEGERS, Karl; BAETTY, Joy. Software Requirements Third Edition. Cápitulo Firts Things Setting Requirements, tópico MoSCoW, página 320 Disponível em: <https://aprender3.unb.br/pluginfile.php/2844990/mod_resource/content/2/PriorizaA%CC%83%C2%A7A%CC%83%C2%A3o%20de%20Req.pdf> Acesso em 10 de abril de 2024.

3. WIEGERS, Karl; BAETTY, Joy. Software Requirements Third Edition. Cápitulo Firts Things Setting Requirements, tópico IN or OUT, página 318 Disponível em: <https://aprender3.unb.br/pluginfile.php/2844990/mod_resource/content/2/PriorizaA%CC%83%C2%A7A%CC%83%C2%A3o%20de%20Req.pdf> Acesso em 10 de abril de 2024.

4. WIEGERS, Karl; BAETTY, Joy. Software Requirements Third Edition. Cápitulo Firts Things Setting Requirements. Disponível em: <https://aprender3.unb.br/pluginfile.php/2844990/mod_resource/content/2/PriorizaA%CC%83%C2%A7A%CC%83%C2%A3o%20de%20Req.pdf> Acesso em 10 de abril de 2024.

Bibliografia

SERRANO, Milene; SERRANO, Maurício. Requisitos (Aula 07): Elicitação, Modelagem e Análise. 2022. Apresentação de Power Point. 50 slides. color. Disponível em: <https://aprender3.unb.br/pluginfile.php/2844984/mod_resource/content/2/Requisitos%20-%20Aula%2007.pdf>. Acesso em: 07/04/2024.

Requisitos de Software. Bilheteria Digital (2023.1). Disponível em: <https://github.com/Requisitos-de-Software/2023.1-BilheteriaDigital>. Acesso em: 10/04/2024.

COHN, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2010. Acesso em: 03/05/2024.

Histórico de Versão

Versão Data Data Prevista de Revisão Descrição Autor(es) Revisor(es)
1.0 07/04/2024 08/04/2024 Criação do documento sobre priorização de requisitos João Artur Henrique Torres
1.1 08/04/2024 08/04/2024 Adicionando seção sobre MoSCoW e Three Level Scale João Artur Luiz Gustavo
1.2 10/04/2024 11/04/2024 Correção bug tabela e adicionado fonte nas tabelas Arthur Alves João Artur
1.3 10/04/2024 15/04/2024 Adição do método In Or Out Douglas Marinho João Artur
1.4 16/04/2024 17/04/2024 Priorização dos requisitos Douglas Marinho, João Artur e Luiz Gustavo Diego Sousa
2.0 04/07/2024 04/07/2024 Correções nos links e padronizações Luiz Gustavo Arthur Alves
2.1 07/07/2024 08/07/2024 Adição de metodologia padrão Douglas Marinho Arthur Alves
2.2 08/07/2024 08/07/2024 Adicionando links e referências João Artur Henrique Torres