Porque é difícil escrever requisitos com qualidade? (Parte 02)

“A parte mais árdua na construção de um software consiste exatamente em identificar o que construir.  Nenhuma outra fase compromete tanto o resultado do trabalho se elaborada de forma incorreta.  Nenhuma outra parte dificulta tanto as correções posteriores.” Frederick P. Brooks

Introdução

Escrever requisitos com qualidade é um dos fatores que determina o sucesso de um projeto, pois é através dele que é delimitado o escopo do projeto.

Neste artigo irei citar seis características [1] que auxiliará o analista na identificação de requisitos problemáticos.

Principais características para obtenção de requisitos de qualidade

A maneira de determinar se cada requisito tem esses atributos é através de técnicas como a Inspeção Formal e através da elaboração de Casos de Testes. O último deve ser elaborado antes de ser escrito uma única linha de código.

Um requisito deve ser:

Correto:

  • Deve descrever exatamente o que deve ser entregue ao cliente. O requisito deve ser revisado e correções devem ser realizadas a fim de garantir a sua qualidade.

Realizável:

  • O requisito deve ser possível de ser implementado dentro de sua capacidade, ambiente e limitações do sistema e do negócio.
  • Para evitar escrever requisitos inviáveis, o analista deve fazer um levantamento do processo a fim de verificar a sua viabilidade técnica/negócio. Isso reduzirá custos e retrabalho por exemplo.

Necessário:

  • O requisito deve ser necessário e documentar uma necessidade real do cliente.
  • A validação da necessidade deve ser realizada com a fonte (usuário/stakeholder) que gerou o requisito. Caso a fonte não seja reconhecida como sendo autoridade para especificar o requisito então, talvez, não seja útil.

Priorizado:

  • O usuário deve priorizar a implementação de cada requisito informando o quanto é essencial para incluí-lo no próximo release. A priorização é utilizada no planejamento do projeto, além de servir como base para uma eventual redução de escopo e pessoal.
  • Normalmente é utilizado três níveis de prioridade, sendo elas:
    • Alta: O requisito tem de ser incorporado no próximo release.
    • Média: O requisito é necessário, mas pode ser adiado para uma versão posterior.
    • Baixa: Seria bom ter o requisito, mas poderá ser descartado caso o projeto não disponha de tempo ou recurso suficiente.

Não Ambígua:

  • Escreva requisitos que possam ser interpretado sempre da mesma forma. Evite palavras subjetivas, como por exemplo, fácil, simples, vários, rápido, eficiente, melhorar, maximizar, minimizar etc.
  • Evite palavras que causam dupla interpretação e palavras técnicas. Além disso, a linguagem utilizada na documentação deve ser simples e de domínio do usuário, pois é ele que realizará a validação.

Testável:

  • O requisito deve ser verificável através de testes e/ou inspeção;
  • É possível verificar se o requisito é testável através de critérios de aceite.

Conclusão

Para alcançar as seis características seguem abaixo algumas dicas:

  • Por mais que você queira, nunca acrescente requisitos antes de alinhar com o usuário, pois ele deverá dizer se o mesmo está correto ou não.
  • Verificar se um requisito é realizável não é apenas ver se o mesmo é factível, é preciso entender a sua real necessidade.
  • Conversar com o responsável pelas definições das tecnologias para entender se da forma que foi definido é possível atendê-lo.
  • E por último, o mais importante: O usuário do requisito. É preciso alinhar com o mesmo qualquer tipo de definição, melhoria ou mudança. Nem sempre o que se diz necessário realmente é! Pode ser que a necessidade exista apenas porque no mundo atual existem falhas no sistema que causam a necessidade. O analista deve dialogar ao máximo para entender a real necessidade do requisito e quando o mesmo parecer inútil, validar antes de descarta-lo.
  • Para ajudar na priorização, o analista tem que deixar claro que se tudo é urgente, nada é urgente, sendo assim existem dois itens que devem ser levados em consideração no momento da priorização: Importância e Impacto.

Quando as características citados neste artigo são implementadas de forma conjunta, é possível encontrar menos ocorrências de imprecisões, omissões e ambiguidade.

Referências

[1] Wiegers Karl. Writing Quality Requirements.

 

Abraços!

 

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *