Levantamento de requisitos de software: o que descobrir antes do código

Requisito não é lista de telas

Levantamento de requisitos de software é o processo de descobrir, antes de escrever qualquer código, quem vai usar o sistema, que decisão ele precisa apoiar, que regra de negócio precisa respeitar e com quais outros sistemas precisa conversar. É um trabalho de entender o processo, não de desenhar tela.

O erro mais caro começa antes disso, numa reunião onde alguém já chega com a solução pronta: "precisamos de uma tela de cadastro com estes doze campos" ou "quero um dashboard com estes quatro gráficos". Parece levantamento de requisitos. Não é.

Tela é consequência de um requisito, não o requisito em si. Quando a especificação nasce da tela, ela carrega os vieses de quem imaginou aquela tela: o campo que parecia óbvio, o passo que fazia sentido para quem preenche o formulário mas não para quem usa o dado depois, a regra que ficou de fora porque ninguém perguntou a quem aplica a exceção todo mês.

O sistema sai bonito na demonstração e falha no uso real. Quem entende o que é um sistema sob demanda sabe que o software nasce do problema, não do produto imaginado. O levantamento de requisitos é onde essa diferença se decide.

Quem precisa estar na sala durante o levantamento

Um levantamento de requisitos malfeito quase sempre tem a mesma causa: poucas pessoas na sala, e as pessoas erradas.

Quatro perfis precisam participar, mesmo que em conversas separadas:

• Quem opera o processo hoje. A pessoa que preenche a planilha, atende o balcão ou roda a rotina manual todo mês conhece a exceção que a área de negócio nem lembra de mencionar. Ignorar esse perfil é a forma mais comum de perder requisito importante.
• Quem vai usar o sistema novo. Nem sempre é quem contrata. O gestor decide, mas quem vai abrir o sistema todo dia é a equipe operacional, e ela precisa validar se o fluxo desenhado faz sentido na rotina dela.
• Quem responde pela regra de negócio. A pessoa que sabe por que a regra existe, e não só como ela é aplicada. É quem consegue dizer se uma exceção pode virar padrão ou se é caso isolado.
• Quem representa a área de TI. Traz o que já existe: outros sistemas, integrações, restrições de infraestrutura e o que a base de dados atual já garante ou não garante.

A ausência de qualquer um desses perfis deixa o levantamento raso em algum ponto. Falta o perfil operacional e o sistema ignora a exceção do dia a dia. Falta quem vai usar o sistema e o fluxo desenhado não encaixa na rotina de quem vai abri-lo todo dia. Falta quem responde pela regra e o sistema automatiza um processo errado com mais eficiência. Falta TI e o sistema nasce sem saber com o que precisa conversar.

Requisitos não funcionais que o setor público não pode deixar de fora

Requisito funcional descreve o que o sistema faz: emitir um documento, validar um cadastro, gerar um relatório. Requisito não funcional descreve como o sistema precisa se comportar para ser aceitável, e é a parte que mais costuma faltar num levantamento apressado.

Para o setor público, três frentes não podem ficar de fora da lista de requisitos, desde a primeira versão.

Acessibilidade desde a lista de requisitos

Serviço público tem obrigação legal de ser acessível, e isso precisa entrar como requisito, não como ajuste de fim de projeto. Definir contraste, navegação por teclado, leitura por leitor de tela e estrutura semântica junto dos requisitos funcionais custa muito menos do que adaptar uma interface já pronta.

LGPD nos dados que o sistema vai tratar

Todo levantamento de requisitos de sistema público precisa responder: que dado pessoal o sistema vai coletar, para qual finalidade, quem pode acessar e por quanto tempo o dado fica guardado. Essas respostas mudam o desenho do banco de dados e das permissões, então precisam estar na especificação desde o início, não numa revisão jurídica posterior.

Disponibilidade que o serviço público exige

Um sistema que atende o cidadão ou outro órgão não pode se contentar em estar disponível "na maior parte do tempo", sem que ninguém tenha pensado no que isso significa na prática. O levantamento precisa registrar, em termos qualitativos, o que acontece se o sistema ficar fora do ar durante um horário crítico, e que rotina de manutenção é aceitável sem impacto no serviço. A equipe não precisa prometer um número de disponibilidade: precisa entender, desde o desenho, o peso que a indisponibilidade tem para quem depende do sistema.

Do requisito ao protótipo navegável

Um requisito bem levantado ainda não é um sistema. É a base para o próximo passo, que é o protótipo navegável: telas clicáveis, sem código funcionando por trás, que servem para testar se o requisito foi entendido certo.

O protótipo não valida a tecnologia. Valida a compreensão. Se a pessoa que opera o processo consegue navegar pelo protótipo e reconhecer o fluxo que ela vive todo dia, o requisito foi bem entendido. Se ela trava, se pede um passo que não está ali, ou se um campo obrigatório não faz sentido para o caso dela, é hora de ajustar a especificação, e não a tela pronta.

Esse ciclo entre requisito e protótipo é o que separa um levantamento de requisitos útil de uma lista de telas com nome bonito. Reduz o risco de retrabalho mais adiante no projeto, porque o erro aparece numa tela de papel, antes de virar código.

Na Evo Tech, nossos profissionais já atuaram em órgãos do setor público federal e em organismos internacionais. Na criação de sistemas sob demanda, o levantamento de requisitos junto de quem opera o processo é o ponto de partida de todo projeto.

Se a sua área está preparando a especificação de um sistema novo, seja para uso interno ou para uma contratação, vale revisar a lista de requisitos com uma pergunta simples: ela descreve o processo e quem vai operá-lo, ou descreve telas que alguém já imaginou?