Hablamos mucho de requisitos y, aun así, en demasiados proyectos seguimos tratándolos como una lista de cosas que “el cliente pidió”. Como si bastara con recopilar peticiones, darles un poco de forma y empezar a construir, la realidad es que las fases de la ingeniería de requisitos son más profundas que eso y sus formas son más complejas y difusas en los proyectos reales
Ese enfoque tiene un problema: confunde recoger frases con entender un sistema.
La ingeniería de requisitos no existe para producir documentos bonitos ni para alargar el arranque de un proyecto. Existe para hacer algo mucho más importante: convertir una necesidad difusa, parcial y a veces contradictoria en una base suficientemente sólida como para diseñar, construir y evaluar un sistema sin incertidumbre.
Dicho de forma más directa: su trabajo es reducir la probabilidad de que acabemos desarrollando software técnicamente correcto pero conceptualmente equivocado.
Por eso conviene recordar algo incómodo. Un equipo puede avanzar muy deprisa y, aun así, estar construyendo sobre una comprensión débil del problema. Puede tener tickets, historias, mockups, épicas y hasta decisiones de arquitectura… y seguir sin haber aclarado qué necesidad real intenta resolver, qué restricciones gobiernan el sistema o cómo sabrá después si lo construido responde de verdad a la intención original.
Ahí es donde entran las fases clásicas de la ingeniería de requisitos: elicitación, análisis, especificación y validación. No como una liturgia académica, sino como un marco para ordenar el trabajo de comprensión.
La literatura clásica lo plantea así. Pohl y Rupp explican la ingeniería de requisitos como una disciplina sistemática orientada a identificar requisitos relevantes, alcanzar acuerdo entre stakeholders, documentarlos adecuadamente y gestionarlos durante el ciclo de vida. Nuseibeh y Easterbrook, por su parte, recuerdan algo igual de importante: estas actividades no suceden como una cadena perfectamente limpia, sino de forma iterativa, solapada y con retrocesos.
Y ahí está una de las primeras lecciones útiles: aprender las fases ayuda mucho; creer que la realidad las respeta de forma lineal, no.
Elicitación: descubrir el problema antes de discutir la solución
La elicitación, lo que vulgarmente suele mal llamarse «levantar requisitos» es la fase en la que intentamos obtener conocimiento útil a partir de personas, documentos, procesos, normas, sistemas existentes y cualquier otra fuente relevante. Y enfatizo lo de «mal llamarse» porque suele denominarse así a las típicas acciones, conversaciones o reuniones que pretenden que el cliente liste uno por uno cada requisito o funcionalidad del producto final.
Sobre el papel suena simple. En la práctica, casi nunca lo es.
La gente rara vez expresa sus necesidades en forma de requisito de calidad. Lo habitual es que hablen en términos de síntomas, preferencias, soluciones asumidas, frustraciones operativas o reglas que dan por sabidas. Un usuario no suele decirte “necesito una política de autorización trazable y coherente con el ciclo de vida de la identidad”. Lo normal es que diga “necesitamos roles”, “esto debería dejarme entrar”, “cuando alguien cambia de departamento siempre hay problemas” o “esto antes lo hacía María manualmente”.
Por eso elicitar no es sentarse a tomar notas y salir con una lista de funcionalidades. Eso, como mucho, es una primera captura del relato superficial del problema.
La elicitación bien hecha se parece más a una investigación que a una transcripción. Obliga a contrastar versiones, detectar contradicciones, buscar reglas de negocio implícitas, identificar restricciones técnicas, legales u operativas, y distinguir entre lo estructural y lo accesorio.
Aquí aparece una trampa muy común: pensar que solo hay dos modos posibles de trabajar. O hacemos un discovery gigantesco de varias semanas o no hacemos nada porque “hay que construir ya”. En realidad, entre ambos extremos hay bastante espacio para hacer buen trabajo.
Lo importante no es convertir cada proyecto en una excavación arqueológica. Lo importante es formular cuanto antes algunas preguntas que casi siempre cambian el nivel de la conversación:
- ¿qué problema se quiere resolver realmente?
- ¿para quién es un problema?
- ¿qué consecuencias tiene resolverlo mal?
- ¿qué restricciones ya existen aunque nadie las haya escrito?
- ¿qué parte de lo que se pide es necesidad y qué parte es solución asumida?
Ese cambio se nota mucho en los proyectos reales.
Cabe mencionar que no todos los productos y casos de negocios, según su dominio permiten arrancar con el mismo nivel de conocimiento, en algunos hay que profundizar bastante, en otros nos basta con un conocimiento más de alto nivel. Esto también dependerá del nivel de conocimiento que tenga el equipo sobre el dominio del negocio.
Cuando alguien dice: “necesitamos login, roles y recuperación de contraseña”, todavía no tenemos requisitos. Tenemos una hipótesis de solución. Las preguntas útiles empiezan un poco después:
- quién da de alta usuarios
- quién los desactiva
- qué trazabilidad exige auditoría
- qué sistemas externos dependen de esa identidad
- qué pasa si una persona cambia de unidad
- qué errores son tolerables y cuáles no
- qué excepciones operativas existen.
Ahí dejamos de escuchar una lista de features y empezamos a descubrir el sistema real.
La elicitación no da certeza absoluta. No es magia. Pero sí reduce algo muy valioso: el riesgo de arrancar con una caricatura del problema.
Análisis: transformar información bruta en entendimiento útil
Después de recoger información, llega una fase que muchos equipos infravaloran: el análisis.
Y conviene decirlo claro: analizar no es ordenar notas ni pasarlas a limpio. Analizar es interpretar, depurar, estructurar y modelar lo descubierto para convertirlo en una base útil para decidir.
Esta diferencia importa más de lo que parece.
Un proyecto puede haber hablado con diez personas, tener cuarenta páginas de notas y seguir sin entender nada esencial. Porque escuchar no equivale a comprender. Si no analizamos, las lagunas, los conflictos y las incoherencias siguen ahí; simplemente ahora están mejor redactados.
El análisis sirve, entre otras cosas, para separar tipos de información que en bruto suelen venir mezclados:
- objetivos de negocio;
- reglas operativas;
- restricciones del entorno;
- supuestos heredados;
- necesidades reales;
- preferencias locales;
- y soluciones imaginadas demasiado pronto.
Si no hacemos esa separación, el resultado suele ser un contenedor confuso donde todo parece igual de importante y donde nadie sabe con claridad qué condiciona realmente el sistema.
Hay tres aportes del análisis que, en mi experiencia, son especialmente valiosos.
El primero es jerarquizar. No todo lo que dice un stakeholder pesa lo mismo. Hay elementos estructurales y hay ruido. Hay restricciones que pueden condicionar arquitectura, compliance o integración, y hay preferencias que pueden resolverse más tarde sin poner en riesgo el proyecto. Analizar bien no significa despreciar lo que parece pequeño, sino entender qué clase de información tenemos delante.
El segundo es hacer visibles los conflictos antes de que se conviertan en deuda. Un área puede pedir flexibilidad mientras otra exige control estricto. Negocio puede querer velocidad y compliance puede exigir validaciones duras. Operaciones puede necesitar autonomía local mientras dirección busca centralización. La ingeniería de requisitos no hace desaparecer esos conflictos, pero sí tiene una obligación clara: sacarlos a la luz cuando todavía se pueden discutir con margen.
El tercero es modelar. Y aquí conviene quitarle solemnidad al término. Modelar no significa llenar el proyecto de diagramas porque sí. Significa representar lo necesario para pensar mejor.
A veces bastará con un mapa de proceso y una tabla de reglas. Otras veces necesitaremos escenarios, estados, entidades, dependencias, comportamientos excepcionales o relaciones entre actores. El criterio no debería ser el formalismo por el formalismo, sino su capacidad para bajar ambigüedad relevante.
Cuando el análisis está funcionando bien, cambia el tipo de preguntas que hace el equipo.
Dejamos de preguntar “qué campos lleva esta pantalla” y empezamos a preguntar cosas bastante más serias:
- ¿qué decisión soporta este flujo?
- ¿qué regla gobierna este caso?
- ¿qué actores intervienen aquí y cuáles no?
- ¿qué evento activa realmente este comportamiento?
- ¿qué parte del sistema debe reaccionar y bajo qué condiciones?
- ¿qué pasa si esta dependencia falla?
- ¿qué estado cambia y cuál debería mantenerse?
Ese cambio de conversación suele ser una mejor señal de madurez que cualquier plantilla.
Especificación: convertir entendimiento en base operativa
La especificación llega cuando lo descubierto y lo analizado se transforma en una representación lo bastante clara, comunicable y utilizable como para servir de referencia real al resto del trabajo.
Aquí también conviene romper una idea muy extendida: especificar no es redactar mucho. Es reducir ambigüedad donde importa.
Un documento extenso puede seguir siendo inútil si deja demasiado espacio a la interpretación. Y uno relativamente compacto puede ser muy potente si deja claro qué debe hacer el sistema, para quién, en qué condiciones, con qué restricciones y con qué criterios podrá comprobarse después.
El problema de muchas especificaciones no es que sean cortas. Es que son blandas.
Falla el lenguaje, falla la separación entre tipos de información y falla la intención de uso. Se escribe como si el documento fuera un archivo de recuerdos del proyecto, no una base operativa para diseñar, implementar, probar y validar.
Por eso aparecen una y otra vez los mismos problemas:
El primero es la ambigüedad del lenguaje natural. Expresiones como “rápido”, “correctamente”, “usuario autorizado”, “cuando proceda” o “según permisos” parecen suficientes hasta que dos personas distintas tienen que implementarlas o probarlas. Entonces se descubre que cada una imaginaba algo diferente.
El segundo es la falsa exhaustividad. Se rellena una plantilla y eso da sensación de solidez. Pero una plantilla completa no garantiza comprensión. Puedes tener todos los apartados cumplimentados y seguir sin haber aclarado reglas críticas, excepciones, dependencias sensibles o criterios reales de aceptación.
El tercero es especificar desde la solución en lugar de hacerlo desde el comportamiento esperado. Cuando todavía no hemos aclarado la necesidad y ya estamos fijando botones, endpoints, microservicios, tablas o pantallas, lo que hacemos no es especificar bien: es congelar una implementación demasiado pronto.
El cuarto es olvidar que la especificación tiene varios lectores y varios usos. No la lee solo desarrollo. La leen QA, arquitectura, negocio, operación, soporte, compliance y, a veces, terceros. Si solo la entiende quien la escribió, no está cumpliendo su función.
Especificar bien significa dejar una base que soporte preguntas serias sin obligar a reconstruir cada vez el sentido del sistema desde cero.
Pensemos en un módulo de usuarios. Una especificación pobre diría: “el administrador podrá gestionar usuarios”. Parece razonable hasta que alguien tiene que implementarlo o validarlo. Una base útil tendría que empezar a separar cosas que de verdad importan: altas y bajas, visibilidad por rol, activación y desactivación, restricciones de unicidad, estados válidos, reglas de auditoría, eventos relevantes, errores esperados, comportamiento ante fallos de integración y condiciones de aceptación observables.
No hace falta escribir una novela. Hace falta dejar una base que no obligue a adivinar.
Validación: comprobar que no hemos entendido una ficción convincente
La validación es, probablemente, la fase más infravalorada de todas. Y también una de las que más dinero puede ahorrar.
Validar no es conseguir un “sí, sí, parece bien” en una reunión. Tampoco es revisar ortografía ni comprobar coherencia interna sin salir del documento. Validar es contrastar si lo que hemos especificado representa de forma suficientemente fiel el problema real, las restricciones reales y la intención real del sistema.
Esa tarea es más difícil de lo que parece por dos motivos.
El primero es epistemológico: entender un problema complejo nunca es automático. El segundo es social: rara vez hay una única visión legítima del valor, del riesgo o de la prioridad. Distintos stakeholders pueden querer cosas compatibles solo en apariencia.
Por eso la validación no suele resolverse con una sola técnica. A veces sirve un walkthrough serio. Otras veces hace falta recorrer escenarios concretos, incluidos casos borde y excepciones. En ocasiones solo un prototipo permite descubrir que aquello que alguien aprobó en abstracto no era en realidad lo que quería. Y muchas veces hay que contrastar reglas con quienes operan el sistema de verdad, no solo con quienes tienen autoridad para aprobar presupuestos o alcance.
Aquí también se repiten tres errores clásicos.
El primero es validar demasiado deprisa y demasiado en abstracto. Mientras el texto “suena bien”, se da por válido. El problema aparece cuando el sistema empieza a comportarse de forma concreta y salen a la luz interpretaciones incompatibles que ya estaban ahí desde el principio.
El segundo es validar con el perfil equivocado. Si todo se revisa solo con perfiles de gobierno o mando, la especificación puede quedar perfectamente alineada con el discurso oficial y al mismo tiempo desconectada de la operación real.
El tercero es confundir validación con cierre definitivo. Se valida una versión y el proyecto actúa como si el conocimiento hubiera quedado sellado. Pero el conocimiento cambia, aparecen restricciones nuevas y se descubre información tarde. Validar una vez no elimina la necesidad de revalidar lo importante cuando cambia el contexto o cuando aumenta el coste del error.
La parte madura del trabajo está en calibrar el esfuerzo. No todo merece la misma intensidad de validación. Los flujos con impacto económico, legal, operativo o arquitectónico requieren más contraste. Lo fácilmente reversible admite más ligereza.
El rigor no se reparte por igual. Se concentra donde equivocarse sale caro.
El proceso real no es lineal: es una reducción iterativa de incertidumbre
La secuencia elicitación, análisis, especificación y validación es un mapa útil. Sirve para enseñar, para ordenar el trabajo y para detectar carencias. Pero no deja de ser un mapa.
En proyectos reales, estas actividades se pisan constantemente.
- Elicitamos mientras analizamos
- Analizamos mientras especificamos
- Especificamos para poder validar
- Y validando volvemos a elicitar porque aparecen huecos, conflictos o supuestos ocultos.
Eso no significa que el trabajo sea caótico. Significa que el conocimiento avanza por iteraciones. Y esta idea tiene consecuencias prácticas muy serias.
La primera es que deja de tener sentido obsesionarse con “cerrar fases” como si fueran casillas administrativas. La pregunta útil no es “¿hemos terminado análisis?”. La pregunta útil es otra: ¿hemos reducido la incertidumbre relevante lo suficiente como para tomar la siguiente decisión con criterio?
La segunda es que obliga a pensar en términos de riesgo. No todo tiene que quedar cerrado al mismo nivel y al mismo tiempo. Hay partes del sistema donde una especificación ligera pero clara es suficiente. Y hay otras donde cualquier ambigüedad relevante se convierte en una amenaza para arquitectura, delivery o cumplimiento.
La tercera es que devuelve valor profesional a la comprensión. Cuanto más barata se vuelve la ejecución, más caro sale entender mal el problema.
El valor real de estas fases
Tomarse en serio las fases de la ingeniería de requisitos no significa convertir cada proyecto en una tesis doctoral. Significa aplicar disciplina proporcional al riesgo.
Cuando ese trabajo se hace bien, pasan cosas concretas:
- desarrollo recibe menos decisiones implícitas disfrazadas de requisito;
- QA valida comportamientos en lugar de perseguir intenciones vagas;
- negocio descubre antes contradicciones que de otro modo estallarían tarde;
- arquitectura toma decisiones con menos niebla;
- y el proyecto depende menos de heroicidades individuales y conversaciones sueltas.
Por eso conviene recordarlo: las fases de requisitos no son burocracia cuando se usan para entender mejor. Se convierten en burocracia cuando se tratan como un trámite documental separado del delivery.
La diferencia no está en la plantilla. Está en el criterio.
La pregunta clave al final de cada iteración del ciclo de ingenieria de requisitos
La ingeniería de requisitos clásica sigue importando por una razón muy simple: antes de construir un sistema, alguien tiene que hacer el trabajo duro de entender qué debe existir, por qué debe existir, bajo qué reglas debe operar y cómo sabremos después si lo construido responde de verdad al problema.
Las fases de elicitación, análisis, especificación y validación no eliminan la incertidumbre. Pero la vuelven visible, tratable y discutible.
Y eso, en un proyecto serio, vale muchísimo más que empezar a producir artefactos o código demasiado pronto.
Porque al final la pregunta importante no es si hemos documentado mucho.
La pregunta importante es esta:
¿hemos convertido información difusa en una base sólida ejecutable como para poder modelar o desarrollar el producto sin tener que inventar o adivinar?