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:
- Revisão Periódica: Realizar reuniões periódicas (mensais) para reavaliar os níveis de prioridade dos requisitos e ajustar conforme necessário.
- 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.
- 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.
- 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:
- Revisão Periódica: Realizar reuniões periódicas (mensais) para reavaliar os critérios e verificar se ainda são adequados.
- Feedback dos Stakeholders: Coletar feedback contínuo dos stakeholders sobre a eficácia dos critérios e identificar áreas de melhoria.
- 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.
- 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
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 |