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

Requirements Engineer

Codifica requisitos en EARS.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El Requirements Engineer es la persona que codifica, descompone y traza requisitos con disciplina. En un SDLC AI-native, el Requirements Engineer opera un stack de primitivas validadas que convierten la intención en borrador en cláusulas EARS auditables.

Resumen ejecutivo

El Requirements Engineer descompone las especificaciones aprobadas en requisitos EARS atómicos y testables, y mantiene la matriz de trazabilidad desde el requisito hasta la prueba y el artefacto desplegado. En un SDLC AI-native, el Requirements Engineer opera dentro de la fase de Discovery con un conjunto fijo de primitivas: un agente de codificación EARS, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son archivos atómicos de requisitos, análisis de brechas, reportes de trazabilidad y registros de revisión de requisitos.

Rol y responsabilidades

Piensa en el Requirements Engineer como un codificador legal que convierte la intención de un legislador en estatutos numerados que los tribunales pueden aplicar sin interpretación. El legislador propone, el codificador transforma y cada juicio futuro cita una cláusula por número. En un SDLC AI-native, el Product Owner propone en SPECIFICATION.md, el Requirements Engineer codifica en forma EARS atómica, y cada prueba, commit y release note cita un ID de requisito.

Responsabilidades principales:

  • Descomponer cada spec aprobado en requisitos EARS atómicos bajo docs/requirements/
  • Mantener la matriz de trazabilidad que enlaza cada requisito con sus criterios de aceptación, pruebas, pull requests y artefactos desplegados
  • Correr gap scans para detectar requisitos sin pruebas, pruebas sin requisitos y despliegues sin ninguno de los dos
  • Correr revisiones de requisitos con el Product Owner, el Software Architect y el QA Engineer en compuertas definidas
  • Operar el agente EARS Encoder y los prompts /ears, /traceability, /gap-scan, /requirement-review
  • Gobernar el log de cambios de requisitos, asegurando que cada cambio referencie un diff de spec aprobado
  • Publicar el reporte de readiness del que dependen los releases

Jobs to be done

  1. Como Requirements Engineer, quiero descomponer un spec aprobado en requisitos atómicos en horas, para que el desarrollo nunca se bloquee esperando aclaraciones.
  2. Como Requirements Engineer, quiero cada requisito en forma EARS estricta, para que agentes y humanos lo parseen de forma idéntica.
  3. Como Requirements Engineer, quiero que la matriz de trazabilidad se regenere en cada merge, para que las respuestas de auditoría siempre estén actualizadas.
  4. Como Requirements Engineer, quiero que los gap scans corran en cada pull request, para que pruebas y requisitos nunca diverjan en silencio.
  5. Como Requirements Engineer, quiero que las revisiones de requisitos sean estructuradas y registradas, para que las decisiones persistan más allá de la reunión.
  6. Como Requirements Engineer, quiero que el reporte de readiness rechace el release si alguna brecha está sin resolver, para que la disciplina de alcance se imponga en la compuerta.

Puntos de dolor antes de la era AI-native

  1. Specs demasiado gruesos para probar. Los specs de alto nivel no se pueden amarrar a casos de prueba. Los developers improvisan la descomposición de forma inconsistente.
  2. Trazabilidad construida una vez y abandonada. Las hojas de cálculo de matriz quedan obsoletas dentro de un sprint. La preparación de auditoría se vuelve una reconstrucción.
  3. Brechas descubiertas en el release. Las pruebas faltantes y las features huérfanas afloran en la compuerta de release, forzando retrasos en el cronograma.
  4. Revisiones sin registros. Las aclaraciones ocurren verbalmente. El siguiente sprint, se pregunta lo mismo de nuevo.
  5. Churn de requisitos no rastreado. Los cambios se hacen en sitio sin un historial de diff. Las regresiones de alcance son invisibles.

Flujo diario AI-native

El Requirements Engineer opera un loop fijo cada día. El loop usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, además de un pequeño catálogo de MCPs validados para contexto externo.

Setup de la mañana

  1. Abrir el repositorio en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y las instrucciones de requisitos con alcance.
  2. Hacer pull del último main y revisar los cambios nocturnos al spec por parte del Product Owner.
  3. Ejecutar /gap-scan para producir el reporte de brechas actual: requisitos sin pruebas, pruebas sin requisitos, despliegues sin ninguno.
  4. Revisar el dashboard de trazabilidad generado a partir de la telemetría del Azure MCP Server y el GitHub MCP.

