Desarrollo de software a medida: cómo usar IA para definir requisitos

Desarrollo de software a medida: requisitos con IA

Antes de escribir código, hay que entender qué necesita el negocio y cómo comprobar que la solución responde a esa necesidad. La IA puede apoyar ese trabajo: organizar antecedentes, proponer historias de usuario, detectar preguntas pendientes y preparar criterios de aceptación para que el equipo los revise.

En un proyecto de desarrollo de software a medida, una solicitud como “necesitamos que los clientes puedan consultar sus solicitudes sin llamar a soporte” abre varias decisiones. ¿Qué solicitudes podrán ver? ¿Quién tendrá acceso? ¿De dónde vendrá la información? ¿Qué ocurrirá cuando el sistema no pueda recuperarla?

La utilidad de la IA en esta etapa depende de cómo ayude a resolver esas preguntas. Para evaluarla, conviene mirar el recorrido completo: necesidad de negocio → requisito → historia de usuario → criterios de aceptación → validación humana.

Una historia bien redactada es un avance, pero una historia que el equipo puede implementar y comprobar, con sus decisiones críticas resueltas, es un resultado más útil.

Por qué los requisitos siguen siendo un cuello de botella

Una necesidad puede llegar en una reunión, un correo o un ticket de pocas líneas. Para transformarla en trabajo de desarrollo, alguien debe reunir antecedentes, consultar a las personas involucradas y separar lo que ya está decidido de lo que sigue abierto.

En ese recorrido aparecen obstáculos concretos: dos áreas entienden de manera distinta la misma palabra, una regla de negocio solo la conoce quien opera el proceso o una integración impone restricciones que todavía no se han discutido.

Para diagnosticar dónde se demora el trabajo, conviene distinguir tres tiempos:

Preparación: reunir información y redactar requisitos, historias y criterios.
Decisión: resolver alcance, reglas, prioridades y excepciones.
Espera: conseguir una respuesta, un acceso o una aprobación.

Esta separación permite evaluar con más precisión una prueba con IA. Si redactar una historia toma menos tiempo, pero la aprobación sigue pendiente durante varios días, hay una dependencia que el equipo todavía debe resolver.

Qué puede hacer la IA con requisitos

La IA generativa puede apoyar tareas como preparar requisitos de negocio, descomponer funcionalidades en épicas, generar historias de usuario y proponer criterios de aceptación. AWS incluye estas actividades entre sus casos de uso para la gestión de requisitos.

Para incorporarla al trabajo diario, conviene pedirle entregables que puedan revisarse:

Un resumen de la necesidad, los usuarios involucrados y el resultado esperado.
Una propuesta de historias vinculadas con esa necesidad.
Preguntas sobre reglas ausentes, contradicciones o excepciones.
Un borrador de criterios de aceptación basado en decisiones confirmadas.

Cada resultado debería distinguir información confirmada, propuestas y preguntas pendientes. Esa separación ayuda a evitar que una sugerencia termine incorporada al alcance como si hubiera sido solicitada por el negocio.

También conviene conservar la referencia al documento, ticket o conversación que respalda cada decisión.

Persona utilizando un computador con gráficos en pantalla, acompañado de iconos de nube e inteligencia artificial.

De lenguaje de negocio a épicas e historias

Veamos un ejemplo ilustrativo, que no corresponde a un caso de cliente ni a un resultado medido.

La necesidad inicial es:

Necesitamos que los clientes puedan consultar sus solicitudes sin llamar a soporte.

Una propuesta de épica podría ser:

Habilitar la consulta de solicitudes en el portal de clientes.

Antes de descomponerla, el equipo debe aclarar aspectos como el acceso, la información disponible y el sistema que mantiene el estado de cada solicitud.

Supongamos que el negocio confirma que cada cliente podrá consultar únicamente las solicitudes asociadas a su cuenta. Con esa decisión, puede formularse un requisito:

El portal debe permitir que un cliente autenticado consulte el estado de las solicitudes asociadas a su cuenta.

Y una historia de usuario:

Como cliente, quiero consultar el estado de mis solicitudes en el portal para conocer su avance sin contactar a soporte.

La historia expresa quién necesita la funcionalidad y para qué. Todavía falta precisar cómo se comportará el sistema y qué condiciones permitirán aceptar el trabajo.

En ese punto, la IA puede proponer una descomposición y señalar decisiones pendientes. El equipo debe revisar que cada historia conserve el propósito de negocio y tenga un alcance abordable.

Cómo identificar ambigüedades y vacíos

Expresiones como “información actualizada”, “acceso seguro” o “respuesta rápida” requieren una definición que permita implementarlas y verificarlas.

