RicardoTecPro

Slide Aula Conceitual 04 - Unidade II - Eng Soft

Leitura de 7 min

🚀 Engenharia de Software

Engenharia de Requisitos (Aula Estendida)

(Descobrindo o que o cliente realmente quer no mundo real)

👨‍🏫 Professor: Ricardo Pires
📚 Unidade II

🎯 A Arte da Engenharia de Requisitos

A programação é a parte fácil. Descobrir o que programar é o verdadeiro desafio da computação. Requisitos estabelecem o que o sistema deve fazer (funções) e quais as suas limitações (restrições legais, temporais ou de hardware).

Na prática diária, o Engenheiro de Requisitos atua como um tradutor alienígena, e precisa:

  1. 🕵️ Descobrir/Elicitar: Sentar com o cliente e arrancar verdades não ditas.
  2. 🧠 Analisar & Negociar: Filtrar pedidos impossíveis.
  3. ✍️ Especificar: Colocar o caos humano num documento técnico rigoroso.
  4. ✅ Validar: Provar que o que foi escrito bate com o desejo final.

🥲 O Abismo da Comunicação

O telefone sem fio é o pior inimigo da Engenharia. O custo de um requisito compreendido de forma errada na primeira semana pode falir a empresa no lançamento do semestre que vem.

[ Cliente ] -> "Quero um controle de clientes seguro"
     │
[ Analista ] -> "O sistema precisa de criptografia RSA 4096"
     │
[ Dev Front ] -> "Vou colocar uma tela de Loading com cadeado piscando"
     │
[ Dev DB ] -> "Salvarei a senha do usuário em TEXTO PURO no banco SQL"
  • O analista sofisticou demais.
  • O front-end mentiu pro usuário.
  • O back-end quebrou a lei e ignorou a segurança pedida (Falha trágica!).

🏗️ Níveis de Profundidade: Do Terno ao Terminal

Documentar bem significa adaptar a linguagem de acordo com quem está lendo na corporação:

  • 👤 Nível Usuário / Executivo: Linguagem natural. Usado para o CEO aprovar a verba e pagar a fatura. Ex: “O App deve ter compras em 1 clique.”
  • ⚙️ Nível Sistema / Técnico: O dicionário do Dev. Define regras, tipos de dados e limites exatos da API que será engolida pelo programador.
  • 📐 Nível de Projeto: Diagramas estruturais da UML mostrando onde o clique vira corrente elétrica.

📚 Exemplo: A Tradução dos Níveis

Vamos ver na prática como a mesma ordem soa em níveis diferentes:

👤 A Ordem do Diretor Médico (Requisito de Usuário): “A minha clínica precisa de um relatório todo fim de mês que some quanto nós gastamos com Dipirona e avise se estiver acabando.”

⚙️ O Documento do Computador (Requisito de Sistema Técnico):

  1. Toda sexta-feira última do mês corrente (CRON Job às 23:59), o microserviço de BI executará a rotina “Soma_Custo_Medicacao”.
  2. Um Payload JSON com total_gasto deverá ser enviado via AWS SES para a diretoria caso a tabela de Estoque acuse quantidade < 50 unidades para o ID_100 (Dipirona).

🗣️ QUIZ VERBAL: O Perigo da Ambiguidade

Pergunta: O dono do supermercado pediu que o novo sistema de caixas tivesse “Telas amigáveis” para os caixas idosos. O Desenvolvedor construiu uma interface hiper-minimalista igual ao “Modo Escuro (Dark Mode)” do Instagram para iPhone. Ao colocar no supermercado iluminado por neon, os idosos não enxergaram nada.

Quem está errado nessa catástrofe?

✅ RESPOSTA DO QUIZ

Ambos, mas a falha técnica primária é do Analista de Requisitos! ❌

Explicação: O termo “Telas amigáveis” é um adjetivo abstrato e inútil na Engenharia de Software. O que é amigável para você, é hostil para o seu avô. Requisitos não podem dar margem à interpretação ou filosofia artística do programador. O Analista deveria ter traduzido para: “O sistema deverá utilizar fonte Tahoma, tamanho mínimo 24px, contrastando em fundo branco com botões em cor sólida primária (WCAG AAA).” (MENSURÁVEL!)

🧩 Os 3 Pilares: RF, RNF e RD

Todo software na Terra obedece a essa equação imutável de categorias: [Entradas] -> [Processamento/Leis] -> [Saídas] = Qualidade.

  1. 🛠️ Requisitos Funcionais (RF): A ação nua e crua. O verbo que executa algo.
  2. 🛡️ Requisitos Não Funcionais (RNF): A barreira protetora e os limites de qualidade onde o sistema roda.
  3. 💼 Requisitos de Domínio (RD): As leis inegociáveis do Universo ou Governo onde o App está sendo lançado.

Vamos mergulhá-los em código!

🛠️ 1. Requisitos Funcionais (RF) na Veia

São os comportamentos. As “Funcionalidades”. Se pedissem para descrevê-los para o app do MercadoLivre:

  • [RF001] O Sistema deverá permitir o Cadastro do Vendedor com CNPJ (Entrada).
  • [RF002] O Sistema deverá calcular o valor total do carrinho (Processamento/Soma).
  • [RF003] O Sistema deverá emitir o Cupom Fiscal Eletrônico ao término (Saída).
  • [RF004] O Comprador deverá conseguir excluir um item (Ação).

🛡️ 2. Requisitos Não Funcionais (RNF)

O cliente não liga pra isso fisicamente… Até o momento que dá errado! Eles garantem Performance, Segurança e Regulamentos de Hardware.

O “Ótimo RNF” contém MÉTTRICAS, NÚMEROS e TEMPO.

  • [RNF-Segurança] A senha deve ser hasheada (escondida) usando Bcrypt antes de ir ao banco.
  • [RNF-Desempenho] A listagem de 10.000 produtos deve demorar menos de 3.5 segundos via rede 4G.
  • [RNF-Legislação] O banco de dados primário deve estar fisicamente em servidores localizados Dentro do Território Brasileiro (Exigência de compliance do BCB).

🗣️ QUIZ VERBAL: O Caçador de Elementos

Pergunta: Leia a frase do escopo assinada pelo cliente abaixo: “O novo App do Uber Eats deve permitir que o usuário chame um Entregador Motorizado. Porém, essa chamada NUNCA pode ficar fora do ar por mais de 5 curtos minutos por ano.”

Desafie-se a separar as categorias: Identifique exatamente qual pedaço de texto é Funcional (RF) e qual é Não Funcional (RNF).

✅ RESPOSTA DO QUIZ

🎯 RF (O Verbo): “O App deve permitir chamar um Entregador…” (A funcionalidade pura de requisitar).

⚡ RNF (A Qualidade Crítica): “…NUNCA ficar fora do ar por mais de 5 minutos por ano” (Isso é uma métrica absurda e agressiva de Disponibilidade de Servidor que forçará o arquiteto a comprar 5 servidores espelhos milionários na AWS para garantir que não vai cair!).

💼 3. Requisitos de Domínio (RD)

Estão acima dos desenvolvedores e da vontade da diretoria. Vêm do ambiente (Leis Fiscais, Regras Químicas, Física do Avião, Leis Trabalhistas).

Exemplos Intransponíveis (Leis da Natureza ou Governo):

  • [RD-Medicina] A dose letal de adrenalina jamais deverá ser permitida, o sistema deve travar o cálculo em 0.5mg/kg (Regra Médica Imutável).
  • [RD-Bancário] O cálculo de juros de cheque especial usará a fórmula Base360 com Spread capitalizado (Regra BACEN Financeira).

Se a empresa errar o RNF, fica lenta. Se errar o RD, o dono vai preso!

📝 BDD: Como a Gestão Ágil descreve isso hoje?

Em ambientes Ágeis modernos (Scrum/XP), abandonamos o Documento do Word chato e escrevemos Requisitos de forma fluida usando Histórias de Usuário e Gherkin (BDD - Behavior-Driven Development):

CENÁRIO: Cliente realiza saque com sucesso
  DADO QUE: O cliente 'João' tem R$ 500 na conta (Contexto)
  E: Ele inseriu o cartão corretamente (Pré-condição)
  QUANDO: Ele solicitar o saque de R$ 100 reais (A Ação/Requisito Funcional)
  ENTÃO: O sistema deve entregar R$ 100 reais (A Saída Esperada)
  E: O novo saldo de 'João' deve virar R$ 400 reais (Regra de Domínio)

(Lemos como humanos, e os testes lá no Java conseguem “Engolir” esse texto acima para testar automaticamente os algoritmos! Espetacular).

📐 Matemática do RNF: SLA e Disponibilidade

Lembre do quiz anterior: “NUNCA fora do ar por mais de 5 minutos por ano”. Em contratos enterprise, isso é formalizado como SLA (Service Level Agreement). Veja os noves famosos:

| SLA | Downtime/Ano | Custo de Infra | |-----||| | | ~87 horas | Barato | | | ~8,7 horas | Moderado | | | ~52 minutos | Caro (Multi-AZ) | | | ~5 minutos | Altíssimo (NASA) |

A fórmula do downtime máximo permitido por ano:

Para :

🎯 Síntese da Aula 04

No fim do dia, o sucesso ou a falência colossal (milhões perdidos na fogueira) de um projeto de software se resume primeiramente a: “Conseguimos entender exatamente a intenção de quem pediu?”

  1. Nunca presuma que o cliente entende os jargões.
  2. Divida os requisitos entre as ações visíveis e as regras matemáticas/tecnológicas ocultas do mundo real.
  3. Não fuja para o código antes de consolidar essas bases. O Código resolve o Requisito, não o contrário.

Visão de gráfico