📋 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
/routesdeve 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 RNF | Exemplo na TecProExpress | Impacto Técnico |
|---|---|---|
| Segurança | Proteção via JWT. | Uso de Spring Security. |
| Performance | Cache de rotas frequentes. | Uso de Redis. |
| Legislativo | Conformidade 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ê". 🧠🛡️