❄️ Bootcamp de Inverno · Julho 2026 · Dia 1 · Segunda

Inteli Camp — Dia 1

Spec & Modelagem do Problema

🎯 O que vamos fazer hoje

Entender o desafio do parceiro e decompor o problema
Aprender o que é uma spec e por que ela evita retrabalho
Identificar atores, entidades e fluxos da solução
Preencher a spec do grupo e ter ela validada

🏁 Entregável do dia

Spec do grupo preenchida e validada
Problema decomposto em atores, entidades e fluxo principal
Critério de aceite definido: como saberemos que a solução funciona

Quem vai conduzir

Seu professor no Inteli Camp

Apresentação

🔗 /in/afonsolelis

Afonso Cesar Lelis Brandão

Software Engineer · Data Engineer · Industrial Engineer · Pesquisador (ATAM)

Pesquisador, consultor e professor nas áreas de engenharia de dados e software. Desde 2023 leciona e mentora alunos em Engenharia de Software, Estruturas de Dados, Sistemas ERP e Big Data.

Engenharia de Software Engenharia de Dados Big Data & Cloud ERP

Professor & Acadêmico

Inteli · Mackenzie · ESPM · Senac — desde 2023

Software Eng. & Data Analytics

Dasa — 2022–2023

Coordenador / Professor

UNAMA — 5 cursos de engenharia

Co-fundador

1950colab — desde 2016

O que é uma Spec e por que ela existe

Antes de construir, é preciso entender o que se vai construir

Spec · Conceito

📄 O que é uma Spec

Documento que descreve o problema, não a solução
Define quem usa, o que precisa e como saberemos que funcionou
Evita o ciclo de "construir, descobrir que estava errado, reconstruir"
Em 5 dias de bootcamp, tempo perdido não volta — spec bem feita é velocidade

🚫 Sem spec, o que acontece

O grupo constrói coisas diferentes sem perceber
A IA recebe instruções vagas → gera resultados inconsistentes
Na hora da apresentação, a banca pergunta "mas quem usa isso?" e ninguém sabe responder
Refatorar às 15h de quinta-feira é o pior pesadelo do camp

✅ Com spec, o que muda

Todos do grupo falam a mesma língua
Os prompts do Dia 3 têm base concreta para partir
O critério de aceite já está definido antes de escrever código
A apresentação final conta uma história coerente do começo ao fim

⏱️ Quanto tempo dedicar

Hoje: 1h para construir a spec com o briefing do parceiro em mãos
Não é um documento longo — é um conjunto de respostas precisas
Se não conseguir responder algum campo, é sinal de que falta entendimento: pergunte ao professor

🧭 Duas bússolas do engenheiro de software

Vocês não precisam decorar — são as referências que os profissionais usam. Hoje, na versão leve.

Fundamentos

O mapa do conhecimento

📚 SWEBOK 4.0

É o guia que organiza tudo o que um engenheiro de software precisa saber, dividido em áreas — entre elas Requisitos e Design, que usaremos hoje.

Pensem nele como o índice de um livro gigante da profissão
Hoje abrimos apenas o capítulo de requisitos

A régua de qualidade

📐 ISO/IEC 25010

É a norma que define o que torna um software "bom" — características como usabilidade, desempenho, segurança e confiabilidade.

Serve para escrever os Requisitos Não Funcionais
Responde "funciona bem?", não apenas "funciona?"

Por que isso importa hoje

Essas duas referências guiam o caminho que vamos percorrer: da necessidade do parceiro até a tecnologia que vamos usar.

🔄 Da necessidade do parceiro à spec

O parceiro descreve um problema; nós o traduzimos em especificação

Tradução

🗣️ O que o parceiro diz

Azul Linhas Aéreas

Criar um agente de IA que apoie o processo seletivo, analisando as entrevistas e organizando um funil de seleção.

Isso é uma necessidade: real e legítima, mas ainda vaga para construir.

🧩 O que nós produzimos

Traduzimos a necessidade em cinco camadas, que respondem uma pergunta cada:

Por quê? → Business Drivers
O quê? → Requisitos Funcionais
Quão bem? → Requisitos Não Funcionais
Como? → Arquitetura
Com o quê? → Tecnologia

🗺️ As 5 visões: da necessidade à tecnologia

Cada camada responde uma pergunta e prepara a seguinte

Visão geral

Por quêBusiness Drivers
O motivo de negócio — o que o parceiro ganha com a solução
O quêRequisitos Funcionais
O que a solução precisa fazer
Quão bemRequisitos Não Funcionais
A qualidade esperada — orientada pela ISO/IEC 25010
ComoArquitetura
Como as partes se organizam e se comunicam
Com o quêTecnologia
As ferramentas concretas que dão vida à solução

Camada	Pergunta	Exemplo — Azul
Business Driver	Por quê?	Acelerar e padronizar o processo seletivo, apoiando contratações melhores
R. Funcional	O quê?	Analisar as entrevistas, pontuar candidatos e montar o funil de seleção
R. Não Funcional	Quão bem?	Proteger os dados dos candidatos (LGPD), evitar viés e aplicar critérios iguais
Arquitetura	Como?	Dados da entrevista → interface → agente de IA → base de critérios
Tecnologia	Com o quê?	Lovable, para construir a interface e conectar a IA

🎯 O que é um Business Driver

Camada 1 — o "porquê" de negócio

Camada 1 · Por quê

Definição

Um business driver é o motivo de negócio que justifica o projeto: o resultado que a organização deseja alcançar.

