Day 1 — Spec & Problem Modeling

Without a spec vs. with a spec

• Without a spec: each team member builds different things without realizing it; the AI receives vague instructions and produces inconsistent results; during the presentation, nobody can answer "but who uses this?".
• With a spec: everyone speaks the same language; the Day 2 prompts start from a concrete base; the acceptance criteria are already defined before the first line of code is written.

The two references

• SWEBOK 4.0 — the map of knowledge. A guide that organizes everything a software engineer needs to know, divided into areas. Two of those areas, Requirements and Design, are the ones we use today. Think of it as the table of contents of a large book about the profession; we will open only the requirements chapter.
• ISO/IEC 25010 — the quality ruler. A standard that defines what makes software "good" through eight quality characteristics, such as usability, performance, security and reliability. It answers the question "does it work well?", not only "does it work?". We use it later to write the non-functional requirements.

What the partner says

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

1. Business Drivers — the "why"

A business driver is the business reason that justifies the project: the outcome the organization wants to achieve. It talks about value — cost, time, satisfaction, reputation — and never mentions screens or code. It answers "why is this worth building?".

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

2. Functional Requirements — the "what"

A functional requirement describes an action the solution must perform — something observable to whoever uses it. It usually starts with a verb ("the system must..."), it is verifiable (you can test whether it happens), and it describes one function at a time, without 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

3. Non-Functional Requirements — the "how well"

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: it gives us the characteristics used to define that quality. Four of the standard's eight characteristics are enough for us today:

• 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

In a hiring process, quality also means avoiding bias: the evaluation must be fair and rely only on the defined criteria, never on characteristics unrelated to the role.

4. Architecture — the "how"

Architecture shows how the parts of the solution are organized and how they talk to each other — a drawing of boxes and arrows. Each box has a single responsibility, and each arrow shows 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.

5. Technology — the "with what"

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: in this edition we will use 💜 Lovable, a platform that lets you build web applications by describing what you want in natural language. It takes the group from prototype to a working solution quickly, without writing the code from scratch — which suits the pace of the camp and keeps the focus on the problem rather than on setup.

Example — Azul: use Lovable to build the recruiter interface and connect it to the AI agent defined in the architecture view.

The 4 modeling questions

1. Who uses it? Identify the actor: who interacts with the solution and with what objective.
2. What comes in? Which data or information the actor provides for the AI to act on.
3. What comes out? What is the output the actor receives and what they do with it.
4. How do we know it worked? Define the acceptance criteria — an objective, verifiable condition.

The 6 spec fields

1. Core problem: in one sentence, which real pain of the partner this solution solves.
2. Main actor: who uses the solution and what that person's objective is.
3. Input: what data the actor provides; which are required and which are optional.
4. Output: what the actor receives, in what format, and with what level of detail.
5. Constraints: what the solution cannot do; prohibited words, topics, or behaviors.
6. Acceptance criteria: the objective condition by which the panel will assess whether the solution works.

Case briefing

• Partner: [partner brand/organization]
• Context: [product or service context]
• Problem: [describe the real problem students will solve with AI]
• Solution output: [type of output] for [target audience]