Aula 17 - Engenharia de Requisitos Avançada e Casos de Uso 📝

📑 1. Fundamentos Teóricos & Análise Técnica

A maior causa de fracasso em projetos de software não reside em erros de codificação ou bugs de compilador, mas no desenvolvimento de funcionalidades que não atendem às necessidades reais dos usuários ou que foram especificadas de forma ambígua.

A Engenharia de Requisitos contemporânea estrutura-se sobre práticas rigorosas de elicitação e validação: 1. Requisitos Funcionais (RF) vs. Não-Funcionais (RNF): - Requisitos Funcionais: O que o sistema deve fazer (comportamento de negócio, cálculos, integrações). - Requisitos Não-Funcionais (Atributos de Qualidade): Como o sistema deve operar (latência de resposta em percentis, disponibilidade de 99.99%, escalabilidade, conformidade de acessibilidade e segurança). Devem ser obrigatoriamente mensuráveis através de métricas objetivas. 2. O Critério INVEST para Histórias de Usuário: - Independent: Historietas desacopladas que podem ser desenvolvidas em qualquer ordem. - Negotiable: Não é um contrato estático; representa o convite para uma conversa. - Valuable: Entrega valor tangível e perceptível para o usuário final. - Estimable: Clareza suficiente para permitir previsões de esforço. - Small: Pequena o suficiente para ser concluída em poucos dias de trabalho. - Testable: Possui critérios de aceitação objetivos e verificáveis. 3. Behavior-Driven Development (BDD / Gherkin): - Especificação de comportamentos através de exemplos concretos na sintaxe Dado que ... Quando ... Então ... (Given-When-Then), servindo simultaneamente como documentação viva compreensível por pessoas de negócio e suíte de testes automatizados executáveis.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Stakeholder["Usuário / Stakeholder"] --> Elicitation["Elicitação & Descoberta de Necessidades"]
    Elicitation --> Story["Histórias de Usuário (INVEST)"]
    Story --> BDD["Especificação com Exemplos BDD (Gherkin)"]
    BDD --> Acceptance["Critérios de Aceitação Automatizados (Cucumber / Playwright)"]
    Acceptance --> Code["Desenvolvimento TDD / Código de Produção"]
    Code --> TestPass["Testes Executáveis Validam Comportamento de Negócio!"]
    style Stakeholder fill:#e1f5fe,stroke:#01579b
    style Story fill:#fff3e0,stroke:#e65100
    style BDD fill:#f3e5f5,stroke:#7b1fa2
    style Acceptance fill:#e8f5e9,stroke:#2e7d32
    style TestPass fill:#e0f2f1,stroke:#00695c

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Eliminação de Ambiguidade: Especificações por exemplos eliminam interpretações divergentes entre engenharia e produto. - Critérios de Aceitação Automatizáveis: Cada cenário Gherkin é diretamente convertido em um teste funcional automatizado. - Rastreabilidade Bidirecional: Garantia de que todo teste unitário e de aceitação esteja mapeado a um requisito de negócio formal. - Foco no Comportamento do Usuário: Descrições centradas no valor gerado em vez de implementações técnicas de banco de dados.

🛠️ 2. Implementação Prática em Engenharia de Requisitos, Histórias de Usuário e BDD

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// checkout_regras.feature (Especificação BDD Executável em Gherkin)
# language: pt
Funcionalidade: Finalização de Compra com Validação de Crédito
  Como um cliente autenticado no portal
  Quero finalizar o checkout do meu carrinho de compras
  Para adquirir os produtos selecionados com entrega garantida

  Contexto:
    Dado que o usuário "carlos.silva@empresa.com" está autenticado no sistema
    E possui um carrinho com o produto "Notebook Pro 16" no valor de 8500.00
    E o endereço de entrega principal está selecionado

  Cenário: Compra aprovada com limite suficiente no cartão corporativo
    Dado que o cartão de crédito corporativo possui limite disponível de 10000.00
    Quando o usuário confirma o pagamento em 1 parcela
    Então o sistema deve autorizar a transação junto ao gateway bancário
    E o pedido deve ser gravado com status "PAGAMENTO_CONFIRMADO"
    E uma notificação de confirmação deve ser enviada para "carlos.silva@empresa.com"

  Cenário: Compra rejeitada por limite de crédito insuficiente
    Dado que o cartão de crédito corporativo possui limite disponível de 3000.00
    Quando o usuário tenta confirmar o pagamento
    Então o sistema deve recusar a operação com a mensagem "Limite de crédito insuficiente"
    E o pedido deve permanecer em estado "AGUARDANDO_PAGAMENTO"
    E nenhum valor deve ser debitado da conta do cliente

💡 Análise Passo a Passo do Código

1. Uso da Sintaxe Padrão Gherkin: Especificação em linguagem natural estruturada que atua como documentação viva executável.
2. Cenários de Sucesso e Exceção: Mapeamento explícito de caminhos felizes e tratamentos de recusa de transação.
3. Testabilidade Absoluta: Permite que frameworks como Cucumber executem os passos diretamente contra o sistema.

🎯 3. Próximos Passos & Sequência Didática