Ejecución al mediodía

  1. Descomposición. Invocar /ears sobre cada nueva sección del spec. El agente EARS Encoder produce requisitos atómicos con IDs únicos, cada uno en forma estricta WHEN ... THE system SHALL ....
  2. Trazabilidad. Invocar /traceability para amarrar cada nuevo requisito con pruebas existentes, pull requests y registros de despliegue. El agente actualiza la matriz y marca los huérfanos.
  3. Cierre de brechas. Para cada brecha marcada en el escaneo de la mañana, ya sea redactar el requisito faltante, levantar una tarea de prueba para el QA Engineer o presentar un ADR si se requiere un cambio arquitectónico.
  4. Sincronización entre personas. Usar el MCP del Microsoft 365 Agents SDK para levantar solicitudes de aclaración en el canal de Teams cuando la intención del spec sea ambigua.

Revisión al final de la tarde

  1. Invocar /requirement-review para correr la sesión de revisión estructurada con el Product Owner, el Software Architect y el QA Engineer. El agente prepara la agenda a partir de los diffs del día y registra decisiones contra los IDs de requisito.
  2. Abrir un pull request sobre los archivos de requisitos. GitHub Copilot Code Review comenta sobre el cumplimiento de EARS; los reviewers humanos aprueban el contenido.
  3. Actualizar el reporte de readiness. Un hook post-merge regenera el reporte con conteos de brechas y listas de bloqueadores.
  4. Publicar el digest diario de requisitos al canal de producto en Teams a través del Microsoft 365 Agents SDK.

Primitivas recomendadas

Agente

AgenteArchivoPropósito
ears-encoder.github/agents/ears-encoder.agent.mdDescomponer specs en requisitos EARS atómicos, mantener trazabilidad, correr gap scans

El EARS Encoder usa claude-sonnet-4-6 por defecto. Herramientas: read, edit, search, grep, glob. Sin acceso a bash. El extended thinking se habilita solo para /gap-scan, donde la correlación entre documentos se beneficia de un razonamiento profundo.

Slash prompts

ComandoArchivoPropósito
/ears.github/prompts/ears.prompt.mdDescomponer una sección del spec en requisitos EARS atómicos
/traceability.github/prompts/traceability.prompt.mdAmarrar requisitos a pruebas, PRs y despliegues, regenerar la matriz
/gap-scan.github/prompts/gap-scan.prompt.mdDetectar requisitos sin pruebas, pruebas sin requisitos, despliegues huérfanos
/requirement-review.github/prompts/requirement-review.prompt.mdPreparar y registrar la sesión de revisión estructurada

Instrucciones con alcance

El applyTo con alcance reduce el costo en tokens en aproximadamente 68 por ciento comparado con instrucciones globales.

Alcance (applyTo)ArchivoPropósito
docs/requirements/**/*.md.github/instructions/requirements.instructions.mdFormato EARS atómico, esquema de IDs, reglas de referencias cruzadas
docs/traceability/**/*.md.github/instructions/traceability.instructions.mdEsquema de matriz, reglas de regeneración, formato de evidencia para auditoría
docs/reviews/**/*.md.github/instructions/reviews.instructions.mdPlantilla de agenda de revisión, formato de registro de decisión

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobierno más fuerte para los requisitos.

  • pre-commit: rechazar cualquier archivo de requisito con cláusulas no atómicas o no EARS, o con IDs duplicados
  • post-commit: regenerar la matriz de trazabilidad y el reporte de readiness
  • pre-merge: bloquear el merge de cualquier cambio de requisitos que introduzca una nueva brecha sin un issue de seguimiento enlazado

MCPs validados

MCPPropósitoDueño
GitHub MCP ServerLeer pull requests, pruebas y corridas de Actions para poblar la matriz de trazabilidadGitHub (oficial)
Azure DevOps MCP ServerLeer work items y planes de prueba en Azure Boards cuando el equipo usa Azure DevOpsMicrosoft (oficial)
Azure MCP ServerConsultar Application Insights para confirmar que los artefactos desplegados coincidan con los IDs de requisitoMicrosoft (oficial)
Microsoft Learn Docs MCPAnclar requisitos sobre superficies de productos Microsoft en documentación vigenteMicrosoft (oficial)
Microsoft 365 Agents SDK MCPLevantar hilos de aclaración en Teams y registrar decisiones desde OutlookMicrosoft (oficial)

Ejemplos reales

Ejemplo 1: descomponer una sección de spec aprobada

Entrada: Una sección de spec sobre renovación de contrato que cubre iniciación, elegibilidad y notificación, aprobada por el Product Owner.

Invocación: /ears seguido de /traceability.