En el ejemplo anterior, pedir a la IA que revise ambigüedades debería producir preguntas concretas:

“Mis solicitudes”: ¿son las creadas por la persona o todas las asociadas a su organización?
“Estado actualizado”: ¿se consulta directamente el sistema de origen o se utiliza una copia sincronizada?
“Ver el avance”: ¿basta con el estado actual o se necesita el historial?
“Acceso”: ¿qué ocurre si alguien intenta consultar una solicitud ajena?

El equipo puede convertir esas preguntas en un registro breve: decisión pendiente, responsable de responderla e impacto en la historia.

Una incógnita debe permanecer visible hasta que exista una respuesta validada. Si el agente propone una alternativa, debe presentarla como propuesta y explicar qué decisión está pendiente.

Generación de criterios de aceptación

Los criterios de aceptación describen las condiciones que debe cumplir una historia para que el equipo pueda comprobar el comportamiento esperado.

Para este ejemplo, supongamos que se han confirmado tres reglas: el cliente debe autenticarse, solo puede consultar solicitudes de su cuenta y debe recibir un aviso cuando no sea posible recuperar la información.

Con esas decisiones, pueden prepararse criterios como los siguientes.

Consulta permitida

Dado un cliente autenticado con una solicitud asociada a su cuenta.
Cuando consulta el detalle de esa solicitud.
Entonces el portal muestra el estado informado por el sistema de origen.

Consulta de una solicitud ajena

Dado un cliente autenticado.
Cuando intenta acceder a una solicitud que no pertenece a su cuenta.
Entonces el sistema impide el acceso a su información.

Información no disponible

Dado que el sistema de origen no responde.
Cuando el cliente intenta consultar una solicitud.
Entonces el portal informa que no fue posible recuperar su estado.

Aún podrían quedar decisiones por resolver, como el contenido del mensaje de error o la posibilidad de reintentar. La IA debe señalarlas, sin completar esos detalles por su cuenta.

La revisión también debe considerar condiciones de rendimiento, accesibilidad o seguridad cuando sean relevantes para el alcance. Sus umbrales y reglas necesitan una definición explícita del equipo.

Qué contexto necesita el agente

Para proponer requisitos útiles, el agente necesita información del negocio y del sistema donde se implementarán.

El contexto puede organizarse en cuatro grupos:

Negocio: problema que se busca resolver, usuarios, proceso actual, resultado esperado y alcance.
Reglas: permisos, restricciones, excepciones y términos que tienen un significado específico para la organización.
Sistema: aplicaciones involucradas, integraciones, fuentes de datos y limitaciones conocidas.
Equipo: formato de historias, acuerdos de revisión y condiciones para considerar el trabajo listo.

Cada fuente debe tener una versión identificable. Si una regla cambia durante el refinamiento, conviene saber qué historias y criterios se prepararon con la versión anterior.

También hay que definir qué información puede consultar el agente y quién autoriza su acceso. Estos controles conectan el trabajo de requisitos con la gobernanza de agentes de IA en el SDLC.

Qué debe validar una persona

La revisión humana debe comprobar que la propuesta representa una necesidad real y que sus condiciones son coherentes con el negocio y el sistema.

Las responsabilidades pueden distribuirse según la organización:

Negocio o Product Owner: propósito, prioridad, alcance y reglas.
Desarrollo o arquitectura: viabilidad, dependencias e integraciones.
QA: claridad de los escenarios y posibilidad de comprobar los criterios.
Seguridad u otros especialistas: controles específicos cuando el alcance lo requiera.

Para considerar una historia lista para desarrollo, el equipo puede acordar una lista breve: propósito claro, reglas críticas resueltas, criterios verificables, dependencias identificadas y dudas restantes aceptadas explícitamente.

No todas las historias necesitan el mismo nivel de revisión. Un cambio de texto y una modificación de permisos requieren decisiones y controles diferentes.

Métricas: cómo medir el recorrido de requisito a trabajo listo

Para evaluar este caso, proponemos utilizar requirement-to-ready como una definición operativa del equipo: el tiempo transcurrido desde que se registra una necesidad con alcance acordado hasta que el trabajo correspondiente se aprueba como listo para desarrollo.

Esta propuesta requiere fijar el inicio y el final de la medición. Si una necesidad se divide en varias historias, debe aclararse si se medirá hasta aprobar la primera entrega o hasta preparar todo el alcance acordado.

Conviene acompañar ese tiempo con otros indicadores:

