Documento de requisitos para una app móvil: plantilla

Documento de requisitos de una app móvil: la respuesta corta

Cuando creas tu propia app, un buen documento de requisitos cabe en una página. Responde diez preguntas: para quién es, qué problema resuelve, cuál es la función principal, cómo gana dinero la app, qué pasa sin cuenta, qué datos tienen que sobrevivir, en qué plataforma, qué queda fuera de la primera versión, cómo sabrás que funciona y con qué restricciones trabajas. La plantilla para copiar está más abajo. También puedes descargar la plantilla y su tabla de validación (.md), sin registrarte.

Las plantillas de 40 páginas que encuentras en internet están escritas para otro uso: un cliente que le encarga una app a un proveedor y necesita un documento contractual. Tú eres a la vez quien decide y quien construye, muchas veces con ayuda de la IA. Tu documento de requisitos sirve para dos cosas: tomar las decisiones antes de programar y darle a Claude, ChatGPT o Cursor un contexto claro para que construyan la app correcta.

Publico mis propias apps iOS. Solys, un despertador con minijuegos, y TradaZen, un simulador de trading, están en el App Store. Nolera y Clic fueron rechazadas por Apple y después corregidas. Este es el método que aplico a cada una, y es el que te propongo aquí.

Por qué una página basta para definir tu propia app

Un documento largo da la impresión de haber avanzado. En la práctica, se escribe una vez, casi nunca se vuelve a leer y el proyecto se aleja de él desde las primeras semanas. Una página, en cambio, se relee en dos minutos antes de cada sesión de trabajo.

El límite de espacio también tiene un efecto útil: te obliga a decidir. Si una respuesta pasa de dos frases, muchas veces es porque la decisión no está tomada. Mejor descubrirlo en una hoja que en tu código, tres semanas después.

Por último, una página es el tamaño adecuado para la IA. Puedes pegarla completa en una conversación o guardarla en el archivo de contexto de tu proyecto. Un documento corto es más fácil de revisar y reduce las instrucciones contradictorias. No garantiza que la IA las siga: verifica sus propuestas contra este marco.

¿Qué debe incluir el documento de requisitos de una app móvil?

Responde cada una de estas preguntas en una o dos frases.

1. ¿Quién usa la app y en qué situación? No «personas de 18 a 35 años». Mejor una persona concreta, en un momento concreto de su día.
2. ¿Qué problema resuelve la app, en una frase? Si necesitas un «y además», estás describiendo dos apps.
3. ¿Cuál es LA función principal de la primera versión? Una sola. Las demás esperarán a los números. La página MVP de una app iOS explica cómo elegirla.
4. ¿Cómo gana dinero la app? Suscripción, pago único o gratis. Esta respuesta cambia la app desde la primera pantalla. Si dudas, lee suscripción o pago único para una app iOS.
5. ¿Qué se puede hacer sin crear una cuenta? Decidir pronto qué es accesible sin registro te evita rehacer todo el recorrido de bienvenida.
6. ¿Qué datos tienen que sobrevivir a un cambio de teléfono? Esta es la pregunta que decide si necesitas un backend como Supabase o si todo puede quedarse en el dispositivo.
7. ¿Solo iOS, o iOS y Android? Mi consejo cuando estás empezando: primero iOS. Explico por qué en app iOS y Android al mismo tiempo.
8. ¿Qué queda explícitamente FUERA de la primera versión? La sección más útil del documento. Corta los debates antes de que existan, contigo mismo y con la IA.
9. ¿Cómo sabrás que funciona? Una sola señal, medible en las semanas posteriores al lanzamiento: pruebas gratuitas iniciadas, suscriptores, usuarios que vuelven.
10. ¿Cuáles son tus restricciones reales? El tiempo que puedes dedicarle cada semana, tu equipo y tu cuenta de Apple Developer, que cuesta 99 $ al año. ¿No tienes Mac? No es un obstáculo, como explico en publicar una app iOS sin Mac.

La plantilla de documento de requisitos para copiar

Copia esta plantilla en una nota o en un archivo de texto en la raíz de tu proyecto y luego reemplaza cada línea.

• Nombre provisional de la app: …
• Para quién: una persona que … en el momento en que …
• Problema resuelto, en una frase: …
• Función principal de la versión 1: …
• Lo que ve el usuario al abrir la app por primera vez: …
• Modelo de negocio: suscripción / pago único / gratis, y qué es de pago: …
• Sin cuenta, se puede: …
• Datos que se conservan entre dos teléfonos: ninguno / …
• Plataforma: primero iOS (Android más adelante si los números acompañan)
• Fuera de la versión 1: …, …, …
• Señal de éxito: …
• Stack: React Native, Expo, Supabase si hacen falta cuentas, RevenueCat para las suscripciones
• Restricciones: … horas por semana, cuenta de Apple Developer abierta o no, Mac o no
• Apps cuya experiencia me gusta, y por qué: …

Agrega de tres a cinco capturas de apps que te gustan, con una palabra sobre lo que te gusta de ellas. Dice más que una guía de estilo, para ti y para la IA.

