Entrevistas de business analyst testam como você levanta requisitos, lida com stakeholders em desacordo, e transforma ambiguidade em algo que um time possa construir. Aqui estão as perguntas mais comuns com respostas modelo. Junior: teoria básica, definições e casos práticos simples.
Um requisito funcional diz o que o sistema faz — o usuário pode resetar uma senha. Um não funcional diz quão bem — em menos de dois segundos, para dez mil usuários concorrentes, acessível a um leitor de tela. Requisitos não funcionais são os que ficam de fora e depois causam uma reescrita, porque restringem a arquitetura em vez do comportamento.
Que você consiga dizer inequivocamente se ele foi cumprido. "A página deveria carregar rápido" não é testável; "a página renderiza em menos de dois segundos em uma conexão 3G" é. O teste é se duas pessoas lendo isso construiriam a mesma verificação — se não construiriam, o requisito é um desejo.
Uma user story nomeia quem quer algo e por quê, em uma frase, e existe para começar uma conversa em vez de substituí-la. Critérios de aceite são as condições que a tornam pronta, escritas para que um desenvolvedor e um testador concordem de antemão. Uma story sem critérios é de onde vêm os desacordos de escopo.
Um requisito de negócio é o resultado que a organização quer — reduzir chamadas de suporte sobre faturamento. Um requisito de solução é o que o sistema deve fazer para chegar lá. Confundir os dois é como um projeto entrega exatamente o que foi pedido e não move o número que importava para alguém.
Entrevistas para profundidade com uma pessoa, workshops quando vários stakeholders precisam concordar na sala, observação para como o trabalho realmente é feito em vez de como é descrito, e análise de documentos para regras já escritas. Observação é a subutilizada, porque o que as pessoas dizem que fazem e o que fazem diferem mais do que percebem.
Um use case descreve uma interação em passos, incluindo fluxos alternativos e de exceção — ele é completo. Uma user story é um placeholder para uma conversa e deliberadamente não é completa. Use cases servem bem para fluxos regulados ou complexos onde exceções importam; stories servem bem para trabalho iterativo onde o detalhe emerge.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Junior Business Analyst →