Perguntas de entrevista Business Analyst

Qual é a diferença entre requisitos funcionais e não funcionais?

Requisitos funcionais descrevem o que o sistema deve fazer — um usuário pode resetar sua senha, uma fatura pode ser exportada. Requisitos não funcionais descrevem quão bem ele deve fazer isso: tempo de resposta, usuários concorrentes, disponibilidade, segurança, acessibilidade. Requisitos não funcionais são os que os times esquecem de escrever e os mais propensos a forçar uma reescrita de arquitetura quando descobertos tarde.

Como você escreve uma user story? O que são critérios de aceite?

Uma user story segue "como papel, quero uma ação, para alcançar um benefício" — a última cláusula importa mais porque captura o porquê, o que deixa o time propor soluções melhores. Critérios de aceite definem o que é pronto em termos testáveis, geralmente na forma Given-When-Then cobrindo o caminho feliz, casos-limite, e erros. Uma story sem critérios é um convite para que três pessoas a interpretem de três formas.

Quais técnicas de levantamento de requisitos você usa?

Entrevistas aprofundam a perspectiva de uma pessoa, workshops trazem à tona conflitos entre stakeholders cedo, observação revela o que as pessoas realmente fazem em vez do que dizem, análise de documentos captura regras existentes, e protótipos geram feedback concreto que a discussão abstrata nunca produz. A escolha depende de quão bem o domínio é entendido — quanto menos certo o problema, mais você se apoia em observação e protótipos.

O que você faz quando stakeholders dão requisitos conflitantes?

Torne o conflito explícito em vez de escolher um lado silenciosamente: documente as duas posições, o raciocínio por trás de cada uma, e o trade-off. Depois reúna os stakeholders com dados — números de uso, custo, risco — e obtenha uma decisão de quem for dono do resultado. O modo de falha é resolver isso em particular, porque o stakeholder que perde descobre na entrega e o trabalho é rejeitado.

O que é priorização MoSCoW? Dê um exemplo.

MoSCoW ordena requisitos em Must have, Should have, Could have, e Won't have desta vez. Os itens Must são aqueles sem os quais o release não tem valor; Won't é a categoria mais útil porque torna as exclusões explícitas e para o scope creep silencioso. Uma disciplina comum é limitar Must a cerca de sessenta por cento da capacidade para que haja espaço para o que a descoberta inevitavelmente revela.

Quais diagramas UML você já usou? Quando usar um use case versus um diagrama de sequência?

Um diagrama de use case mostra quais atores interagem com quais capacidades do sistema — bom para conversas de escopo com stakeholders de negócio. Um diagrama de sequência mostra as mensagens ordenadas entre componentes ao longo do tempo e é voltado a desenvolvedores projetando uma interação. Diagramas de atividade e BPMN ficam entre eles para fluxo de processo, e um diagrama de estado é a ferramenta certa quando uma entidade tem um ciclo de vida como um pedido ou um chamado.

O que são BRD, FRD e SRS? Em que diferem?

Um BRD captura necessidades e objetivos de negócio em linguagem de negócio — o porquê. Um FRD traduz isso em comportamentos específicos do sistema — o quê. Um SRS é a especificação completa incluindo requisitos funcionais e não funcionais, restrições, e interfaces, geralmente para uma audiência técnica. Muitos times Agile substituem os três por um backlog de produto mais documentos de apoio mais leves, mantendo specs formais só onde compliance exige.

Como você valida que os requisitos estão claros para o time de desenvolvimento?

O sinal mais forte são as perguntas feitas durante o refinement — o silêncio geralmente significa que o time não se engajou, não que tudo está claro. As verificações práticas são fazer um desenvolvedor repetir a story com suas próprias palavras, revisar os critérios de aceite com QA antes de o desenvolvimento começar, e usar um protótipo ou uma sessão de example mapping para trazer à tona suposições ocultas. Qualquer coisa descoberta aqui é muito mais barata do que depois da implementação.