❄️ Winter Bootcamp · July 2026 · Day 1 · Monday

Inteli Camp — Day 1

Spec & Problem Modeling

🎯 What we will do today

Understand the partner's challenge and decompose the problem
Learn what a spec is and why it prevents rework
Identify the actors, entities and flows of the solution
Fill in the group's spec and get it validated

🏁 Deliverable of the day

Group spec filled in and validated
Problem decomposed into actors, entities and main flow
Acceptance criteria defined: how we will know the solution works

Who will lead

Your instructor at Inteli Camp

Introduction

🔗 /in/afonsolelis

Afonso Cesar Lelis Brandão

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

Researcher, consultant and professor in the fields of data and software engineering. Since 2023 he has taught and mentored students in Software Engineering, Data Structures, ERP Systems and Big Data.

Software Engineering Data Engineering Big Data & Cloud ERP

Professor & Academic

Inteli · Mackenzie · ESPM · Senac — since 2023

Software Eng. & Data Analytics

Dasa — 2022–2023

Coordinator / Professor

UNAMA — 5 engineering programs

Co-founder

1950colab — since 2016

What a Spec is and why it exists

Before building, you must understand what you are going to build

Spec · Concept

📄 What a Spec is

A document describing the problem, not the solution
Defines who uses it, what they need and how we will know it worked
Avoids the cycle of "build, discover it was wrong, rebuild"
In a 5-day bootcamp, lost time never returns — a good spec is speed

🚫 Without a spec, what happens

The group builds different things without noticing
The AI receives vague instructions → produces inconsistent results
At presentation time, the panel asks "but who uses this?" and no one can answer
Refactoring at 3 p.m. on Thursday is the camp's worst nightmare

✅ With a spec, what changes

Everyone in the group speaks the same language
The Day 3 prompts have a concrete foundation to start from
The acceptance criteria are already defined before any code is written
The final presentation tells a coherent story from start to finish

⏱️ How much time to dedicate

Today: 1h to build the spec with the partner's briefing at hand
It is not a long document — it is a set of precise answers
If you cannot answer a field, it is a sign that understanding is missing: ask the instructor

🧭 Two compasses of the software engineer

You don't need to memorize them — they are the references professionals use. Today, the light version.

Fundamentals

The map of knowledge

📚 SWEBOK 4.0

The guide that organizes everything a software engineer needs to know, split into areas — among them Requirements and Design, which we use today.

Think of it as the table of contents of a giant book about the profession
Today we open only the requirements chapter

The quality ruler

📐 ISO/IEC 25010

The standard that defines what makes software "good" — characteristics such as usability, performance, security and reliability.

It is used to write the Non-Functional Requirements
It answers "does it work well?", not just "does it work?"

Why this matters today

These two references guide the path we will walk: from the partner's need to the technology we will use.

🔄 From the partner's need to the spec

The partner describes a problem; we translate it into a specification

Translation

🗣️ What the partner says

Azul Linhas Aéreas

Build an AI agent that supports Azul's hiring process, analyzing interviews and organizing a candidate selection funnel.

This is a need: real and legitimate, but still too vague to build.

🧩 What we produce

We translate the need into five layers, each answering one question:

Why? → Business Drivers
What? → Functional Requirements
How well? → Non-Functional Requirements
How? → Architecture
With what? → Technology

🗺️ The 5 views: from need to technology

Each layer answers a question and prepares the next

Overview

WhyBusiness Drivers
The business reason — what the partner gains from the solution
WhatFunctional Requirements
What the solution must do
How wellNon-Functional Requirements
The expected quality — guided by ISO/IEC 25010
HowArchitecture
How the parts are organized and communicate
With whatTechnology
The concrete tools that bring the solution to life

Layer	Question	Example — Azul
Business Driver	Why?	Speed up and standardize hiring, supporting better decisions
Functional Req.	What?	Analyze interviews, score candidates and build the selection funnel
Non-Functional Req.	How well?	Protect candidate data (LGPD), avoid bias and apply equal criteria
Architecture	How?	Interview data → interface → AI agent → criteria base
Technology	With what?	Lovable, to build the interface and connect the AI

🎯 What is a Business Driver

Layer 1 — the business "why"

Layer 1 · Why

Definition

A business driver is the business reason that justifies the project: the outcome the organization wants to achieve.

Answers "why is this worth building?"
Talks about value — cost, time, satisfaction, reputation
Does not mention screens or code

