paulasilvatech ASP Personas do SDLC Agêntico v1.0.0
EN PT ES
03 product · Discovery

Engenheiro de Requisitos

Codifica requisitos em EARS.

Atualizado: 2026-04-24 14 seções Baixar .zip

O Requirements Engineer é a persona que codifica, decompõe e rastreia requisitos com disciplina. Em um SDLC AI-native, o Requirements Engineer opera uma pilha de primitivas validadas que converte intenção em draft em cláusulas EARS auditáveis.

Resumo executivo

O Requirements Engineer decompõe especificações aprovadas em requisitos EARS atômicos e testáveis, e mantém a matriz de rastreabilidade de requisito para teste para artefato implantado. Em um SDLC AI-native, o Requirements Engineer opera dentro da fase de Discovery com um conjunto fixo de primitivas: um agente de encoding EARS, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são arquivos de requisitos atômicos, análises de gap, relatórios de rastreabilidade e registros de review de requisitos.

Papel e responsabilidades

Pense no Requirements Engineer como um codificador jurídico que transforma a intenção do legislador em estatutos numerados que os tribunais podem aplicar sem interpretação. O legislador propõe, o codificador transforma, e todo julgamento futuro cita uma cláusula pelo número. Em um SDLC AI-native, o Product Owner propõe no SPECIFICATION.md, o Requirements Engineer codifica em forma EARS atômica, e todo teste, commit e release note cita um ID de requisito.

Responsabilidades primárias:

  • Decompor toda spec aprovada em requisitos EARS atômicos sob docs/requirements/
  • Manter a matriz de rastreabilidade que liga cada requisito a seus critérios de aceitação, testes, pull requests e artefatos implantados
  • Rodar gap scans para detectar requisitos sem testes, testes sem requisitos e deploys sem nenhum dos dois
  • Rodar reviews de requisitos com o Product Owner, Software Architect e QA Engineer em gates definidos
  • Operar o agente EARS Encoder e os prompts /ears, /traceability, /gap-scan, /requirement-review
  • Governar o log de mudanças de requisitos, garantindo que toda mudança referencie um diff de spec aprovado
  • Publicar o relatório de prontidão do qual os releases dependem

Jobs to be done

  1. Como Requirements Engineer, eu quero decompor uma spec aprovada em requisitos atômicos em horas, para que o desenvolvimento nunca fique bloqueado aguardando clarificação.
  2. Como Requirements Engineer, eu quero todo requisito em forma EARS estrita, para que agentes e humanos o parseiem de modo idêntico.
  3. Como Requirements Engineer, eu quero que a matriz de rastreabilidade se regenere a cada merge, para que as respostas de auditoria estejam sempre atuais.
  4. Como Requirements Engineer, eu quero gap scans rodando em todo pull request, para que testes e requisitos nunca divirjam silenciosamente.
  5. Como Requirements Engineer, eu quero que reviews de requisitos sejam estruturadas e registradas, para que decisões persistam para além da reunião.
  6. Como Requirements Engineer, eu quero que o relatório de prontidão recuse o release se qualquer gap estiver sem resolução, para que a disciplina de escopo seja enforçada no gate.

Dores antes da era AI-native

  1. Specs grossas demais para testar. Specs de alto nível não podem ser vinculadas a casos de teste. Developers improvisam decomposição de modo inconsistente.
  2. Rastreabilidade construída uma vez e abandonada. Planilhas de matriz ficam defasadas dentro de uma sprint. Preparação de auditoria se torna uma reconstrução.
  3. Gaps descobertos no release. Testes ausentes e features órfãs aparecem no gate de release, forçando atrasos no cronograma.
  4. Reviews sem registros. Clarificações acontecem verbalmente. Na próxima sprint, a mesma pergunta é feita de novo.
  5. Churn de requisitos não rastreado. Mudanças são feitas no próprio lugar sem histórico de diff. Regressões de escopo são invisíveis.

Fluxo diário AI-native

O Requirements Engineer opera um loop fixo todo dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, além de um pequeno catálogo de MCPs validados para contexto externo.

Setup da manhã

  1. Abra o repositório no Visual Studio Code. GitHub Copilot Chat carrega o AGENTS.md e as instruções escopadas de requisitos.
  2. Puxe o último main e revise mudanças noturnas de spec feitas pelo Product Owner.
  3. Rode /gap-scan para produzir o relatório de gap atual: requisitos sem testes, testes sem requisitos, deploys sem nenhum dos dois.
  4. Revise o dashboard de rastreabilidade gerado a partir da telemetria do Azure MCP Server e do GitHub MCP.

