🎯 Objetivo do dia
Sair da apresentação do desafio com uma spec validada: um documento curto e preciso que descreve o problema do parceiro, quem o vive, o que a solução recebe e entrega, e como saberemos que ela funcionou. Em um bootcamp de cinco dias, o tempo perdido não volta — uma spec bem feita é o que transforma esforço em velocidade.
📄 O que é uma spec e por que ela existe
Uma spec (do inglês specification) é um documento que descreve o problema, não a solução. Ela define quem usa, o que essa pessoa precisa e como saberemos que a necessidade foi atendida. A spec existe para evitar o ciclo mais caro do desenvolvimento: construir, descobrir que estava errado e reconstruir.
Sem spec vs. com spec
- Sem spec: cada integrante do grupo constrói coisas diferentes sem perceber; a IA recebe instruções vagas e gera resultados inconsistentes; na apresentação, ninguém sabe responder "mas quem usa isso?".
- Com spec: todos falam a mesma língua; os prompts do Dia 2 partem de uma base concreta; o critério de aceite já está definido antes de escrever a primeira linha de código.
🧭 Duas bússolas do engenheiro de software
Antes de traduzir a necessidade do parceiro em uma especificação, convém conhecer duas referências que orientam o trabalho de engenharia de software. Não é necessário memorizá-las: elas indicam a direção do caminho que percorreremos, da necessidade até a tecnologia.
SWEBOK 4.0 — o mapa do conhecimento
O SWEBOK (Software Engineering Body of Knowledge) organiza todo o conhecimento que um engenheiro de software precisa dominar, dividido em áreas — entre elas Requisitos e Design, que empregaremos hoje. Funciona como o índice de um livro extenso da profissão; neste dia, abrimos apenas o capítulo de requisitos.
ISO/IEC 25010 — a régua de qualidade
A norma ISO/IEC 25010 define o que torna um software adequado, por meio de oito características de qualidade — entre elas usabilidade, desempenho, segurança e confiabilidade. É a referência para escrever os requisitos não funcionais: responde à pergunta "funciona bem?", e não apenas "funciona?".
🔄 Da necessidade do parceiro à especificação
O parceiro apresenta um problema em linguagem cotidiana. A Azul Linhas Aéreas, por exemplo, descreve a necessidade assim: "Criar um agente de IA que apoie o processo seletivo, analisando as entrevistas e organizando um funil de seleção". Trata-se de uma necessidade real e legítima, porém ainda vaga para construir: não indica o que exatamente a solução deve fazer, com que qualidade nem como será organizada.
O trabalho de especificação consiste em traduzir essa necessidade em cinco camadas, cada uma respondendo a uma pergunta e preparando a seguinte.
🗺️ As cinco visões: da necessidade à tecnologia
As cinco visões formam um fluxo — Business Drivers (por quê) → Requisitos Funcionais (o quê) → Requisitos Não Funcionais (quão bem, orientados pela ISO/IEC 25010) → Arquitetura (como) → Tecnologia (com o quê). Percorrê-las na ordem garante que a solução seja construída sobre o entendimento do problema, e não sobre uma escolha precipitada de ferramenta.
| Camada | Pergunta | Exemplo — Azul |
|---|---|---|
| Business Driver | Por quê? | Acelerar e padronizar o processo seletivo, apoiando contratações melhores |
| Requisito Funcional | O quê? | Analisar as entrevistas, pontuar candidatos e montar o funil de seleção |
| Requisito 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 |
A seguir, cada camada em detalhe, com a respectiva aplicação ao caso da Azul.
Camada 1 — Business Drivers (por quê)
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?". Refere-se a valor — custo, tempo, satisfação, reputação — e 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.
Camada 2 — Requisitos Funcionais (o quê)
Um requisito funcional descreve uma ação que a solução deve realizar — algo observável para quem a utiliza. Costuma iniciar por um verbo ("o sistema deve...") e é verificável: é possível testar se acontece ou não. Cada requisito descreve uma única função, 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.
Camada 3 — Requisitos Não Funcionais (quão bem)
Um requisito não funcional não acrescenta uma nova função; especifica a qualidade com que a solução funciona. É onde se aplica a ISO/IEC 25010. Num processo seletivo, isso inclui proteger os dados dos candidatos e evitar vieses na avaliação. Das oito características da norma, quatro são especialmente úteis neste desafio.
Quatro características de qualidade (ISO/IEC 25010)
- Usabilidade — fácil de entender e de utilizar.
- Desempenho — responde com rapidez.
- 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.
Camada 4 — Arquitetura (como)
A arquitetura mostra como as partes da solução se organizam e se comunicam entre si — um desenho de caixas e setas. Cada caixa tem uma responsabilidade; as setas indicam por onde a informação passa. Ainda não é a ferramenta, e sim 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.
Camada 5 — Tecnologia (com o quê)
A tecnologia é o conjunto de ferramentas concretas que dão vida à arquitetura. Vem por último: primeiro compreende-se o porquê, o quê, o quão bem e o como. Escolher a ferramenta antes de compreender o problema é a principal fonte de retrabalho.
Nossa escolha — Lovable
A ferramenta adotada nesta edição é o Lovable, plataforma para criar aplicações web descrevendo em linguagem natural o que se deseja.
- Permite ir do protótipo à solução com rapidez, sem escrever o código do zero.
- Adequada ao ritmo do camp, por manter o foco no problema em vez da configuração.
🔍 Como decompor o problema
Modelar é responder quatro perguntas, na ordem. Se você não consegue responder alguma delas, é sinal de que falta entendimento — pergunte ao professor antes de seguir.
As 4 perguntas da modelagem
- Quem usa? Identifique o ator: 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 e verificável.
Antes de abrir o computador, desenhe o fluxo no papel. Um diagrama de caixas com setas (ator → entrada → IA → saída) já é suficiente para alinhar o grupo.
📐 Exemplo de decomposição
| Campo | Exemplo |
|---|---|
| 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 respeita o tom de voz, não contém palavras proibidas e tem menos de 280 caracteres |
📋 Template da spec — preencha em grupo
Os 6 campos da spec
- Problema central: em uma frase, qual dor real do parceiro esta solução resolve.
- Ator principal: quem usa a solução e qual é o objetivo dessa pessoa.
- Entrada: que dados o ator fornece; quais são obrigatórios e quais opcionais.
- Saída: o que o ator recebe, em que formato e com que nível de detalhe.
- Restrições: o que a solução não pode fazer; palavras, temas ou comportamentos proibidos.
- Critério de aceite: a condição objetiva pela qual a banca avaliará se a solução funciona.
🏁 Entregável
🧩 O desafio desta edição
Briefing do case
- Parceiro: [marca/organização parceira]
- Contexto: [contexto do produto ou serviço]
- Problema: [descreva o problema real que os alunos vão resolver com IA]
- Output da solução: [tipo de output] para [público-alvo]
➡️ Próximo dia
Dia 2 — Prompts a partir da Modelagem: transformar cada campo da spec em instruções precisas para a IA, construindo prompts parametrizáveis que guiam a solução.