Cómo escribir un documento de requisitos para un sitio web
Un documento de requisitos existe para que usted y quien desarrolle estén describiendo el mismo sitio web. No tiene por qué ser largo. Un encargo de cuatro páginas que ambas partes han leído de verdad evita más disputas que una especificación de cincuenta que ninguna ha terminado.
Esta guía cubre qué debe contener, qué dejar fuera y cómo escribir la sección que más importa: lo que el proyecto no es.
Para qué sirve un documento de requisitos#
Tiene tres funciones: permitir que varios desarrolladores presupuesten lo mismo para que las cifras sean comparables, darle una referencia cuando haya desacuerdo sobre el alcance y obligarle a decidir mientras decidir todavía es barato.
No es un briefing de diseño ni una especificación técnica. Decir «el sitio debe cargar rápido» es un requisito; decir «usar Redis para la caché de objetos» es una solución, y elegirla antes de contratar a nadie elimina la experiencia por la que está pagando.
- Enuncie resultados y restricciones, no implementaciones.
- Escríbalo para que alguien de fuera de su organización lo entienda sin una llamada.
- Manténgalo lo bastante corto para leerlo de una sentada: de cuatro a ocho páginas sobran para casi todos los sitios.
- Póngale fecha y versión, porque cambiará.
Las secciones que merecen la pena#
Esta estructura cubre casi todos los proyectos web. Omita lo que no aplique en vez de rellenarlo.
| Sección | Qué va dentro |
|---|---|
| Contexto | A qué se dedica la organización y por qué se construye o sustituye el sitio |
| Objetivos | El objetivo principal, los secundarios y cómo se mide el éxito |
| Público | Dos o tres grupos de visitantes y la pregunta con la que llega cada uno |
| Estructura de páginas | Cada página, agrupada en secciones, marcada como crítica o posterior |
| Requisitos funcionales | Formularios, búsqueda, cuentas, filtros, reservas, pago: qué debe hacer cada uno |
| Integraciones | Cada sistema externo, con un contacto y enlace a su documentación de API |
| Contenido | Quién escribe cada página, quién la aprueba, cuándo vence |
| No funcionales | Rendimiento, accesibilidad, navegadores y dispositivos, idiomas, seguridad |
| Fuera de alcance | Trabajo excluido explícitamente: la sección más valiosa |
| Restricciones | Rango de presupuesto, fecha y cualquier decisión fija (alojamiento actual, CMS impuesto) |
Escriba requisitos que se puedan comprobar#
Un requisito es útil cuando ambas partes pueden acordar después si se cumplió. «El sitio debería ser rápido» no se puede comprobar; «la página de listado de productos alcanza Largest Contentful Paint por debajo de 2,5 segundos en un Android de gama media sobre 4G» sí.
Lo mismo con las funcionalidades. «Un formulario de contacto» deja fuera todas las preguntas que importan.
| Vago | Comprobable |
|---|---|
| Un formulario de contacto | Seis campos, protección antispam, guarda en base de datos, envía a dos direcciones, línea de consentimiento RGPD |
| Adaptado a móvil | Usable a 320 px, todos los objetivos táctiles de al menos 44 px, sin desplazamiento horizontal |
| Rápido | LCP por debajo de 2,5 s y CLS por debajo de 0,1 en las cuatro plantillas principales, medido en 4G |
| Accesible | WCAG 2.2 AA en las plantillas, verificado con pasadas de teclado y lector de pantalla |
| Apto para SEO | Títulos y descripciones editables, URLs limpias, sitemap, datos estructurados en artículos |
| Multiidioma | Tres idiomas, URLs traducidas, etiquetas hreflang, selector de idioma en cada página |
La lista de fuera de alcance#
Es la sección que la gente se salta y la que salva el proyecto. Escriba las cosas que una persona razonable podría dar por incluidas y diga con claridad que no lo están, o inclúyalas, si deberían estarlo.
Hacerlo antes de que lleguen los presupuestos hace que sean comparables. Hacerlo después significa una discusión.
- Redacción y corrección de textos: dé por hecho que son suyos salvo que el presupuesto diga lo contrario.
- Fotografía, ilustración y licencias de banco de imágenes.
- Carga de contenido: ¿quién teclea 200 productos en el CMS?
- Configuración de correo, migración de DNS y traspaso de la cuenta de alojamiento.
- Trabajo de SEO continuo, distinto de la configuración técnica al lanzar.
- Formación, documentación y traspaso.
- Soporte posterior al lanzamiento: qué se cubre, durante cuánto y qué se factura.
Un buen profesional añadirá cosas a esta lista sin que se lo pidan. Quien acepta todo sin preguntas normalmente no la ha leído, y el desacuerdo simplemente queda aplazado.
Preguntas frecuentes
¿Cuánto debe ocupar un documento de requisitos?
De cuatro a ocho páginas cubre casi cualquier web de empresa. Las tiendas y las aplicaciones se alargan porque crece la sección funcional, pero si pasa de veinte páginas pregúntese qué se está describiendo que una conversación no resolvería. La medida es si ambas partes lo han leído, no si es exhaustivo.
¿Debo especificar la tecnología?
Solo donde tenga una restricción real: un CMS que su equipo ya conoce, un alojamiento en el que debe permanecer, un sistema que hay que integrar. Por lo demás, enuncie el resultado y deje que quien contrate elija la implementación. Imponer una tecnología que no entiende reduce sus opciones y le da una respuesta peor.
¿Necesito también wireframes?
Wireframes de baja fidelidad para las tres o cuatro plantillas más importantes eliminan mucha ambigüedad con muy poco esfuerzo, y son mucho más baratos de cambiar que un diseño. No sustituyen a los requisitos escritos —muestran disposición, no comportamiento—, pero los dos juntos permiten presupuestar con mucha más precisión que cualquiera por separado.
¿Y si no sé algunas respuestas?
Escriba «por decidir» y nombre quién decide y para cuándo. Un hueco honesto con responsable está bien; una respuesta inventada no, porque el presupuesto se construirá sobre ella. Quien desarrolla valora la incertidumbre de todos modos, así que hacerla visible suele darle mejor cifra que esconderla.
documento de requisitos webbriefing webespecificación sitio webpliego webalcance del trabajo webrequisitos desarrollo web
