Day: September 8, 2025

Levantar requisitos de software é um trabalho contínuo: Apesar de ter um template, consultar múltiplas partes e revisar, é possível que haja uma ou outra brecha na especificação.

Para você que trabalha com levantamento de requisitos, aqui vai um checklist prático e dividido em etapas, para evitar omissões e mal entendidos na especificação.

Antes da especificação

1 – Identifique a Dor Principal: No início do projeto, trabalhe junto ao Product Owner e stakeholders para identificar qual é a maior dor a ser resolvida, e formalize esta identificação em um lugar acessível a todos. A dor principal que o projeto visa resolver será utilizada posteriormente para priorização dos requisitos, evoluções, e para manter o foco no valor de negócio durante todo o desenvolvimento.

2 – Estabeleça um template: Manter a consistência na documentação de um projeto é importante e transmite credibilidade. Além disso, um bom modelo de documento, que exija determinadas informações, previne que algum detalhe seja esquecido.

Recomenda-se que o seu template tenha as seguintes informações:

• 2.1 – Numeração de requisitos: Todos os requisitos devem ser numerados seguindo um padrão consistente (ex: 001, 002, etc). Esta numeração facilita a rastreabilidade e comunicação entre equipes.
• 2.2 – Critérios de aceite: Para cada requisito, defina claramente como será testado através de critérios de aceite específicos, mensuráveis e verificáveis, com exemplos práticos. Estes critérios servem como base para testes automatizados e validação de entrega. Exemplo: “Ao clicar em “Enter”, a próxima tela deverá ser carregada em até 3 segundos.
• 2.3 – Fluxos de exceção: Documente cenários de erro, falhas de sistema, dados inválidos e situações inesperadas (exemplo: Usuário tinha uma lista de vídeos para assistir, mas um dos vídeos está indisponível por falha do servidor ou porque o arquivo está corrompido. O que deve aparecer na tela? Deve pular automaticamente para outro vídeo e ignorar aquele? Essa ocorrência deve ser salva em algum log?). Para cada exceção, defina como o sistema deve reagir, que mensagens exibir ao usuário e se o problema deve ser registrado para análise posterior.
• 2.4 – Protótipos e diagramas: Inclua wireframes, mockups, diagramas de fluxo e modelos de dados para tornar os requisitos mais tangíveis. Os protótipos ajudam os desenvolvedores a entender a expectativa visual, e os fluxos ajudam a validar cenários complexos com múltiplas exceções e validações.
• 2.5 – Campos de dados: Para cada campo de entrada, especifique tamanho máximo, formato esperado, validações necessárias e comportamento em casos de erro. Por exemplo: “Campo CEP: 8 dígitos numéricos, formato XXXXX-XXX, validação via API dos Correios”. Além disso, especifique também o que deve ocorrer com campos muito grandes apresentados em tela (se serão apresentados pela metade, se ao clicar o usuário poderá ver mais, ou só de apontar o mouse o texto restante aparecerá em um tooltip, etc). Caso não seja especificado, é provável que os desenvolvedores utilizem um tamanho padrão para cada campo, mas é bom ser o mais completo possível.

Durante a especificação

3 – Requisitos não funcionais básicos: usabilidade, segurança e integração:

• Usabilidade: Defina padrões de experiência do usuário, tempos de resposta esperados, acessibilidade e facilidade de aprendizado. Especifique métricas como “90% dos usuários devem completar a tarefa X em menos de 3 cliques”.
• Integração: Como o sistema irá interagir com outros sistemas? incluindo APIs, formatos de dados, protocolos de comunicação e tratamento de indisponibilidades de serviços externos (este ponto se relaciona também com os fluxos de exceção).
• Informações sensíveis: Estabeleça políticas claras para tratamento de informações sensíveis, incluindo: critérios de classificação de dados, métodos de criptografia, controles de acesso, logs de auditoria e conformidade com regulamentações (LGPD, GDPR). Defina quem tem acesso a quais dados e em que circunstâncias.

4 – Valide os requisitos com um ponto focal e um desenvolvedor: Esta etapa é extremamente negligenciada, muitas vezes por conta de prazos apertados. Entretanto, o ideal é que o documento de requisitos seja validado pelo menos uma vez por uma pessoa da área de negócio (que entende as necessidades do usuário) e um desenvolvedor (que compreende a viabilidade técnica e o esforço de desenvolvimento). Esta dupla validação identifica inconsistências, ambiguidades e problemas de implementação antes que se tornem custosos.

