Documento de requisitos de una app: plantilla para 2027

Qué es el documento de requisitos de una app y en qué se diferencia del briefing

El documento de requisitos (también llamado especificación técnica) es el texto donde se escribe qué debe saber hacer exactamente la app y cómo vas a comprobar que está terminada. Lo leen tres personas a la vez: tú, el diseñador y el desarrollador. Si los tres entienden lo mismo, desaparece la principal fuente de discusiones en los proyectos: «yo pensaba que eso estaba incluido».

No mezcles tres documentos distintos. El briefing responde a «para qué» y «para quién»: objetivo, público, mercado, presupuesto. El documento de requisitos responde a «qué debe funcionar exactamente»: pantallas, acciones, reglas, datos. El presupuesto responde a «cuánto y cuándo», y llega después, a partir de los requisitos. Para una web ya vimos el briefing en el artículo briefing y requisitos de una página web; en una app hay más cosas que definir: el móvil, las tiendas de aplicaciones, las notificaciones, el funcionamiento sin conexión.

La buena noticia: no necesitas escribirlo como un ingeniero, con 80 páginas. Bastan 3–6 páginas de texto sencillo siguiendo la plantilla de abajo. El proveedor completará los detalles técnicos, pero no puede inventar por ti lo que necesita tu negocio.

Hay otra ventaja: con un documento único consigues presupuestos comparables. Cuando cinco estudios valoran el mismo texto, los precios se pueden poner uno al lado del otro. Cuando cada uno valora su propia versión de tu idea, no hay nada que comparar.

Plantilla de especificación de una app móvil: 10 apartados

Copia esta lista en un documento y rellena cada punto, aunque sea con una o dos frases. Un apartado vacío es una pregunta que habrá que resolver igualmente, pero más tarde y más cara.

1. Objetivo y resultado medible. Una frase: «los clientes reservan solos y el 30 % de las reservas llega por la app». Sin cifra también vale, pero entonces escribe cómo sabrás que ha funcionado.
2. Usuarios y roles. Quién la usa: cliente, profesional, administrador, repartidor. Cada rol tiene sus pantallas y sus permisos.
3. Plataformas. iOS, Android o ambas; si hace falta tableta; si basta una web que se instala en el móvil como una app (PWA) o hacen falta las tiendas de aplicaciones. Si dudas, compara antes app, web y PWA en coste y en tareas.
4. Mapa de pantallas. Lista de todas las pantallas y flechas entre ellas: acceso, inicio, catálogo, ficha, carrito, perfil. Vale un dibujo a mano fotografiado.
5. Escenarios. Paso a paso, qué hace la persona: «abre la app, elige un servicio, elige hora, paga, recibe el recordatorio».
6. Funciones con prioridades. Tres columnas: «sin esto no se puede lanzar», «estaría bien» y «más adelante». Es el apartado más importante para el presupuesto.
7. Datos e integraciones. Dónde se guardan usuarios y pedidos y con qué sistemas se conecta: pago, CRM, contabilidad, mapas, correo, mensajería.
8. Requisitos no funcionales. Velocidad, funcionamiento sin conexión, idiomas, seguridad, accesibilidad (más detalle abajo).
9. Publicación y cuentas. A nombre de quién se abren las cuentas de desarrollador, quién redacta la ficha de las tiendas, en qué países se publica.
10. Aceptación y fases. Cómo se comprueba el resultado, cuántas rondas de cambios hay y cómo se reparte el pago por fases.

A cada punto conviene añadir ejemplos de apps que te gusten y una línea sobre qué te gusta exactamente. «Quiero algo como Uber» no dice nada; «quiero que el mapa con puntos se vea como el de Uber y que el registro sea con número de teléfono» lo dice todo.

Requisitos de una app: funcionales y no funcionales

