Requisitos, histórias de usuário, casos de uso e critérios de aceite

Do zero

Pense numa reforma de cozinha. Antes de quebrar a parede, o arquiteto pergunta: o que você quer fazer nela (cozinhar para seis pessoas, ter uma ilha)? E como ela precisa ser (fácil de limpar, pronta em 30 dias, dentro do orçamento)? As respostas à primeira pergunta são requisitos funcionais; as da segunda, requisitos não funcionais.

Em software é igual, e é aqui que nasce a maior parte dos problemas: um sistema bem programado que faz a coisa errada não serve. Por isso a engenharia de requisitos é um ciclo: descobrir o que as pessoas precisam (levantamento), entender e resolver conflitos (análise), escrever de forma clara (especificação), confirmar com elas que é isso mesmo (validação) e controlar as mudanças ao longo do projeto (gerenciamento).

Há dois jeitos populares de escrever requisitos: a história de usuário, curta e centrada em quem usa (“Como auditor, quero filtrar contratos por valor para priorizar a análise”), e o caso de uso, mais detalhado, com o passo a passo da conversa entre usuário e sistema. Os critérios de aceite dizem como saber que o requisito foi cumprido.

Frase para guardar: funcional é o que o sistema faz; não funcional é como ele precisa ser; critério de aceite é como se prova que ficou pronto.

Em 1 minuto

• Requisito funcional: uma função ou comportamento (“emitir certidão de regularidade”). Não funcional: uma qualidade ou restrição (desempenho, segurança, disponibilidade, usabilidade, portabilidade, conformidade legal).
• Etapas: levantamento (elicitação), análise e negociação, especificação, validação e gerenciamento (mudanças e rastreabilidade).
• História de usuário: “Como [papel], quero [ação], para [benefício]”. Boas histórias seguem o INVEST: Independente, Negociável, Valiosa, Estimável, Pequena e Testável.
• Critério de aceite: condição verificável, muitas vezes escrita como Dado / Quando / Então.
• Caso de uso: ator, pré-condições, fluxo principal, fluxos alternativos e de exceção, pós-condições. include é sempre executado; extend é opcional, sob condição.

Exemplo concreto: emissão de certidão para jurisdicionados

História de usuário:

Como gestor municipal, quero emitir a certidão de regularidade da minha prefeitura pelo portal, para anexá-la a um convênio sem ir ao Tribunal.

Critérios de aceite:

• Dado que a prefeitura não tem pendências, quando o gestor solicita a certidão, então o sistema gera um PDF assinado digitalmente, com código de verificação.
• Dado que a prefeitura tem prestação de contas atrasada, quando o gestor solicita a certidão, então o sistema informa a pendência e não emite a certidão.

Requisitos não funcionais do mesmo recurso:

• Gerar a certidão em até 3 segundos para 95% das solicitações (desempenho).
• Exigir login pelo gov.br (segurança).
• Ficar disponível 99,5% do tempo no mês (disponibilidade).

O mesmo recurso como caso de uso, resumido: ator “Gestor municipal”; pré-condição “gestor autenticado”; fluxo principal (solicita, sistema verifica pendências, gera e assina o PDF); fluxo alternativo (há pendência: exibe a lista); fluxo de exceção (serviço de assinatura fora do ar: informa e registra o erro); pós-condição “certidão registrada no histórico”. O caso de uso inclui (include) “Verificar pendências”, que sempre acontece, e pode ser estendido (extend) por “Enviar certidão por e-mail”, que só acontece se o gestor pedir.

Comparação: técnicas de levantamento

Verificação × validação: verificar é conferir se o produto está de acordo com a especificação (“construímos certo?”); validar é conferir se atende à necessidade real do usuário (“construímos a coisa certa?”).

Priorização MoSCoW: Must (tem de ter), Should (deveria ter), Could (poderia ter) e Won’t (não terá desta vez).

Rastreabilidade: ligar cada requisito à sua origem (a norma, o pedido do usuário) e ao que ele gerou (código, testes). Assim se sabe o impacto de uma mudança.

Como a FCC cobra

• Funcional × não funcional, inclusive restrições legais e de desempenho.
• Técnicas de levantamento e quando usar cada uma.
• Formato e qualidades (INVEST) da história de usuário.
• include × extend nos casos de uso.
• Verificação × validação.

Pegadinhas

Explique com suas palavras

Explique a um servidor de outra área a diferença entre requisito funcional e não funcional, e por que todo requisito precisa de um critério de aceite.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Requisito funcional é algo que o sistema faz: emitir uma certidão, cadastrar um processo, gerar um relatório. Requisito não funcional é como ele precisa fazer: em quanto tempo, com que segurança, por quanto tempo no ar, para quantos usuários ao mesmo tempo.

O critério de aceite diz como vamos saber que o requisito foi atendido. “O sistema deve ser rápido” não dá para testar; “gerar a certidão em até 3 segundos” dá. Sem critério de aceite, cada pessoa entende uma coisa e a entrega vira discussão.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Quando o caso pedir uma solução de sistema, comece pelos requisitos: dois ou três funcionais (o que o sistema fará) e os não funcionais mais importantes, com medida (tempo de resposta, disponibilidade, autenticação). Escrever um critério de aceite no formato Dado / Quando / Então mostra ao examinador domínio prático.

Fontes da lição

• Edital nº 01/2026, Anexo II, Engenharia de Software (fontes/edital-01-2026.txt).
• Ian Sommerville, Engenharia de software (engenharia de requisitos, verificação e validação).
• Mike Cohn, User Stories Applied (histórias de usuário).
• Bill Wake, “INVEST in Good Stories, and SMART Tasks” (2003)