Example — Azul

Speed up screening and reduce the hiring cycle time
Standardize evaluation and support fairer hiring decisions
Free recruiters for the steps that require human judgment

⚙️ What is a Functional Requirement

Layer 2 — the "what"

Layer 2 · What

Definition

A functional requirement describes an action the solution must perform — something observable to whoever uses it.

Usually starts with a verb: "the system must..."
It is verifiable: you can test whether it happens
One function per requirement, no ambiguity

Example — Azul

Analyze an interview's answers against the evaluation criteria
Score and rank candidates, organizing the selection funnel
Summarize the interview, comparing the candidate to the role profile

🛡️ What is a Non-Functional Requirement

Layer 3 — the "how well", guided by ISO/IEC 25010

Layer 3 · How well

Definition

A non-functional requirement does not describe a new function, but the quality with which the solution works. This is where ISO/IEC 25010 comes in. In a hiring process, this includes protecting candidate data and avoiding bias in evaluation.

Four characteristics (of the standard's eight)

Usability — easy to understand and use

Performance — responds fast

Security — protects the data

Reliability — works without failing

Example — Azul

Security: protect the candidates' personal data (LGPD)
Reliability: apply the same criteria to every candidate
Usability: make clear why each candidate was scored
Performance: analyze an interview in a few seconds

🏗️ What is Architecture

Layer 4 — the "how"

Layer 4 · How

Definition

Architecture shows how the parts of the solution are organized and talk to each other — a drawing of boxes and arrows.

Each box has one responsibility
The arrows show where the information flows
It is not the tool yet — it is the organization of the parts

Example — Azul

Interview
data → Recruiter
interface → AI
agent → Criteria
base

The criteria base holds the evaluation criteria and role profiles the AI uses to analyze each interview.

🧰 Technology — we will use Lovable

Layer 5 — the "with what" (and why it comes last)

Layer 5 · With what

Definition

Technology is the set of concrete tools that bring the architecture to life.

It comes last: first we understand why, what, how well and how
Choosing the tool before understanding the problem is the main source of rework

Our choice

💜 Lovable

A platform to build web applications by describing what you want in natural language
Lets you go from prototype to solution quickly, without starting the code from scratch
Ideal for the pace of the camp — focus on the problem, not on setup

How to decompose the problem

Actors, entities, flow and acceptance criteria

Spec · Method

🔍 The 4 modeling questions

Who uses it? — identify the actor(s): who interacts with the solution and with what goal
What comes in? — which data or information the actor provides for the AI to act
What comes out? — what output the actor receives and what they do with it
How do we know it worked? — define the acceptance criteria: an objective, measurable condition

Tip

Draw the flow on paper before opening the computer. A box-and-arrow diagram is enough.

📐 Example decomposition

Actor

Marketing analyst at the partner company

Input

Product briefing: name, target audience, tone of voice, forbidden keywords

Output

3 copy variations for social media, with hashtags and a suggested visual format

Acceptance criteria

The generated copy respects the tone of voice, contains no forbidden words and is under 280 characters

🔨 Hands-on — write the spec

Group activity · 30-min timer running · fill in one field at a time

⏱️ Active Learning

1. Core problem

In one sentence: which real pain of the partner does this solution solve?

2. Primary actor

Who uses the solution? What is this person's goal when using it?

3. Input

What data or information does the actor provide? Are they required or optional?

4. Output

What does the actor receive? In what format? At what level of detail?

5. Constraints

What must the solution NOT do? Which words, topics or behaviors are forbidden?

6. Acceptance criteria

How will the panel assess whether the solution works? Define an objective, verifiable condition.

⏱️ 30 minutes — start the timer 👥 Full group 📋 Partner's briefing at hand ✋ Call the instructor to validate

🎓 Day 1 Wrap-up

Where we got to and what comes tomorrow

Wrap-up

✅ Today you

Understood the partner's challenge and decomposed the problem
Identified actors, inputs, outputs and constraints
Produced and validated the group spec
Defined the solution's acceptance criteria

➡️ Tomorrow — Day 2

Technical Visit & Immersion at the Partner
Observe the real process and confirm the spec's assumptions
Come back with a sharpened spec to build the solution

🧩 Remember

The spec validated today is the foundation of everything that comes after. If tomorrow, on the visit, the group realizes something has changed, update the spec before building.