Un documento de requisitos no es una lista de deseos. Es una lista de decisiones tomadas.

Ejemplo: la página completa para una app ficticia

Para que veas el nivel de detalle esperado, aquí está la plantilla completa para una app inventada como ejemplo, un temporizador de estudio.

• Para quién: un estudiante que estudia solo por la noche y se distrae a los diez minutos.
• Problema: no logra aguantar una sesión de trabajo sin tocar el teléfono.
• Función principal: iniciar una sesión cronometrada y ver su racha de días cumplidos.
• Primera pantalla: un solo botón para iniciar una sesión.
• Modelo de negocio: suscripción para las estadísticas detalladas, sesión básica gratis.
• Sin cuenta: todo, salvo el respaldo entre dos teléfonos.
• Fuera de la versión 1: modo grupal, ranking entre amigos, widgets, versión Android.
• Señal de éxito: usuarios que vuelven varios días seguidos.

Fíjate en lo que falta a propósito: ninguna lista de veinte pantallas, ningún color impuesto, ninguna arquitectura. Esas decisiones llegarán mientras construyes, y la página te sirve para comprobar que siguen al servicio de la función principal.

Cómo usar tu documento de requisitos para guiar a la IA

Aquí es donde tu página rinde más. Una IA que programa sin contexto adivina, y muchas veces adivina una app distinta de la tuya.

Pon la página en el contexto permanente del proyecto. Claude Code lee un archivo CLAUDE.md en la raíz, Cursor tiene sus propios archivos de reglas. Pega ahí tu documento de requisitos, junto con tu stack. Así cada petición parte de la misma base.

Cita la sección «fuera de la versión 1» cuando la IA se pase. Los asistentes proponen funciones extra con gusto: un modo oscuro, una opción para compartir, una notificación. Tu lista de exclusiones te da una respuesta lista: ahora no.

Pide un plan que respete la página. Antes de una tarea grande, escribe: «este es mi documento de requisitos, propón un plan para la función principal, todavía no programes». Detectas enseguida si el plan se aleja de lo que decidiste.

Haz que revise la página, no solo el código. Pregúntale: «¿qué preguntas de este documento de requisitos son confusas o contradictorias?». Es un uso subestimado de la IA y te ahorra semanas de trabajo en la dirección equivocada.

Para profundizar en este tema, detallé las trampas y las verificaciones en crear una app iOS con IA.

Convertir las decisiones en criterios de validación

Una función principal debe tener un resultado observable. Para el temporizador ficticio de este ejemplo, «el temporizador funciona» es demasiado vago. Escribe mejor: «Inicio una sesión, se muestra el tiempo restante, puedo detenerla y encontrar la última sesión terminada después de volver a abrir la app». Decide por separado si el temporizador debe seguir con la pantalla bloqueada: esa decisión puede cambiar el trabajo técnico.

Agrega para cada función tres líneas: acción, resultado esperado, prueba. La prueba puede ser un test automatizado para un cálculo o una verificación en el dispositivo para un recorrido. Anota también lo que no se probó. Esta pequeña tabla evita confundir una pantalla terminada con una función lista para usarse.

Aquí tienes una tabla completa para nuestro temporizador ficticio. Son criterios por verificar, no pruebas ya superadas:

Decisión del planteamiento	Qué probar	Resultado esperado
La sesión básica es accesible sin cuenta	Instalar la app e iniciar una sesión sin registrarse	Ningún formulario de registro bloquea el inicio
Una sesión abandonada no cuenta para la racha	Detener una sesión antes de que termine y abrir el historial	No se agrega ninguna sesión terminada
El historial se queda en el dispositivo	Terminar una sesión, cerrar la app y volver a abrirla	La sesión aparece una sola vez con la duración correcta
El temporizador básico funciona sin conexión	Activar el modo avión y terminar una sesión	El temporizador y el guardado local siguen funcionando
Las estadísticas detalladas son de pago	Abrir las estadísticas sin suscripción	Se muestra la oferta; la sesión básica sigue accesible

Los temas que siguen confusos se convierten en decisiones pendientes. Por ejemplo: ¿qué hacer si el usuario bloquea la pantalla o cambia la hora del teléfono durante una sesión? No dejes que el agente decida en silencio. Escribe el comportamiento que quieres y luego agrega el caso a la tabla. Para organizar estas pruebas en una instalación real, usa la guía probar tu app de iPhone con TestFlight.

Decidir qué quitar cuando la primera versión se desborda

Repasa cada función y hazte una pregunta: «Sin ella, ¿el usuario todavía puede obtener el resultado prometido?». Para nuestro temporizador, un ranking entre amigos puede esperar. Recuperar una sesión terminada es necesario si prometes una racha de días. Una pantalla de suscripción solo se vuelve necesaria si realmente vendes las estadísticas desde esta versión.

Anota la decisión y su motivo en el registro de la plantilla descargable. Podrás reconsiderar esa decisión después de las pruebas sin perder el porqué del alcance inicial. El tutorial crear una aplicación con Claude Code muestra después cómo convertir este planteamiento en peticiones acotadas y verificables.

