⚖️ Requisitos Funcionais e Não Funcionais
Um requisito é uma condição imprescindível para atingir um objetivo específico. Na Engenharia de Software, eles definem o que o algoritmo faz e quais os limites físicos e operacionais impostos (SOMMERVILLE, 2011).
Essa é a diferença mais fundamental na carreira de um Analista/Arquiteto.
📊 Classificação dos Requisitos (Sommerville, 2011)
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
style RF fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
style RNF fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
📗 Exemplos Técnicos Java/Cloud
| Classificação Mestre | Significado | Exemplos na Vida Real de Engenharia |
|---|---|---|
| Funcional (RF) | É uma tarefa tangível do sistema. Normalmente atrelado a um botão no Front-end ou Rota REST. | - Criar um Endpoint GET para cálculo de ICMS; - Emitir PDF de matrículas com JasperReports; - Bloquear cadastro para CPFs menores de 18 anos. |
| Não Funcional (RNF) | É uma exigência orgânica ou comportamental invisível. Quase sempre molda a Arquitetura da infraestrutura. | - A API não pode demorar mais de 100ms na pesquisa (Cache Redis); - O sistema suportará 2 milhões de TPS sem Downtime; - Será desenvolvido restritamente em Java 17. |
[!CAUTION] 💡 A Fronteira do RNF gerando RF: Frequentemente, um requisito abstrato Não Funcional (ex: "O sistema deve ser super seguro") gerará diversos Requisitos Funcionais acionáveis para a equipe ("Fazer tela de Login", "Configurar Spring Security Oauth2", "Travar conta após 3 limites no banco"). O requisito Não Funcional sempre refina a sua Arquitetura base.