5 – Verifique requisitos conflitantes: Revise sistematicamente os fluxos e os requisitos para identificar contradições, sobreposições ou dependências problemáticas. Caso o projeto seja muito grande ou complexo, considere criar uma matriz de rastreabilidade.

Extra – Uso de IA: A inteligência artificial é uma grande aliada para revisar requisitos, identificar inconsistências, sugerir casos de teste e automatizar partes da documentação. Entretanto, aqui vai uma dica: Escreva primeiro uma versão sem IA, e só depois a utilize.

Este estudo testou a utilização de IA para a escrita, e os resultados mostram que a dependência completa de IA pode criar um débito cognitivo – diminuição da atividade cerebral em áreas como memória e criatividade. Portanto, os participantes que escreveram primeiro de forma livre e somente depois utilizaram a IA tiveram uma melhor performance.

Após a especificação

6 – Mantenha o documento vivo e versionado: Mantenha o documento sempre atualizado e use controle de versão rigoroso. Cada versão deve ter data, responsável pelas mudanças e resumo das alterações, usando ferramentas disponíveis como Git, SharePoint, dentre outras.

7 – Estabeleça um fluxo para mudanças de requisito: Um processo claro gera transparência para toda a equipe. Por isso, estabeleça critérios para alterações nos requisitos, incluindo: quem pode solicitar mudanças, impacto, quando as mudanças serão feitas e implementadas.

Mudanças não controladas são uma das principais causas de estouro de prazo e orçamento.

CHAOS REPORT, 2023.

Referências

1. Nataliya Kosmyna, Eugene Hauptmann, Ye Tong Yuan, Jessica Situ, Xian-Hao Liao, Ashly Vivian Beresnitzky, Iris Braunstein, Pattie Maes. 2025. Your brain on ChatGPT: Accumulation of cognitive debt when using an AI assistant for essay writing task [Preprint]. arXiv. Available from: https://doi.org/10.48550/arXiv.2506.08872
2. The standish group. CHAOS REPORT 2023. Available from: https://thestory.is/en/journal/chaos-report.

Há diversos tipos de Padrões Obscuros. Citaremos alguns deles abaixo.

• Sopa de palavrinhas (“Trick wording”): Ao preencher um formulário, você responde a uma pergunta que o leva a dar uma resposta que não pretendia. Lendo rápido, a pergunta lhe parece perguntar algo, mas ao ler de novo, o conteúdo da pergunta é outro;
• Item surpresa (“Sneaking”): Você tenta comprar algo, mas em algum momento o site insere um item a mais em sua cesta;
• Vendendo a alma (“Hard to cancel”): Você entra em uma situação com muita facilidade, mas descobre que é difícil sair dela (por exemplo, uma assinatura premium);
• Privacidade Zuckering: Você é levado a compartilhar publicamente mais informações sobre si mesmo do que pretendia;
• Difícil de comparar (“Comparision prevention”): A loja torna difícil para você comparar o preço de um item com outro, então acaba não conseguindo decidir a compra com mais informação;
• Desvio de atenção (“Visual interference”): O design foca propositadamente sua atenção em algo para distraí-lo quanto a outro ponto;
• Custos escondidos (Hidden costs): Você chega à última etapa e descobre algumas cobranças inesperadas (por exemplo, taxa de entrega);
• Isca e troca: Você se propõe a fazer algo, mas um evento diferente e indesejável acontece (por exemplo, vê um anúncio tentador, mas quando tenta finalizar a compra, percebe que a opção não mais está disponível, momento em que a loja te oferece outras opções mais favoráveis no negócio);
• Vergonha de confirmação (“Confirmshaming”): A opção de recusar é formulada de forma a envergonhar o usuário. Por exemplo, quando o site mostra uma oferta e apresenta dois botões: “eu quero perder o desconto” e “eu quero desconto!”;
• Anúncios disfarçados (Disguised ads): Anúncios que são disfarçados como outros tipos de conteúdo ou navegação, para que você clique neles.
• Continuidade forçada (Sneaking): Quando sua avaliação gratuita com um serviço chega ao fim e seu cartão de crédito começa a ser cobrado silenciosamente sem nenhum aviso.
• Spam de amigos: O produto solicita permissões de e-mail ou mídia social sob o pretexto de que será usado para um resultado desejável, mas envia spam a todos os seus contatos em uma mensagem que afirma ser sua.

Referências:

• Livro “Enviesados” – Rian Dutra.
• https://www.deceptive.design/