Una especificación funcional es el documento que convierte una idea de negocio en algo que un equipo técnico puede construir sin tener que preguntar cada dos pantallas. La diferencia entre tener una y no tenerla suele ser tres meses de proyecto y un 30% más de presupuesto. La diferencia entre una buena y una mala suele ser exactamente la misma.
No hablamos de un brief comercial, ni de un PowerPoint con casos de uso. Hablamos de un documento que cualquier desarrollador, analista o jefe de proyecto pueda leer y entender qué tiene que existir, cómo se comporta y qué pasa cuando algo va mal. Si después de leerlo quedan decisiones técnicas importantes en el aire, no es una especificación: es un esbozo.
Estos son los bloques que toda especificación funcional debería contener para una PYME. No los repetimos en orden académico: los presentamos por orden de impacto si los obvias.
Modelo de datos y reglas de negocio
Es el bloque más importante y el que más se omite. Una especificación funcional sin modelo de datos es papel mojado, porque todo lo demás (pantallas, integraciones, validaciones) depende de cómo estén estructuradas las entidades del negocio.
Qué debe describir. Las entidades principales (cliente, pedido, factura, producto...), sus atributos, las relaciones entre ellas, las restricciones (un cliente puede tener varios pedidos, pero un pedido pertenece a un único cliente; un pedido sin líneas no se puede guardar). También los estados que puede atravesar cada entidad (un pedido pasa por borrador, confirmado, en preparación, enviado, entregado, anulado) y bajo qué condiciones cambia de uno a otro.
Por qué se ignora. Porque parece técnico y se asume que "ya lo definirá el desarrollador". El problema es que esas decisiones son de negocio, no de programación. Si el desarrollador decide que un pedido anulado se borra, en vez de marcarse como anulado, pierdes trazabilidad fiscal. Esa decisión la debe tomar quien lleva el negocio, no quien escribe código.
Cómo de detallado. Suficiente para que dos analistas leyendo el mismo documento construyan el mismo modelo de datos. Si en una empresa de servicios profesionales tu producto puede ser una hora facturable o un paquete cerrado, esa distinción tiene que estar en la spec con sus campos y comportamiento. No basta con decir "habrá productos".
Casos de uso y flujos
Aquí se describe qué hace el usuario, paso a paso, y qué responde el sistema. No son maquetas. Son secuencias de acciones con condiciones.
Qué debe describir. Por cada flujo de negocio relevante, los pasos en orden, los datos que se introducen, las validaciones que se aplican, las decisiones que toma el sistema y los caminos alternativos. "El usuario crea un pedido nuevo" es un comienzo, no una especificación. "El usuario crea un pedido nuevo, selecciona un cliente del listado, añade una o más líneas con producto y cantidad, el sistema valida que haya stock suficiente y muestra el total con impuestos calculados" empieza a serlo.
Por dónde se rompe. Por los caminos alternativos. Casi todo el mundo describe el feliz, donde todo va bien. Las especificaciones serias también describen qué pasa si el cliente no existe (¿se puede crear sobre la marcha?, ¿hace falta validación?), qué pasa si no hay stock (¿se rechaza el pedido?, ¿se permite con aviso?, ¿se reserva con fecha estimada?), qué pasa si se cae la conexión a mitad de operación.
Indicador de calidad. Una especificación útil cubre al menos los tres caminos típicos por flujo: el principal, el de error de datos y el de excepción de negocio.
Pantallas e interacción
A veces se confunde la especificación funcional con el diseño visual. No son lo mismo. La spec define qué información se muestra, qué acciones puede hacer el usuario y qué relaciones hay entre pantallas. El diseño visual viene después y cambia sin afectar al funcional, salvo cuando descubre vacíos.
Qué debe describir. Por cada pantalla relevante, qué información presenta, qué filtros y búsquedas tiene disponibles, qué acciones puede ejecutar el usuario y qué pantallas se abren a continuación. No hace falta indicar dónde va cada botón ni qué color tiene; eso es trabajo de UX.
Por qué importa. Porque al describir las pantallas aparecen huecos del modelo de datos que no eran evidentes antes. Si la pantalla de listado de pedidos debe permitir filtrar por estado y por rango de fechas, eso obliga a tener esos campos indexados. Si debe permitir exportar a Excel los pedidos del último trimestre, eso obliga a definir un endpoint de exportación. Cada decisión de pantalla aterriza decisiones técnicas.
Integraciones con sistemas existentes
Es donde más sobrecoste aparece en proyectos mal especificados. Una integración mal definida puede multiplicar por tres el esfuerzo del módulo afectado.
Qué debe describir. Para cada sistema externo con el que la solución va a hablar: qué datos se intercambian, en qué dirección, con qué frecuencia, mediante qué tecnología (API REST, archivo, base de datos directa, mensajería), cómo se autentica, qué pasa cuando la integración no está disponible, cómo se reintenta y qué se hace con los datos huérfanos.
Lo que se omite con más frecuencia. El comportamiento ante fallo. "Cuando se confirma un pedido en el ecommerce, se envía a SAP" es la mitad de la especificación. La otra mitad: ¿qué pasa si SAP está caído?, ¿se guarda en cola y se reintenta?, ¿durante cuánto tiempo?, ¿quién recibe el aviso?, ¿el cliente final ve el pedido como confirmado aunque SAP no lo haya recibido todavía?
Una regla útil. Si solo describes el caso bueno, no estás especificando una integración: estás documentando un deseo.
Requisitos no funcionales
Son los que casi nadie pone por escrito porque "se asumen". El problema es que cada agencia asume cosas distintas, y cuando descubres que tu sistema cae con cien usuarios concurrentes ya es tarde.
Qué debe describir. Tiempos de respuesta esperados (ventanas claras: el listado de pedidos no debería tardar más de dos segundos), volumen de datos previsto a tres años, número de usuarios concurrentes en pico, ventanas de mantenimiento permitidas, política de copias (frecuencia, retención, tipo de copia, prueba de restauración), exigencias de seguridad (cifrado en tránsito y en reposo, gestión de accesos, auditoría), cumplimiento legal aplicable (RGPD, factura electrónica, retención fiscal).
Por qué importa más de lo que parece. Porque cambia la arquitectura. Una solución para 50 usuarios concurrentes no es la misma que para 500. Una solución que tolera diez minutos de caída al mes no es la misma que la que tolera diez segundos. Si no lo dices, te dan la barata, y luego es muy caro cambiarla.
Criterios de aceptación
Los criterios de aceptación son lo que separa "ya está" de "todavía no". Sin ellos, el proyecto puede arrastrarse durante meses entre arreglos pequeños.
Qué debe describir. Por cada caso de uso o módulo, qué se considera entregado y qué no. "El módulo de pedidos está terminado cuando se pueden crear, editar, anular, listar con filtros, exportar a Excel y se ha probado con un volumen mínimo de mil registros sin degradación de rendimiento." Eso es un criterio. "Cuando funcione" no lo es.
Quién los redacta. Los redacta el cliente, idealmente con apoyo externo. La agencia no es la mejor posicionada para definir qué es "terminado" porque tiene incentivos cruzados. El propietario del producto sí.
Volumen de datos y migración
Si vas a sustituir un sistema actual, hay datos a migrar. Casi siempre se infraestima.
Qué debe describir. Qué datos hay hoy (cuántos clientes, cuántos pedidos históricos, cuántas facturas, cuántas líneas por pedido en media), qué calidad tienen (¿hay duplicados?, ¿campos vacíos?, ¿códigos antiguos?), qué se va a migrar (todo, los últimos N años, solo los abiertos), cómo se va a transformar y qué pasa con los datos que no se migran.
El error típico. Asumir que "los datos están bien". En el 95% de las migraciones, los datos del sistema antiguo están peor de lo que el cliente recuerda. La agencia acaba dedicando tiempo a limpieza no presupuestada y la fecha de salida se retrasa.
Glosario y stakeholders
Aparentemente prescindible, en realidad muy útil. En una empresa cualquiera, "cliente" puede ser cuatro cosas distintas: el contacto comercial, la cuenta facturable, el usuario final del producto, la entidad jurídica firmante. Si esa ambigüedad no se resuelve en el glosario, aparece a mitad de proyecto.
Qué debe describir. Los términos del negocio con su definición precisa, los actores que interactúan con el sistema (rol, permisos típicos, qué puede hacer y qué no) y los stakeholders del proyecto (quién decide, quién valida, quién tiene voz en cada bloque).
Cómo validar la propia especificación
Cuando hayas terminado el documento, antes de mandarlo a cotizar, comprueba estos seis puntos:
- ¿Dos personas leyendo el mismo párrafo entenderán lo mismo? Si encuentras frases que admiten interpretaciones distintas, no son funcionales.
- ¿Hay caminos alternativos descritos en cada flujo? Si solo describes el caso bueno, hay trabajo por hacer.
- ¿Las integraciones tienen comportamiento ante fallo? Si solo dices qué pasa cuando todo va bien, falta la mitad.
- ¿Los criterios de aceptación son verificables? "Funciona" no es verificable. "Se pueden crear mil pedidos en una hora sin degradación" sí lo es.
- ¿Los requisitos no funcionales tienen números? Sin números no hay forma de medir.
- ¿El glosario resuelve la ambigüedad de los términos del negocio? Si "cliente" puede ser cuatro cosas, el glosario tiene que aclararlo.
Una buena especificación funcional es la que evita el 80% de las discusiones que tendrías a mitad de proyecto. No la tendrá perfecta nadie a la primera. Pero la versión 3, después de dos rondas de revisión con el equipo y un externo crítico, suele estar lista para cotizar y para ejecutar.