Execução no meio do dia

  1. Decomposição. Invoque /ears em cada nova seção da spec. O agente EARS Encoder produz requisitos atômicos com IDs únicos, cada um em forma WHEN ... THE system SHALL ... estrita.
  2. Rastreabilidade. Invoque /traceability para vincular cada novo requisito a testes, pull requests e registros de deploy existentes. O agente atualiza a matriz e sinaliza órfãos.
  3. Fechamento de gap. Para cada gap sinalizado no scan matinal, ou escreva o requisito ausente, levante uma tarefa de teste para o QA Engineer, ou abra um ADR se uma mudança arquitetural for necessária.
  4. Sincronização entre personas. Use o Microsoft 365 Agents SDK MCP para levantar pedidos de clarificação no canal do Teams quando a intenção da spec for ambígua.

Revisão no fim da tarde

  1. Invoque /requirement-review para rodar a sessão de review estruturada com o Product Owner, Software Architect e QA Engineer. O agente prepara a pauta a partir dos diffs do dia e registra decisões contra os IDs de requisito.
  2. Abra um pull request nos arquivos de requisito. GitHub Copilot Code Review comenta em conformidade EARS; revisores humanos aprovam o conteúdo.
  3. Atualize o relatório de prontidão. Um hook de post-merge regenera o relatório com contagens de gap e listas de bloqueadores.
  4. Publique o digest diário de requisitos no canal do Teams do produto via Microsoft 365 Agents SDK.

Primitivas recomendadas

Agente

AgenteArquivoPropósito
ears-encoder.github/agents/ears-encoder.agent.mdDecompor specs em requisitos EARS atômicos, manter rastreabilidade, rodar gap scans

O EARS Encoder usa claude-sonnet-4-6 por padrão. Ferramentas: read, edit, search, grep, glob. Sem acesso a bash. Extended thinking é habilitado apenas para /gap-scan, onde a correlação entre documentos se beneficia de raciocínio profundo.

Slash prompts

ComandoArquivoPropósito
/ears.github/prompts/ears.prompt.mdDecompor uma seção da spec em requisitos EARS atômicos
/traceability.github/prompts/traceability.prompt.mdVincular requisitos a testes, PRs e deploys, regenerar a matriz
/gap-scan.github/prompts/gap-scan.prompt.mdDetectar requisitos sem testes, testes sem requisitos, deploys órfãos
/requirement-review.github/prompts/requirement-review.prompt.mdPreparar e registrar a sessão estruturada de review

Instruções escopadas

applyTo com escopo reduz o custo em tokens em aproximadamente 68 por cento comparado a instruções globais.

Escopo (applyTo)ArquivoPropósito
docs/requirements/**/*.md.github/instructions/requirements.instructions.mdFormato EARS atômico, schema de ID, regras de cross-reference
docs/traceability/**/*.md.github/instructions/traceability.instructions.mdSchema da matriz, regras de regeneração, formato de evidência de auditoria
docs/reviews/**/*.md.github/instructions/reviews.instructions.mdTemplate de pauta de review, formato de registro de decisão

Hooks

Hooks custam zero tokens de LLM. São a camada de governança mais forte para requisitos.

  • pre-commit: rejeitar qualquer arquivo de requisito com cláusulas não-atômicas ou não-EARS, ou com IDs duplicados
  • post-commit: regenerar a matriz de rastreabilidade e o relatório de prontidão
  • pre-merge: bloquear o merge de qualquer mudança de requisito que introduza um novo gap sem uma issue de follow-up vinculada

MCPs validados

MCPPropósitoDono
GitHub MCP ServerLer pull requests, testes e runs do Actions para popular a matriz de rastreabilidadeGitHub (oficial)
Azure DevOps MCP ServerLer work items do Azure Boards e planos de teste quando o time usa Azure DevOpsMicrosoft (oficial)
Azure MCP ServerConsultar Application Insights para confirmar que artefatos implantados correspondem a IDs de requisitoMicrosoft (oficial)
Microsoft Learn Docs MCPAncorar requisitos em superfícies de produto Microsoft em documentação atualMicrosoft (oficial)
Microsoft 365 Agents SDK MCPLevantar threads de clarificação no Teams e registrar decisões do OutlookMicrosoft (oficial)

Exemplos reais

Exemplo 1: decompor uma seção de spec aprovada

Entrada: Uma seção de spec sobre renovação de contrato cobrindo iniciação, elegibilidade e notificação, aprovada pelo Product Owner.

Invocação: /ears seguido de /traceability.