En un documento de requisitos de una app suele haber dos tipos de anotaciones. Los funcionales describen lo que hace la app: «el usuario puede mover su reserva hasta 2 horas antes». Los no funcionales describen lo bien que lo hace: rápido, seguro, claro y en los idiomas necesarios. Estos últimos son los que más se olvidan, y luego provocan discusiones.

Ejemplo para una app de reservas en un salón

Rol «cliente». Registro con número de teléfono y código por SMS. Catálogo de servicios con precio y duración. Elección de profesional y de hora libre. Pago anticipado con tarjeta. Recordatorio un día antes y 2 horas antes. Cancelación gratuita hasta 24 horas antes. Rol «administrador»: agenda de los profesionales, lista de reservas, devoluciones, envío de promociones.

Esa es la parte funcional. Le añadimos la no funcional:

• Velocidad. La pantalla principal se abre sin retraso apreciable en un móvil medio de hace cinco años.
• Conexión. Qué ve el cliente sin internet: su última reserva o un mensaje de error. Un modo sin conexión completo cuesta aparte.
• Idiomas y monedas. Cuántos idiomas tiene la interfaz, en qué moneda van los precios y cómo se muestran las fechas.
• Seguridad y datos. Qué datos personales se guardan, quién los ve y cómo borra una persona su cuenta. Si trabajas en tu país, consulta con un abogado los requisitos de protección de datos: en la UE se aplica el RGPD y, en España, también la LOPDGDD.
• Accesibilidad. Letra grande, contraste y etiquetas para lectores de pantalla. Es comodidad y, además, una exigencia en algunos mercados.
• Dispositivos. Desde qué versión de iOS y Android se da soporte y en qué pantallas se prueba.

No olvides la parte «invisible»: la mayoría de las apps tienen un panel de administración donde el equipo gestiona contenidos y pedidos. En el documento se escribe como apartado propio; si no, resulta que la app está lista pero no hay con qué gestionarla.

Qué escribir sobre App Store y Google Play

La publicación es una fase aparte, con sus propias reglas, y en ella influyen más factores que nosotros. Por eso conviene dejar por escrito varios puntos desde el principio.

• Cuentas de desarrollador. Apple cobra $99 al año y Google Play, $25 una sola vez. Publicamos la app en tu cuenta, así que anota quién la abre y quién guarda los accesos.
• Versión terminada para revisión. Según las normas de Apple (apartado 2.1, «integridad de la app»), a revisión se envía una versión completa: sin marcadores ni páginas provisionales, con enlaces que funcionan y, si hay acceso con cuenta, con un acceso de prueba para el revisor; además, la parte de servidor debe estar operativa en ese momento. En el documento esto se convierte en un punto de aceptación: «cuenta de prueba y descripción para el revisor preparadas».
• Pruebas para Google Play. A las cuentas personales de desarrollador nuevas Google les exige una prueba cerrada: al menos 12 probadores conectados durante 14 días seguidos, y solo después permite el lanzamiento para todos. Cuenta con esas dos semanas en el plazo o abre una cuenta de organización; consulta las condiciones actuales en la ayuda de Google Play.
• Textos e imágenes para las tiendas. Descripción, capturas, política de privacidad y clasificación por edades. Quién los redacta y en qué idiomas.
• Pagos. Si en la app se venden productos digitales o suscripciones, las tiendas tienen sus propias reglas y comisiones. Para productos físicos y servicios las reglas son otras. Anota qué vendes y el proveedor te indicará el esquema adecuado.

Los plazos de revisión de las tiendas no dependen de nosotros, así que nunca prometemos una fecha exacta de aparición en la tienda. Los pasos de la publicación están explicados en el artículo cómo crear una app: de la idea al App Store.

Cinco errores en el documento que alargan plazos y suben el precio

