Map of the existing system
The discovery arm reads the code and returns the map: stack and versions, structure, entry point, end-to-end request flow, routes, database and deploy.
Deliverable: platform map, with file and lineOcto for requirements and discovery · discovery and architect arms
Before the code, the request in writing.
Requirements are the first knowledge area in SWEBOK. Two Octo arms work at this step: discovery maps the system that already exists (stack, routes, request flow, database and deploy), and the architect turns the request into item-by-item requirements, with open questions and the definition of done in writing. Your company's tech lead approves the scope.
ArmsDiscovery and architectwork at this step
SWEBOK v4.0a1st of 18knowledge areas: requirements
Sources6listed at the end of the page
01
What Octo does in requirements.
Four possible deliverables. The scope and the definition of done are approved by the tech lead.
Request item by item
The architect breaks the request into numbered requirements, each with the criterion that says when it is done, so building and review work from the same text.
Deliverable: requirements with a definition of doneOpen questions
Whatever the code doesn't answer becomes a question for the team: the deploy process, decisions made outside the repository, business rules only someone knows.
Deliverable: list of questions for the tech leadSecurity requirements from the start
Security requirements come in alongside the functional ones, using the ASVS as the reference baseline and keeping in mind the privacy by design that the LGPD requires.
Deliverable: security requirements in the same list
02
Eight arms, one clear request.
The same Octo cycle, applied to this step. Each arm has a narrow role; your company's tech lead is in charge and approves.
-
Discovery
Maps the system
Stack, routes, request flow, database and deploy, with file and line for each point.
-
Data
Reads the database involved
Which tables and relationships the request touches, before anyone commits to a deadline.
-
Security
Surveys what needs protection
Login, roles and personal data the request reaches become security requirements.
-
Architecture
Writes the requirements
Item by item, with open questions and the definition of done in writing.
-
Development
Doesn't code yet
At this step the development arm only reads; coding starts after the plan is approved.
-
Review
Keeps the criterion
The reviewer will check the delivery against the same requirements, one by one.
-
Release
Notes the release path
How the system gets to production today, so the plan is compatible from the start.
-
Documentation
Records what was learned
The map and the team's answers go into the system dossier, so no one has to rediscover them.
Octo doesn't decide the scope. The tech lead answers the questions, approves the requirements and accepts the definition of done; legal requirements are validated by the team and the company's legal department.
03
Who does what in requirements.
What each arm delivers and what remains your team's decision.
| Step | Octo arm | Stays with the tech lead |
|---|---|---|
| Map the system | Discovery | Say what isn't in the code |
| Write the requirements | Architect | Approve the scope and the requirements |
| Define done | Architect | Accept the definition of done |
| Security and personal data requirements | Security and architect | Validate with legal and the data protection officer |
04
From request to routine.
Three steps. Each one only makes sense once the previous one has shown results on your team.
A proposal, not a promise
System map
Octo reads the system you already have and returns the map, without changing anything.
- Stack, routes and request flow
- Database and deploy
- Questions for the team
Request with a definition of done
Every new task starts with requirements and a definition of done in writing.
- Numbered requirements
- Questions answered before the code
Living dossier
The map is updated with every task delivered.
- Up-to-date platform map
- Dated decisions on record
05
Confirmed by source.
Each point below has a source published by the organization responsible for the standard, the specification or the tool, or in Brazilian federal law. The sources are in the next section.
8
points with a published source, each with its reference alongside.
- ConfirmedRequirements in SWEBOK
- Software requirements are the first of the 18 knowledge areas in SWEBOK v4, from the IEEE Computer Society.Source: IEEE Computer Society, SWEBOK
- ConfirmedKnown security requirements
- NIST SSDF practice PO.1 calls for development security requirements to be known at all times, so they apply throughout the software lifecycle.Source: NIST, SP 800-218 (SSDF 1.1), PO.1
- ConfirmedASVS as a baseline
- The OWASP ASVS is a set of security requirements for designing, developing and testing modern web applications and web services.Source: OWASP, ASVS
- ConfirmedPrivacy by design
- The LGPD requires security measures to be observed from the design phase of the product or service.Source: Planalto, Law 13.709/2018, art. 46, § 2
- ConfirmedInterview until the spec
- The documentation for Claude Code, the tool under Octo, describes asking the tool to interview the person until it can write the specification to a file.Source: Claude Code, best practices
- ConfirmedDefinition of done
- With the specification written, building starts with a clean context and a written definition of done.Source: Claude Code, best practices
- ConfirmedTrace the flow
- For an unfamiliar system, the documentation shows how to ask for an overview and trace a process end to end, such as login from the front end to the database.Source: Claude Code, common workflows
- ConfirmedWhat isn't in the code
- What isn't in the repository, such as a deploy process that lives in someone's head, has to be stated by that person.Source: Claude Code, best practices
06
What Octo does and what stays with you.
Octo prepares everything, but does not sign. The document of record stays with whoever is accountable for it.
Octo prepares
Maps, plans, codes on the task branch, reviews with evidence and prepares the release: plans, code, reviews, security reports and the system dossier.
Deliverable: material ready for reviewYour team reviews
Whoever is in charge is the company's tech lead or senior developer: they approve the plan, review the PR and merge it. Nothing goes to production without their approval.
Step: approval by whoever is in chargeWho signs and is accountable
Octo does not sign and is not accountable for the system. The tech lead accepts the risk and is accountable for the system in production; a security report or opinion is signed by a professional at the company.
Accountable: the company's tech lead
07
Sources.
SWEBOK from the IEEE Computer Society, NIST, OWASP, federal legislation published on the Planalto website and the Claude Code documentation. Accessed October 31, 2026.
- IEEE Computer Society: SWEBOK v4.0aThe 18 knowledge areas of software engineering
- NIST: SP 800-218, SSDF 1.1 (February 2022)PO.1, security requirements
- OWASP: ASVSApplication security requirements
- Planalto: Law 13.709/2018 (LGPD)Art. 46, § 2
- Claude Code: best practicesSpecification, definition of done and what lives outside the code
- Claude Code: common workflowsOverview and end-to-end tracing
Your system, described in writing.
The assessment starts by reading the system you already have, without changing anything. You get the map and the open questions and decide with them in hand.