Saída esperada:

  1. Um diretório docs/requirements/contract-renewal/ com doze arquivos de requisito atômicos, cada um com um ID único e cláusula EARS estrita.
  2. Uma matriz de rastreabilidade regenerada que vincula três testes pré-existentes a dois dos novos requisitos e sinaliza os dez restantes como gaps.
  3. Um pull request com comentários do Copilot Code Review sobre forma da cláusula e consistência de ID.

Exemplo 2: fechamento de gap antes do release

Entrada: Um release candidate com 146 requisitos merged. O relatório matinal do /gap-scan sinaliza seis requisitos sem testes passando e dois testes sem requisitos.

Invocação: /gap-scan seguido de /requirement-review.

Saída esperada:

  1. Seis tarefas no GitHub Projects criadas via o GitHub MCP, cada uma vinculada à âncora do requisito e atribuída ao QA Engineer.
  2. Dois arquivos de requisito escritos para vincular os testes órfãos a IDs de requisito.
  3. Uma sessão de review registrada em docs/reviews/2026-q3-release-readiness.md com decisões taggeadas por ID de requisito.
  4. Uma atualização no relatório de prontidão que reabre o gate de release até que todos os oito itens fechem.

Anti-padrões

  1. Requisitos compostos. Cláusulas que juntam duas ou mais condições não podem ser testadas atomicamente. Mitigação: o agente /ears e o hook de pre-commit rejeitam cláusulas não-atômicas.
  2. Rastreabilidade manual. Planilhas não podem ser confiáveis na borda de uma sprint. Mitigação: a matriz se regenera no post-commit.
  3. Colisões silenciosas de ID. IDs reutilizados quebram trilhas de auditoria. Mitigação: o hook de pre-commit rejeita duplicatas em toda a árvore docs/requirements/.
  4. Reviews sem registros. Clarificações verbais evaporam. Mitigação: /requirement-review enforça uma decisão registrada para cada item de pauta.
  5. Gaps renunciados verbalmente. Um gap renunciado sem ADR ou issue de follow-up re-emerge no release. Mitigação: pre-merge bloqueia o caminho de renúncia.

KPIs e métricas de impacto

KPILinha baseMetaMedição
Requisitos em EARS atômico30 por cento100 por centoLinter de requisitos no GitHub Actions
Frescor da rastreabilidade, última regeneração7 dias< 1 horaTimestamp do hook de post-commit
Contagem de gap no gate de release140Relatório de prontidão
Tempo de ciclo de review de requisitos2 semanas< 1 semanaTimestamps de PR
Taxa de teste órfão12 por cento< 2 por centoSaída do gap scan
Tempo de resposta de consulta de auditoria1 dia< 1 horaLog de consultas da matriz de rastreabilidade

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualSpecs em prosa, decomposição ad-hoc, rastreabilidade construída à mão
L2AssistidoCopilot usado para polir o fraseamento do requisito, sem disciplina atômica
L3AumentadoAgente EARS Encoder, quatro slash prompts, instruções escopadas, matriz auto-gerada, gap scans em PR
L4AutônomoKit completo de primitivas, hooks enforçados, relatório de prontidão ao vivo, reviews registradas automaticamente, resposta de auditoria em até uma hora

Integração com outras personas

  • Do Product Owner: SPECIFICATION.md aprovado com requisitos EARS numerados como input canônico
  • Do Business Manager: outcomes atados a KPIs que informam priorização de gaps
  • Para o Software Architect: IDs de requisito estáveis que ancoram o CODEMAP.md e contratos de API
  • Para o QA Engineer: requisitos atômicos que guiam geração de casos de teste e relatórios de cobertura
  • Para o Developer: âncora de requisito em todo PR habilitando rastreabilidade de implementação
  • Para o Compliance Auditor: matriz regenerada como evidência de auditoria sob demanda
  • Para o Release Manager: relatório de prontidão gatekeeping do corte de release

Glossário

  • EARS: Easy Approach to Requirements Syntax. A forma canônica WHEN ... THE system SHALL ....
  • Requisito atômico: uma única cláusula testável com ID único, sem conjunções que introduzam condições independentes.
  • Matriz de rastreabilidade: tabela gerada vinculando cada requisito a critérios de aceitação, testes, pull requests e deploys.
  • Gap scan: varredura automatizada que detecta requisitos sem testes, testes sem requisitos e deploys sem nenhum dos dois.
  • Relatório de prontidão: documento gerado que resume o status do gate de release contra gaps abertos de requisito.
  • Review de requisitos: sessão estruturada e registrada que aprova ou adia mudanças de requisito com participantes nomeados.

Referências