Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

📋 CAPÍTULO 05: FUNDAMENTOS DE REQUISITOS

A engenharia de requisitos é a fundação de qualquer projeto de software. Sistemas lentos e APIs que quebram diariamente raramente são culpa de "programadores ruins", mas sim de requisitos negligenciados. 🛡️🧩


🎯 Objetivo do Capítulo

Ao final desta unidade, você será capaz de diferenciar O Que o sistema faz (RF) de Como ele se comporta (RNF), traduzindo necessidades de negócio em especificações técnicas precisas.


🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, o departamento jurídico emitiu um alerta: o novo sistema de rastreamento deve estar 100% em conformidade com a LGPD (Lei Geral de Proteção de Dados). Ao mesmo tempo, o setor de vendas exige que o mapa de entregas carregue em menos de 1 segundo.

"Seu desafio como Analista de Requisitos é documentar essas necessidades. O que é uma funcionalidade (botão) e o que é uma restrição de performance ou lei? Se você errar aqui, o sistema pode ser multado ou rejeitado pelos usuários."


🧠 Perspectivas de Requisitos

Segundo Sommerville (2011), o termo "requisito" varia conforme quem o lê:

  • Perspectiva de Usuário (PO): Declarações de alto nível. Ex: "O motorista deve visualizar suas rotas".
  • Perspectiva de Sistema (Dev): Detalhamento técnico. Ex: "O endpoint GET /routes deve retornar um JSON com coordenadas geográficas do PostgreSQL".

📊 Classificação dos Requisitos

graph TD
    R(["Requisitos de API / Software"])
    R --> RF["Funcionais - RF"]
    R --> RNF["Não Funcionais - RNF"]
    
    RF --- |"Rotas / Endpoints"| E1["Serviços & Funções Lógicas"]
    RNF --- |"Performance / Segurança"| E2["Qualidade & Restrições Físicas"]

    style R fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

1. Requisitos Funcionais (RF)

São as tarefas tangíveis. Se o sistema não faz o que o RF pede, ele está incompleto.

  • Exemplos: Cadastrar motorista, Gerar boleto de frete, Validar CPF.

2. Requisitos Não-Funcionais (RNF)

São as restrições e qualidades. Eles moldam a Arquitetura.

  • Performance: A API deve responder em < 100ms.
  • Segurança: Todas as senhas devem ser criptografadas (BCrypt).
  • Disponibilidade: O sistema deve operar 24/7 (SLA de 99.9%).
Categoria RNFExemplo na TecProExpressImpacto Técnico
SegurançaProteção via JWT.Uso de Spring Security.
PerformanceCache de rotas frequentes.Uso de Redis.
LegislativoConformidade com LGPD.Anonimização de dados sensíveis.

🔍 Detalhamento: Ambiguidade é Retrabalho

Um requisito ambíguo como "Calcular o frete de forma rápida" é perigoso. "Rápida" para quem? Para um computador é 1ms, para um humano é 1 segundo.

[!CAUTION] Dica de Especialista: Sempre defina métricas exatas para requisitos não-funcionais. Em vez de "Rápido", use "A resposta deve ocorrer em no máximo 200ms". Isso protege a equipe durante a entrega final. 🧠🛡️


💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se um cliente pede que o sistema "seja seguro", isso é um RF ou um RNF? (Resposta: É um RNF abstrato que gerará vários RFs concretos, como 'Tela de Login', 'Recuperação de Senha' e 'Logs de Auditoria'). Nunca ignore o "Como" em favor do "O Quê". 🧠🛡️