Esfuerzo de preparación y revisión: horas dedicadas por las personas involucradas.
Aprobación en primera revisión: proporción de historias aceptadas sin cambios sustanciales.
Reapertura: historias que vuelven a refinamiento por dudas o reglas ausentes.
Retrabajo durante el desarrollo: correcciones vinculadas con problemas de requisitos.
Costo por historia aprobada: esfuerzo humano y consumo de herramientas incluidos en la medición.

La comparación debe considerar trabajos de complejidad semejante y registrar cuántos se observaron. Una mejora en velocidad necesita revisarse junto con la calidad: aprobar antes pierde valor si después aparecen más aclaraciones y correcciones.

Riesgos de automatizar requerimientos sin contexto

Un requisito generado puede parecer completo y aun así contener decisiones que nadie tomó.

Entre los riesgos que conviene revisar están:

Incorporar reglas o funcionalidades que no fueron solicitadas.
Utilizar documentación desactualizada.
Omitir excepciones relevantes para la operación.
Generar criterios que no permiten comprobar un resultado.
Compartir información con herramientas o agentes sin autorización.
Perder la relación entre una historia y su necesidad de origen.

Para controlar estos riesgos, el flujo debe conservar las fuentes utilizadas, las preguntas abiertas, los cambios y las aprobaciones. Esa evidencia permite entender por qué una historia quedó definida de cierta manera y revisarla cuando cambie el contexto.

Cómo probar este caso mediante un POC

Una prueba de concepto puede partir de un conjunto acotado de necesidades reales y un problema observable: preparación lenta, aclaraciones repetidas o historias que regresan a refinamiento.

El diseño de la prueba puede seguir seis pasos:

Elegir el alcance. Definir qué tipo de necesidades se trabajarán y qué actividades apoyará la IA.
Registrar una línea base. Medir cómo se prepara y aprueba actualmente un conjunto comparable de historias.
Preparar el contexto. Reunir documentación vigente, reglas confirmadas y accesos autorizados.
Acordar la revisión. Determinar quién valida cada resultado y qué condiciones permiten aprobarlo.
Medir el recorrido completo. Incluir preparación, correcciones, esperas y aprobación.
Observar qué ocurre después. Revisar si durante el desarrollo reaparecen dudas o aumenta el retrabajo.

En ACL powered by DataArt, SPIREX® incorpora el trabajo con requerimientos dentro de un flujo con contexto del proyecto, agentes especializados y revisión humana de historias. Su aporte en esta etapa puede evaluarse con esas mismas preguntas: cuánto tarda el equipo en preparar y aprobar el trabajo, cuánto debe corregirlo y qué dudas reaparecen al implementarlo.

Este caso conecta con una visión más amplia del desarrollo de software con IA: integrar la asistencia de los agentes en actividades concretas, con responsables y evidencia para decidir dónde conviene ampliar su uso.

¿Tu equipo dedica demasiado tiempo a aclarar requisitos antes de desarrollar? Conversa con nuestros expertos sobre SPIREX® para evaluar un POC acotado, con una línea base y criterios de revisión definidos desde el inicio.

Preguntas frecuentes

¿Cómo se utiliza la IA en los requisitos del desarrollo de software a medida?

Puede apoyar la organización de necesidades, proponer historias, identificar preguntas pendientes y preparar criterios de aceptación. El equipo debe aportar contexto y validar las reglas, el alcance y la viabilidad de lo propuesto.

¿Qué diferencia hay entre un requisito y una historia de usuario?

Un requisito expresa una necesidad o condición que debe satisfacer el sistema. Una historia de usuario describe una capacidad desde la perspectiva de quien la necesita y el propósito que busca cumplir. Puede requerir reglas y criterios adicionales para orientar su implementación.

¿La IA puede generar criterios de aceptación?

Puede preparar un borrador a partir de una historia y sus reglas confirmadas. Una persona debe comprobar que los escenarios sean pertinentes, verificables y coherentes con el comportamiento esperado.

¿Qué hacer si falta información para completar una historia?

Registrar la pregunta, identificar quién puede resolverla y evaluar si bloquea el desarrollo. Si la IA sugiere una respuesta, debe mantenerse como propuesta hasta que la persona responsable la confirme.

¿Cómo saber si un POC de IA para requisitos dio resultado?

Comparando tiempo, esfuerzo de revisión y calidad frente a una línea base. También conviene seguir las historias durante su implementación para comprobar si disminuyeron las dudas y el retrabajo asociados con los requisitos.

¿Te ha interesado este contenido? No te pierdas nuestros otros artículos

Contrata a los mejores desarrolladores de software en Latinoamérica

Accede a talento top y soluciones de TI eficientes con nuestros servicios Nearshore.

Contáctanos