Responde à pergunta "por que vale a pena construir isto?"
Fala de valor — custo, tempo, satisfação, reputação
Não menciona telas nem código

Exemplo — Azul

Acelerar a triagem e reduzir o tempo do processo seletivo
Padronizar a avaliação e apoiar decisões de contratação mais justas
Liberar os recrutadores para as etapas que exigem julgamento humano

⚙️ O que é um Requisito Funcional

Camada 2 — o "o quê"

Camada 2 · O quê

Definição

Um requisito funcional descreve uma ação que a solução deve realizar — algo observável para quem a usa.

Costuma começar com um verbo: "o sistema deve..."
É verificável: dá para testar se acontece ou não
Uma função por requisito, sem ambiguidade

Exemplo — Azul

Analisar as respostas de uma entrevista segundo os critérios de avaliação
Pontuar e classificar os candidatos, organizando o funil de seleção
Resumir a entrevista comparando o candidato ao perfil da vaga

🛡️ O que é um Requisito Não Funcional

Camada 3 — o "quão bem", orientado pela ISO/IEC 25010

Camada 3 · Quão bem

Definição

Um requisito não funcional não descreve uma nova função, e sim a qualidade com que a solução funciona. É onde entra a ISO/IEC 25010. Num processo seletivo, isso inclui proteger os dados dos candidatos e evitar vieses na avaliação.

Quatro características (das oito da norma)

Usabilidade — fácil de entender e usar

Desempenho — responde rápido

Segurança — protege os dados

Confiabilidade — funciona sem falhar

Exemplo — Azul

Segurança: proteger os dados pessoais dos candidatos (LGPD)
Confiabilidade: aplicar os mesmos critérios a todos os candidatos
Usabilidade: deixar claro por que cada candidato foi pontuado
Desempenho: analisar uma entrevista em poucos segundos

🏗️ O que é Arquitetura

Camada 4 — o "como"

Camada 4 · Como

Definição

A arquitetura mostra como as partes da solução se organizam e conversam entre si — um desenho de caixas e setas.

Cada caixa tem uma responsabilidade
As setas mostram por onde a informação passa
Ainda não é a ferramenta — é a organização das partes

Exemplo — Azul

Dados da
entrevista → Interface do
recrutador → Agente
de IA → Base de
critérios

A base guarda os critérios de avaliação e os perfis de vaga que a IA usa para analisar cada entrevista.

🧰 Tecnologia — vamos usar o Lovable

Camada 5 — o "com o quê" (e por que ela vem por último)

Camada 5 · Com o quê

Definição

A tecnologia é o conjunto de ferramentas concretas que dão vida à arquitetura.

Vem por último: primeiro entendemos por quê, o quê, quão bem e como
Escolher a ferramenta antes de entender o problema é a principal fonte de retrabalho

Nossa escolha

💜 Lovable

Plataforma para criar aplicações web descrevendo o que se quer em linguagem natural
Permite ir do protótipo à solução com rapidez, sem começar o código do zero
Ideal para o ritmo do camp — foco no problema, não na configuração

Como decompor o problema

Atores, entidades, fluxo e critério de aceite

Spec · Método

🔍 As 4 perguntas da modelagem

Quem usa? — identifique o(s) ator(es): quem interage com a solução e com qual objetivo
O que entra? — quais dados ou informações o ator fornece para a IA agir
O que sai? — qual é o output que o ator recebe e o que ele faz com ele
Como sabemos que funcionou? — defina o critério de aceite: uma condição objetiva, mensurável

Dica

Desenhe o fluxo no papel antes de abrir o computador. Um diagrama de caixa com setas já é suficiente.

📐 Exemplo de decomposição

Ator

Analista de marketing da empresa parceira

Entrada

Briefing do produto: nome, público-alvo, tom de voz, palavras-chave proibidas

Saída

3 variações de copy para redes sociais, com hashtags e sugestão de formato visual

Critério de aceite

O copy gerado respeita o tom de voz, não contém palavras proibidas e tem menos de 280 caracteres

🔨 Mãos à obra — escrevam a spec

Atividade em grupo · cronômetro de 30 min rodando · preencham um campo de cada vez

⏱️ Metodologia Ativa

1. Problema central

Em uma frase: qual dor real do parceiro esta solução resolve?

2. Ator principal

Quem usa a solução? Qual é o objetivo dessa pessoa ao usá-la?

3. Entrada

Que dados ou informações o ator fornece? São obrigatórios ou opcionais?

4. Saída

O que o ator recebe? Em que formato? Com que nível de detalhe?

5. Restrições

O que a solução NÃO pode fazer? Que palavras, temas ou comportamentos são proibidos?

6. Critério de aceite

Como a banca vai avaliar se a solução funciona? Defina uma condição objetiva e verificável.

⏱️ 30 minutos — iniciem o cronômetro 👥 Grupo completo 📋 Briefing do parceiro em mãos ✋ Chame o professor para validar

🎓 Fechamento do Dia 1

Onde chegamos e o que vem amanhã

Fechamento

✅ Hoje você

Entendeu o desafio do parceiro e decompôs o problema
Identificou atores, entradas, saídas e restrições
Produziu e validou a spec do grupo
Definiu o critério de aceite da solução

➡️ Amanhã — Dia 2

Visita Técnica & Imersão no Parceiro
Observar o processo real e confirmar as premissas da spec
Voltar com a spec afiada para construir a solução

🧩 Lembre-se

A spec validada hoje é a fundação de tudo que vem depois. Se amanhã, na visita, o grupo perceber que algo mudou, atualizem a spec antes de construir.