La mayoría de los proyectos tecnológicos que se derrumban no fracasan por culpa de malos programadores. Fracasan meses antes de que se escriba una sola línea de código — en la etapa en la que nadie se molestó en definir qué se supone que debe hacer el sistema, para quién y por qué. Ese es exactamente el papel de la especificación de sistemas de información: convertir una idea vaga («necesitamos un sistema para gestionar clientes») en un documento preciso a partir del cual se pueda construir, presupuestar y medir.
Qué es la especificación de sistemas de información (y qué no es)
La especificación de sistemas de información es el proceso de mapear las necesidades del negocio, los flujos de trabajo y los usuarios — y traducirlos en requisitos definidos: qué hace el sistema (requisitos funcionales), con qué rapidez, seguridad y disponibilidad debe operar (requisitos no funcionales), qué aspecto tiene (especificación de interfaz) y sobre qué tecnologías se ejecuta (arquitectura).
Lo que no es: una especificación no es «un documento de 80 páginas que nadie lee». Una buena especificación es una herramienta de trabajo viva — tan breve como sea posible, tan precisa como sea necesario. Tampoco es una etapa que se pueda saltar porque «ya lo resolveremos sobre la marcha»: los datos demuestran que es la apuesta más cara de todo el proyecto.
Los números reales: dos casos documentados
El FBI quemó 170 millones de dólares en un sistema que nunca llegó a funcionar
Entre 2001 y 2005 el FBI desarrolló Virtual Case File — un sistema para gestionar expedientes de investigación. El proyecto se canceló en 2005 tras un gasto aproximado de 170 millones de dólares, sin que el sistema llegara nunca a entrar en servicio. Las investigaciones del Congreso que siguieron señalaron una causa central: requisitos que nunca se definieron correctamente desde el principio y que cambiaban sin cesar — cientos de modificaciones de requisitos durante el desarrollo. No falló la tecnología. Falló la especificación.
El aeropuerto de Denver: 16 meses de retraso por un sistema de equipajes
El sistema automatizado de equipajes del Aeropuerto Internacional de Denver se convirtió en un caso de estudio clásico: unos requisitos poco realistas que nunca se contrastaron con la realidad operativa retrasaron la apertura de todo el aeropuerto 16 meses, con sobrecostes de cientos de millones de dólares y un coste de mantenimiento cercano al millón de dólares por cada día de retraso. Al final el sistema fue casi por completo abandonado en favor de una solución más sencilla — que se podría haber especificado desde el principio.
Y para quien piense que esto solo les ocurre a los gigantes: un estudio del PMI concluyó que casi la mitad (47%) de los proyectos que no alcanzan sus objetivos fracasan por una mala gestión de requisitos, y investigaciones clásicas de IBM y del NIST demostraron que corregir un defecto en producción cuesta entre 30 y 100 veces más que corregirlo en la fase de requisitos. Una hora de especificación ahorra una semana de desarrollo.
Seis pasos para una especificación de sistemas que funcione de verdad
1. El objetivo de negocio antes que nada
No se empieza por «qué pantallas necesitamos» sino por «qué problema de negocio estamos resolviendo y cómo mediremos el éxito». Un CRM concebido para acortar el tiempo de respuesta a un lead es muy distinto de uno concebido para aumentar las ventas recurrentes. Una frase de propósito más dos o tres indicadores de éxito — antes que cualquier otra cosa.
2. Mapeo de procesos y usuarios
Siéntese con las personas que realmente van a usar el sistema — no solo con los directivos. Mapee el proceso existente paso a paso, incluidas las excepciones feas (un pedido cancelado, un cliente que vuelve, la hoja de cálculo paralela que todo el mundo usa en silencio). La mayoría de las sorpresas caras del desarrollo se esconden justo ahí.
3. Requisitos funcionales: qué hace el sistema
Cada requisito debe formularse de modo que se pueda comprobar: «el sistema envía una alerta al responsable en un plazo de 5 minutos desde la apertura de una incidencia» — sí. «El sistema será fácil de usar» — no. Priorice con MoSCoW (imprescindible / deseable / opcional / ahora no), porque una primera versión que lo contenga todo es una versión que nunca saldrá.
4. Requisitos no funcionales: rendimiento, seguridad, disponibilidad
¿Cuántos usuarios simultáneos? ¿Qué datos son sensibles y quién está autorizado a verlos? ¿Qué ocurre cuando el sistema se cae? Son los apartados más fáciles de omitir en una especificación — y los más caros de descubrir después de la puesta en producción.
5. Especificación de interfaz y experiencia de usuario
Wireframes de las pantallas principales y el recorrido del usuario de extremo a extremo. No hace falta un diseño visual completo en esta fase — sí hace falta la certeza de que el usuario llega del punto A al punto B sin perderse.
6. Arquitectura, integraciones y documento final
¿Con qué sistemas existentes debe conectarse (contabilidad, pasarela de pago, mensajería, ERP)? ¿Construir o comprar? Todo converge en un documento de especificación (SRS) que incluye también una estimación de costes y un calendario — y que se convierte en la base para comparar las ofertas de los proveedores con exactamente el mismo rasero.
Cuánto cuesta una especificación de sistemas de información
La especificación de un sistema pequeño o mediano (una aplicación de negocio, un CRM a medida, un sistema operativo interno) suele situarse entre 4.000 y 16.000 dólares, y en proyectos más complejos alcanza las seis cifras. Una regla habitual: entre el 10% y el 15% del presupuesto total del proyecto se destina a la especificación. Parece mucho, hasta que uno recuerda que el FBI pagó 170 millones de dólares por la decisión de ahorrar en esta fase. Igual de importante: una especificación independiente y objetiva, elaborada por separado de la empresa de software que va a construir el sistema — para que quien pone el precio no sea también quien define lo que hace falta.
Especificar sistemas de IA: qué cambia en 2026
Cuando se especifica un sistema basado en inteligencia artificial — un chatbot de atención, un motor de recomendaciones, una automatización inteligente — aparecen preguntas que no existían en la especificación clásica: qué datos hay realmente y cuál es su calidad (un buen modelo sobre datos malos es un mal sistema), cuál es el umbral de precisión por debajo del cual el sistema resulta dañino, dónde se requiere una persona en el bucle y qué se hace cuando el modelo alucina delante de un cliente real. Además, la especificación debe definir costes recurrentes (tokens, llamadas a API) que no existen en el software convencional. Así se evita engrosar el 80% de proyectos de IA que fracasan.
Preguntas frecuentes
¿Cuánto tarda la especificación de un sistema de información?
Para un sistema pequeño o mediano: de tres a ocho semanas, según el número de procesos y de sistemas conectados. Un proyecto corporativo amplio puede llevar de dos a cuatro meses. Una especificación que se alarga más que eso suele ser señal de que se está intentando especificar demasiado a la vez.
¿Cuál es la diferencia entre especificación funcional y técnica?
La especificación de negocio responde al «qué y por qué» — procesos, usuarios, requisitos e indicadores de éxito, en un lenguaje que cualquier directivo entiende. La especificación técnica responde al «cómo» — arquitectura, bases de datos, API. El orden importa: lo técnico antes que lo funcional es construir la casa por el tejado.
¿Se puede saltar la especificación en un proyecto pequeño?
Se acorta — no se salta. Incluso un proyecto de un mes solo necesita un documento de 5 a 10 páginas con un objetivo, los procesos principales y una lista priorizada de requisitos. La diferencia entre eso y «ya lo resolveremos sobre la marcha» suele ser la diferencia entre una desviación del 10% y una del 100%.
¿Quién debería redactar la especificación, nosotros o un proveedor externo?
El conocimiento del negocio solo lo tienen ustedes, pero un analista con experiencia sabe qué preguntas hacer, cómo formular requisitos verificables y cómo traducirlos al lenguaje que los proveedores de desarrollo saben presupuestar. La combinación ganadora: un analista externo objetivo trabajando codo con codo con las personas clave de su organización.