Tags:

Priorização de requisitos

A priorização de requisitos ajuda a resolver conflitos, a planejar entregas e a decidir sobre quais requisitos implementar. A decisão de priorizar as necessidades de um projeto deve ser tomada a partir de uma parceria entre cliente e desenvolvedor.

Várias técnicas que envolvem a estimativa do valor e custo relativo de cada requisito já foram propostas pela indústria de software, tais como a técnica de MoSCoW, a de Desdobramento da Função Qualidade – “Quality Function Deployment” (QFD) e Gestão da Qualidade Total – “Total Quality Management” (TQM). QFD e TQM são técnicas complexas e, portanto, de difícil de adoção e, a de MoSCoW, por ser muito simplista, pode ser insuficiente. 

O método proposto por Karl E. Wiegers em seu artigo intitulado “First Things First: Prioritizing Requirements[1] sugere uma abordagem de priorização menos formal e bastante eficaz, sendo descrita abaixo:

Os participantes neste processo de priorização devem ser:

  • O gerente do projeto, que lidera o processo, arbitra conflitos e ajusta as entradas dos outros participantes se necessário;

  • Representantes do cliente, que fornecem a classificação dos benefícios e penalidades;

  • Representantes de desenvolvimento, como líderes técnicos da equipe, que avaliam o custo e risco.

Ao definir prioridades é preciso equilibrar:

  • Os benefícios que cada função proporcionará contra seu custo;

  • O custo de cada função;

  • Quaisquer implicações que esta decisão poderá acarretar para a arquitetura e evolução futura do produto;

  • As dependências entre os diferentes requisitos e seu alinhamento com os requisitos de negócio;

  • O risco técnico, ou outras dificuldades associadas a um dado requisito;

  • A granularidade na qual priorizar os requisitos. É preciso escolher um nível adequado de abstração para a priorização, sem perder o que faz sentido lógico para classificar analiticamente e de forma consistente. A lista de requisitos do sistema não deve ultrapassar a casa das dezenas.

Os requisitos essências do sistema tais como, as funções núcleo do produto, diferenciais do produto, ou as que atendem regulamentações governamentais, não devem fazer parte deste processo por serem todos imprescindíveis.

Seguir os oito passos descritos abaixo:

  • Passo 1. Faça uma lista de todos os requisitos, características, ou casos de uso que você deseja priorizar em uma planilha. Todos os artefatos devem estar ao mesmo nível de abstração. Se funções estão logicamente ligadas (ou seja, você só iria implementar B se A for implementada), incluir apenas o recurso A na análise.

  • Passo 2. Estime o benefício relativo que cada recurso fornece ao cliente ou ao negócio em uma escala de 1 a 9, onde 1 é o menos significativo e 9 o máximo. Benefícios indicam alinhamento com os requisitos de negócio. Os representantes dos clientes são as melhores pessoas para definir esta escala.

  • Passo 3. Estimar a penalidade que o negócio sofreria se o recurso não for incluído. Mais uma vez, usar uma escala de 1 a 9, onde 1 significa, nenhuma penalidade e 9 indica uma grande desvantagem. Por exemplo, deixar de cumprir uma regulamentação do governo pode ser uma grande penalidade, mesmo que o benefício para o cliente seja baixo.

  • Passo 4. A coluna Valor Total é a soma do (Benefício Relativo * Peso Relativo) e da (Penalidade Relativa * Peso Relativo). Por padrão, benefício e pena devem ser ponderados de forma igual. Como refinamento, você pode alterar os pesos para esses dois fatores.

  • Passo 5. Estime o custo relativo de implementação de cada característica, em uma escala que varia de um mínimo de 1 a um máximo de 9. Os desenvolvedores devem classificar os custos com base em fatores como a complexidade de implementação, a interface de usuário necessária, a capacidade potencial de reutilização de telas ou código, e os níveis de testes e documentação necessários.

  • Passo 6. Os desenvolvedores estimam o grau relativo de risco técnico ou outro associado a cada requisito em uma escala de 1 a 9. Uma estimativa de 1 significa que eles podem ´programar dormindo´, enquanto que 9 indica sérias preocupações sobre a viabilidade, a disponibilidade de pessoal com o conhecimento necessário, ou o uso de ferramentas e tecnologias desconhecidas. Por padrão, o custo e o risco são ponderados igualmente, e cada um tem o mesmo peso que os definidos para benefícios e penalidades. Como refinamento, você pode alterar os pesos para esses dois fatores.

  • Passo 7. Calcular um número de prioridade para cada requisito. A fórmula para a coluna Prioridade é: Prioridade = valor % / (custo % * Peso custo + riscos % * Peso Risco).

  • Passo 8. Ordenar a lista de recursos por ordem decrescente de prioridade calculada. As características no topo da lista têm o melhor o equilíbrio entre valor, custo e risco, e, portanto, deve ter uma prioridade mais elevada execução. Os principais representantes dos clientes e desenvolvedores devem rever a planilha completa e concordar com os ratings e a sequência resultante.

Abaixo um exemplo da planilha:

tabela

Tabela 1 – Tabela de Prioridades

placas

Este método não é matematicamente rigoroso e é limitado pela capacidade da equipe de estimar o benefício, penalidade, custo e risco para cada item. É uma ferramenta que pode ajudar a tomar decisões de troca de requisitos, quando se avaliam novas necessidades. Estimando a prioridade usando o modelo já preenchido para o projeto, podemos verificar como as novas necessidades se comportam em relação aos requisitos existentes. Com isso, podemos escolher a sequência de implementação apropriada.

Qualquer ação que possa ser tomada para passar a priorização de requisitos da arena política para uma arena objetiva vai melhorar a capacidade de fornecer as funcionalidades mais importantes na sequência mais adequada.

 [1] Karl E. Wiegers – First Things First: Prioritizing Requirements

Por ANA BEATRIZ VARGAS

Postado em: 09 de janeiro de 2015

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário