🚀 Engenharia de Software

O Processo de Engenharia de Requisitos

(Do “Achismo” à Validação Real)

👨‍🏫 Professor: Ricardo Pires
📚 Unidade II

⚙️ O Ciclo da Engenharia de Requisitos

Não basta apenas ligar para o cliente num sábado e “perguntar o que ele quer”. A ciência exige um Processo Metodológico Iterativo que envolve 4 grandes etapas:

[1. ESTUDO DE VIABILIDADE]  ---> (Aprova?) ---> (Se não, Cancele o Projeto)
         │ (Sim)
         ▼
[2. LEVANTAMENTO E ANÁLISE] <--- (Feedbacks contínuos do MVP)
         │
         ▼
[3. ESPECIFICAÇÃO TÉCNICA ] ---> (A Geração do Contrato/DRS)
         │
         ▼
[4. VALIDAÇÃO MATEMÁTICA  ] ---> (Aprova final?) --> (Roda Prod!)

💰 1. Estudo de Viabilidade (R$ e Tempo)

Antes de mobilizar 10 Engenheiros que custam 20 mil mensais cada, responde-se a 3 grandes perguntas que são a guilhotina de projetos:

Viabilidade de Negócio: Fazer um sistema de R $500.000, 00 p a r a u m r e t r aba l h o d ees t o q u i s t a q u e h o j ec u s t a R$ 1.000/ano à empresa não fecha a conta. A tecnologia não se paga.
Viabilidade Tecnológica: “Queremos um App que identifique o DNA pela tela do celular”. A física/hardware de 2024 não permite isso. Cancela o projeto.
Viabilidade de Integração: O cliente comprou um super ERP europeu, mas só usa disquete no escritório do armazém e quer que o programa comunique com máquinas de escrever IBM antigas.

🗣️ 2. Levantamento e Análise (Elicitação)

É a imersão da equipe técnica na rotina dos Stakeholders. (Stakeholder = Qualquer pessoa afetada pelo sistema: o dono, a secretária de balcão, o auditor da receita federal).

⚠️ As Armadilhas da Elicitação Humana:

A “Síndrome do Óbvio”: O funcionário não te conta que aperta o botão vermelho antes de fechar o caixa, porque para ele é tão óbvio há 15 anos, que ele esquece que robôs não deduzem coisas.
O Feudo (Fator Político): O gerente esconde regras da equipe de TI porque ele tem medo que o software robótico elimine o cargo dele automatizando a emissão de relatórios.

✍️ 3. Especificação (Domando o Caos)

Após a fumaça de meses de reuniões abaixar, os arquitetos de dados trancam-se e convertem as centenas de áudios de Whatsapp e rascunhos em leis imutáveis.

É a geração literal do Documento de Requisitos (DRS) contendo tudo dividido nas caixinhas de Requisitos Funcionais (Ação), Não Funcionais (Métrica/Segurança) e Domínio (Leis).

É nesse momento que os diagramas da UML nascem para guiar o código e o Banco de Dados.

✅ 4. Validação Contínua (Anti-Catástrofe)

A Validação pergunta: O cliente vai processar a gente no final do ano se entregarmos o que está escrito aqui?

Nunca programe sem validar! Corrigir uma falha em Documento custa 1 real (só reescrever o parágrafo). Corrigir a tela já pronta e o banco de dados cheio de clientes em produção custa 1.000 reais.

O Check-list Cauteloso:

Consistência: O RF-01 fala pra bloquear senha errada no 3º erro. Mas o RF-40 de Segurança, fala para bloquear no 5º. Conflito fatal lógico.
Completeza: Deixaram cadastrar Dependentes na tela, mas não tem como deletar um dependente que morreu. O Requisito está Manco.

🛠️ Protótipos: A Bala de Prata da Validação

Como o arquiteto verifica isso com o Diretor Médico se o diretor não lê JSON nem entende Banco de Dados Relacional?

Figma, Balsamiq e Mockups! A equipe desenha a tela falsa (um site de papelão clicável onde o botão não salva nada). A Reação Visual é animal e instantânea:

“Nossa, muito lindo. Mas onde eu vejo o histórico de alergias do paciente? Sem o histórico a cirurgia não pode acontecer!”

Pronto! A prototipação te salvou de descobrir isso no último dia de entrega.

👾 Código Falando pela UML (BDD Automatizado)

A Verificação também desce para as raízes do código escrito. Hoje usamos linguagens humanas compiláveis, como o Gherkin (Cucumber) ou Pytest, para assegurar que o requisito validado vire barreira técnica no servidor:

# O Computador testando o requisito legal (Domínio) do negócio
def test_deve_exigir_menor_de_18_anos():
    cliente = Cliente(idade=17)
    with pytest.raises(ExcecaoDeMenorDeIdade):
        # A locacao do dvd +18 deve quebrar o script propositalmente!
        cliente.alugar("O Exterminador do Futuro (Censura 18)")

🗣️ QUIZ VERBAL: O Valor do Protótipo Cedo

Pergunta: O levantamento de requisitos de um novo ERP de aviação com o Diretor Aéreo levou 3 meses. Gerou-se um Documento formal Técnico de 800 páginas, que ele assinou com firma reconhecida no cartório sem ler por falta de tempo. Ao final de ano intenso de programação Java, a primeira tela foi revelada aos comandantes de bordo. Todos odiaram e disseram ser inutilizável em voo. O Sistema morreu. De quem é a culpa pela falência financeira do projeto e como a ciência moderna evitaria isso visualmente de forma barata na primeira quinzena?

✅ RESPOSTA DO QUIZ

Culpa do Modelo Rígido Analítico (e do Arquiteto)! Desenhar telas Fake (Prototipação) salva vidas comerciais. 🎨

Explicação: Diretores bilionários jamais lerão mil páginas de jargões arquiteturais cruos (ID, Foreign_Key etc). E mesmo se lessem, textos abstratos no cérebro humano não traduzem usabilidade real. O Engenheiro deveria ter aplicado validação por Prototipação Navegável (Telas Físicas sem código) na primeira quinzena. Ao entregar o Tablet com o modelo falso na mão do piloto, a percepção cinestésica dos comandantes destruiria o projeto em 10 minutos, salvando milhões e forçando a rota correta do produto precocemente.

📐 Matemática da Viabilidade: ROI do Projeto

O Estudo de Viabilidade de Negócio é calculado com o ROI (Return on Investment):

$R O I = \frac{G anh o d o I n v es t im e n t o - C u s t o d o I n v es t im e n t o}{C u s t o d o I n v es t im e n t o} \times 100%$

Exemplo prático:

Sistema proposto custa R$ 120.000 para desenvolver.
Economia anual estimada (retrabalho eliminado): R$ 80.000/ano.
Retorno em $n$ anos: $R O I = \frac{80.000 \times n - 120.000}{120.000} \times 100$
Em 2 anos: $R O I = \frac{160.000 - 120.000}{120.000} \approx 33%$ ✅ Viável!

Se o ROI for negativo no horizonte de planejamento, o Estudo de Viabilidade cancela o projeto antes de qualquer linha de código.

🗣️ QUIZ VERBAL: O Requisito em Conflito

Cenário: Numa clínica médica, o time de requisitos coletou:

RF-05: O sistema deve permitir que QUALQUER recepcionista cancele uma consulta agendada.
RNF-03 (Segurança): Somente o médico responsável pode autorizar cancelamentos de consultas.

Esses dois requisitos convivem pacificamente no documento? O que o Engenheiro de Requisitos deve fazer ao detectar esse conflito durante a fase de Validação?

✅ RESPOSTA DO QUIZ FINAL

Não! Há conflito direto — o Engenheiro deve escalar e arbitrar antes de fechar o DRS. ⚖️

Explicação: O RF-05 e o RNF-03 são mutuamente exclusivos: não é possível que qualquer recepcionista cancele E que somente o médico autorize. A solução típica é criar um fluxo de aprovação (a recepcionista solicita o cancelamento, o médico aprova via notificação). Esse conflito, se não resolvido no papel, gera bugs de segurança em produção. A fase de Validação existe exatamente para cazar esses choques antes do código.

🎯 Resumo de Fixação da Unidade II

Requisitos são o coração e a alma biológica que ditam como será o corpo do software.
Nós dividimos a caça em: Viabilidade Financeira/Técnica → Investigação da Dor → Especificação Estrutural → Verificação Contínua.
Não presuma, pergunte. Não decida, valide usando Protótipos baratos antes de escrever código caro.
Entregar o aplicativo perfeito, hiper seguro e incrivelmente rápido sendo que ele resolve o problema errado, é o atestado de óbito da Engenharia de Software focada em capricho e cega às dores reais.

Explorador

RicardoTecPro

Slide Aula Conceitual 06 - Unidade II - Eng Soft