Salida esperada:

  1. Un directorio docs/requirements/contract-renewal/ con doce archivos de requisitos atómicos, cada uno con un ID único y una cláusula EARS estricta.
  2. Una matriz de trazabilidad regenerada que amarra tres pruebas preexistentes a dos de los nuevos requisitos y marca los diez restantes como brechas.
  3. Un pull request con comentarios de Copilot Code Review sobre la forma de las cláusulas y la consistencia de los IDs.

Ejemplo 2: cierre de brechas antes del release

Entrada: Un release candidate con 146 requisitos fusionados. El reporte matutino de /gap-scan marca seis requisitos sin pruebas pasando y dos pruebas sin requisitos.

Invocación: /gap-scan seguido de /requirement-review.

Salida esperada:

  1. Seis tareas en GitHub Projects creadas vía el MCP de GitHub, cada una enlazada al ancla del requisito y asignadas al QA Engineer.
  2. Dos archivos de requisitos redactados para amarrar las pruebas huérfanas a IDs de requisito.
  3. Una sesión de revisión registrada en docs/reviews/2026-q3-release-readiness.md con decisiones etiquetadas por ID de requisito.
  4. Una actualización del reporte de readiness que reabre la compuerta de release hasta que cierren los ocho ítems.

Anti-patrones

  1. Requisitos compuestos. Las cláusulas que agrupan dos o más condiciones no se pueden probar atómicamente. Mitigación: el agente /ears y el hook pre-commit rechazan cláusulas no atómicas.
  2. Trazabilidad manual. Las hojas de cálculo no son confiables al cierre del sprint. Mitigación: la matriz se regenera en post-commit.
  3. Colisiones silenciosas de IDs. Los IDs reutilizados rompen los rastros de auditoría. Mitigación: el hook pre-commit rechaza duplicados a través del árbol docs/requirements/.
  4. Revisiones sin registros. Las aclaraciones verbales se evaporan. Mitigación: /requirement-review exige una decisión registrada para cada ítem de la agenda.
  5. Brechas dispensadas verbalmente. Una brecha dispensada sin un ADR o issue de seguimiento reaparece en el release. Mitigación: pre-merge bloquea la ruta de dispensa.

KPIs y métricas de impacto

KPILínea baseMetaMedición
Requisitos en EARS atómico30 por ciento100 por cientoLinter de requisitos en GitHub Actions
Frescura de la trazabilidad, última regeneración7 días< 1 horaTimestamp del hook post-commit
Conteo de brechas en la compuerta de release140Reporte de readiness
Tiempo de ciclo de revisión de requisitos2 semanas< 1 semanaTimestamps de PR
Tasa de pruebas huérfanas12 por ciento< 2 por cientoSalida del gap scan
Tiempo de respuesta a consulta de auditoría1 día< 1 horaLog de consultas a la matriz de trazabilidad

Madurez en cuatro niveles

NivelNombreMarcadores
L1ManualSpecs en prosa, descomposición ad-hoc, trazabilidad construida a mano
L2AsistidoCopilot usado para pulir el fraseo de requisitos, sin disciplina atómica
L3AumentadoAgente EARS Encoder, cuatro slash prompts, instrucciones con alcance, matriz auto-generada, gap scans en PR
L4AutónomoKit completo de primitivas, hooks forzados, reporte de readiness en vivo, revisiones registradas automáticamente, respuesta de auditoría dentro de la hora

Integración con otras personas

  • Desde Product Owner: SPECIFICATION.md aprobado con requisitos EARS numerados como entrada canónica
  • Desde Business Manager: resultados ligados a KPI que informan la priorización de brechas
  • Hacia Software Architect: IDs de requisito estables que anclan CODEMAP.md y los contratos de API
  • Hacia QA Engineer: requisitos atómicos que dirigen la generación de casos de prueba y reportes de cobertura
  • Hacia Developer: ancla del requisito en cada PR habilitando la trazabilidad de implementación
  • Hacia Compliance Auditor: matriz regenerada como evidencia de auditoría a demanda
  • Hacia Release Manager: reporte de readiness que controla el corte de release

Glosario

  • EARS: Easy Approach to Requirements Syntax. La forma canónica WHEN ... THE system SHALL ....
  • Requisito atómico: una cláusula testable única con un ID único, sin conjunciones que introduzcan condiciones independientes.
  • Matriz de trazabilidad: tabla generada que amarra cada requisito a criterios de aceptación, pruebas, pull requests y despliegues.
  • Gap scan: barrida automatizada que detecta requisitos sin pruebas, pruebas sin requisitos y despliegues sin ninguno.
  • Reporte de readiness: documento generado que resume el estado de la compuerta de release contra brechas de requisitos abiertas.
  • Revisión de requisitos: sesión estructurada y registrada que aprueba o difiere cambios de requisitos con participantes nombrados.

Referencias