Como experiencia real, TradaZen cambió de alcance después de su publicación. El planteamiento sirve para lanzar una primera versión medible y luego decidir la siguiente con comentarios reales.

La trampa del catálogo de funciones

El reflejo natural es listar todo lo que la app «tendrá que hacer»: el mapa, el chat, las notificaciones, los referidos, el modo sin conexión. Ese catálogo es la señal más fiable de un proyecto que no llega a buen puerto, por una razón simple: cada función agregada antes del lanzamiento retrasa el momento en que usuarios reales te dicen qué importa.

Una buena primera versión hace una cosa y la hace bien. Pero cuidado con el exceso contrario: Apple pide que una app vaya más allá de un sitio web empaquetado, según la regla 4.2 de las App Review Guidelines. Una sola función principal, sí; un cascarón vacío, no: ese es el motivo de la guideline 4.2.

Lo que no debe incluir el documento de requisitos de una app móvil

• Una guía de estilo completa. Al principio bastan unas cuantas capturas de referencia.
• Un calendario día por día. Todavía no tienes la información para cumplirlo. Basta con un objetivo semanal.
• Una arquitectura técnica detallada. Elige un stack probado y deja que los detalles se decidan mientras construyes.
• Funciones «para después» mezcladas con el resto. Todas van en la sección fuera de la versión 1.

¿Cuándo actualizar tu documento de requisitos?

Reléelo al inicio de cada semana de trabajo. Actualízalo solo cuando una decisión cambie por una razón real: una prueba en tu iPhone que demuestra que una pantalla no funciona, un comentario de un tester, una restricción de Apple descubierta en el camino. Si lo modificas todos los días, es que ya no está definiendo nada.

Una vez publicada la primera versión, la página se vuelve la base de la siguiente: lo que estaba fuera de la versión 1 sube, ordenado según lo que te dicen los números. La visión general del recorrido, de la idea a la publicación, está en la página crear una app para iPhone.

Pasar de la página a la app publicada

Si respondiste las diez preguntas, ya hiciste el trabajo que muchos proyectos se saltan. Lo que sigue es construir la función principal, probarla en tu iPhone, conectar las suscripciones y preparar el expediente para Apple.

Ese recorrido es el del iOS Kit, en cuatro etapas para seguir a tu ritmo: la primera sirve para elegir la app que puede generar ingresos, su público y su precio, y tu documento de requisitos es el punto de partida.

¿No sabes si tu idea está lista para caber en una página? El diagnóstico gratuito te dice qué está frenando tu proyecto hoy y qué etapa abordar primero. Después, la página de inicio muestra cómo crear una app móvil a partir de este planteamiento, con Claude Code.

No te prometo ingresos ni publicación: Apple es quien aprueba y el mercado decide el resto. Sin el kit, esta plantilla te basta para empezar.

Preguntas frecuentes

¿Cómo redactar un documento de requisitos para una app móvil?

Haz que tu documento de requisitos quepa en una página: diez preguntas, una o dos frases por respuesta. Tratan sobre el público, el problema, la función principal, el modelo de negocio, lo que pasa sin cuenta, los datos que tienen que sobrevivir, la plataforma, lo que queda fuera de la primera versión, la señal de éxito y las restricciones. Si una respuesta pasa de dos frases, muchas veces es porque la decisión no está tomada.

¿Qué programa usar para redactar el documento de requisitos de una app?

Una simple nota o un archivo de texto en la raíz de tu proyecto: copias la plantilla y reemplazas cada línea. También puedes descargar la plantilla y su tabla de validación (.md), sin registrarte. Para guiar a una IA, guárdalo después en el archivo de contexto de tu proyecto.

¿Hace falta un documento de requisitos de 40 páginas para una app?

No, cuando creas tu propia app: basta con una página. Las plantillas de 40 páginas que hay en internet están escritas para un cliente que le encarga una app a un proveedor y necesita un documento contractual. Tú decides y construyes: tu página sirve para tomar las decisiones antes de programar y darle contexto a la IA.

¿Cómo darle tu documento de requisitos a una IA que programa?

Pon la página en el contexto permanente del proyecto: Claude Code lee un archivo CLAUDE.md en la raíz, Cursor tiene sus propios archivos de reglas. Cita la sección «fuera de la versión 1» cuando la IA se pase. Antes de una tarea grande, pide un plan que respete la página, sin programar todavía.

¿Cómo comprobar que una función respeta el documento de requisitos?

Agrega para cada función tres líneas: la acción, el resultado esperado y la prueba. La prueba puede ser un test automatizado para un cálculo o una verificación en el dispositivo para un recorrido. Anota también lo que no se probó, para no confundir una pantalla terminada con una función lista para usarse.

¿Qué no hay que poner en el documento de requisitos de una app?

Cuatro cosas que evitar: una guía de estilo completa, un calendario día por día, una arquitectura técnica detallada y funciones «para después» mezcladas con el resto. Al principio bastan unas cuantas capturas de referencia, y para el calendario basta un objetivo semanal. Todas las funciones para después van en la sección fuera de la versión 1.