Thumbnail Image
Atlassian

8 armadilhas a serem evitadas na análise de requisitos de software

Softwares de qualidade são desenvolvidos em cima de excelentes requisitos. Por outro lado, falhas e frustrações são comuns quando processos de desenvolvimento e gerenciamento de requisitos são deixados de lado.

1. Ambiguidade

A definição de conceitos pode variar entre usuários. É importante evitar o uso de linguagem ambígua ou confusa.

Revise os requisitos com o seu time para garantir um consenso do entendimento. Elabore um glossário com os principais termos e, se necessário, adicione recursos visuais para elucidar as informações. LucidChart e Gliffy são add-ons excelentes para adicionar recursos visuais em suas ferramentas Atlassian como o Confluence.

2. Envolvimento Inadequado do Cliente

Classes de usuários desprezadas e Stakeholders que se posicionam como usuários principais são problemas comuns durante a análise de requisitos.

Identifique quais usuários são responsáveis pelas decisões e revisões dos requisitos propostos e estabeleça critérios para que a entrega esteja alinhada com a expectativa do cliente.

3. Requisitos Mal Priorizados

A etapa de priorização de requisitos é uma das mais importantes. Determinar prioridades é desafiador quando diferentes stakeholders interpretam a urgência dos requisitos de formas distintas.

Para evitar dúvidas no desenvolvimento ou despriorização de algum requisito, é fundamental que as prioridades estejam consistentes e alinhadas ao sistema que está sendo desenvolvido.

4. Funcionalidades Que Ninguém Usa

Se você já ouviu alguém discutir uma funcionalidade, priorizá-la e, ao concluir o desenvolvimento, perceber que ela não agregava valor ao produto final, você não está sozinho. É comum que usuários proponham funcionalidades que não se relacionam ao sistema.

Para driblar essas armadilhas, é indispensável validar, ao lado do usuário, todos os requisitos conforme o benefício para o sistema, de forma a evitar requisitos funcionais de alto custo e baixo valor.

5. Metas Ilusórias

A engenharia de requisitos é uma ciência e nenhum sistema é perfeito.

É necessário que você escreva requisitos que reflitam a realidade do sistema para que sejam facilmente verificados, a ponto de simplificar manutenções e correções futuras, visando a melhoria contínua da aplicação.

6. Requisitos Intermináveis

O desenvolvimento de requisitos parece interminável? Lembre-se que o objetivo não é criar requisitos perfeitos e sim desenvolver partes que funcionem sob risco aceitável.

Escolha um ciclo de vida de desenvolvimento apropriado para que os requisitos sejam implementados aos poucos, e o entendimento de cada um deles seja aprimorado. Alinhe a comunicação com os clientes, analistas de negócio, desenvolvedores e testadores e defina quais os riscos de se iniciar o desenvolvimento antes de concluir o requisito.

7. Requisitos Mal Levantados

Podem ocorrer dissonâncias no levantamento de requisitos se essa prática não for padronizada de forma efetiva.

Estabeleça um template para a documentação dos requisitos com seções, escritas padrões e diagramas para evitar o uso de diferentes abordagens. Um documento padronizado faz com que todos os analistas estejam alinhados em relação à entrega.

8. Mudanças Inadequadas de Requisitos

Muitos usuários não respeitam o processo de mudança e falam diretamente com membros do time de desenvolvimento, ocasionando trabalhos implementados antes de serem aprovados. O responsável deve validar o processo de mudança e comunicá-lo aos possíveis afetados.

Estabeleça políticas de controle de mudanças e compare as prioridades com os requisitos já existentes no backlog. Na e-Core, utilizamos o JIRA e Confluence para coletar, acompanhar e comunicar alterações.

Para finalizar, compartilhamos algumas dicas para evitar os abismos da documentação de requisitos:

  • Escreva/defina um requisito por vez;
  • Evite usar cláusulas de exclusão. Exemplo: mas, exceto, se necessário;
  • Cada requisito deve formar uma única ideia;
  • Não faça especulações quanto aos requisitos;
  • Entenda os diferentes tipos de requisito;
  • Construa uma relação colaborativa entre analista e usuário do sistema;
  • Tenha times treinados e experientes no levantamento de requisitos

Para reforçar o estudo em análise de requerimentos e análise de negócios:

https://businessanalystlearnings.com
Software Requirements, 3rd Edition,by Karl Wiegers and Joy Beatty (Microsoft Press, 2013)
Business Analysis Body of Knowledge – BABOK