1. Sin prioridades. Cuando todo es «muy necesario», la valoración incluye todo y lanzas la primera versión a los seis meses en lugar de a los dos. Divide las funciones en «imprescindible», «estaría bien» y «más adelante».
2. Sin criterios de aceptación. «Bonito y cómodo» no se puede comprobar. «La reserva se crea en no más de cuatro toques» sí.
3. Se olvidan el panel de administración y los roles. La app para el cliente es la mitad del producto. La otra mitad es la herramienta de tu equipo.
4. Integraciones vagas. «Conectar con el CRM» supone trabajos de distinto tamaño según el sistema. Nombra el sistema y describe qué datos van adónde.
5. Sin responsable. Si por tu parte deciden tres personas, el proyecto se frena en las aprobaciones. Nombra a una sola persona que diga «sí» o «no».

Otra trampa frecuente es escribir el documento para un «producto ideal» ya terminado. Es mejor describir la primera versión, que pone a prueba la idea con personas reales, y aparte una lista con todo lo que añadirás si funciona. Cómo es esa primera versión y cuánto cuesta lo explica el artículo qué es un MVP y cuánto cuesta lanzarlo.

Comprueba si tu documento está listo para que lo valoren

Haz la breve lista de comprobación de abajo. Te indica si ya puedes enviar el documento a los proveedores o conviene cerrar antes algunos huecos. Si respondes «no» a la mayoría, no pasa nada: parte de las preguntas puede resolverse junto con el proveedor, y estamos dispuestos a hacerlo.

Quién debe redactarlo: tú, el proveedor o los dos

Hay tres escenarios que funcionan, y la elección depende de lo clara que tengas la idea.

• Lo escribes tú siguiendo la plantilla. Sirve si la idea es sencilla y conoces a tu público. Recibirás varias valoraciones y podrás compararlas.
• El proveedor lo redacta a partir de tu briefing. Es cómodo, pero recuerda: cuanto más detallado es el documento, más exacto es el presupuesto. Un documento gratuito a menudo acaba siendo un «documento a la medida de nuestro precio», así que pregunta de quién es si luego eliges a otro equipo.
• Trabajo previo de pago. Para productos complejos (roles, pagos, varios sistemas) lo hacemos como fase aparte: la sesión de arquitectura por €3.500. Obtienes el mapa del producto, el presupuesto y el plan de la primera versión. Ese importe se descuenta del proyecto, y el mapa es tuyo en cualquier caso, aunque después elijas a otro equipo.

Si necesitas pantallas y no solo texto, añade diseño y prototipo, desde €1.990: un prototipo en el que se puede hacer clic en el móvil explica la idea mejor que diez páginas de descripción. En los paquetes de app ya preparados el diseño está incluido.

Cómo elegir a quién confiar el documento y el proyecto lo explica el artículo cómo elegir una agencia de diseño web y no equivocarte: las mismas preguntas valen para quien desarrolla apps. Y cuánto cuesta la app en sí lo cuenta cuánto cuesta hacer una app.

Qué elegir en tu situación

• La idea es sencilla: un escenario, un rol. Rellena la plantilla tú mismo, envíala a dos o tres equipos y compara las respuestas. Una app para iOS y Android cuesta con nosotros desde €10.900; la cifra exacta se calcula en el presupuesto, después de los requisitos.
• Hay varios roles, pagos e integraciones. No lo escribas a ciegas: empieza por la sesión de arquitectura y obtén los requisitos en forma de mapa del producto y presupuesto.
• No estás seguro de que necesites una app. Quizá baste una web en el móvil o una mini app de Telegram. Compara las opciones y su coste antes de escribir el documento.
• Ya tienes un documento de otro estudio. Muéstranoslo a nosotros y a otros proveedores: un documento, varias propuestas. Cómo comparar las respuestas con honestidad lo explica el artículo cómo comparar presupuestos de diseño web.
• Necesitas lanzar cuanto antes. Describe solo las funciones imprescindibles y deja el resto para la segunda versión.

Si no sabes por dónde empezar, escríbenos tu idea en el formulario de contacto: te diremos qué formato de arranque encaja contigo, en tu ciudad o en remoto.