La IA para analizar requisitos de software me resulta útil cuando la utilizo como una segunda mirada crítica, no como una fuente de verdad. Antes de un refinamiento no le pido que me resuma la historia de usuario. Le pido que encuentre lo que todavía no está decidido: ambigüedades, reglas incompletas, dependencias, escenarios alternos y riesgos que podrían convertirse en defectos cuando la funcionalidad llegue a producción.
En proyectos ágiles es frecuente recibir una historia que parece clara porque tiene una descripción, un diseño y algunos criterios de aceptación. Sin embargo, al revisarla desde el punto de vista de calidad aparecen preguntas sobre permisos, estados, límites, errores, datos y efectos posteriores. Llegar con esas preguntas preparadas permite que el refinamiento se concentre en decisiones. También evita diseñar pruebas sobre supuestos que cada integrante del equipo interpreta de manera diferente.
Qué debe buscar la IA al analizar requisitos de software
Para mí, el análisis previo debe responder como mínimo cinco preguntas: qué problema del usuario se intenta resolver, qué reglas están confirmadas, qué información falta, qué sistemas participan y qué daño produciría una interpretación equivocada. La IA puede ordenar estas dimensiones rápidamente siempre que reciba suficiente contexto.
No sirve pegar una frase como «el usuario podrá modificar su límite diario» y pedir casos de prueba. Antes necesito aclarar si el límite aplica por operación o por acumulado, si cambia según el tipo de cliente, cuál es el valor mínimo, qué sucede con operaciones en curso y qué canal mantiene la autoridad sobre ese dato. Si esa información no existe, la respuesta correcta no es inventarla: es convertirla en preguntas para el equipo.
El programa ISTQB CT-GenAI incluye el uso de ingeniería de prompts en actividades de análisis y diseño, pero también advierte sobre alucinaciones, privacidad y evaluación de resultados. Esa combinación coincide con la forma en que uso estas herramientas: acelerar el borrador sin delegar la decisión.
La información que preparo antes de pedir el análisis
Una respuesta útil depende más del contexto entregado que de una frase ingeniosa. Antes de consultar la IA, organizo:
- objetivo de negocio y usuario que recibe el valor;
- historia de usuario y criterios de aceptación disponibles;
- reglas confirmadas y decisiones que siguen abiertas;
- diseño, diagrama o contrato de API relevante;
- roles, permisos, estados y datos involucrados;
- dependencias con otros servicios o procesos;
- restricciones no funcionales conocidas;
- formato en el que necesito recibir los hallazgos.
También elimino nombres de clientes, cuentas, documentos, teléfonos, credenciales, URLs privadas y cualquier información que no sea necesaria. Si el contenido es confidencial, trabajo con una versión abstracta o con datos sintéticos. La productividad no justifica copiar información sensible en una herramienta que no esté aprobada por la organización.
Mi flujo para preparar un refinamiento con IA
1. Separo hechos de supuestos
Marco explícitamente lo que está confirmado y lo que solo estoy interpretando. Esta separación reduce el riesgo de que la IA complete vacíos con comportamientos plausibles pero inexistentes.
2. Pido preguntas, no soluciones
Solicito que identifique ambigüedades y formule preguntas para Product Owner, desarrollo, arquitectura o diseño. Una buena salida indica por qué cada pregunta importa y qué riesgo evita. No necesito treinta preguntas genéricas; necesito las que pueden cambiar el alcance o la cobertura.
3. Clasifico los hallazgos
Agrupo los resultados en negocio, datos, interfaz, API, integración, permisos, errores, observabilidad y operación. Así puedo dirigir cada pregunta a la persona adecuada y evitar que el refinamiento se convierta en una conversación desordenada.
4. Verifico cada observación contra la evidencia
Regreso a la historia, al diseño o al contrato para confirmar que el vacío existe. Si la IA afirma que falta una regla que sí está documentada, descarto el hallazgo. Si sugiere un comportamiento nuevo, lo presento como pregunta, nunca como requisito.
5. Priorizo lo que debe resolverse ahora
No toda duda bloquea el desarrollo. Distingo entre decisiones necesarias para comenzar, decisiones que afectan la prueba y temas que pueden resolverse después. El refinamiento gana valor cuando termina con responsables y acuerdos, no cuando produce una lista infinita de posibilidades.
Ejemplo: modificación del límite de transferencias
Supongamos una historia: «Como cliente quiero modificar mi límite diario de transferencias para controlar cuánto dinero puedo enviar». Los criterios indican que el valor debe estar entre un mínimo y un máximo, y que el usuario recibirá una confirmación.
Una lectura superficial permitiría crear casos para valores válidos, menores al mínimo y mayores al máximo. Con un análisis más profundo aparecen preguntas distintas:
- ¿El límite es diario por cliente, por cuenta o por canal?
- ¿Se calcula por fecha calendario o por una ventana de 24 horas?
- ¿La zona horaria depende del país del cliente o del sistema?
- ¿Una reducción aplica inmediatamente si ya existen transferencias programadas?
- ¿Se necesita autenticación reforzada para aumentar el límite?
- ¿Qué sucede si la notificación falla después de guardar el cambio?
- ¿Otros canales ven el nuevo valor de inmediato?
- ¿Queda auditoría del valor anterior, el nuevo y el origen del cambio?
- ¿Existen perfiles que no pueden modificarlo?
- ¿Qué ocurre con dos solicitudes simultáneas desde dispositivos distintos?
La IA puede proponer parte de esta lista, pero el valor senior está en relacionar las preguntas con el riesgo. La zona horaria afecta el cálculo. La concurrencia puede dejar un valor inesperado. La autenticación protege una operación sensible. La auditoría permite investigar reclamos. Con ese razonamiento, las preguntas dejan de parecer casos extremos y se convierten en decisiones de producto.
Qué llevo realmente al refinamiento
No llevo la conversación completa con la IA. Presento una tabla breve con la pregunta, la evidencia que la originó, el riesgo, la persona que puede resolverla y si bloquea el trabajo. Ese formato facilita tomar notas y actualizar la historia en el mismo momento.
Mi salida ideal tiene cuatro grupos:
- Ambigüedades: frases que permiten más de una interpretación.
- Reglas faltantes: límites, permisos, estados o cálculos no definidos.
- Dependencias: servicios, canales o procesos afectados.
- Hipótesis de riesgo: situaciones que conviene evaluar, aunque todavía no sean requisitos.
Después del refinamiento actualizo el contexto. Las respuestas confirmadas reemplazan supuestos y se convierten en insumo para el diseño de casos. Las preguntas abiertas quedan visibles con responsable; no las oculto detrás de un resultado generado que aparenta estar completo.
Qué no delegaría a la IA
No delegaría la aceptación de una regla de negocio, la prioridad del riesgo, la interpretación de una norma interna ni la decisión de que una historia está lista. Tampoco asumiría que conoce la arquitectura real por reconocer términos comunes como transferencia, saldo o límite.
La herramienta no participa en las conversaciones previas del equipo, no conoce incidentes que no se hayan documentado y puede confundir una práctica habitual del sector con una obligación del producto. El QA sigue siendo responsable de contrastar, preguntar y dejar trazabilidad.
Cómo medir si el método está aportando valor
Evito afirmar que «la IA ahorra un 70 %» sin evidencia. Para medir un ejercicio concreto registro el tiempo de preparación, el número de preguntas útiles, cuántas decisiones se incorporaron a la historia y cuántos defectos de entendimiento se evitaron antes del desarrollo.
También observo señales cualitativas: refinamientos más cortos, menos aclaraciones durante la ejecución, criterios de aceptación más verificables y menor retrabajo en pruebas. Si la salida requiere más tiempo de limpieza que el análisis manual, ajusto el contexto o dejo de usarla para ese tipo de historia.
De preguntas claras a una mejor cobertura
Usar IA antes del refinamiento no consiste en producir documentación adicional. Consiste en llegar mejor preparado para conversar con el equipo. La herramienta ayuda a explorar y ordenar; el criterio del QA decide qué vale la pena discutir.
Cuando las reglas quedan confirmadas, el siguiente paso es transformar ese conocimiento en escenarios trazables. En la guía sobre cómo hacer preguntas efectivas para crear casos de prueba explico la base del cuestionamiento. Esta colección continúa ese enfoque mostrando cómo utilizar IA sin aceptar automáticamente sus respuestas.
El proceso continúa en cómo crear casos de prueba con IA desde historias de usuario y en el plan de pruebas con IA basado en riesgos, donde las respuestas del refinamiento se convierten en cobertura y decisiones de ejecución.