Na minha opinião, o levantamento de requisitos é uma das etapas mais críticas no desenvolvimento de software. Um erro nessa fase pode gerar retrabalho, custos adicionais e até comprometer o sucesso do projeto. No entanto, muitas pessoas acabam subestimando essa fase ou enfrentam dificuldades para extrair as informações corretas dos stakeholders e é aí que os problemas começam a aparecer.
Sabemos que há diversas formas de fazer esse levantamento e em empresas mais estruturadas temos cargos e pessoas especializadas para desempenhar esse papel (ao menos para os requisitos funcionais), como os próprios Analistas de Requisitos, Product Owners, etc. Essa não é uma realidade para empresas menores, por diversas vezes, desenvolvedores e arquitetos precisam desempenhar esse papel. Mesmo para médias e grandes empresas, frequentemente é um processo um tanto caótico ou desorganizado e a intenção desse artigo é dar algumas dicas de quem já viveu isso por diversas vezes.
Os requisitos de um sistema podem ser classificados em funcionais e não funcionais. Os requisitos funcionais descrevem o que o sistema deve fazer, ou seja, suas funcionalidades e comportamentos esperados. Por exemplo, em um sistema bancário, um requisito funcional pode ser “permitir que o usuário transfira dinheiro entre contas”. Já os requisitos não funcionais especificam como o sistema deve operar, englobando aspectos como desempenho, escalabilidade, segurança e usabilidade. Por exemplo, um requisito não funcional pode ser “o sistema deve processar 1000 transações por segundo”.
A coleta desses requisitos é geralmente uma responsabilidade compartilhada. Desenvolvedores e arquitetos de software desempenham um papel fundamental na análise e tradução dos requisitos para uma implementação técnica eficiente. Enquanto isso, os stakeholders, como usuários finais, gerentes e especialistas de negócio, ajudam a definir os requisitos funcionais, garantindo que o sistema atenda às necessidades operacionais. Já os requisitos não funcionais costumam ser identificados pelos arquitetos e times técnicos, garantindo que a solução seja robusta, segura e performática.
Minha dica aqui vai para os desenvolvedores e arquitetos: Por mais que a identificação e definição dos requisitos funcionais não seja sua responsabilidade, você precisa LER, ENTENDER e AVALIAR para determinar a viabilidade técnica do que está sendo pedido. Se necessário, interfira, sugira novos caminhos que cheguem ao mesmo resultado. Omitir-se não é uma opção se quiser poupar dores de cabeça.
Vá além do óbvio: Fale com diferentes perfis de usuários
Uma das falhas mais comuns é conversar apenas com um grupo específico de usuários. Normalmente, acabamos falando apenas com quem usa a aplicação na ponta operacional. Há outros perfis que podem fornecer insights valiosos. No mínimo, devemos considerar:
- Operacionais: São os usuários que lidam diretamente com o sistema. Eles podem apontar dificuldades na usabilidade, necessidades específicas e problemas recorrentes.
- Gerentes: Costumam se preocupar com relatórios, métricas e produtividade. Eles podem indicar necessidades relacionadas a dashboards e visibilidade de dados.
- Diretores: Focam em indicadores estratégicos e podem ter necessidades diferentes, como exportação de dados para tomada de decisão.
Ao coletar requisitos desses diferentes grupos, você consegue alinhar expectativas e criar um sistema que atenda de forma equilibrada a todas as camadas da organização.
Torne o levantamento visual
Muitos usuários não conseguem expressar claramente o que precisam, mas sabem identificar quando algo está errado. Para facilitar essa comunicação, transforme o levantamento de requisitos em algo mais visual:
- Use protótipos e wireframes para ilustrar fluxos e telas.
- Crie diagramas de processos para mapear como as atividades ocorrem atualmente e como podem ser melhoradas.
- Utilize storyboards para representar a jornada do usuário dentro do sistema.
Quando um usuário vê algo concreto, ele pode rapidamente dizer se aquilo atende às suas expectativas ou se precisa de ajustes. Isso evita interpretações erradas e reduz a necessidade de mudanças no futuro.
Torne o processo de coleta de requisitos dinâmico (menos cansativo/chato), colaborativo (deixando-os falarem sobre detalhes importantes e perguntando o máximo possível para extrair os detalhes mais “escondidos”) e visual (facilitar a interpretação). Manter a atenção dos stackholders focada no processo é fundamental para um levantamento de requisitos de qualidade.
Documente o processo de Levantamento de Requisitos
Levantamento de requisitos não é apenas coletar informações. É essencial documentá-las de forma organizada. Isso não só evita esquecimentos, como também serve como um registro oficial das decisões tomadas. Algumas sugestões aqui do que documentar:
- Todas as informações coletadas: Quem falou, quando e quais requisitos foram levantados.
- Motivação dos requisitos: Por que essa funcionalidade é necessária?
- Pontos de dúvida: Caso precise revisitar o assunto no futuro.
- Mudanças ao longo do tempo: Se requisitos forem alterados, registre o motivo.
A forma de documentar fica por sua conta, como achar melhor e ficar mais claro, mas organizar os requisitos em planilhas ou de forma tabular funciona muito bem. Algumas sugestões de informações úteis para utilizar:
- Identificar quais são requisitos funcionais e não funcionais;
- O uso de macro requisitos pode auxiliar no momento de agrupar os requisitos mais específicos;
- Correlacionar itens, deixando claro qual requisito depende de qual;
- Determinar se são requisitos obrigatórios, importantes ou apenas desejáveis;
- Adicione outras informações que sejam úteis para o seu processo, mas seja contido para não tornar o processo muito burocrático.
Para evitar mal-entendidos e garantir que todos estejam alinhados, peça aos stakeholders envolvidos para validarem a documentação e assinarem digitalmente ou por e-mail. Isso protege tanto o time técnico quanto o negócio.
Use casos de teste para validar requisitos
Uma abordagem interessante para validar requisitos é escrever casos de teste junto com o usuário ou equipe de negócios. Isso ajuda a transformar requisitos em critérios verificáveis. Algumas coisas que podem te ajudar nesse processo:
- BDD (Behavior Driven Development): Pode ser uma excelente alternativa, descrevendo cenários em linguagem natural usando algum framework do seu gosto.
- TDD (Test-Driven Development): Podem ser escritos antes do desenvolvimento (se sua equipe se der bem com isso), garantindo que o sistema se comporte conforme esperado.
- Criar checklists de validação ajuda a garantir que todas as regras de negócio foram atendidas.
Na dúvida, escreva, registre! Não deixe coisas subentendidas, vai dar RUIM!
Conclusão
O levantamento de requisitos é um processo contínuo e essencial para o sucesso de qualquer projeto de software. É uma tarefa que muitas vezes é subestimada, trazendo sérios problemas, desde retrabalho até o não atendimento das necessidades dos usuários/clientes (uma das piores coisas que podem acontecer).
As estratégias e dicas que mencionei nesse artigo devem ajudar empresas, times e profissionais que não tem esse processo bem definido ou que possuem, mas não estão tendo bons resultados.
Lembrando que, o levantamento de requisitos é uma responsabilidade compartilhada tanto da área de negócios quanto da área técnica. Uma boa comunicação e relação entre esses profissionais é uma receita que geralmente dá muito certo!
