Modelado de requisitos y criterios de aceptación para trazabilidad en Jira

Qué significa “modelar requisitos” para lograr trazabilidad

En Jira, modelar requisitos no es solo “crear issues”, sino estructurarlos de forma que permitan: (1) entender el alcance, (2) verificar criterios de aceptación con pruebas, y (3) navegar relaciones (dependencias, bloqueos, cobertura) para reportar estado con confianza. La trazabilidad se logra cuando cada criterio de aceptación puede vincularse a uno o más activos de prueba y a evidencia verificable.

Jerarquía recomendada: Epic → Historia → Tareas/Subtareas (y cómo usar cada nivel)

Epic (resultado de negocio y alcance macro)

• Úsalo para agrupar un objetivo de negocio o capability (p. ej., “Checkout con tarjeta”).
• Debe contener el alcance general, supuestos y límites (qué incluye / qué no incluye).
• Sirve como contenedor para reportes de avance y cobertura a nivel alto.

Historia de usuario (comportamiento verificable)

• Representa una necesidad concreta que puede validarse en un sprint.
• Debe incluir criterios de aceptación verificables (no ambiguos).
• Es el nivel ideal para vincular pruebas funcionales y evidencia.

Tareas/Subtareas (trabajo técnico y descomposición)

• Úsalas para trabajo de implementación, ajustes de UX, datos, instrumentación, etc.
• No sustituyen criterios de aceptación: las tareas describen “cómo se hace”, los criterios describen “cómo se valida”.
• Las subtareas ayudan a reflejar dependencias internas sin romper la trazabilidad del requisito.

Guía práctica paso a paso: capturar requisitos con criterios verificables

Paso 1: Crear el Epic con alcance y dependencias de alto nivel

En el Epic, documenta:

• Objetivo: qué valor entrega.
• Alcance: lista breve de “incluye” y “excluye”.
• Dependencias: integraciones, equipos, componentes.

Ejemplo de alcance en el Epic:

• Incluye: pago con tarjeta, validación 3DS, confirmación de compra.
• Excluye: pagos en efectivo, cuotas, reembolsos.

Paso 2: Crear Historias con un “enunciado” y criterios de aceptación

Una historia debe ser entendible por negocio y testeable por QA. Un formato útil es:

Como [tipo de usuario] quiero [acción] para [beneficio]

Luego agrega criterios de aceptación en formato verificable. Evita frases como “debe funcionar”, “rápido”, “intuitivo” sin umbrales.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Paso 3: Convertir criterios en condiciones testeables (Given/When/Then o checklist verificable)

Un criterio verificable define: precondición, acción, resultado observable. Dos formatos comunes:

• BDD (Given/When/Then): ideal para reducir ambigüedad.
• Checklist con condiciones medibles: útil cuando hay múltiples validaciones simples.

Ejemplo (Historia: “Como comprador quiero pagar con tarjeta para completar mi compra”):

Paso 4: Reflejar dependencias y alcance en Jira (sin perder trazabilidad)

Para que la trazabilidad sea útil en proyectos ágiles, las dependencias deben ser visibles y consultables:

• Dependencias entre issues: usa enlaces del tipo blocks / is blocked by para reflejar impedimentos reales (p. ej., “Historia de pago” bloqueada por “Integración con gateway”).
• Relación con componentes: asigna Component/s (p. ej., “Checkout”, “Payments”, “Notifications”) para filtrar y reportar.
• Alcance por versión: usa Fix Version/s o un campo equivalente para indicar release objetivo.
• Impacto transversal: etiqueta con labels para temas como security, pci, performance, accessibility.

Regla práctica: si una dependencia afecta el orden de validación o la posibilidad de ejecutar pruebas, debe modelarse como enlace entre issues (no solo como texto en la descripción).

Estructura recomendada de campos y etiquetas para búsquedas y reportes

La consistencia de datos es lo que habilita reportes confiables. Una estructura mínima recomendada:

Convención de etiquetas (labels) sugerida

Define un “diccionario” de etiquetas para evitar variantes. Ejemplo:

• Dominio: payments, checkout, notifications
• Tipo de prueba: regression, smoke, e2e
• Riesgo: critical-path, high-risk
• Regulatorio: pci, gdpr

Ejemplos de búsquedas (JQL) para reportes

Con campos consistentes, puedes construir consultas reutilizables:

• Historias de un componente y versión: project = ABC AND issuetype = Story AND component = Payments AND fixVersion = 1.8.0
• Requisitos críticos pendientes: labels = critical-path AND status not in (Done)
• Issues bloqueados: issue in linkedIssuesOf("status not in (Done)", "is blocked by")

Enfoque para asegurar cobertura: del criterio a la prueba y a la evidencia

1) Definir “unidad de cobertura”: criterio de aceptación como átomo verificable

Para trazabilidad, trata cada criterio (AC-01, AC-02…) como una unidad que debe quedar cubierta por al menos una prueba. Si un criterio es demasiado grande, divídelo hasta que sea ejecutable y observable.

2) Vincular requisitos con activos de prueba

Un enfoque práctico es mantener una relación explícita entre:

• Historia ↔ Casos de prueba (o checklist de pruebas) que cubren sus criterios.
• Criterio ↔ Paso(s) de prueba o caso específico.

Si usas una app de gestión de pruebas integrada (p. ej., Xray, Zephyr, TestRail integrado), vincula el issue de requisito con el/los test cases. Si no usas app, puedes crear un issue type “Test” y enlazarlo con relates to o un enlace específico de tu esquema.

3) Matriz simple de cobertura dentro de la Historia

Para que sea auditable sin herramientas adicionales, incluye una tabla en la descripción o en un campo de texto:

4) Definir qué evidencia valida un criterio (Definition of Evidence)

Para evitar discusiones al final del sprint, define por criterio qué evidencia es aceptable. Ejemplos de evidencia:

• UI: capturas con timestamp o video corto mostrando el flujo.
• API: request/response (con datos sensibles enmascarados), logs de correlación, ID de transacción.
• Datos: registro en base de datos (si aplica) o evento emitido (p. ej., mensaje en cola) con identificador.
• Observabilidad: trazas o métricas que confirmen ejecución (cuando sea requisito no funcional verificable).

Regla práctica: la evidencia debe permitir a un tercero reproducir mentalmente el resultado sin “confiar” en quien ejecutó la prueba.

5) Criterios no funcionales: convertirlos en umbrales verificables

Cuando aparezcan requisitos como rendimiento, seguridad o accesibilidad, conviértelos en condiciones medibles:

• “Rápido” → “Tiempo de respuesta < 2s en P95 para endpoint /payments/authorize con carga X”.
• “Seguro” → “No registrar PAN completo; logs enmascarados; validación de roles para ver órdenes”.
• “Accesible” → “Cumple WCAG 2.1 AA en pantalla de pago (teclado, contraste, labels)”.

Plantilla reutilizable para Historias con trazabilidad lista para QA

Puedes copiar esta estructura en la descripción de una historia:

Contexto/Objetivo: ...  Alcance (incluye/excluye): ...  Dependencias: (links a issues) ...  Reglas de negocio: ...  Criterios de aceptación:  AC-01: Given... When... Then...  AC-02: Given... When... Then...  Cobertura y evidencia:  | AC | Test | Evidencia |  | AC-01 | TEST-... | ... |  | AC-02 | TEST-... | ... |

Esta plantilla facilita que el equipo construya búsquedas, reportes y auditorías de cobertura sin re-trabajo, y mantiene alineados requisito, prueba y evidencia.