Levantamiento de requerimientos: cómo hacerlo para que el software resuelva tu operación

En los proyectos de software que he liderado, la mayoría de los problemas no aparecieron programando, aparecieron mucho antes, en la conversación inicial en la que alguien dijo "necesitamos un sistema para..." y nadie preguntó lo suficiente. El levantamiento de requerimientos es ese momento, y hoy tiene un ingrediente nuevo: la inteligencia artificial ya transcribe las entrevistas y redacta borradores de requisitos en minutos, lo que hace muy tentador saltarse la parte de entender.

En este artículo te explico qué es un levantamiento de requerimientos, cómo hacerlo paso a paso, qué técnicas y preguntas usar (también con personas que no son técnicas), qué debe tener el documento y qué cambia con la IA.

Qué es el levantamiento de requerimientos

El levantamiento de requerimientos (también le dicen toma de requerimientos o, en los textos más formales, elicitación de requisitos) es el trabajo de descubrir y dejar por escrito qué tiene que hacer un software para resolver un problema concreto de la operación. Un buen levantamiento de requerimientos de software responde cómo funciona hoy el proceso, qué tiene que pasar distinto cuando el sistema exista y cómo vamos a saber que funcionó.

Normalmente los requerimientos se separan en dos grupos. Los funcionales describen lo que el sistema hace: registrar un pedido, aprobar una compra, avisarle al cliente. Los no funcionales describen cómo lo hace: quién puede ver qué, cuántas personas lo usan al mismo tiempo, desde qué dispositivos y con qué otros sistemas se tiene que conectar.

Por qué el levantamiento define si el software sirve

Un error en el levantamiento es el más caro de todo el proyecto, porque todo lo que viene después se construye sobre él. Si el requerimiento dice "el sistema debe generar la factura" y no se preguntó que buena parte de las facturas tienen una excepción que hoy resuelve una persona a mano, el software sale funcionando, pasa las pruebas y aun así la operación sigue igual (o peor, con una manualidad nueva para corregir lo que el sistema hace mal).

Por eso, en mi experiencia, el levantamiento va más allá de anotar lo que el cliente pide: hay que entender el proceso lo suficiente como para mejorarlo antes de automatizarlo, porque de lo contrario el software termina automatizando el desorden.

Cómo hacer un levantamiento de requerimientos paso a paso

1. Define el problema y cómo se va a medir. Antes de hablar de pantallas, pon por escrito qué está pasando hoy y qué indicador debería cambiar: tiempo de respuesta al cliente, errores en los pedidos, horas que se van en reprocesos. Si no está claro qué debería mejorar, todavía no es momento de pedir un software.
2. Identifica a las personas que hacen el proceso. Además del gerente que pide el sistema, a quien digita, a quien aprueba y a quien recibe el resultado. Pasa con frecuencia que quien pide el software es quien menos lo va a usar.
3. Mira el proceso como ocurre, no como está en el manual. Siéntate con la persona mientras trabaja y pídele que te muestre la hoja de cálculo, el correo o el chat donde de verdad se resuelve el día a día.
4. Dibuja el proceso actual y el proceso mejorado. Un diagrama sencillo con los pasos, quién hace cada uno y dónde se queda esperando la información. Aquí aparecen los pasos que sobran y las aprobaciones que nadie recuerda por qué existen.
5. Escribe los requerimientos y priorízalos. Cada requerimiento con un criterio para saber si está cumplido, y separando lo indispensable para la primera versión de lo que puede esperar.
6. Valida con los usuarios y con quien decide. Devuelve el documento a las mismas personas que entrevistaste y pide que lo corrijan; es mucho más barato cambiar una línea en un documento que una pantalla ya construida.
7. Mantén el documento vivo. Los requerimientos cambian durante el proyecto, y lo importante es que cada cambio quede registrado con su razón y con quien lo aprobó.

Este es el primer paso de cualquier proyecto de desarrollo de software a la medida que hacemos en DSC; si quieres ver cómo lo trabajamos, lo explicamos en consultoría de software antes de construir.

Técnicas de levantamiento de requerimientos

No hay una técnica mejor que las demás; se combinan según el proceso y las personas. Las que más uso:

• Entrevistas uno a uno, con preguntas abiertas. Son la base, aunque la gente suele describir el proceso como cree que funciona y no siempre como funciona.
• Observación: ver a la persona trabajar. Es la técnica que más sorpresas da, porque ahí aparecen los atajos, las hojas de cálculo paralelas y el "eso lo hago yo a mano".
• Talleres con las áreas que tocan el proceso en la misma mesa. Sirven para resolver choques (ventas promete algo que operaciones no puede cumplir) y para acordar prioridades.
• Revisión de documentos y datos: formatos, reportes, correos tipo y exportaciones del sistema actual. Los datos reales muestran los casos raros que no salen en la entrevista.
• Prototipos, aunque sean bocetos en papel. Cuando la gente ve algo concreto, corrige mucho más que leyendo un documento.
• Encuestas, cuando hay muchos usuarios repartidos en varias sedes, como complemento y nunca como única fuente.

Preguntas para un levantamiento de requerimientos

Estas son preguntas que uso con frecuencia, en el lenguaje de la operación y no en el de sistemas:

