Um guia prático para definir requisitos de software
Pedir requisitos de um software é uma das tarefas mais malfeitas no desenvolvimento. A gente vê gente anotando "o sistema precisa ser rápido" e chamando isso de especificação. Não é. Requisitos sem critério de aceitação são achismo. E é esse achismo que quebra projetos depois.
O que realmente compõe os requisitos de um software
Requisito funcional descreve o que o sistema faz. Requisito não funcional descreve como o sistema se comporta. Funcional é coisa de negócio. Não funcional é coisa de engenharia. As duas precisam existir juntas, senão você entrega um sistema que funciona mas ninguém aguenta usar. Um exemplo simples. Você tem um módulo de login. Funcional: o sistema autentica com CPF e senha. Não funcional: o tempo de resposta do login não pode exceder 2 segundos em 95% das requisições. Sem o segundo, o primeiro requisito não tem como validar se tá funcionando bem.
A gente costuma cair na pegadinha de escrever requisitos como histórias de usuário genéricas. "Como usuário, quero me cadastrar." Ok, mas como? Com quê? Qual o fluxo? O que acontece se der erro? Essas perguntas que separam um requisito útil de um requisito que não serve pra nada.
Método prático para levantar requisitos
O método que eu uso desde 2012 não é nenhum framework novo. É basicamente o velho brainstorm estruturado com alguém que realmente entende do domínio. Pega um representante operacional, não só o gerente. O gerente fala o que acha que acontece. O operador fala o que realmente acontece. Primeiro passo: listar todos os atores do sistema. Não apenas usuários finais. Inclui sistemas externos, APIs, processadores batch. Segundo passo: mapear os fluxos principais de cada ator. Terceiro: identificar cenários de exceção. Quarto: transformar cada item em requisito com critério de aceitação claro.
O problema é que a maioria dos levantamentos pára no passo dois. O pessoal acha que ter o fluxo principal mapeado já basta. Falha porque não considera o que acontece quando algo quebra. E é nesses momentos que o projeto estoura.
Um caso real que todo mundo ignora
Certa vez eu trabalhei num sistema de emissão de notas fiscais onde o requisito não funcional de disponibilidade estava escrito como "sistema deve estar disponível 99% do tempo". Parecia razoável. O problema era que o SLA de homologação da SEFAZ exige resposta em até 30 segundos por requisição. O requisito de performance estava implícito mas não documentado. Quando o sistema foi para produção, tinha picos de lentidão que não estavam previstos. A solução foi adicionar um timeout de 25 segundos nas chamadas à SEFAZ e um mecanismo de retry com backoff exponencial. Se tivéssemos documentado esse requisito logo no início, teríamos economizado umas três semanas de retrabalho.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Isso é um exemplo de requisito que parece óbvio mas precisa ser explícito. Integrações com sistemas de terceiros quase sempre têm gargalos que só aparecem em produção. Anotar esses limites desde o início evita dor de cabeça depois.
Pegadinhas comuns ao definir requisitos
A primeira pegadinha é confundir solução com requisito. "O sistema precisa ter um botão verde" não é requisito. É decisão de design. Requisitos descrevem o que precisa ser atingido, não como atingir. Se você escreve soluções em vez de necessidades, qualquer mudança de ferramenta ou framework vira uma guerra política. A segunda pegadinha é a ambiguidade. Palavras como "rápido", "fácil", "seguro" são inúteis sozinhas. Rapidinho significa milissegundos para uns e segundos para outros. Foco em dados mensuráveis sempre que possível. Se não conseguir medir, o requisito não existe de verdade.
A terceira, e mais chata, é a ausência de priorização. requirements list sem prioridade é apenas uma wish list. MoSCoW funciona bem: Must have, Should have, Could have, Won't have. Sem isso, a equipe gasta tempo igual em features críticas e features que nem estão no scope real.
Ferramentas que ajudam (e as que atrapalham)
Eu já usei Jira, Confluence, Trello, Notion, Azure DevOps, e até planilhas de Excel. Ferramenta é secundária. O que funciona de verdade é o hábito de revisitar os requisitos a cada sprint. Documentar e esquecer é o caminho mais rápido pro projeto dar errado. Um detalhe prático: versionamento de requisitos. Mudança de escopo acontece. Anotar a data, o responsável e o motivo de cada alteração economiza horas de conversa travada quando o cliente pergunta "por que isso mudou?". Um documento simples com histórico funciona melhor que sistemas complexos que ninguém mantém.
Limitações do meu método
Não funciona bem em equipes distribuídas onde o representante operacional não está disponível para reuniões. Nesses casos, a alternativa é gravar sessões de shadowing e transformar em vídeos. O custo é maior, mas a qualidade da informação aumenta drasticamente. Também tem o problema do viés do entrevistador. Às vezes o analista interpreta mal o que o usuário disse e acaba documentando algo diferente. Duas revisões cruzadas resolvem isso na maioria das vezes. Se tiver orçamento, contratar um especialista em UX Research ajuda muito.
Requisitos de um software bem feitos são a base de tudo. O resto do processo, arquitetura, código, testes, segue naturalmente quando os requisitos estão claros. O que não está claro nos requisitos vira dívida técnica disfarçada de funcionalidade. Se você tá começando agora, pega um projeto pequeno, lista atores, mapeia fluxos, adiciona critérios de aceitação e revisa com quem vai usar o sistema. Leva tempo, mas é o tempo mais bem gasto do projeto inteiro.
