Pliego de requisitos de una aplicación: lo que cuenta

El pliego de requisitos tiene mala fama, y a menudo con razón: un documento largo redactado una vez, que nadie vuelve a leer y que describe funciones en lugar de necesidades. Sin embargo, es el documento que decide si tres presupuestos son comparables, si el proyecto se ciñe a su presupuesto y si, en la entrega, se puede decir que está terminado. Lo que cuenta no es su extensión, sino lo que permite decidir.

En resumen

• Un pliego de requisitos útil sirve para tres cosas: comparar presupuestos, fijar el primer día y saber cuándo está terminado.
• Describe usos y resultados, no una lista de funciones ni decisiones técnicas impuestas sin motivo.
• Cuentan siete elementos: los usuarios, el primer día, los datos y los permisos, las integraciones, las restricciones, la propiedad y la explotación.
• Las obligaciones (datos personales, eliminación de cuenta, accesibilidad) se escriben desde el principio, cuando menos cuestan.
• Un prototipo navegable lo completa: muestra lo que las palabras describen mal.

Para qué sirve un pliego de requisitos

Un pliego de requisitos no es un trámite antes del trabajo de verdad. Presta tres servicios, que se miden a lo largo de todo el proyecto.

• Comparar presupuestos. Tres proveedores que leen el mismo documento cuantifican lo mismo. Sin él, cada uno cuantifica su propia idea del proyecto, y la diferencia de precio no dice nada.
• Fijar el primer día. Los desvíos suelen venir de funciones añadidas por el camino. Un perímetro por escrito permite decir «sí, en la próxima versión», sin conflicto.
• Saber cuándo está terminado. Unos criterios de aceptación por escrito («un técnico registra una intervención con tres fotos en menos de un minuto») convierten la entrega en una verificación, en lugar de en un debate.

Los siete elementos que cuentan

1. Quién la usa, y para qué

Los usuarios, nombrados por su función (el técnico, el cliente, la contable), y para cada uno los dos o tres gestos que debe poder hacer. Un recorrido descrito en una frase («el cliente sube un documento que falta desde su teléfono y recibe una confirmación») vale más que una lista de cuarenta funciones.

2. El primer día, y lo que esperará

La lista corta de lo que hace la aplicación en el lanzamiento, y la lista, más larga, de lo que vendrá después. Es la decisión que más pesa en el precio de una aplicación.

3. Los datos, y quién ve qué

Qué información guarda la aplicación, de dónde viene y, para cada función, lo que puede leer y modificar. Es la base de la seguridad de una aplicación, y es lo que hace posible un portal de clientes en el que cada uno solo ve sus expedientes.

4. Los programas que hay que conectar

El CRM, el ERP, la herramienta de facturación: para cada uno, qué circula y en qué sentido, y si dispone de una interfaz de programación documentada. Suele ser la línea más incierta de un presupuesto; un buen pliego de requisitos permite al proveedor decirlo.

5. Las restricciones de uso

Las condiciones reales: teléfonos de la empresa o personales, sin red en algunos lugares (vea la aplicación sin conexión), idiomas, notificaciones esperadas (vea las notificaciones push), pagos (vea la suscripción), funciones de IA (vea la IA en una aplicación). Y el canal de distribución: navegador, tiendas de aplicaciones o distribución privada, que compara PWA o aplicación nativa.

6. La propiedad

El código, la base de datos, las cuentas de desarrollador, el alojamiento y el dominio a su nombre, y una cesión de derechos por escrito. Es lo que evita tener que retomar un día una aplicación abandonada por su proveedor, y lo que explica publicar con su propia cuenta de desarrollador.

7. La explotación tras el lanzamiento

Quién vigila, quién corrige, en qué plazo, y el coste mensual partida por partida: alojamiento, base de datos, correos, cuentas de las tiendas, actualizaciones obligatorias. El detalle está en el presupuesto de mantenimiento de una aplicación.

Las obligaciones que hay que escribir desde el principio

Algunas exigencias cuestan poco al principio y mucho si hay que recuperarlas después. Tienen su lugar en el pliego de requisitos.

• La protección de datos desde el diseño. El artículo 25 del RGPD exige aplicar la protección de datos en el momento de diseñar el tratamiento, y tratar por defecto solo los datos necesarios para cada finalidad, según el texto publicado por la CNIL. Un dato que no se recoge no hay que protegerlo.
• La eliminación de cuenta. Las directrices de revisión de Apple son claras: una aplicación que permite crear una cuenta también debe permitir eliminarla desde la aplicación, según la regla 5.1.1.
• La accesibilidad. Desde el 28 de junio de 2025, la directiva europea de accesibilidad se aplica a ciertos servicios prestados a particulares, entre ellos el comercio electrónico y la banca. Incluso cuando no le afecta, una aplicación legible por todos sirve también a sus usuarios con prisa, a pleno sol o con una sola mano.

Lo que no tiene cabida en un pliego de requisitos

Imponer una tecnología no está prohibido cuando existe un motivo: sus equipos ya mantienen ese lenguaje, su departamento de informática impone un alojamiento. Sin motivo, más vale describir el resultado esperado, dejar que el proveedor proponga y después comparar las propuestas. Si una herramienta sin desarrollador puede bastar, el pliego de requisitos también lo revelará: es el tema de low-code o código.

Por dónde empezar

Escriba primero, en una página, los usuarios y sus gestos, y después el primer día. Haga probar esos gestos en un prototipo navegable antes de completar el resto: el prototipo eliminará funciones inútiles y revelará otras. Si aún duda entre desarrollar y comprar, la tabla de a medida o herramienta del mercado se rellena con la misma información. Para una aplicación de campo, parta de lo que cambia para sus equipos; para el back-end, de Supabase, Firebase o servidor propio. Y si la idea es generarlo todo con una IA, el vibe coding dice lo que queda por decidir a las personas.

Nuestro desarrollo de aplicaciones empieza por este documento: una definición por escrito de lo que hace la aplicación el primer día y de lo que esperará.

Preguntas frecuentes

Fuentes

1. CNIL, RGPD, capítulo 4 (nueva pestaña)cnil.fr
2. Directrices de revisión de la App Store, Apple (nueva pestaña)developer.apple.com
3. Directiva (UE) 2019/882, EUR-Lex (nueva pestaña)eur-lex.europa.eu