1. ¿Qué es lo primero que haces cuando llega un pedido, una solicitud o un caso?
2. ¿De dónde sacas la información que necesitas para hacerlo?
3. ¿Qué parte de tu trabajo haces por fuera del sistema, en hojas de cálculo, correos o mensajes?
4. ¿Qué pasa cuando algo sale distinto a lo normal? ¿Quién lo resuelve y cómo?
5. ¿Dónde se queda esperando el trabajo, y esperando a quién?
6. ¿Qué error se repite más y cuánto trabajo cuesta corregirlo?
7. ¿Quién necesita ver el resultado de tu trabajo y para qué decisión lo usa?
8. Si mañana el proceso funcionara perfecto, ¿qué notarías distinto?

La cuarta es la que más vale. El caso normal casi siempre está claro; lo que hace fallar un software son las excepciones que nadie escribió porque "eso pasa poco".

Cómo hacerlo con usuarios no técnicos

Las personas que más saben del proceso casi nunca son técnicas, y no tienen por qué serlo. Algunas cosas que me han funcionado:

• Hablar de su trabajo y no del sistema. En lugar de "¿qué campos necesita el formulario?", preguntar "¿qué datos le pides al cliente y para qué los usas después?".
• Pedir ejemplos reales: el último pedido difícil, la última queja, el reporte del mes pasado.
• Mostrar en lugar de describir. Un boceto o un prototipo sencillo les permite decir "así no" mucho más rápido que un documento de veinte páginas.
• Contarle a la persona, al final de la entrevista y con sus propias palabras, lo que entendiste, y dejar que te corrija.
• No pedirles que diseñen la solución. Ellos conocen el problema mejor que cualquiera; diseñar cómo resolverlo es trabajo del equipo que construye.

Formato de levantamiento de requerimientos: qué debe tener el documento

No hace falta un documento de cincuenta páginas. Un formato de levantamiento de requerimientos útil cabe en pocas hojas si tiene lo esencial:

• El objetivo y el indicador que debe mejorar.
• Las personas y roles que usan el sistema, y qué puede hacer cada uno.
• El proceso actual y el proceso mejorado, en un diagrama sencillo.
• Los requerimientos funcionales, cada uno con su criterio de aceptación (cómo se prueba que está cumplido).
• Los requerimientos no funcionales: seguridad, accesos, volumen de uso, dispositivos.
• Las integraciones con otros sistemas y qué datos van y vienen.
• Lo que queda por fuera de esta versión, escrito de forma explícita.
• Las decisiones tomadas y quién las aprobó.

Lo que queda por fuera parece un punto menor, pero evita buena parte de las discusiones al final del proyecto.

Lo que cambió con la inteligencia artificial (y lo que no)

Hay una parte del levantamiento que la IA sí cambió. Un artículo de CIO del 7 de agosto de 2026 sobre cómo está cambiando el rol del analista de negocio describe herramientas que ya transcriben las reuniones e identifican requisitos, restricciones, riesgos y dependencias, que resumen las entrevistas y que generan los primeros borradores de historias de usuario. Nosotros también lo usamos, y tener la entrevista transcrita y un primer borrador ordenado ahorra horas de manualidad.

Ese mismo artículo deja claro que el analista sigue respondiendo por explicar el porqué de las decisiones y por validar que lo que produce la IA sea correcto y esté alineado con la estrategia del negocio. Y en la Encuesta de Desarrolladores 2025 de Stack Overflow, planear proyectos aparece entre las tareas donde más resistencia hay a la IA: el 69 % de los desarrolladores dijo que no planea usarla para eso.

Mi lectura de este momento es que la IA es muy buena escribiendo lo que se dijo en la entrevista, pero no sabe lo que nadie dijo. No ve la hoja de cálculo paralela, no nota que la persona dudó antes de responder ni se da cuenta de que dos áreas describen el mismo paso de forma distinta. Un borrador bien redactado sobre un proceso mal entendido es más riesgoso que uno desordenado, porque se ve terminado y ya no se cuestiona.

Por eso la parte que más pesa hoy es justamente la que menos se puede automatizar: entender el proceso, decidir qué se mejora antes de construir y validarlo con la gente que lo vive. El IIBA (el instituto internacional de análisis de negocio), en una publicación del 8 de enero de 2026, recoge de su informe global de 2025 que el 76 % de los profesionales ve que el análisis de negocio tiene un papel más grande en las decisiones estratégicas de su organización.

Antes de pedir cotizaciones

Si estás pensando en un software para tu empresa, un buen levantamiento de requerimientos es lo que te permite comparar cotizaciones con el mismo alcance y, a veces, descubrir que no necesitas construir nada. Si todavía estás en la duda entre construir o usar una herramienta que ya existe, en el artículo sobre software a la medida o estándar te cuento cómo decidir.

Si quieres revisar tu proceso con nosotros antes de decidir, puedes pedir un diagnóstico gratis y lo miramos juntos. ¿Cuál es el paso de tu operación que más se resuelve por fuera del sistema?

Fuentes

• CIO, Sarah K. White (7 de agosto de 2026): How AI is changing the business analyst role for the better.
• Stack Overflow, Encuesta de Desarrolladores 2025, sección de IA: survey.stackoverflow.co/2025/ai.
• IIBA, Jared Gorai (8 de enero de 2026): Top 6 Business Analysis Trends to Monitor in 2026.