La mitad de los conflictos entre clientes y desarrolladores empieza con una frase: «Pero habíamos quedado en que funcionaría de otra manera». Quedado, sí. Por escrito, no. Una especificación de requisitos de software resuelve justo este problema: deja por escrito qué se va a construir, cómo va a funcionar y qué se considera terminado.
Esta guía recorre la estructura completa de una especificación apartado por apartado, repasa los errores típicos con ejemplos de «mal» y «bien», y responde a la eterna pregunta: ¿quién debe redactar la especificación, el cliente o el proveedor?
Qué es una especificación y cuándo la necesitas de verdad
Una especificación de requisitos de software (ERS, o SRS en inglés) es un documento que describe qué debe hacer el sistema, no cómo funciona por dentro. Responde a «qué construimos», no a «con qué lo construimos». La arquitectura, la elección de frameworks y la estructura de la base de datos son trabajo de los desarrolladores, no de la especificación.
Una buena especificación hace tres cosas:
Cuándo NO necesitas una especificación
Siendo sinceros, no siempre hace falta. Estas son las situaciones en las que una especificación detallada es una pérdida de tiempo:
Proyectos MVP de menos de unos 13.500 €. Cuando estás validando una hipótesis, no construyendo un sistema corporativo. Aquí bastan historias de usuario + un prototipo en Figma. Una especificación de 40 páginas para un MVP le lleva a un analista 2–3 semanas. En ese tiempo ya podrías tener el MVP hecho. Cuánto cuestan un MVP y un producto completo lo explicamos en nuestro artículo sobre el coste de desarrollar una app.
Trabajo ágil con un equipo de producto. Si tienes un equipo dedicado, un product owner y sprints de dos semanas, el backlog sustituye a la especificación. Los requisitos se van definiendo por iteraciones en lugar de escribirse con un año de antelación.
Proyectos estándar. Una tienda online sobre una plataforma ya hecha, una landing page o una web corporativa con un CMS: basta con un brief que describa las páginas y el contenido.
La regla: necesitas una especificación cuando el proyecto cuesta unos 13.500 € o más y/o dura más de 2 meses, tiene una lógica de negocio poco estándar, y el cliente y el desarrollador se imaginan el resultado de forma distinta. Cuanto más caro es el proyecto, más cuesta un malentendido.
La estructura de una buena especificación: 14 apartados
Errores típicos al redactar una especificación
Error 1: describir una solución en lugar del problema
Mal: «Poner en la página de inicio un slider con 5 banners que cambien cada 4 segundos con una animación de fundido».
Bien: «La página de inicio tiene un bloque con las promociones vigentes (hasta 5 a la vez). El administrador lo gestiona desde el panel. Los visitantes ven las promociones sin hacer scroll».
Por qué: en el primer caso has impuesto una implementación concreta (un slider), aunque la tarea «mostrar promociones» quizá se resuelva mejor con tarjetas, un carrusel o un vídeo. Describe qué necesitas, no cómo construirlo.
Error 2: requisitos que no se pueden medir
Mal: «El sistema debe ser rápido y fácil de usar».
Bien: «Cualquier página carga en 2 segundos como máximo con una conexión de 10 Mbps. La acción clave (crear una reserva) requiere 3 clics como máximo desde la página de inicio».
Por qué: «rápido» y «fácil» son subjetivos. Para una persona 3 segundos es rápido; para otra, lento. Los números eliminan la subjetividad.
Error 3: una especificación de 100 páginas para un proyecto de 13.500 €
Un caso real: una empresa dedicó 3 meses y casi 12.000 € a redactar la especificación de un proyecto de 36.000 €. Cuando estuvo lista, los requisitos de negocio ya habían cambiado. Hubo que reescribir un tercio del documento.
La regla: la especificación debería costar el 5–10% del proyecto. Para un proyecto de 27.000 €, eso es una especificación de 1.350–2.700 € (1–2 semanas de trabajo de un analista). Para uno de 135.000 €, de 6.750–13.500 € (3–4 semanas).
Error 4: olvidarse de los casos límite
Mal: «El usuario paga el pedido con tarjeta».
Bien: «El usuario paga el pedido con tarjeta. Si el pago falla, mostramos un error y le ofrecemos reintentarlo o elegir otro método. Si el pago se completa pero el producto está agotado, se hace un reembolso automático en un plazo de 24 horas con aviso por email. Si el usuario cierra la página durante el pago, el pedido se reserva durante 30 minutos».
Por qué: todo el mundo describe el escenario principal. Muy pocos describen los errores y las excepciones. Y es justo en los casos límite donde fallan la mayoría de los sistemas.
Error 5: no indicar lo que NO está incluido
El cliente esperaba que con la plataforma web viniera una app móvil: «hombre, es evidente». El desarrollador daba por hecho que el alcance era solo web. Un apartado de «Limitaciones y supuestos» evita conflictos así.
Error 6: decir una cosa en un sitio y contradecirla en otro
Apartado 4: «El usuario inicia sesión con email y contraseña». Apartado 9, un caso de uso: «El usuario inicia sesión con un código por SMS». Cuando una especificación la escriben distintas personas a lo largo de 3 semanas, las contradicciones son inevitables. Por eso necesita una revisión completa antes de cerrarla: una persona lee todo el documento de principio a fin y busca conflictos internos.
Error 7: no priorizar los requisitos
Cuando una especificación tiene 80 funciones y todas están marcadas como «obligatorias», no es una especificación, es la carta a los Reyes Magos. Usa la priorización MoSCoW: Must have (sin esto el sistema no tiene sentido), Should have (importante, pero se puede lanzar sin ello), Could have (estaría bien tenerlo), Won't have (no en esta versión). Así es más fácil encajar el proyecto en el presupuesto: si el dinero solo cubre Must + Should, el resto pasa a la siguiente iteración.
Checklist: cómo comprobar la calidad de una especificación
Antes de dar el visto bueno a una especificación y empezar el desarrollo, repasa estos 10 puntos:
¿Quién debe redactar la especificación?
La respuesta corta: el proveedor (el estudio o el desarrollador), con el cliente muy implicado.
La respuesta larga: una especificación traduce los requisitos de negocio al lenguaje del desarrollo. El cliente aporta el conocimiento del negocio (conoce los procesos, los problemas y a los usuarios). El proveedor aporta el conocimiento técnico (sabe qué es viable, qué sale caro y dónde están las trampas).
Una especificación escrita solo por el cliente tiene requisitos de negocio sin ningún criterio técnico detrás: es una lista de deseos. Una especificación escrita solo por el desarrollador, sin meterse en el negocio, es una fantasía técnica desconectada de la realidad.
El mejor proceso:
Cuánto cuesta redactar una especificación
(web, landing page, MVP)
(plataforma web, CRM)
(marketplace, ERP)
Qué incluye: una serie de entrevistas con el cliente, análisis de los procesos de negocio, requisitos funcionales y no funcionales, prototipos de las pantallas clave (Figma), un mapa de integraciones y un desglose por fases con presupuesto.
Qué recibes: un documento de 15–60 páginas (según el proyecto), un prototipo clicable y un presupuesto de desarrollo detallado.
Importante: si un estudio te ofrece una «especificación gratis», lo más probable es que sea un brief de 2 páginas, no una especificación de requisitos de verdad. Una especificación real lleva 1–4 semanas de trabajo de un analista. Nadie lo hace gratis: el coste simplemente va incluido en el precio del desarrollo (y lo pagas sin saberlo).
Nuestra plantilla de especificación
Hemos preparado la plantilla de especificación que usamos en nuestros propios proyectos. No es un modelo vacío sacado de internet. Es un documento de trabajo que hemos ido puliendo durante años de desarrollo de software para decenas de clientes.
Qué incluye:
14 apartados con instrucciones y ejemplos para cada bloque. Un checklist de revisión: 25 puntos para valorar si el documento está completo y es sólido. Ejemplos de redacción: cómo describir funciones, roles, integraciones y requisitos no funcionales.
Para recibir la plantilla, envíanos una solicitud y escribe «Plantilla de especificación» en el mensaje. Te la mandamos por email en un día laborable. Es gratis y sin compromiso.
Si ya tienes una idea del proyecto pero no tienes recursos para redactar la especificación, podemos encargarnos nosotros. Hacemos las entrevistas, describimos los requisitos, construimos los prototipos y preparamos un documento con el que se puede empezar a desarrollar de inmediato.
Preguntas frecuentes
¿Puedo empezar el desarrollo sin especificación?
Puedes, si el proyecto cuesta menos de unos 9.000–13.500 € y dura 4–6 semanas. Para un MVP, muchas veces bastan historias de usuario + un prototipo. Pero en proyectos de más de 27.000 €, saltarse la especificación es jugar a la ruleta rusa: puede salir bien o puede costarte un 30–50% más de presupuesto en rehacer trabajo.
¿En qué se diferencia una especificación de un brief?
Un brief son 2–5 páginas con una descripción general de la tarea: quién eres, qué quieres, el presupuesto, el plazo. El cliente lo rellena en 1–2 horas. Una especificación son 15–60 páginas que describen en detalle cada función, escenario, integración y limitación. La redacta un analista en 1–4 semanas. El brief es la puerta de entrada al proyecto. La especificación es la base del presupuesto y del desarrollo.
¿La especificación debe describir el diseño?
Sí, pero como requisitos de UX, no como maquetas. «La acción clave requiere 3 clics como máximo», «La interfaz debe funcionar en pantallas desde 320px», «Navegación como la de Notion: barra lateral + búsqueda». El diseño visual es una fase aparte (UI) que llega después de aprobar la especificación.
¿Puede cambiar la especificación durante el desarrollo?
Puede y debe: los requisitos de negocio no se quedan quietos. Pero cada cambio tiene que pasar por un proceso formal: describir el cambio → evaluar su impacto en plazo y presupuesto → aprobarlo → actualizar la especificación. Sin ese proceso, el scope creep (el alcance que crece sin control) se comerá el presupuesto y la motivación del equipo.
¿Cuál es el mejor formato para una especificación?
Para el documento, Google Docs o Notion (edición conjunta, comentarios, historial de versiones). Para los prototipos, Figma. Para los escenarios, Miro (diagramas de flujo de usuario). PDF solo para la versión final que firman ambas partes. Mientras se trabaja en él, el documento debe seguir «vivo», abierto a comentarios y cambios.
¿La especificación tiene que seguir un estándar formal?
Existen estándares formales para documentos de requisitos, como IEEE 830 (revisado por última vez en 1998 y sustituido después por ISO/IEC/IEEE 29148). Imponen una estructura rígida con muchos apartados obligatorios. Si un contrato público o una licitación exige un estándar concreto, síguelo. En proyectos comerciales no hace falta. Hoy una especificación tiene que ser clara para ambas partes, no marcar todas las casillas de una plantilla de hace décadas.
¿Cuánto tiempo sigue siendo válida una especificación?
En la práctica, 3–6 meses. Pasado ese tiempo, los requisitos de negocio, el mercado y la tecnología cambian lo suficiente como para que haya que actualizarla. Si la especificación se redactó y el desarrollo empieza 8 meses después, revisa el documento antes del arranque.
Si estás planificando un proyecto y quieres empezar con la especificación adecuada, escríbenos. Te hacemos una consulta gratuita, te ayudamos a definir el alcance y te proponemos cómo trabajar juntos.
