Mapa do sistema existente
O braço de descoberta lê o código e devolve o mapa: stack e versões, estrutura, ponto de entrada, fluxo da requisição de ponta a ponta, rotas, banco e deploy.
Entrega: mapa da plataforma, com arquivo e linhaOcto para requisitos e descoberta · braços de descoberta e arquiteto
Antes do código, o pedido por escrito.
Requisitos são a primeira área de conhecimento do SWEBOK. Nesta etapa atuam dois braços do Octo: o de descoberta mapeia o sistema que já existe (stack, rotas, fluxo da requisição, banco e deploy) e o arquiteto transforma o pedido em requisitos item a item, com as perguntas abertas e o critério de pronto por escrito. Quem aprova o escopo é o líder técnico da sua empresa.
BraçosDescoberta e arquitetoatuam nesta etapa
SWEBOK v4.0a1ª de 18áreas de conhecimento: requisitos
Fontes6listadas no fim da página
01
O que o Octo faz nos requisitos.
Quatro entregas possíveis. O escopo e o critério de pronto são aprovados pelo líder técnico.
Pedido item a item
O arquiteto quebra o pedido em requisitos numerados, cada um com o critério que diz quando está pronto, para a construção e a revisão usarem o mesmo texto.
Entrega: requisitos com critério de prontoPerguntas abertas
O que o código não responde vira pergunta para a equipe: o processo de deploy, as decisões tomadas fora do repositório, as regras de negócio que só alguém conhece.
Entrega: lista de perguntas para o líder técnicoRequisitos de segurança desde o início
Os requisitos de segurança entram junto com os funcionais, tomando o ASVS como base de referência e lembrando a segurança desde a concepção que a LGPD pede.
Entrega: requisitos de segurança na mesma lista
02
Oito braços, um pedido claro.
O mesmo ciclo do Octo, aplicado a esta etapa. Cada braço tem um papel estreito; quem comanda e aprova é o líder técnico da sua empresa.
-
Descoberta
Mapeia o sistema
Stack, rotas, fluxo da requisição, banco e deploy, com arquivo e linha de cada ponto.
-
Dados
Lê o banco envolvido
Quais tabelas e relações o pedido toca, antes de alguém prometer prazo.
-
Segurança
Levanta o que protege
Login, perfis e dados pessoais que o pedido alcança viram requisito de segurança.
-
Arquitetura
Escreve os requisitos
Item a item, com perguntas abertas e o critério de pronto por escrito.
-
Desenvolvimento
Ainda não programa
Nesta etapa o braço de desenvolvimento só lê; o código começa depois do plano aprovado.
-
Revisão
Guarda o critério
O revisor vai conferir a entrega contra os mesmos requisitos, um por um.
-
Publicação
Anota o caminho de publicação
Como o sistema vai para produção hoje, para o plano já nascer compatível.
-
Documentação
Registra o que se aprendeu
O mapa e as respostas da equipe vão para o dossiê do sistema, para ninguém redescobrir.
O Octo não decide o escopo. O líder técnico responde as perguntas, aprova os requisitos e aceita o critério de pronto; requisito legal é validado pela equipe e pelo jurídico da empresa.
03
Quem faz o quê nos requisitos.
O que cada braço entrega e o que continua sendo decisão da sua equipe.
| Etapa | Braço do Octo | Fica com o líder técnico |
|---|---|---|
| Mapear o sistema | Descoberta | Dizer o que não está no código |
| Escrever os requisitos | Arquiteto | Aprovar o escopo e os requisitos |
| Definir o pronto | Arquiteto | Aceitar o critério de pronto |
| Requisito de segurança e de dados pessoais | Segurança e arquiteto | Validar com o jurídico e o encarregado |
04
Do pedido à rotina.
Três degraus. Cada um só faz sentido depois que o anterior mostrou resultado na sua equipe.
Proposta, não promessa
Mapa do sistema
O Octo lê o sistema que você já tem e devolve o mapa, sem alterar nada.
- Stack, rotas e fluxo da requisição
- Banco e deploy
- Perguntas para a equipe
Pedido com critério de pronto
Cada atividade nova nasce com requisitos e critério de pronto por escrito.
- Requisitos numerados
- Perguntas respondidas antes do código
Dossiê vivo
O mapa é atualizado a cada atividade entregue.
- Mapa da plataforma em dia
- Decisões registradas com data
05
Confirmado em fonte.
Cada ponto abaixo tem fonte publicada pela organização responsável pela norma, pela especificação ou pela ferramenta, ou em lei federal. As fontes estão na seção seguinte.
8
pontos com fonte publicada, cada um com a referência indicada ao lado.
- ConfirmadoRequisitos no SWEBOK
- Requisitos de software são a primeira das 18 áreas de conhecimento do SWEBOK v4, da IEEE Computer Society.Fonte: IEEE Computer Society, SWEBOK
- ConfirmadoRequisitos de segurança conhecidos
- A prática PO.1 do NIST SSDF pede que os requisitos de segurança do desenvolvimento sejam conhecidos o tempo todo, para valer em todo o ciclo de vida do software.Fonte: NIST, SP 800-218 (SSDF 1.1), PO.1
- ConfirmadoASVS como base
- O OWASP ASVS é um conjunto de requisitos de segurança para projetar, desenvolver e testar aplicações web e serviços web modernos.Fonte: OWASP, ASVS
- ConfirmadoSegurança desde a concepção
- A LGPD pede que as medidas de segurança sejam observadas desde a fase de concepção do produto ou do serviço.Fonte: Planalto, Lei 13.709/2018, art. 46, § 2º
- ConfirmadoEntrevista até a especificação
- A documentação do Claude Code, a ferramenta sob o Octo, descreve pedir à ferramenta que entreviste a pessoa até conseguir escrever a especificação num arquivo.Fonte: Claude Code, boas práticas
- ConfirmadoDefinição de pronto
- Com a especificação escrita, a construção começa com contexto limpo e uma definição de pronto por escrito.Fonte: Claude Code, boas práticas
- ConfirmadoRastrear o fluxo
- Para um sistema desconhecido, a documentação mostra como pedir a visão geral e rastrear um processo de ponta a ponta, como o login do front-end até o banco.Fonte: Claude Code, fluxos de trabalho comuns
- ConfirmadoO que não está no código
- O que não está no repositório, como um processo de deploy que vive na cabeça de alguém, precisa ser dito pela pessoa.Fonte: Claude Code, boas práticas
06
O que o Octo faz e o que fica com vocês.
O Octo prepara tudo, mas não assina. O documento que vale continua com quem responde por ele.
O Octo prepara
Mapeia, planeja, programa na branch da atividade, revisa com evidência e prepara a publicação: planos, código, revisões, relatórios de segurança e o dossiê do sistema.
Entrega: material pronto para conferirA sua equipe confere
Quem comanda é o líder técnico ou o desenvolvedor sênior da empresa: aprova o plano, revisa o PR e faz o merge. Nada vai para produção sem a aprovação de quem comanda.
Etapa: aprovação por quem comandaQuem assina e responde
O Octo não assina e não responde pelo sistema. Quem aceita o risco e responde pelo sistema em produção é o líder técnico; laudo ou parecer de segurança é assinado por profissional da empresa.
Responsável: líder técnico da empresa
07
Fontes.
SWEBOK da IEEE Computer Society, NIST, OWASP, legislação federal publicada no Planalto e documentação do Claude Code. Consultadas em 31/10/2026.
- IEEE Computer Society: SWEBOK v4.0aAs 18 áreas de conhecimento da engenharia de software
- NIST: SP 800-218, SSDF 1.1 (fevereiro de 2022)PO.1, requisitos de segurança
- OWASP: ASVSRequisitos de segurança de aplicação
- Planalto: Lei 13.709/2018 (LGPD)Art. 46, § 2º
- Claude Code: boas práticasEspecificação, definição de pronto e o que fica fora do código
- Claude Code: fluxos de trabalho comunsVisão geral e rastreio de ponta a ponta
O seu sistema descrito por escrito.
O diagnóstico começa lendo o sistema que você já tem, sem alterar nada. Você recebe o mapa e as perguntas abertas e decide com eles na mão.